3D Maze - It's in the title

Games
21

I did some investigating in Godbolt.

Sure enough, shifting an int64_t seems to result in a call to __ashrdi3 (64-bit variable asr) for any shift between 1 and 63, even multiples of 8. For a shift of 8 that will probably cost on the order of 100 cycles.

The situation is similar for uint64_t, but this seems to only happen with 64-bit shifts.

2 Likes
22

Accurate one +1.
(BTW the forum also supports polls)

The graphics are wonderful but the control scheme is a bit jarring; muscle memory makes me press up/ down for foward and back… :upside_down_face:

1 Like
23

Thank you! And I agree, but my hands were hurting trying to use the arrow keys so I had to change it lol. If I make a real game out of it I’ll probably have multiple control schemes

Boy, everyone loves the accurate one (I do too). I really hope I have enough cpu time + brains to make it work with the new things lol, we’ll see.

24

OK, I have finally added the feature I most wanted. I think I’m done for now. Just have to think of a game to make (maybe after a long break lol)

recording_20230918010308

(sprite art isn’t mine, it’s Tileset 1bit Color | OpenGameArt.org)

Runs at a pretty consistent 24fps. That’s about all I can get out of it; while not looking at sprites, it can still run at 30, but drawing over the same area of screen multiple times is really pushing it. Other than some tweaks and cleanup, I’m pretty much done. The source code is already out there, if anybody wants to make anything out of it, but I’m probably going to change some things and I’m sure there are bad bugs (I haven’t tested moving sprites): https://github.com/randomouscrap98/arduboy_collection/tree/master/arduboy_raycast3

Edit: Oh right, caveats if you use it:

  • Map is limited to 16x16 now (used to be 49x49 in the original), I wanted to make it more but there’s some precision issues with some of the speedups I’ve been adding. You can increase the map size but you’ll need to change some of the data types and things will get slower (map size doesn’t actually impact performance, it’s just the data type thing). I figure it’s big enough to feel big for such a small device, and you can always load new maps through doors, it’s basically instant (you might even be able to do it without a loading screen, honestly).
  • Sprite resolution can probably be increased, but I haven’t tried it. Honestly 16x16 is probably all you should do though, considering what would have to be done to support higher…
  • There’s no shading on the sprites, I might add it but it’ll probably tank performance
  • Sprite location precision is VERY LOW in order to condense the sprite definition. Otherwise they take up too much data. It should be high enough for most things, just something to consider: the location “resolution” is about 16x16 within one cell. I haven’t tried moving sprites, it may not even be an issue
  • Sprite depth sorting is insertion sort since the list is small. If you want to push 100 sprites or something (not even sure if it can), you’ll need to put a better sorting algorithm
  • Sprite collision detection is up to you but should be easy, it has nothing to do with the raycaster
  • Same with interaction, but again it should be relatively easy. I don’t plan on adding those to the example release (sorry!)
6 Likes
25

Ah I should post a demo

I spruced up the demo area and added examples of animated sprites and moving sprites. They both seem to work fine. Just walk out of the little starting area to get to the demo area. That’s the only place with sprites.

arduboy_raycast3.ino.hex (52.9 KB)

7 Likes
26

A blood sacrifice was made

recording_20230918185426

Back up to 35fps. It feels so good to see it run so well, my gosh. But about that sacrifice:

24fps storage:
image

35fps storage:
image

I mean it’s not THAT bad, but at 1300 bytes, I made it a precompile flag. So if you want to use the raycaster and need more program data back, you can turn off CRITICALLOOPUNROLLING and get all that back, at the cost of frames. In fact, there are several tradeoff precompiler flags that do similar things, such as the accurate vs. inaccurate textures (the 35fps was achieved with accurate textures, that’s the power of loop unrolling!).

I’m still working on cleaning up the code so it’s more easily reused, but as usual if you want to mess around with it, it’s https://github.com/randomouscrap98/arduboy_collection/tree/master/arduboy_raycast3

arduboy_raycast3.ino.hex (56.4 KB)

Edit: in reality, you’d probably want to run it at 30fps to leave overhead for game + enemy logic, but still…

EDIT2: Even after all these years, I still make off-by-one errors. I updated the hex, if you have an older version that crashes simply by using the menu it should no longer do that

6 Likes