ZDoom

Dump it.

@ Graf: Should we close and reject this, or do you have any reason to keep it open?

Yeah, but if you have more frames of animation than tics, you could theoretically "interpolate" between them, in the sense that if you've got a 35 ticrate game, you could have several frames that take place in 1 tic, but are displayed over several frames in between the beginning and the end of the tics. This is possible with the animated textures, for example. Those, however, are only loosely tied to tic-rate, unlike HUD sprites. This would be a lot more logically complex than just upping the ticrate, but could be more universally used. I'd have to take a long look at the codebase to figure out how to even [i]start[/i] tilting at this windmill, though.

[quote="Surface2EvilShotgun"][quote="Rachael"]Remember - Quake has a tic rate of 10 tics per second. MMORPG's have an even lower tic rate (EverQuest, for example, has a 1/6th per second tic rate - i.e. it only tics once every 6 seconds!).[/quote]They don't limit the animations to the ticrate, right? Maybe I should take that approach instead.[/quote]
Don't know about those games specifically, but it is possible to limit animations and physics to a low ticrate and interpolate them for between-tic frames, giving the appearance of more detailed animation and movement. It's how you can get smooth results on 100+hz monitors even if the game logic updates 30 or 60 times a second. ZDoom interpolates physics/object positions IIRC, so objects appear to move smoothly with 35+hz refreshes, but you can't interpolate sprite animation as easily as skeletal animation, so those will still appear limited.

[quote="Rachael"]Remember - Quake has a tic rate of 10 tics per second. MMORPG's have an even lower tic rate (EverQuest, for example, has a 1/6th per second tic rate - i.e. it only tics once every 6 seconds!).[/quote]They don't limit the animations to the ticrate, right? Maybe I should take that approach instead.

Also it just isn't a good idea to have a high tic rate. There needs to be an upper limit and it needs to be lower than 70. Probably 50 is the very most, but that's stretching it. The biggest problem here is network and demo compatibility - higher tic rates will demand much more throughput in bytes per second - and that's going to be an even bigger issue going forward with the change in network model since that will necessitate the server sending much more data than it currently is.

Remember - Quake has a tic rate of 10 tics per second. MMORPG's have an even lower tic rate (EverQuest, for example, has a 1/6th per second tic rate - i.e. it only tics once every 6 seconds!).

Doom is one of the games with the highest tic rates ever. Even Build engine games run at only 30 tics per second.

TBH I don't see this working out. The changes are far too extensive and often far too subtle and I think it speaks volumes that basically no port has ever tried - and those who did try to mess around with this ultimately fail to properly run the game.

I feel like changing how speed and gravity work would be less intuitive than just keeping them as-is. I mean, having to work with speed in terms of MU per 1/35ths of a second in your 60fps project is pretty arbitrary instead of just working with MUs per 1/60ths of a second, especially when your actor's states are all bound to whatever framerate your game is working at to begin with.

That is correct. Or they are precalculated based on 35, which is even harder to find.

I'm guessing a lot of things don't use the TICRATE variable and instead have a hardcoded "35" in their math.

gameinfo
{
	TICRATE = 70
}

[url=https://github.com/WalterBarrett/gzdoom/tree/gameinfo-ticrate]GitHub link.[/url]

I'm working on a pull request to allow setting the TICRATE via (Z)MAPINFO's GAMEINFO section. This would be useful for TCs that want to run at a different tic rate than Doom (PS1/N64 Doom TCs would benefit from 30 tics, Wolfenstein TCs would benefit from 70 tics, and I can imagine 60 tics being a popular choice for certain mods). I'd like to avoid the end user having to change everything's speed and gravity, only their states. I was going to wait until I finished it before posting here, but I'm having issues getting movement to feel correct at ticrates other than 35. I've been testing with tic rates 10, 35, 70, and 700. Sliding against the wall is currently the wrong speed. Jumping and gravity are close, but aren't *quite* perfect (at 700 tics, DoomGuy will grunt from this own jumps). Friction is absolutely busted. At a ticrate of 10, you slide much futher, and at a ticrate of 700, you stop on a dime. I've tried various methods to counteract the friction, but they've been fruitless. I'd appreciate any advice.

To test this, create a ZMAPINFO with the following contents:
[code]gameinfo
{
TICRATE = 70
}[/code]