So, what actually causes slowdown?

[OneCrudeDude]

I apologize if this is the wrong section, or if this question shouldn't be asked at all.

The NES biggest and most well known flaw was flicker, but another flaw that was somewhat persistent was slowdown. Slowdown seems to vary on a case by case scenario, and it appears you can't always pin the fault on "poor optimization"; sometimes the game is just poorly designed. First, I will start with games that seem to push a lot of objects around with little to no slowdown.

A well known example of a relatively fast game would be K.I.D.'s Summer Carnival '92: RECCA. The game is undeniably fast, though this comes at the expense of intense flicker, and it will suffer from slowdown from time to time. Given it is a game from 1992, you can assume this was due to the programmers being very familiar with how the NES works. But then there's older games, such as TOSE's Chubby Cherub from 1986 (skip to 7:48), where they push an obscene amount of stuff around with no slow down, though on occasion the graphics will start to flicker. And then there are pirated (!) games, like Magic Dragon, that seems to not slow down at all, though the screen will start to roll once the sprite limit has been reached. And then there's a curiosity like Gun Nac where you can choose framerate at the expense of flicker, or (attempt to) disable flicker at the expense of framerate; the results of the second option, thanks to the NES' scanline limitation, are dubious at best.

It also seems like, as time went on, programmers got lazier and lazier and didn't bother to do the best job they can do. Notorious examples of slowdown ridden games would be Contra Force and Parodius Da!, both late NES Konami games. Especially baffling since Konami has managed to put out games with much more on screen with less slowdown, such as Contra, Super C, and Gradius (when you're not on stage 5). Even Nintendo can be argued of not giving a shit, as Kirby's Adventure, a game universally lauded as being 'advanced', can slowdown when there's next to nothing on screen. Even the demo will slow down when Kirby demonstrates the "Spark" power up at 1:14! While I can't find a video of it happen, even the NES' flagship title, Super Mario Bros, will slowdown when you simply exceed the scanline limit, not to mention it appears as if the fabric of reality itself is about to tear.

Sorry for the lengthy post, I just wanted to appear as if I am somewhat educated. The important questions are: how can a programmer combat slowdown? What will encourage slowdown? And finally, have any of you guys ever had to fight slowdown, or is slowdown born from poor design, poor optimization, and over-ambition?

[tokumaru]

Contrary to popular belief, there is no direct relation between the amount of sprites on the screen (or sprites being dropped) and slowdowns. That just seems to be the case because more often than not, "more sprites" means "more objects being processed", but that isn't always the case, since a game can have a shitload of tasks to perform and not show a single sprite, or it can have all sprites on screen at once but hardly spend any time processing them.

Slowdowns happen when the game engine can't finish the tasks of a single frame within the time it takes for the NES to display a frame. See, while the NES is rendering a picture to the screen, the game engine is running and preparing all the data for the next frame. This means moving all objects (which may need physics), testing for collisions between objects and the level map, testing for collisions between objects, scrolling the level map, advancing the current music and sound effect(s), and so on. When the NES finishes displaying the picture if goes "hey game, I'm done, now it's time for you to give me the data I need to draw the next frame". So, if the game engine didn't finish a new frame, it simply can't give the NES data for a new picture, so it responds "sorry, not now... maybe next time", so the same frame is displayed again. This is what slowdown is.

Since a lot of tasks involve objects, and the number of objects often varies as you move through the levels, they are usually the ones blamed for the slowdowns, but every task performed by the game engine has a part in it. For example, if the scrolling engine is slow, it's eating away precious time that could be used by more objects.

It's considered bad practice to optimize code prematurely, so most programmers will focus on getting the games running even if that means sacrificing some performance at first. The problem with commercial game development is that deadlines are always too tight, and there hardly is any time left for optimizations (hell, in many cases they can't even find time to fix actual bugs!), so it's no wonder that some big name games as not as efficient about their CPU/memory usage as they could have been.

[OneCrudeDude]

It's considered bad practice to optimize code prematurely

