1
Other Projects / Re: Golems — a DOS Lemmings game engine
« on: May 09, 2024, 03:47:41 AM »if a terrain piece has a pixel that uses one of the fixed 8 colors, that pixel will be visible but nonsolid.I haven't tested it, but Golems should have this implemented at least half correctly. It uses the most-significant bitplane for terrain existence, so gameplay should be correct. It probably does not currently display the phantom terrain, however.
One thing that would be nice - it's possible to set a page so that a tap and hold on mobile doesn't get treated as a right click (ish).This should be the case already? The game screen area has touch-action: none;, which should suppress that. Maybe I need to apply it to the black area outside the game screen as well in case the touch is just outside the game screen?
The smoothness of the rewind feature is particularly impressive, might I ask how you achieve this in Golems?The game takes a snapshot of the game state every 17 frames (1 second of game-time). Stepping back one frame is accomplished by going back to the previous game state snapshot and stepping forward however many frames necessary to end up one frame back.
All those snapshots would eat up memory pretty quickly, so I added a super fast/simple algorithm for compressing the terrain bitmap. Any snapshot older than the latest snapshot gets compressed. The game holds on to a copy of the original terrain bitmap to reference. The compression algorithm produces a data stream that can be interpreted according to the following algorithm:
Code: [Select]
Set `refCursor` to the first pixel in the reference bitmap.
Set `dstCursor` to the first pixel in the destination bitmap.
While `dstCursor` is not at the end of the destination bitmap:
Read a 16-bit unsigned integer from the stream and store it in `sameCount`.
Read `sameCount` pixels from `refCursor` and write them to `dstCursor`; `refCursor` and `dstCursor` advance by `sameCount` pixels.
Read a 16-bit unsigned integer from the stream and store it in `diffCount`.
Read `diffCount` pixels from the stream and write them to `dstCursor`; `dstCursor` advanced by `diffCount` pixels.
Advance `refCursor` by `diffCount` pixels.
The same compression scheme is applied to the effect map as well. This way each snapshot basically only needs to store the accumulated changes to the terrain and effect maps along with the (uncompressed) creature states, gadget states, and various other small bits of game state.It could probably be smarter and occasionally choose to create a new reference bitmap if the terrain changes a lot.
Also, is this open-source?Not yet, but probably eventually. But it is .NET and not obfuscated, so you could use ILSpy to easily peek at the code.