Lemmings in html-in-canvas release

[VorticonCmdr]

I am guessing that everybody in this forum knows https://www.elizium.nu/scripts/lemmings/ and the various web versions there are. Well today I made my take on it public which I was working on for the last two weeks or so.

You are the first to hear about it and I would love to hear your feedback!

Some things I did which hoping to give back to the community I learned so much from:

• video modes: VGA/EGA/CGA/Tandy video mode
• music modes: Amige (.mod)/CDI-I (.mp3)/Adlib/Tandy
• sfx modes: Adlib/Tandy/? (OGG)
• a graphics pack editor (work in progress)
• a level editor inspired by the original level editor(work in progess)
• asset explorer
• exploded assembly viewer
• 2-player network mode (not playtested)

I am sure there are still some bugs but I simply couldn't wait any longer I had to tell/show you guys. So without much further ado: Github and Github pages

[Simon]

Hi! I believe that the first Github link should point to VorticonCmdr/lemmings, not to the github.io.

Networking mode against myself works in Chromium after enabling the HTML-in-Canvas global option, which is disabled by default.

On your readme, you explain how you support efficient rewind in singleplayer by taking savestates and recomputing. This is the most performant solution that we know. Lix was the first to do that in multiplayer, then NeoLemmix implemented it for singleplayer, and then Lix offered it in singleplayer.

Your multiplayer assignments during netplay have significant delay, over half a second. I think that such input delay is a problematic way of combatting lag. Clones (another Lemmings-like) and Starcraft do it like this, too, but it's more acceptable in Starcraft (where commands should happen ASAP) than in Lemmings (where it's a problem when commands happen too early). Have you considered instead to rely on the efficient recomputing from singleplayer? When the local player receives a delayed command from the opponent, the local player inserts it into his own history, then recomputes. I suspect that recomputation makes it harder to catch cheating, but it makes for better flow.

There is a third, novel way of combatting lag: Neon Swarm (Lemmings-like in Lockstep Arcade) makes terrain modifications and blockers immediate for the local player, and has a ~1-second delay before they materialize for the opponent. From the local player's view, his own young builder bricks are semitransparent until they're old enough to affect everybody.

Do you strive for exact 1991 Lemmings 1 two-player physics, bugs and all? Then you can't use such immediate local impact with delayed remote impact, and I'd suggest savestates and recomputation instead. It really depends on what exactly you envision. E.g., the 1991 physics have a possibly unwanted first-player advantage because his lemmings spawn before the second player's lemmings.

-- Simon

[VorticonCmdr]

Hi Simon, thanks for the great feedback. To be honest 2-player came after the fact I noticed that I now have everything needed to implement it. You gave me a lot to think about.

[The Tomato Watcher]

Hello VorticonCmdr, and welcome to the Forums since I hadn't said that yet. 

I've spotted some graphics and sound issues, and apologies if this seems nitpicky; I read the documents to check what you were and weren't aware of. First, the EGA graphics. The terrain colors are slightly different to how they appear in-game, and the lemming and object colors are completely and totally wrong, and I can see exactly how this happened! Colors 0-7 in the palette ARE the standard colors (except color 7) shared across all graphics sets (though it is absolutely correct that they aren't the low-intensity CGA palette). That 16-byte copy you mention does NOT copy starting from the offset that you label "ega_custom" and copies through to the end of "ega_standard"; it copies from "ega_standard" through the array that you labeled "ega_preview", because those "ega_preview" colors are actually the colors used in the levels. The "ega_preview" entries in the dirt set example match up with the terrain colors seen in-game (screenshot below), and it only contains CGA colors, which is important since EGA does NOT support non-CGA colors in 200-line video modes, which Lemmings uses during a level; thus the "ega_custom" colors could not possibly be used in a level.



Now for the AdLib sound. It's pretty good overall, but the tick rate for the music driver isn't correct. player.asm's timing loop simply is not accurate to what the actual game does. As far as I know, in all cases EXCEPT when running VGALEMMI with the "For High Performance PCs" or "For an IBM PS/2 Machine" options selected, the game programs the PIT to fire at a rate of 72.8261 Hz, which it uses to help throttle the gameplay speed, and the music is also driven at that rate. (The aforementioned exceptions seem to synchronize with the VGA video rate(?) independent of the PIT, which results in the music playing very slightly slower, but I am NOT an expert on how the High Performance mode works, so take that with a grain of salt.)

Next, the Tandy sound. The actual game uses the same 72.8261 Hz tick rate to drive the Tandy sound as it does to drive the AdLib sound. Additionally, the PSG clock speed is also incorrect, specifically half as fast compared to what it should be. There's some significant sequencing issues in the Tandy player as well, resulting in extreme desync and misplaced effects, though I imagine you're aware of that even if I didn't catch any explicit mention of that in your document. I also notice, thanks to Lemmings Tune 18, that the software PSG is using more than 10 bits for the period of the square channels, as that tune attempts to play notes that would require an 11-bit period to play, resulting in garbage pitches on the real chip as the most significant bit is discarded. Don't ask me why the tuning table contains 11-bit periods in the first place.

Finally, the PC Speaker sound. First of all, I had no idea there were unused sounds in the PC Speaker driver, so it was very cool to listen to them. However, the sounds seem to play much too fast. This is easiest to hear with Patch 12, which is triggered in-game when a lemming explodes (recording below). Unfortunately in this case, I'm not entirely sure what the tick rate should be; the driver certainly isn't getting called at 72.8261 Hz, as that would make the sounds play even faster. Sorry!



Hope this is helpful at all!