[SUG][PLAYER] Customisable Fast-Forward Speed [RESOLVED-CAN BE CLOSED]

[WillLem]

It's come up a few times that "waiting around" for Lemmings once a level is complete is sometimes an issue, even with smaller lem counts. Also, there are times when you want to move ahead quickly, but the Frameskip buttons can sometimes be unpredictable (that's not a complaint - I love my custom Frameskip buttons and use them all the time).

However, not everyone uses custom Frameskipping and may enjoy the use of a TURBO button!

[ericderkovits]

I know when watching replays and the level is long it can a while to watch. I always turn off high resolution mode when watching packs. I would like to see a turbo button to speed up replays. maybe 2x the speed. just not as fast as LIX's turbo that Is extremly fast. that is like 10x. that is so fast I can't even see what is happening.

[namida]

I explained in your fast-rewind suggestion topic, as part of why that feature isn't viable, how fast forward works.

What it comes down to is - for fast forward, in reality if the game was left to run as fast as your PC could handle, it'd be, well, a lot faster than it is now. There's code specifically to limit the speed; fast forward simply increases that limit (in most cases, the speed limit is still the limiting factor, though in intensive situations and/or weak PCs* you might find that fast forward mode is further limited by your PC's power).

* what really matters is RAM speed and single-core CPU performance

Leading on from that - there's no reason I couldn't define an even-higher limit. The one thing to be aware of is I suspect that if it were even faster than current-FF, most PCs would not actually reach the limit. It's probably best that some limit still exists, though - WinLemm got caught out by not accounting for that faster PCs would exist in the future, let's not make the same mistake in NL.

But yeah - if there's interest in an even-faster-forward, and those who are interested understand that the available processing power on their PC might limit whether the full faster-forward speed can actually be reached - then sure, I can look at this. I could perhaps even look at letting the player define outright custom fast-forward speeds.

For the record - one reason that Lix can achieve an even-faster-forward without slowdown is due to differences in graphics rendering. NeoLemmix relies on the CPU for graphics rendering; Lix offloads it to the GPU. It would take close to a full rewrite to achieve the same in NeoLemmix, which is why it has not happened. There's advantages to both - the GPU is literally built for this sort of stuff so does it much faster, and of course, sharing the load generally means things get done faster. On the other hand, using the CPU allows for a fine level of control that isn't directly possible on GPUs (at least, not without methods that negate the speed advantages), although I can think of ways to emulate much of what NL does in this regard - at the cost of needing more GPU memory, though I suspect even then NL's requirements would be very low by modern standards - the real issue isn't the capabilities, it's the effort that would be needed to change it.

[WillLem]

I explained in your fast-rewind suggestion topic, as part of why that feature isn't viable, how fast forward works.

To be fair, assigning a Hotkey to {Time Skip -4 Frames} and holding it down achieves the desired result anyways - I mentioned this in the fast-backwards topic and then Minim commented saying basically the same thing!

I could perhaps even look at letting the player define outright custom fast-forward speeds.

This would be awesome! One thing I've noticed since playing NL on my new laptop is that the FF speed is quite a few fps faster than it was on my old machine - the ability to customise it to suit your setup would be great.

Just a thought - is there a way to FF without the timer being affected? If so, maybe there could be an in-game end-user-assigned Superlemming mode, where players can toggle {FF/timer-not-affected/no-pause-allowed} and play levels in the resulting state. That way, anybody who enjoys the feature can use it for challenges, etc, and it isn't quite the same as allowing users to create levels with enforced Superlemming mode as a gimmick.

EDIT: I realise that this is not going to happen, given NL's gameplay philosophy and the time needed to be devoted to more important features. But, realistically, would such a feature be easy to implement code-wise, for someone that wanted to do a custom version of NL?

one reason that Lix can achieve an even-faster-forward without slowdown is due to differences in graphics rendering. NeoLemmix relies on the CPU for graphics rendering; Lix offloads it to the GPU

Thanks for the CPU/GPU explanation, it's interesting to learn about the advantages and disadvantages for each. Since NeoLemmix is heavier on the general processing given its many features, it makes sense for it to be a more CPU-based game. That said, the recent introduction of hi-res mode and the known issues with the HQ minimap may call for some GPU workload. Is there no way to, for example, assign just the processing of the HQ minimap to the GPU without affecting too much else?

That said - out of interest I just tested the HQ minimap with the most graphics-intensive level in Lemminas on my new laptop, and it handles like a boss! I'll keep the HQ minimap enabled for a while and see how it fares on the new setup.

[namida]

This would be awesome! One thing I've noticed since playing NL on my new laptop is that the FF speed is quite a few fps faster than it was on my old machine - the ability to customise it to suit your setup would be great.

This will be the case that on your old laptop, the laptop's speed was the limiting factor, while on your new one, you can actually reach the point the speed limiter kicks in.

Just a thought - is there a way to FF without the timer being affected? If so, maybe there could be an in-game end-user-assigned Superlemming mode, where players can toggle {FF/timer-not-affected/no-pause-allowed} and play levels in the resulting state. That way, anybody who enjoys the feature can use it for challenges, etc, and it isn't quite the same as allowing users to create levels with enforced Superlemming mode as a gimmick.

Almost anything you can name is possible, but this wouldn't be very easy. As explained, fast forward works by increasing the frequency of frame updates. The in-game timer is directly tied to this - 17 physics updates = 1 second on the game clock. One possible "hacky" method would be that if, say, this fast-forward mode is 4 times as fast, it adjusts to a rate of "68 physics updates = 1 second".

However, I would note - the actual Superlemming mode from ONML (and older NL) increases the speed of the timer, too. It remains 17 physics updates = 1 second; just at a higher frame rate.

Thanks for the CPU/GPU explanation, it's interesting to learn about the advantages and disadvantages for each. Since NeoLemmix is heavier on the general processing given its many features, it makes sense for it to be a more CPU-based game.

Both games would use the CPU to process physics, user input, etc. The GPU would purely be used, if at all, for graphics rendering. The biggest issue with that for NL would be things like the state-based recoloring - I'm not sure if it's possible, let alone how easy or fast it would be, to recolor on-the-fly on the GPU in the same manner NL does on the CPU. However, that doesn't mean there isn't a way at all - one workaround would be to, when loading a level, split the lemming sprites into multiple images - one being the pixels that never get recolored, then one image for each area that can be recolored. This would presumably be done on CPU. Then, create pre-rendered recolored versions of each individual area, in each possible color it could be recolored to in the current level. This could be done on either, though I don't think there would be a significant speed advantage to either here (simply due to how relatively small the task is), so it would just come down to "which one is easier to do it on in the framework being used?" And then finally, when rendering in-game, each lemming would be reconstructed from these split images, using the appropriate recolors where applicable - this part would absolutely be a GPU task (it's no different from any other 2D GPU rendering except in terms of "what images are being fed into it", after all - all the fancy stuff was one I prepared earlier (reference intended), now it's just a matter of "pick the right images and draw them").

Is there no way to, for example, assign just the processing of the HQ minimap to the GPU without affecting too much else?

Not as simple as it might sound. The HQ minimap is generated, of course, from the overall level image. This image updates each frame, so to draw the HQ minimap, we'd have to generate it from a new image each frame. While this is not something one might expect - transferring image data from the main system RAM (which is what the CPU would be using) to the GPU memory is one of the slowest operations of all (usually, all images would be loaded to the GPU's memory when loading, and used from there as necessary, rather than regularly loaded).

