Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Blastfrog

Ticrates of Doom ports

Recommended Posts

So, if Jaguar Doom was used as a base for PSX Doom which was used as a base for Doom 64, and Jaguar Doom used a ticrate of 15 while Doom 64 used 30, what did PSX Doom use? I can imagine it being either 15 or 30, but I'm not sure which. I'd assume maybe it's 15 due to the PSX version not having that great of a framerate anyway, but I don't want to assume anything.

Share this post


Link to post

If you're trying to link to wikia, that's not allowed on this forum due to the official wiki move.

Share this post


Link to post
Quasar said:

If you're trying to link to wikia, that's not allowed on this forum due to the official wiki move.


So the faster framerate bullet point is a lie? Alright, my mistake.

Share this post


Link to post

Like Doom64, PSXDoom runs on threads in which the renderer and game ticker is run separately. The renderer runs at 30 FPS while the game ticker runs at 15, so to answer your question, TICRATE is set to 15 but the renderer itself continues to run at 30 FPS.

Doom64 however uses a TICRATE of 30 for the game ticker but P_Tick skips a tic if the game and render tic variables are not in sync.

Share this post


Link to post
MetroidJunkie said:

So the faster framerate bullet point is a lie? Alright, my mistake.

I didn't say that, but Kaiser does know the proper answer. That change to the article on wikia was either reverted on doomwiki.org, or was made after the fork in February 2011.

Share this post


Link to post

I think the PS1 version could have possibly had a higher framerate if the textures had been mip-mapped, like they are in almost every PS1 game, but Doom never had that feature, so maybe it would have been difficult to implement.

Share this post


Link to post

Hey, Kaiser. Didn't you make some utility at some point that could edit/view actor states and properties in the PSX version?

Also, do you ever plan to include anything in the KEX engine to be able to externally edit the states of Doom 64 actors, or even add extra ones?

Share this post


Link to post
Sodaholic said:

Also, do you ever plan to include anything in the KEX engine to be able to externally edit the states of Doom 64 actors, or even add extra ones?

He said he was planning on adopting and adapting ZDoom's DECORATE language. Since one of the stated long-term goals of the engine is to be a platform for entirely new games, the ability to define new content is necessary.

Share this post


Link to post

I plan on adopting and adapting ZDoom's DECORATE language. Since one of the stated long-term goals of the engine is to be a platform for entirely new games, the ability to define new content is necessary.

Share this post


Link to post

Does anyone know how ticrates work on fps uncapped ports? If you're getting 500 fps is the underlying ticrate still the doom standard of 35 or w/e and you're drawing 465 frames of nothing?

Share this post


Link to post
mark55 said:

Does anyone know how ticrates work on fps uncapped ports? If you're getting 500 fps is the underlying ticrate still the doom standard of 35 or w/e and you're drawing 465 frames of nothing?

The basic idea is to dissociate the game logic/world sim ticrate from the renderer loop. Then for extra niceness, you can use interpolation to smooth out predictable movement in between tics.

Share this post


Link to post
mark55 said:

Does anyone know how ticrates work on fps uncapped ports? If you're getting 500 fps is the underlying ticrate still the doom standard of 35 or w/e and you're drawing 465 frames of nothing?


For every new tic you remember previous positions of actors and when you need to draw a frame you read the current real time and use linear interpolation between two remembered postions. This way you get a new position between two remembered ones and use it only for rendering.

Of course it means that uncapped framerate makes display lag more behind the true state of the world.

Share this post


Link to post

However, uncapped FPS is wasteful. Sure you could get 5000 frames per second but you wouldn't be able to experience that anyway. Your eyes have a limited "refresh rate" meaning after a certain rate it will just look the same to you. Also your monitor has a limited refresh rate too. So the lowest denominator for those would be the monitor refresh rate. So a nice 60Hz monitor will only allow you to see 60Hz at a time. Also these days, drivers might not even bother updating the screen higher than the refresh rate (Mesa started doing this for example). So the FPS is best capped to 60 or in Doom's case 70 to save on CPU usage.

Share this post


Link to post
GhostlyDeath said:

However, uncapped FPS is wasteful. Sure you could get 5000 frames per second but you wouldn't be able to experience that anyway. Your eyes have a limited "refresh rate" meaning after a certain rate it will just look the same to you.


Human eyes don't have refresh rate, they work with continious stream of light. But yeah, after certain framerate there will be no difference. But this threshold depends. And in video games there IS difference between 60 FPS and 120 FPS. But having constant lower FPS is better than overall higher but varying FPS. 30 FPS cap can make you feel that a game has good permormance compared to the same game without FPS cap.

GhostlyDeath said:

Also your monitor has a limited refresh rate too. So the lowest denominator for those would be the monitor refresh rate. So a nice 60Hz monitor will only allow you to see 60Hz at a time. Also these days, drivers might not even bother updating the screen higher than the refresh rate (Mesa started doing this for example). So the FPS is best capped to 60 or in Doom's case 70 to save on CPU usage.

Vsync? It is good if it doesn't cause problems like noticeably increased input lag. Or for some reason ZDoom's software renderer periodically lags when Vsync is on.

Anyway, in doom ports "uncapped framerate" typically means "framerate independent from ticrate" and "every frame is not an exact visualisation of current game state". And this "uncapped framerate" setting is independent from vsync and other FPS cappers.

Share this post


Link to post

I wonder how much the gameplay would change if the ticrate uncapped too.

I assume doom game code is hard coded to tic counts so it would be a lot of effort to re-code it to time counts. But if for example a shotgun zombie takes 35 tics after firing to fire again, you could recode it to take 1000ms or whatever it is between firing, and then uncap the tic rate so the player could fire a shotgun and get a hit on the next frame rather than the next vanilla tic which could be hundreds of frames away.

It would break demo compatibility pretty hardcore and alter the gameplay a bit for what I imagine is not much benefit though.

Share this post


Link to post

I believe Quake 3 can have an uncapped ticrate or at least an increased one.

eiUACei said:

Vsync? It is good if it doesn't cause problems like noticeably increased input lag. Or for some reason ZDoom's software renderer periodically lags when Vsync is on.

Anyway, in doom ports "uncapped framerate" typically means "framerate independent from ticrate" and "every frame is not an exact visualisation of current game state". And this "uncapped framerate" setting is independent from vsync and other FPS cappers.


If there's any input lag with vertical sync it, it is most likely a bug in the game. But the point I was getting at was not vsync, but that you can only push so many frames to the video hardware at once. You could possibly get shearing because the game is pushing more frames that the hardware can handle.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×