GZDoom 3.2.2 Released

[Rachael]

I'll do that, then. I'll make a 3.2.3 off of that.

(By the way, I kept oldmaint3_2 for purposes of keeping a branch with the tag, but both can safely be deleted)

[Rachael]

@_mental_:

The g3.2.3 tag has been pushed.

[Graf Zahl]

Please don't move branch labels like this. This can easily create a huge mess for other users of the repo that can be difficult to sort out. It would have been better to give the new maint branch another name.

BTW, the oldmaint label is on the wrong branch, but this doesn't really matter. A tagged revision is just as safe without an actual branch.

[Rachael]

Alright, sorry about that. I did move the tag forward one commit, though, but it's just a zscript.txt change which fixes GZDoom even starting at all due to wrong zscript version.

[Graf Zahl]

Moving a tag is not a problem. Branches are different, because a pull from the remote will try to merge with the local tracking branch and that can go really bad if the labels are in unrelated places.

[Rachael]

I understand. Again, I apologize. Do you want me to delete maint3_2 and rename it maint-3_2 or something?

[agenten]

[*]35 tics now actually is 1 whole second. Means the game is just a little bit slower, but now it's spot on 1 second, not 0.98... seconds[/list]

This is amazing, I cannot thank you enough for this. It's going to save me a lot of time and frustration.

[Graf Zahl]

I understand. Again, I apologize. Do you want me to delete maint3_2 and rename it maint-3_2 or something?

Yes, I think it's best to delete the old label and give it a new one. That'd avoid problems at least for those who haven't pulled yet.

[Rachael]

Done.

[GFD]

• 35 tics now actually is 1 whole second. Means the game is just a little bit slower, but now it's spot on 1 second, not 0.98... seconds

...why?? Changing the speed of the playsim is a very significant change to make, and I don't know the justification for it here. This seems like something that could affect existing content/mods drastically. Anything that depends on the old speed for syncing up multiple overlapping sound effects, for example, would be thrown out of sync by changing the playsim speed without changing the sound playback speed. In my case, I've been working on a mod that tries to simulate animations and physics from other video games that run at 60 fps in GZDoom's engine, and the whole thing thus far has been built on the assumption that 1 tic is exactly 28 milliseconds.

Is this done to be closer to vanilla timings, or does it depart from vanilla timings for convenience? I admit I take less issue with this change if the former is true.

[Chris]

Anything that depends on the old speed for syncing up multiple overlapping sound effects, for example

That's not "safe" anyway, since the audio clock is not synced to the system clock the game time is based on. Not to mention, you can't guarantee exactly when a sound starts relative to calling to play it since it's at the mercy of the audio device saying when it's ready for more audio, which depends on several factors. Proper synchronization would need to be done if you require matching audio to some external timer event, rather than assuming the audio clock is synced with the external timer.

Is this done to be closer to vanilla timings

Yes. In vanilla Doom, 1 tic was exactly two refreshes of a 70hz video mode (70/2 = 35, so 35 tics was exactly 1 second as far as the monitor was concerned). It was a change early in ZDoom's development when it no longer relied on the video refresh for timing that caused the timer to deviate from having exactly 35 tics per second.

[Rachael]

This should probably be continued here --> viewtopic.php?f=1&t=58620

The timer was changed because no matter how you cut it GZDoom just was not smooth. I think if you play 3.2.1 and 3.2.3 you will see a huge difference in how the motion feels in the game. Yes, it is slightly slower, if it really bothers you that much type "i_timescale 1.02" in the console.