Interesting. Why 2,147,483,647? It seems such a specific number! Is there a reason for this particular amount, as in relating to other factors in the game's code?
Because the game stores the lemming count in a 32-bit signed integer. It's nothing to do with it being a 32-bit app specifically - a 32 bit app could still have a signed (or unsigned) 64-bit integer, and that's without going into floating-point values which work a bit differently.
On this note - an
unsigned integer has the same
amount of possible values as a same-bit-count signed integer; just the range is different. In the case of 32-bit, a signed integer can have values from -2147483648 (ie: -(2^31)) to +2147483647 (ie: (2^31)-1), for 2^32 possible values. An unsigned integer still has 2^32 possible values, but instead they range from 0 to 4294967295 (ie: (2^32)-1).
A 64-bit integer would instead have 2^64 possible values. However, aside from that it's clearly not going to matter in any real-world situation, increasing the lemming count to a 64-bit value probably wouldn't achieve anything useful here - it's very likely the TObjectList (a Delphi structure that contains list of "objects" (in the programming sense), in this case, the lemmings) uses a 32-bit integer to count how many objects it contains, so we'd still get issues. And even if not - we'd exceed the available memory for a 32-bit app before we got anywhere near 2^32 lemmings; a full change to 64-bit app would be needed to avert that.
This level features multiple hatches, because I wanted a random Lemming to come out from a different hatch (hence the title One in a Million), requiring a glider assignment. There are therefore 17 hatches in this level - would this slow things down?
Yes, but the impact would be almost negligable compared to the thousands of lemmings. Lemmings are complicated to process. Objects are not.
Drawing objects is processor-intensive, but they aren't actually being drawn during a frameskip. The game does have to quickly check each object to see if it needs anything, but in the case of an entrance, that's all it needs to do with them once they've opened. (Spawning the lemmings happens seperately from the general object update code.)
On a side note, the lack of a need to draw anything during frameskips (aside from updating the terrain layer with destructive / constructive skill masks; it also takes save-states every so often but this is just a blind "make a copy" without doing any actual new drawing) is why processing times for a frameskip don't really differ much between low-res and high-res, even though high-res does slow down live gameplay. Indeed, on a level with not so many lemmings, I tried out a 1mil frame frameskip once; high-res did take a bit longer to process but the difference was basically negligable.
Just in case, I've also made a level which is simply 1,000,000 Lemmings spawning from a single hatch and falling directly into an exit, simply titled Lemmillionism.
No-longer-existing lemmings (whether due to death or exiting) are less processor-intensive than still-existing ones, but they still have an impact. There are technical reasons the game still needs to know about them.
I've noticed that, upon cancelling these levels, the post-screen only displays up to 4 figures for saves/save requirement, so... would the level be "passed" if 9999 saves was reached?
No. That's purely a cosmetic thing. Looks like you already answered that with your 76312 saved situation, though. (Interestingly though, vanilla Lemmix
does have a bug along these lines. It calculates the %, rounds it off, then determines pass or fail based on the rounded % instead of the actual saved count / requirement. This means for example, if you had a level with 200 lemmings that required 199 to be saved, the player could save 198 and still pass the level, as both of these come out as 99% in Lemmix. This bug was fixed
very early in NeoLemmix.)
