release rate calculation

[0xdeadbeef]

Hi there,

I wondered if someone can help me out with the correct formula of the release rate.

First of all, rt's LVL file format description says:

Release Rate      : 0x0000 is slowest, 0x00FA is fastest

This seems to be wrong, as obviously 99 (0x63) is the highest value. No official level seems to have a lower value than 1 or a higher than 99, so I'd guess the official range would be 1..99.

Then I found a formula in the web that says to release a new lemming every (3+(100-speed)/2) time steps, where one time step is  60ms (3s/50).

Then again, the windows version seems to run a little slower. If I trim the formula's offset value to 10 instead of 3, the release rate seems to be more or less on par with Lemmings for Windows, but the lemmings on the windows version move a little slower than one pixel each 60ms. So I guess the problem might not be the formula, but the update speed of Lemmings for Windows. I also have the impression that the lemmings moved a little faster on the Amiga version than they do on the windows version.

Is the windows version "too slow" Or is the formula wrong or even the 60ms time grid?

Can anyone comment on this?

[ccexplore]

All I know is that in the DOS version, the formula is that for a given RR, the number of frames from one release to the next is:

(99 - RR) / 2 + 4

Where the division is the standard truncating integer division (so for example RR 99 and RR 98 acts identically).

This means for example, at RR 99, it'd be "release, wait, wait, wait, release, wait, wait, wait, release, ..."

I don't know what the frame rate is though on the DOS version, although to a large extent this mostly does not matter, since most aspects of the game mechanics is based off of number of frames rather than absolute time.

[0xdeadbeef]