Of course - I'm not sure how severe the impact of this would be. Tiel Attack uses such a workflow - it renders its graphics internally with custom CPU-based code, then transfers it to the GPU for output onto the screen each frame. Even on my fairly-weak 2-in-1 laptop, the limiting factor to speed is still the explicit frame rate limit coded into the game, not the speed of this CPU->GPU transfer. However, it should be noted that the image being transferred is only 320x180 - which is only slightly larger than a default-size NL level in low-res. NL levels can get far bigger than that.

The flipside again is in NL's case, this image would probably then have to be transferred back to the CPU yet again, because the CPU-based graphics code even handles the final output to the screen in NL. (This is not the case in TA, where the screen image gets transferred to the GPU, which then directly outputs it to the screen.)

[WillLem]

However, I would note - the actual Superlemming mode from ONML (and older NL) increases the speed of the timer, too. It remains 17 physics updates = 1 second; just at a higher frame rate.

I wonder whether the resulting speed was also hardware-dependent, or whether it was set to a fixed speed somehow.

And then finally, when rendering in-game, each lemming would be reconstructed from these split images, using the appropriate recolors where applicable - this part would absolutely be a GPU task (it's no different from any other 2D GPU rendering except in terms of "what images are being fed into it", after all - all the fancy stuff was one I prepared earlier (reference intended), now it's just a matter of "pick the right images and draw them").

