Variable Ticrate

[DoomKrakken]

I propose a change to make it so that the ticrate for GZDoom is not a constant, but rather is a modifiable global variable, which can cause all actors to be affected by the speeding up or slowing down of the game. This can allow for better control over time-dilating effects in many mods, as opposed to using the PowerTimeFreezer "hack".

[_mental_]

No means NO.

[DoomKrakken]

Well, shoot.

That really sucks.

[Graf Zahl]

Seriously, the main purposes it's going to be used for would be increasing the tic rate to make "smoother" animations. But when you consider that it'd run the entire playsim at that accelerated speed it'd be very detrimental to performance.

[DoomKrakken]

What I wanted it for was to have better control over time dilation in the game. Like with replicating the effects of Saving Throw (from DOOM) or Chrono Strike (from DOOM Eternal). So, not a larger ticrate, but a smaller one.

[Apeirogon]

Seriously, the main purposes it's going to be used for would be increasing the tic rate to make "smoother" animations. But when you consider that it'd run the entire playsim at that accelerated speed it'd be very detrimental to performance.

And how hard it would be to add feature for smoother animation, without touching tick rate at all? Like, change sprite frame/name during tick, instead of left it "static"?

Saving Throw (from DOOM) or Chrono Strike (from DOOM Eternal)

Slow-mo/bullet time like? If yes, you can attach thinkers to all actors which would increase ticks amount and scale velocity vector if you press "bullet time" button.
But it cant do anything with doors, lifts and sounds since.

[Rachael]

And how hard it would be to add feature for smoother animation, without touching tick rate at all? Like, change sprite frame/name during tick, instead of left it "static"?

It might be possible to extend the ANIMDEFS system for such an idea - if it were changed to be allowed on sprites and allowed to use non-integer tic values for frame durations, and could also somehow be configured to allow each object instance to have its own animation instance instead of all linked together if using the same sprite texture. However, the major drawbacks are a) this might require gross hacks to accomplish, which means it'd never be accepted, and b) frame transitions never happen more than once per rendered frame. So if someone runs at a limited framerate (ie vsync at 60 fps) and you try to serve up animations that are 75 frames per second, then the animation will be noticeably slower on the 60 fps monitor.

So overall I want to say no, it likely won't be possible.

[Apeirogon]

IIRC gzdoom decide is it time to tick gamesim or no by calculating difference between last tick time and current time. If it equal to 1/35 tick, else not.
So idea was to add some way to change appearance using this difference. Like, two/three/fifteen/nan times per single gamesim tick (i.e using 1/(35 * amount of changes per tick) ) , not per renderer frame.

As a example of what I mean:

Add new field "animator" to actor.
Define animator class, which looks like

Code: Select all

class internal animator definition
{
    unsigned int amount of changes per gamesim tick _number_;
    state which use it;

    sprite frame for first change;
    same for second;
    etc.
}

Attach animator dynamically to some state with a_attachanimator(actor, state, animator);
And then just check in renderer is actor have valid animator, and if it is use data from it for rendering.

[Graf Zahl]

Can you code that stuff without breaking any existing mod?

[Gez]

The only variable ticrate I can see making sense would be some gameinfo thing where it's set to either 35 or 30. 30 would allow correct speed for PSX Doom and Doom 64.

[Rachael]

The only variable ticrate I can see making sense would be some gameinfo thing where it's set to either 35 or 30. 30 would allow correct speed for PSX Doom and Doom 64.

I agree here, I definitely would like to add an option for 30 sometime down the line. It's a lot smoother on 60hz monitors anyhow, even with the interpolation. The difference in speed is barely noticeable anyhow.