The frame rate is quite important obviously, since for a time grid of 30ms, the game moves twice as fast as with a grid of 60ms.
Even the small difference between the 60ms I use and the obviously lower value in Lemmings for Windows leads to a noticeable different gameplay.
First of all, a smaller timer period for one frame means a higher release rate and faster moving lemmings: so you have to react faster on the one hand (which makes the game harder). On the other hand, lemmings can reach the exit quicker, which would make the game easier if the time out was really an issue (which it isn't for most levels).
Also lemmings are closer together and it's harder to pick a single lemming. Indeed the distance of lemmings, specially at high release rates (like 99), makes it quite easy to notice very small differences in release rate.

[ccexplore]

The frame rate is quite important obviously, since for a time grid of 30ms, the game moves twice as fast as with a grid of 60ms.

Let me clarify what I meant.  Obviously the frame rate will affect the gameplay a lot since it is basically equivalent to game speed.  However, it has no impact in terms of how the gamestate (eg. position and action of lemmings, state of non-constant traps, etc.) evolves from frame to frame, since the game mechanics regarding those matters are all expressed in terms of frames, not seconds.  It is the latter that I am emphasizing in my earlier post, when I said the frame rate is of lesser concern.

It is not that difficult to simply experiment around with various different frame rates until you achieve one that seems closest to whatever standard you are using (Windows, DOS, Amiga, etc.).

Also lemmings are closer together and it's harder to pick a single lemming. Indeed the distance of lemmings, specially at high release rates (like 99), makes it quite easy to notice very small differences in release rate.

Distance between lemmings should not be affected by the frame rate, if it is then your game mechanics is not correct.  As I said, most aspects of the game mechanics should be based on frames rather than any particular absolute time unit.

You need this in particular if you are planning to support the SuperLemmings feature in ONML Wicked 2(oh wait, I bet you never experienced that level since they left it out of WinLemm).  On that level, the game mechanics is the same except the framerate doubles (or maybe more).  So everything (including the game clock countdown) runs twice as fast.  If your walking speed is based on absolute units of time rather than frames, it will not be possible to implement this feature.

[0xdeadbeef]

Let me clarify what I meant.  Obviously the frame rate will affect the gameplay a lot since it is basically equivalent to game speed.  However, it has no impact in terms of how the gamestate (eg. position and action of lemmings, state of non-constant traps, etc.) evolves from frame to frame, since the game mechanics regarding those matters are all expressed in terms of frames, not seconds.  It is the latter that I am emphasizing in my earlier post, when I said the frame rate is of lesser concern.

Sure.

It is not that difficult to simply experiment around with various different frame rates until you achieve one that seems closest to whatever standard you are using (Windows, DOS, Amiga, etc.).[/color]

That's exactly my problem. I experimented with the release rate and the frame rate, but somehow I never came out the same as the windows version, which is the easiest for me to check. Either the lemmings had a different distance or they simply came out faster or slower. So I hoped the frame rate and release rate were known for at least one version. Since if the windows version uses the DOS release rate, it obviously has a different frame rate than 3/50.

If I think about it, I could imagine that the original (European) versions of Lemmings (especially the Amiga version) really had a PAL-based frame rate of 3/50 frames per second. Surely the (C64/Amiga/ST) NTSC ports already had a different frame rate, like 4/60 which was then taken over by the dos and windows ports (since 50HZ was never supported by PCs). Most probably they adjusted the release rate as well to compensate for the difference in frame rate, which sums up quite a little over a minute or so.
This would explain, why the lemmings on the (PAL) Amiga version move a little faster (3/50 frames per second -> 60ms per frame) than those on the dos/windows version (4/60 frames per second -> 66ms per frame).

Distance between lemmings should not be affected by the frame rate, if it is then your game mechanics is not correct.  As I said, most aspects of the game mechanics should be based on frames rather than any particular absolute time unit.

Ok, true. A misinterpretation on my side. A different distance hints on a different release rate calculation in the windows version.
I'm beginning to think it uses a different frame rate AND a different release rate calculation. I will check with my 66ms theory

You need this in particular if you are planning to support the SuperLemmings feature in ONML Wicked 2(oh wait, I bet you never experienced that level since they left it out of WinLemm).  On that level, the game mechanics is the same except the framerate doubles (or maybe more).  So everything (including the game clock countdown) runs twice as fast.  If your walking speed is based on absolute units of time rather than frames, it will not be possible to implement this feature.

I planned to support the fast forward feature of the Win95 version - though most probably not in the first release. This would do about the same (decrease frame period to increase game speed). However, at the moment, there are indeed a few things left which are based on time (e.g. the time and animation speed of objects in the level), but not the game mechanic itself.
Then again, my level INI files don't support any level specific "Superlemming" mode at the moment. I could add this of course if there's demand for it Still, I'm most probably missing the level which uses this feature if it was missing in the Win95 version.
But I'll put it on my (still pretty large) "to do" list.

[0xdeadbeef]

A little update after messing around the last hour: the release rate of 4+(99-RR) seems to fit perfectly, judging the lemmings' distance.

However, after some measuring and testing, I can clearly say that the timing of the Win95 version is completely messed.
I found it out differently, but the most obvious hint is that the game time actually runs much too slow. If one minute passes in real time, only about 44 seconds pass in WinLemm game time. This means that a "WinLemm second" is 1.36 seconds in real time.

If you multiply my assumed period time of 66ms (4s/60) with the factor 1.36, you'll get a period time of about 90ms. Further testing showed that this seems to be almost exactly the period time that WinLemm uses.

Yeah, well. I think I'll stay with either 60ms or 66ms.

[Leviathan]

Is it possible to hex edit a .lvl file and increase the RR to a value more than 99 like it's possible to enable superlem mode that way?

[0xdeadbeef]

Definetely not, since Superlemming mode - as I understand it - increases the update rate of everything. This includes the release rate, but also the animation and movement speed and even the game timer. Vice versa, increasing the release rate to values higher than 99 will only increase the release rate, maybe it's not even working because it's limited internally. The release rate is only displayed with 2 digits, so I guess, the different versions will either limit this value to 99 or have show display corruption.

By the way:I just added a "fast forward" mode and it works fine. Only the icon is missing...

[ccexplore]

A little update after messing around the last hour: the release rate of 4+(99-RR) seems to fit perfectly, judging the lemmings' distance.

That would correspond exactly to the formula I gave for the DOS version, after accounting for the lower resolution on the DOS version compared with Windows.

However, after some measuring and testing, I can clearly say that the timing of the Win95 version is completely messed.
I found it out differently, but the most obvious hint is that the game time actually runs much too slow. If one minute passes in real time, only about 44 seconds pass in WinLemm game time. This means that a "WinLemm second" is 1.36 seconds in real time.

That isn't necessarily messed up, I never bothered to measure the game time of Amiga or DOS Lemmings against real time, so they might differ as well.  In fact, it's almost guaranteed that at least one of them does not follow real time, because on levels with tight time limits, for example "Just a Minute (Part 2)", some solutions that work in DOS version times out on the Amiga.

It's generally accepted in gaming that game time does not correspond exactly to real time.  Often people don't even realize it during play.

Yeah, well. I think I'll stay with either 60ms or 66ms.

I will advise to use a speed that matches the Amiga version.  The main rationale being that for the level "Just a Minute (Part 2)", there is good indication that the easier solutions that work in DOS version but times out on the Amiga likely indicates that such easier solutions are not intended to work, that such solutions should in fact time out like in the Amiga.  Thus if your game clock runs slower, it would be violating the spirit of the level (unless you choose to modify the level to compensate).

On the other hand, if your game clock ends up faster than the Amiga version, then you should test out that level to make sure it remains doable.

[0xdeadbeef]

That would correspond exactly to the formula I gave for the DOS version, after accounting for the lower resolution on the DOS version compared with Windows.

No, sorry my fault. Indeed I use "8 + (99 - releaseRate)" since I update at the double refresh rate to compensate for the doubled resolution (don't ask). To avoid confusion, I wanted to reverse this value for discussion to avoid confusion, but only divided the first part by two.
So indeed my "8 + (99 - releaseRate)" at doubled frequency means the same as "4+ (99-releaseRate)/2" at normal frequency.

That isn't necessarily messed up, I never bothered to measure the game time of Amiga or DOS Lemmings against real time, so they might differ as well.  In fact, it's almost guaranteed that at least one of them does not follow real time, because on levels with tight time limits, for example "Just a Minute (Part 2)", some solutions that work in DOS version times out on the Amiga.

Interesting. Yet, if a game tells me that I have 5 minutes left, if I can nearly use 7 minutes, I would call this a messed up timing.
If my theory is right and the PAL Amiga version used 60ms per period, it would have most probably used 17 ticks for one second. So one minute would be 61.2 seconds. With 66ms per second and the same number of ticks, it's already 67.32 seconds.
Assuming, that only the time resolution was changed, Amiga PAL and NTSC (or DOS/WIN) versions would differ by about 6 seconds per minute. However the Windows version is off by 20 seconds or so.

It's generally accepted in gaming that game time does not correspond exactly to real time.  Often people don't even realize it during play.

I don't really like that idea to be honest. Time will be exact in my port. Probably I will give the level time in seconds, so levels can be "fine tuned" to the second, without messing around with the length of a second.

I will advise to use a speed that matches the Amiga version.  The main rationale being that for the level "Just a Minute (Part 2)", there is good indication that the easier solutions that work in DOS version but times out on the Amiga likely indicates that such easier solutions are not intended to work, that such solutions should in fact time out like in the Amiga.  Thus if your game clock runs slower, it would be violating the spirit of the level (unless you choose to modify the level to compensate).
On the other hand, if your game clock ends up faster than the Amiga version, then you should test out that level to make sure it remains doable.

I'd guess that the clocks in all versions run (more or less) slower than real time. Mine will run normally (no FF, no Superlemming) at real time, so it will probably be faster, not slower. However the difference to the Amiga version should be minimal (1.2 seconds per minute, if my assumptions are correct).
If people will complain about certain levels in the beta testing phase (hint  ;D), I will patch the level time to be a little longer.