Would you say it's simpler keeping all workload to the CPU, i.e. if you were starting NL from scratch, would you still opt to go fully-CPU or would you split the load across CPU and GPU wherever possible? Also - just out of curiosity, what do you mean by the "fancy stuff"?

transferring image data from the main system RAM (which is what the CPU would be using) to the GPU memory is one of the slowest operations of all (usually, all images would be loaded to the GPU's memory when loading, and used from there as necessary, rather than regularly loaded).

This seems to suggest that it would be worse to use the GPU for HQ minimap rendering...?

Incidentally, the HQ minimap is still working like a charm on my new system. I haven't fully battle tested it in OBS yet, but I'll hopefully be recording another episode of "First Rank" soon so we'll see how it fares. I'd fancy its chances actually; my laptop is capable of recording a full-screen Dolphin emulation in OBS with no stutter or lag, as long as it's got a decent amount of battery % - once it drops below a certain %, it seems to just stop allowing certain programs to use as much of the CPU/RAM. There's a very sudden and noticeable drop once it gets to about 10%.

Anyways - regarding the original topic, I'm happy to update the suggestion to "Customisable Fast-Forward Speed" following your suggestion that this might be possible (changed the title). Hopefully others will be interested in this feature as well; please do add a poll if it'll help.

[namida]

Would you say it's simpler keeping all workload to the CPU, i.e. if you were starting NL from scratch, would you still opt to go fully-CPU or would you split the load across CPU and GPU wherever possible? Also - just out of curiosity, what do you mean by the "fancy stuff"?

Having seen the limits that get encountered when trying to do it CPU-only, I would absolutely use the GPU as much as possible for graphics if I were rewriting NL now. Changing the existing code would be fairly close to a full rewrite of anything relating to graphics, which is why I haven't done so.

The "fancy stuff" I was referring to is the earlier-generated images (split by recolorable section etc).

This seems to suggest that it would be worse to use the GPU for HQ minimap rendering...?

It would be worse to use the GPU for the HQ minimap alongside the current code where everything else is done on the CPU. It would, by a long shot, be better to use the GPU for the HQ minimap as part of new fully (or near-fully) GPU-based rendering code.

Basically - the issue isn't "the GPU is bad for that task", it's "trying to make the two work together in the fashion (I believe) would be needed to use GPU for just the minimap, is bad for that task".

[Simon]

I agree with everything. The GPU is fast for drawing and for parallelized computation. It wants to do the same thing over and over. The CPU is fast for special computations or for many different computations. The CPU doesn't like context switching either, but it's better at switching than the GPU.

When something is in VRAM (video memory, the GPU operates with that), it's expensive to read it. It's fast to draw from VRAM bitmap to a different VRAM bitmap, or to the screen.

If you must remember what is drawn where, e.g., you want the CPU to compute physics on a VRAM Lemmings level image, consider carrying the physics representation in RAM, separately from the VRAM images. Carrying the same mutable knowledge in two independent places is a classical source of bugs; this is one price to pay for faster graphics.

Lemmings is special in that the physics and the graphics are so closely related. Other genres would lose more from being written purely with CPU graphics. I think Lemmings is very forgiving, and NeoLemmix is already performant on many machines.

Lix doesn't have skill shadows yet, they're elaborate to implement both nicely and fast. I have a crude version (with video) in a 2018 branch. It's possible to release that, but I feel like I should polish it more. I haven't done it in two years.

-- Simon

[namida]

Added a poll.

Note that I have added slow-mo as well as fast-forward into this. The reasoning here is simple - fast forward and slow-mo work in exactly the same way; they simply adjust how much delay is forced between frames when the game isn't paused. Allowing one but not the other to be customized as part of such a feature, would be more work compared to just letting it go both ways, and there's no downside to allowing both ways - so why not?

I'll also note - as this is completely a "you can ignore it if you don't like it" feature, the No votes are mostly to get an idea of proportion of users who want it - I won't be interpreting them as specifically "avoid doing this", only as a "there are people who don't care about this so may be better to focus on other things".

[WillLem]

Lix doesn't have skill shadows yet, they're elaborate to implement both nicely and fast. I have a crude version (with video) in a 2018 branch. It's possible to release that, but I feel like I should polish it more. I haven't done it in two years.

These look pretty good to be honest, but I can see that more refined versions are possible. For example, making it so the destructive blueprint only appears on the terrain that it will affect rather than the entire mask being shown.

Whatever you do, be sure to make these optional! I don't play Lix much at the mo but I keep meaning to - I'll likely make my next LP series Lix-based. It would be great to play through a few more levels and finally get around to reviewing the editor!

Edit Simon: This discussion continues in:
Skill blueprints a.k.a. shadows in Lix (old unreleased branch)

Note that I have added slow-mo as well as fast-forward into this

Brilliant! The more customisation possibilities the better. Slow-mo can be very useful as well, particularly when analysing a replay.

Just to clarify something - you seem to be suggesting that multiple speeds can be customised and used at the same time. Is this the case, or would it be more that the one speed could be customised, and it would always operate at the currently-specified speed?

[namida]

Just to clarify something - you seem to be suggesting that multiple speeds can be customised and used at the same time. Is this the case, or would it be more that the one speed could be customised, and it would always operate at the currently-specified speed?

Yes, my suggestion is to allow multiple custom speeds.

Fast-forward and slow-mo (as well as of course regular speed, which is "default", and pause, which is a special case that isn't handled solely by adjusting frame rate) already exist, so at the very least, I'd need to preserve "one fast speed + one slow speed". It isn't much more work to allow arbitrary, any-number-of-speeds, compared to allowing a fixed but more-than-one number of custom speeds, so it would make little sense to restrict it to just one.

It would likely work on a basis, similar to frameskips, of that the speed is configured as an attribute of a hotkey. If you press a hotkey with a different speed to current (for example, you're currently in 3x speed and you press a 5x speed key), gameplay would switch to the speed of the key you've pressed. If you press a hotkey with the same speed as current (for example, you're currently in 5x speed and you press a 5x speed key), you would go back to normal speed.

I don't see much point in taking this second part as far as "if you press the same key". If you have both F and G configured to "5x speed", and you were to press F and then G, it would go into 5x mode when you press F and back to normal when you press G - because they're the same speed, so it would detect (when you press G) "the user has pressed a alt-speed key that matches the current speed, so return to 1x speed".

I don't see any reason not to allow specifically creating a "1x speed" key. This would essentially just be a "cancel any alternate speed" key in practice, of course, but again - it's a case of "more work to prevent than to allow".

The one question is what to do with the panel fast forward button. Currently with only a single fast-forward speed, it only needs to match that. Likewise, if there were multiple pre-set speeds, one of these could be arbitrarily chosen. However, with customizable ones, there are some questions that arise:

1) Should it be possible to configure the speed of the button at all, or should it remain at the original, fixed speed?
2) If so, should it be independently configured, or tied to the hotkey configuration?
3) If it's tied to the hotkeys, should it use the fastest? Slowest? Median? Average?
4) And what should it do in the event the user has no fast-forward hotkeys configured? Or if all the user's alt-speed keys are slow-mo speeds?