Thank you for your response. I always had a theory where, if I ever hired an NES development team, I'd require them to make the game work first, and then optimize the game code as much as possible. Forgot to mention, since Contra Force was essentially a quick rebranding of a cancelled game, Arc Hound, it likely meant that the programmers just simply made the game work, and put it out to recuperate some of the development losses. Since you mentioned that having sprites on screen isn't exactly the root cause, I recall Contra Force having this gimmick of a "computer controlled character", which didn't work all too well and made the game unbearably slow, not like it was fast to begin with.

Speaking of the frames not being updated fast enough, would that be the main reason why Micronics developed games seem to hover at 15-20 FPS, despite the NES itself operating at 60 FPS? Micronics isn't alone, even the venerable Technos seemed to compromise framerate. Double Dragon, DD2, and RCR seem to run at 30 FPS, and RCR will drop to around 20FPS with two players.

[tokumaru]

Since you mentioned that having sprites on screen isn't exactly the root cause, I recall Contra Force having this gimmick of a "computer controlled character", which didn't work all too well and made the game unbearably slow, not like it was fast to begin with.

Yeah, any kind of heavy processing will help causing slowdowns, it's just that "large amounts of active objects" is the most common type of heavy processing, since objects require physics, collisions, and dynamic generation of OAM data... all of that can be pretty slow.

Speaking of the frames not being updated fast enough, would that be the main reason why Micronics developed games seem to hover at 15-20 FPS, despite the NES itself operating at 60 FPS?

Definitely. If you can't make your game engine run in a single frame, it's easier to make it always use 2 (or 3) frames instead and change the physics to move the objects twice (or 3 times) as much as they would in 1 frame. The apparent speed of the game will not be affected then (i.e. a character moving 3 pixels every 3 frames will cover the same distance in 1 second as a character moving 1 pixel every frame), only the animations will not look as smooth.

[OneCrudeDude]

Speaking of framerates, modern games seem to have the ability to reduce their framerate when there's too much to process. Would it be possible to make an NES game run at, say 30FPS when there's too much to process, instead of simply slowing down? This will give the illusion that the game is moving fast, but it will draw every other frame instead.

[koitsu]

Would it be possible to make an NES game run at, say 30FPS when there's too much to process, instead of simply slowing down? This will give the illusion that the game is moving fast, but it will draw every other frame instead.

See my first post here: viewtopic.php?f=21&t=10878

Possible yes, but not desirable. It also brings into question playability/usability; so you choose to only update relevant graphics bits every other frame (hence 30fps); what do you do about joypad reading and response to that input? If you poll input at the same rate (every other frame), graphics vs. input are "in sync" but the end user might end up feeling like there's "input lag" of sorts. If you continue to poll at 60fps but only update graphics every other frame, the end user might feel like there's a mismatch in responsiveness between input and what's visually seen on the screen.

Try the game "Downtown Special - Kunio-kun no Jidaigeki Dayo Zenin Shuugou!" (find an area that has enemies on the screen) for what this feels like, then ask yourself if it's worth it.

[MottZilla]

When emulating you can eliminate slowdowns by adding more cpu time at the end of the frame before vertical blank in many games.

I'm not sure about your idea of skipping frame updates to maintain overall speed. I think that would look bad. I think some games might reduce slowdown by dividing processing tasks between even and odd frames. It's probably best to just do your best to reduce the chances of serious slowdowns. But I wouldn't worry too much about slowdowns that aren't as bad.

[Bregalad]

While I back up what tokumaru said for the most part, I'd still say that, if the sprites are handled "properly", this means metasprites are copied to individual sprites into shadow OAM every frame, a lot of sprites will tend to also greatly influence the CPU load, because decoding/moving all those metasprites into OAM with effects applied on them can take a lot of time.

So it's wrong to say a game slowing down is because lots of objects and not because lots of sprites. I could be one, the other, or (the most likely) a combination of both.

[thefox]

Would it be possible to make an NES game run at, say 30FPS when there's too much to process, instead of simply slowing down? This will give the illusion that the game is moving fast, but it will draw every other frame instead.

