Dwedit wrote:
The CPU doesn't slow down at all. It's just that the game has exceeded the complexity of what can be done in a single frame, and those calculations need an additional frame to complete.
Where is that quote from anyway? Someone has a severe misunderstanding of what's going on.
This quote was written by me, a person who actually has a severe misunderstanding of what's going on, in a Google doc and it was based off of things I read from across the internet. It was either out-of-date, I misread it, or it was vague. I probably have a
lot of things written down incorrectly there, but that's why I'm asking here to get some...
PEER REVIEW
...in order to make sure I get things right.
If you want to look at all the things I have written down (probably incorrectly), here's the
link. Anything dealing with ASM was copied straight from tutorials because HOO BOY that's a little complicated for me at the moment and I want to understand the hardware before I get into the software.
tokumaru wrote:
Yeah, the hardware has nothing to do with this. Slowdowns are purely a software thing that happens when the program can't finish processing the game logic in time, so it continues to do it on the next frame, effectively delaying the game by one frame. If this happens consistently across several frames, the perceived frame rate will be 30fps (NTSC).
So the program code is intentionally written so that the slowdown effect occurs then; it's not a matter of the CPU
performing slowly, it's a matter of needing to slow down the PRG by 50% in order to let the CPU perform what it needs to. So what exactly is being slowed down then? Is there some kind of feed that goes from the ROM PRG into the CPU that is being slowed down (like intentionally adding cholesterol to a vein to restrict blood flow), or is the PRG literally programmed to be slow when there are too many sprites on-screen and then bump back up to regular speed when there isn't? My bet is on the latter.