5) Let's suppose the fast-forward button is, one way or another, supposed to give a 3x speed (just for the sake of example). The player has configured a hotkey that gives 5x speed. The player presses this hotkey, activating 5x speed mode. If the user clicks the Fast Forward key now, should gameplay switch to 3x speed (as would happen upon pressing a 3x speed hotkey at this point) or return to 1x speed (as it should be expected the click just toggles the mode off)?

[WillLem]

1) Should it be possible to configure the speed of the button at all, or should it remain at the original, fixed speed?

I'd suggest configurable for three reasons (two of which are opinion-based): 1) it avoids possible confusion as to what speed this button is supposed to be set up, 2) different user's setups result in a different speed when this button is pressed anyway, and 3) more customisation is always better.

2) If so, should it be independently configured, or tied to the hotkey configuration?
3) If it's tied to the hotkeys, should it use the fastest? Slowest? Median? Average?
4) And what should it do in the event the user has no fast-forward hotkeys configured? Or if all the user's alt-speed keys are slow-mo speeds?

To attempt to answer all three of these in one go, I'd suggest that the FF key has a default speed that can be independently configured. So - if it's set to 3x by default, the user can set it to be 5x if they prefer a faster FF speed, or 2x if they prefer a slower one (for example). Therefore if the user doesn't specify a button speed, it will always be 3x by default and not hotkey-dependent.