Well, if your games normal speed is 60 FPS, then slowdown specifically means that it's then running at 30 FPS (or less). What matters is how the game's internal time is handled. Most NES games have a fixed time step, i.e. no matter how much time passes in real life, the in-game time is increased by the same amount on each frame. In other words, the game doesn't give a f about the FPS and accepts the slowdown if it happens. The reason they do this is that it's much easier to implement, especially given limited CPU resources. It also provides more consistent behavior.

[rainwarrior]

The other thing is that if the game isn't structured in such a way that slowdown happens gracefully, very often it will be accompanied by rendering glitches, especially where a status bar or some kind of scroll split is involved. For example, TMNT's status bar will disappear on alternating frames during slowdown. Unless your game has no special rendering techniques, keeping it together despite slowdown usually requires careful planning and delegation of important timed tasks to the NMI (scroll splits, music, etc.).

[tokumaru]

Speaking of framerates, modern games seem to have the ability to reduce their framerate when there's too much to process. Would it be possible to make an NES game run at, say 30FPS when there's too much to process, instead of simply slowing down? This will give the illusion that the game is moving fast, but it will draw every other frame instead.

I think this would be somewhat hard to implement on the NES. Modern platforms can dynamically adapt the physics in function of the time, so if a game is about to render a new frame and it detects that 50ms have passed since the last update, it will do all the physics calculations assuming that 50ms have passed in the game world as well. NES game however, sync the physics to logic frames. If a logic frame takes too long to finish and ends up using the time of 2 hardware frames, all physics calculations will still have used the parameters define for a single frame, hence the slowdown.

To fix this on the NES, you'd have to count missed frames and try to compensate for them in the next logic frame. I guess you could have tables with all the physics parameters for different frame counts (i.e. if an object accelerates 0.2 pixels/frame, it will accelerate 0.4 in 2 frames and 0,6 in 3), and before starting each logic frame the engine would check how many frames behind it is, so that it knows which set of values to use. The game would constantly be keeping track of the number of missed frames and trying to compensate for them.

The problem is that not everything can be solved with tables... if the current speed of an object is 4 pixels, and the game is 3 frames behind, you'll have to add that amount to its position 3 times, and that will need more CPU time, effectively increasing the probability of missed frames in the future. Another problem is that when you move greater distances to compensate for the lost time, you take the risk of having objects run through walls! For example, if a wall is 8 pixels thick, and your character moves 4 pixels per frame, there's no way he won't bump into the wall, but if he moves 12 pixels to compensate for 2 lost frames, he may go completely through the wall.

[OneCrudeDude]

I'm so glad that my topic seems to have garnered many replies! As for the Kunio Kun game Koitsu mentioned, the abhorrent slowdown this game suffers is the main reason why I will never play the game. It looks cool and has some neat features, but the slowdown, oh my god. Thank you all, regardless, for the helpful information!

I also have another question that will likely be within the realm of impossibility. Would it be possible to carefully develop an NES game so that it doesn't suffer intense slowdown and ensures that everything else won't glitch out, like the health bar in TMNT? Technically speaking, there are plenty of slowdown free NES games, mostly because they don't have much going on in the first place. I don't think you would hold Friday the 13th over Recca because, unlike Recca, it doesn't slow down at all. Or is the NES, so to speak, too weak? Given it's hardware from 1983, that's to be expected, but I mean weak as in you can't do much more than sidescrollers with 3 enemies tops on screen. At least it's not the SNES.

[tepples]

I also have another question that will likely be within the realm of impossibility. Would it be possible to carefully develop an NES game so that it doesn't suffer intense slowdown and ensures that everything else won't glitch out, like the health bar in TMNT?

It's straightforward to guarantee that a top status bar won't glitch because the CPU can just sit in a loop for the first 32 scanlines after the end of vertical blanking without losing too much processing time. It's much less so to guarantee that a bottom status bar won't glitch. Either the CPU has to sit in a loop for most of the frame (which drastically increases slowdown) or the cartridge has to contain an interval timer circuit that interrupts the CPU when it's time to draw the status bar. Many later NES games, such as the arcade-style TMNT games, contain an MMC3 ASIC, one of whose functions is to act as such an interval timer.

