Hi guys I was watching a video on youtube which then got me thinking about Frame rates.
An example would be TMNT which runs at 30fps as opposed to SMB at 60, I grasp or (assume) the fact that the 6502 hasn't got enough time to write all the necessary data to the ppu registers during vblank to produce the next frame, but I am curious in the case of TMNT as to what causes this to be the case?
I mean at a very basic level doesn't each game image use/have the same amount of nametable data to be written, max sprites per scanline used and said attribute data, what other factors would determine a games frame-rate?.
Any help is appreciated and feel free to get technical happy to read up on what I don't gather.
Cheers
Y
Frame-Rates and Vblank Data Explained
Moderator: Moderators
Re: Frame-Rates and Vblank Data Explained
IDK about those specific games, but I doubt that it's the writing of the graphical data that limits the frame rate. Games may have to do more calculations than can fit in the time of one 60-Hz frame in order to even prepare the graphical data for writing. I suspect that to be a more likely reasion for frame rates lower than 60.
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: Frame-Rates and Vblank Data Explained
Or in other words; the game logic itself. The CPU is so slow that even basic game logic can take up a large portion of CPU time. Games that don't take this into account may experience constant slow down, which is why games like TMNT may choose to refresh its screen at a lower rate in order to avoid this.
Re: Frame-Rates and Vblank Data Explained
The preparation of data for video updates and the video updates themselves do indeed consume CPU time, but everything else that the CPU has to process (audio, game logic, etc.) should also be factored in when estimating the CPU load on each frame. If everything added together requires more cycles than the CPU can execute in a single frame, the game simply won't be able to advance to the next frame in time, and it will lag. Game logic is usually the biggest culprit, since each object added to a scene will require physics calculations, collision detections, interactions with other objects, and so on.
If a developer realizes that their game is lagging too frequently, they can either try to optimize the code and reduce the CPU load, or deliberately use 2 frames for each update, effectively doubling the amount of CPU cycles per game frame, while halving the smoothness of the animations.
If a developer realizes that their game is lagging too frequently, they can either try to optimize the code and reduce the CPU load, or deliberately use 2 frames for each update, effectively doubling the amount of CPU cycles per game frame, while halving the smoothness of the animations.
Re: Frame-Rates and Vblank Data Explained
Thank you for the explanation makes sense - just to clarify if the CPU can't execute the total amount of instruction exceeding the available clock cycles within vBLANK they use two vblank periods to update 1 frame so half of the data gets updated and the other half in the next vblank period which creates the lag.
It would be interesting to see within the TMNT code to see exactly what causes the frame to be split into vblanks.
Thanks again for the help in understanding
It would be interesting to see within the TMNT code to see exactly what causes the frame to be split into vblanks.
Thanks again for the help in understanding
Re: Frame-Rates and Vblank Data Explained
Not really - games spend most of the CPU time processing the game logic and preparing data for video updates, but if they don't have everything ready by the time vblank starts, they don't do any video updates at all, since a partially updated video frame would look glitchy. Games will usually just skip all video updates for a frame (causing the previous frame to be displayed again - that's the lag frame) and continue processing the game logic, hopefully having everything ready for the next vblank.
Re: Frame-Rates and Vblank Data Explained
Makes clearer sense now thank you for clarifying, I did see a youtuber make mention of the jump mechanics in TMNT and how it took for 4-6 cycles to register what type jump it was with regard to how long the A button was held down for - so again assuming this logic and other type instructions as you mentioned audio etc being executed would account for the CPU not able update the respective PPU registers in time before Vblank and as a result reading in the previous frames data.
Quite interesting stuff you have to appreciate some of these programmers and how they went about things,
Thanks again again for the help my friend
Y
Quite interesting stuff you have to appreciate some of these programmers and how they went about things,
Thanks again again for the help my friend
Y