As far as I can tell, this keeps things simple, and also leaves NL behaving more or less the way it does now for players who don't care about FF speed customisation.

5) ...If the user clicks the Fast Forward key now, should gameplay switch to 3x speed (as would happen upon pressing a 3x speed hotkey at this point) or return to 1x speed (as it should be expected the click just toggles the mode off)?

This one's a bit trickier.

My instinct is to say that it should switch to whatever speed the button is set to, and always override any hotkey-assigned speed. It's one of the reasons it helps to have a "pressed" graphic for these sorts of keys: if FF is activated, then no speed-related hotkeys should work, and it should always be easy to see if FF has been activated. This would keep things the most simple.

So... if the FF speed is set to [Speed A] and the user has activated [Speed A] via a hotkey, then the FF button would be "activated", and the speed would remain at [Speed A] until the user "deactivates" FF, at which point it would return to 1x. Conversely, activating the FF button from [Speed B] would result in [Speed A] being applied to the game (again, until the button is deactivated).

I'm not sure how that would work coding-wise, but from a user point of view it keeps things simple and allows the FF button to retain its importance as a feature of the panel.

EDIT: It appears I'm the only person so far who's interested in this feature! Anyone else up for custom speeds? Slo-mo in particular could be extremely useful.

[namida]

2) different user's setups result in a different speed when this button is pressed anyway

If you're meaning "currently", then this is not a meaningful reason. Yes, a weaker PC might give slower FF - and that will remain true even with customizable speeds (perhaps the impact could be reduced with an "only render every 2nd frame" setup or similar, but let's worry about that later once we've got adjustable speeds working in general). However, the actual speed cap that applies in FF mode, is the same regardless of one's setup. If you were to compare the bare weakest PC that can reach the speed cap, and the world's fastest supercomputer (ignoring the question of whether it's software-compatible, of course), they would run at the same FF speed - it's only when you reach the point of "too weak PC and/or too much going on" that it starts to slow down, and that is not due to anything NL is intentionally doing.

So... if the FF speed is set to [Speed A] and the user has activated [Speed A] via a hotkey, then the FF button would be "activated", and the speed would remain at [Speed A] until the user "deactivates" FF, at which point it would return to 1x. Conversely, activating the FF button from [Speed B] would result in [Speed A] being applied to the game (again, until the button is deactivated).

I'm not sure how that would work coding-wise, but from a user point of view it keeps things simple and allows the FF button to retain its importance as a feature of the panel.

Having it seperate altogether, let alone blocking other speed input keys, is out of the question. The only question is if, when any fast-forward mode is already active, should it act as a "change speed" (like different-than-current FF speeds would do via hotkey) or "revert to normal speed"?

Slo-mo in particular could be extremely useful.

Slow-mo in general already exists (on the same "there's one fixed speed for it" basis as FF); my mention of it here is purely to clarify that it would be included in any "adjustable speeds" proposal, rather than them purely covering FF.

[namida]

Okay, so it doesn't seem like there's much demand for this, so I'm not going to prioritize it. With that being said - for now I'll leave it open, in case opinions change, as there's no reason to outright reject it other than concerns about the effort involved.

[WillLem]

If you were to compare the bare weakest PC that can reach the speed cap, and the world's fastest supercomputer (ignoring the question of whether it's software-compatible, of course), they would run at the same FF speed

This is interesting. I wonder - how fast is the world's fastest supercomputer, and how is it so fast? It's my current understanding that adding more and more RAM and processing power to a computer can actually start to slow it down as it becomes more power-hungry and has more processing to do because it has so much stuff to deal with. There's probably a much better way of explaining it than that...!

Having it seperate altogether, let alone blocking other speed input keys, is out of the question. The only question is if, when any fast-forward mode is already active, should it act as a "change speed" (like different-than-current FF speeds would do via hotkey) or "revert to normal speed"?

In that case, I'd go with "change speed" to whatever setting has been configured for the FF button.

Slo-mo in particular could be extremely useful.

Slow-mo in general already exists

I know, I use it from time to time (normally when trying to figure out what Proxima has done when he's managed to get Lems to the top of a pillar without using any constructive skills, or something similar!)

I meant specifically that being able to customise the slo-mo speed could be equally useful.

Let's see some more interest in this feature!