powerup.type SloMo, please?

[Nash]

I imagine it'd be a really funny experience if the slow motion powerup lowers the pitch of sounds as well... :P oooohhhhh..... ssssshhhhiiiiiiittt......

[CaptainToenail]

I am proud to announce that I want this feature, now!

[Graf Zahl]

The way Doom uses the 35 tic system doesn't make slowmo look wierd. It's not really slow motion, just pauses in between. o_o

Correct - and conveniently ignored by the majority here.

A typical feature that sounds cool on paper but with consequences nobody will want to deal with.

[XutaWoo]

Out of curiousity, would this feature be added if DOOM was 30-tic and not 35-tic? If so, I can understand why you don't want to implent it.

[Graf Zahl]

The only way you can do SloMo is by halting the game for single frames. It would cause a very choppy experience that wouldn't look that great. Ever seen one of those modern movies with digital Slow Motion? It'd look like that.

[Xaser]

Another, slightly nerdier illustration: Take a .gif with pretty smooth animation and double the time each frame is shown. It looks almost like a slideshow in comparison.

[HotWax]

Couldn't interpolation be used to handle that? If everything's speed and frames were cut in half, but the game was still rendering at 60+ FPS, I don't think this would be as bad an effect as described.

Sure, with slowing the animations down it's never going to look as smooth as normal (does it even look that smooth now? ) but as long as you're not going any slower than 50% I can see any real problem there.

[Xaser]

In theory, it sounds that way, but the way Graf is describing doing the slow-motion is by slowing down the game's clock, so to speak, which would slow everything down, interpolation included. When you stop and think about it a bit, doing it the "proper" way is a frak-load more work than one would first think.

Here's a short list of just a few of the things that would need to be done to check for and implement a "proper" half-speed slow-motion mode:

• All ACS scripts would have to work in half-speed; that is, the delays have to be doubled.
• All actors' states would have to do the same thing: double delays, meaning countless more checks in the code every tic.
• Map actions, like doors, lifts, and polyobjects, would need to have their their speed cut in half.
• Logically, projectiles would need their speed halved as well, but this isn't even that simple. The entire physics engine would have to operate at half-speed, so falling, projectiles with gravity, and bouncing things would work right.
• Sound becomes a dilemma: Without pitch-shifting, some sounds (shotgun firing) would no longer match up with their animations, but the other extreme, pitch-shifting everything, sounds really strange after a while. If the latter method were chosen, the decision also has to be made whether or not random pitch-shifting would be allowed during slow-mo (which would mean even more code hacks to keep track of). Keep in mind that this would also have to be done for every single sound in the game, anywhere.

And I'm probably missing a lot more. Each of these involves a hack somewhere in the code to check for this, and if one tried to implement not just half-speed but variable slow-motion, this could easily become a nightmare to handle.

In summary, the simpler method would simply be to increase the length of time a single tic is, and since every calculation is done in that timespan, it's liable to look really choppy. As much as I love the idea (true Matrix mode, anyone?), it's sadly not going to happen for said reasons. Funny how I'm the guy saying this, now. Usually I'm the bitter opposition in these kind of cases.

[InsanityBringer]

Wait, it would affect interpolation? I thought Zdoom used a separate timer with no speed limits to do things like this (It animates textures too, which can go at rates faster than a tic, and more presice than a tic too.)

I might be missing a *huge*, important factor here, but doesn't the game timer control everything that happens within the game? If so I don't see a huge problem.

[Gez]

The renderer is disconnected from the gameplay engine. That's why texture animation don't pause.

[Graf Zahl]

Wait, it would affect interpolation? I thought Zdoom used a separate timer with no speed limits to do things like this (It animates textures too, which can go at rates faster than a tic, and more presice than a tic too.)

I might be missing a *huge*, important factor here, but doesn't the game timer control everything that happens within the game? If so I don't see a huge problem.

It wouldn't help because instead of interpolating A->B->C->D you'd interpolate A->A->B->B->C->C->D->D, which would look even worse than if the game wasn't interpolated at all because the choppiness became even more apparent.


Sorry, but not all good ideas are really doable.

[bagheadspidey]

In theory, it sounds that way, but the way Graf is describing doing the slow-motion is by slowing down the game's clock, so to speak, which would slow everything down, interpolation included. When you stop and think about it a bit, doing it the "proper" way is a frak-load more work than one would first think.

Yeah, that's pretty much how it looks to me. The game's clock is based on a constant tic rate (aptly named TICRATE) which is set to 35... At least 24 other constants are defined based on TICRATE, and these timing constants are referenced all over the place in the code. For this to ever work, all of these constants would have to be replaced with new variables or functions to calculate timing. Every place in the code that refers to the old timing constants would have to be updated to use the new timing system. Almost every aspect of the game would have to be tested before a commit. In other words, not going to happen any time soon.

[CaptainToenail]

How do more modern games do this then? Do they have these 'tic' rates too?

[Enjay]

My guess is that it's not so much "being modern" that is important as having such a feature be part of the engine structure from the early planning stages. Trying to bolt something as fundamental as changing the game speed on to an already established engine is logically more difficult than including it as a feature as you are coding the engine.

[Gez]

How do more modern games do this then? Do they have these 'tic' rates too?

Games that don't use an internal "tic" use the CPU's own clock. Which has a funny side effect when you try to play them again fifteen years later on a computer that's a thousand times faster...