Or is the NES, so to speak, too weak? Given it's hardware from 1983, that's to be expected, but I mean weak as in you can't do much more than sidescrollers with 3 enemies tops on screen. At least it's not the SNES.

Compare processors:

• NES: 1.8 MHz 6502, sprite display list transfer at 0.9 MHz, video memory transfer at 0.22 MHz
• Super NES: 3.0 MHz* 65816, video memory and sprite display list transfer at 2.7 MHz

One big advantage of the 65816 is ability to access arrays larger than 256 bytes, such as level maps, without having to "carry the 1" all the time. But the bigger advantage for quickly updating the screen is that the CPU also contains a DMA controller, allowing it to copy data to video memory 24 times as fast as the NES CPU can. (This is the same principle used by "Blast Processing" on the Genesis.) Another thing is that Super NES sprites can be 16x16 pixels, meaning the sprite code doesn't have to write as many entries to the display list for a large sprite. Even with the bigger sprites, Super NES games rarely flicker because each scanline on the Super NES can hold 34 slivers (8x1 pixel units) of sprites, compared to only 8 slivers on the NES.


* Estimated average speed. The CPU normally runs at 3.6 MHz, but it slows to 2.7 MHz when accessing RAM, and it pauses for a few cycles of each scanline for DRAM refresh.

[OneCrudeDude]

The SNES comment was simply a joke on how the SNES has many games with intense slowdown, almost to the point where every other game that's not an RPG suffers from it. Especially insulting since the SNES is a much stronger console, but the NES has some games that would probably slow down a lot if they were ever ported.

[rainwarrior]

Tokumaru hit on this a bit, but a bit more explanation.

A lot of modern game simulation steps take a floating point "delta time" for the frame as a parameter, and this gets multiplied or otherwise applied to every operation in the simulation for that frame. For example:

Code: Select all

void simulate_motion(float delta_time)
{
    position += velocity * delta_time;
}

When you can multiply with floating points, it is rather straightforward to propagate a time delta into everything you do. When there is more time between frames, you get a longer measured time delta, so the overall apparent speed of simulation won't slow down; accuracy will suffer as the delta becomes longer, but it will remain approximately correct as long as the delta does not become too long. It's normal to cap it at some maximum delta and just accept real slowdown if the framerate drop is too drastic to avoid the chaos that results when things get too inaccurate.

Having to use fixed point instead of floating point makes this kind of thing trickier to apply. On the NES you have no floating point, nor do you even have a multiplication instruction. It's not really sensible to take this approach.

A very simple way to deal with this is to count frames in your NMI and try to play catch-up by running the simulation that many times before trying to draw the frame. i.e. if the last frame took two frames to simulate and display, do two simulations for this frame before displaying. If your simulation is quick enough, it will keep up at a steady 30fps. If it is not, however, it will bog down, as the extra catch-up simulations result in longer and longer frame times, resulting in more frames to catch-up on, etc. like before you need to put a limit on the catch-up and just accept slowdown at some point in the interest of keeping the game running and playable. The advantage of this method, at least, is that no simulation accuracy is lost.

A second way, which tokumaru was getting at, is to have a separate lower-accuracy simulation to catch up for a lost frame, essentially a 2-for-1 update where the player would move twice as far, etc. just performing all the same calculations just with different numbers (probably with a lot of use of the ASL instruction). This is the same as having a longer delta time: less accurate, but maintains the apparent speed. This can be a lot more complicated to implement, and also it becomes a source of chaotic behaviour. You probably don't want to implement a 3-for-1 catch up version, this is probably only effective if you can keep the slowdown to a single missed frame. Again you have a cap beyond which you must simply accept slowdown to keep things running.

As you can see, this becomes a pretty complicated problem, made even worse by the limited architecture. This is the reason that NES games don't try to compensate for missed frames, and just try to keep the updates within a frame and accept slowdown if they can't.