4 ms·

> Since the NES-processor is clocked (roughly 70%) faster than a stock C64 there can be slowdowns during gameplay Well, it's impressive that it works without b

> Since the NES-processor is clocked (roughly 70%) faster than a stock C64 there can be slowdowns during gameplay Well, it's impressive that it works without being always painfully slow, then. How is this done?

jacobush 8y ago
Maybe the original game didn't always use all available cycles. But I imagine there is more to this story, I think it takes some great wizardry to make this at all. The NES and the C64 have very different graphics and sound chips.
Waterluvian 8y ago
The original had bad slowdown too at times if I recall.
- recursive 8y ago
  Not this bad.
tenebrisalietum 8y ago
The more significant advantage of the NES over the C64 is the way hardware scrolling works. The NES supports a 4-screen screen memory or "nametable", and the PPU, or graphics chip, can be programmed with one or two register writes to basically display any position within that 4 screens. Scrolling is just updates to the scroll registers and populating new video data on the incoming edge (which has to happen during VBLANK). Whereas the C64's VIC-II can only select a few fixed places to start reading video memory to render the screen (2k boundaries for text mode). It can finely shift the screen left or right up to 8 pixels, but scrolling past that requires a many, many cycle recopy of RAM to video memory. Throw in the need to recopy color memory as well and that puts the C64 at a serious disadvantage. Looks like this game on the C64 used some really advanced technique called VSP, which tells the VIC to I guess read from arbitrary memory addresses instead of the fixed ones it normally supports. This apparently exposed a VIC-II hardware bug that can corrupt RAM (since VIC-II is responsible for DRAM refresh). Really interesting. Seems some systems are more susceptible to this hardware bug than others, and there's difficult software workarounds for it.
- vidarh 8y ago
  Scrolling at most requires copying 2K. In practice much less - even without VSP, Mario levels usually have lots of long runs of the same tiles all over the screen that makes it simple to optimize the copying (or rather optimize which parts you don't need to copy). For that matter you could double buffer and spread the copying of the tiles (not the colors) over multiple frames. The normal approach if you for whatever reason could find a way to copy what you needed, though, was simply constraining the amount of the screen you used a bit and e.g. putting extra decoration top/bottom. But really, Mario should not be a challenge to do this for - the C64 had tons of platform games of similar complexity. Especially Giana Sisters - put this video of Giana Sisters side by side with the Mario version above from the start of level 1, and see why Nintendo threatened the publishers: https://www.youtube.com/watch?v=8teXm6723-g https://www.youtube.com/watch?v=8teXm6723-g (EDIT: I've not checked, but e.g. the clouds in Giana Sisters in some of the levels looks like they might be sprites - using sprites for some of the "background" objects, especially if mostly vertically separated from the main game area was certainly a common method of reducing the amount of background that needed to be copied; notice how the levels without clouds mostly have several lines worth of tiles that doesn't require colour updates near the top and bottom, and often hardly ever requires any copying at all - e.g. mostly unbroken runs of floor tiles; many of the levels requires pretty much no colour updates anywhere) The only reason I can see for using VSP here is because it means less need to actually figure out how to do the copying efficiently.
  - djmips 8y ago
    you don't need to double buffer to amortize the copy time. That is you don't need to do all of the copying in the vertical sync time. As long as you stay ahead of the raster you can spread the copy over the subsequent frame. So in my scrolling routine I start copying the top portion and work my way down the screen to stay ahead of the raster. Interrupts still fire during this time and handle some game updates / joystick reads.
vidarh 8y ago
It's a very simple game, I'm more surprised that there'd be any slowdowns. Giana Sisters copied Mario to such an extent Nintendo threatened a lawsuit, and the C64 version is perfectly fine. The C64 had plenty of other equally complex platform games.
- zapzupnz 8y ago
  Giana Sisters was rather simplistic compared to Super Mario Bros, with many fewer elements on screen at once, fewer animations, simpler physics, and smaller stages. Giana Sisters was great at the time but it really isn't comparable to what the developers of this clone have managed.
  - vidarh 8y ago
    Size of the levels is pretty much irrelevant to the performance. Fewer elements on screen at once matters very little for performance on the C64 if they're rendered with sprites. It really does not explain the difference. Especially not as Giana Sisters was rather simplistic compared to many other scrollers on the C64 as well.
    - zapzupnz 8y ago
      > Fewer elements on screen at once matters very little for performance on the C64 if they're rendered with sprites Videos of this game in action beg to differ. The only time the game seems to slow down is when there are two or more animated sprites, usually enemies, on screen at once. This is compounded by tile-based scrolling being available in NES' hardware but not the C64, so scrolling is a costly operation — AND there are more enemies on screen at any time. On top of this, the NES could have 64 sprites on screen at once, fully animated at full speed (barring any other slowdown). The C64 can only have 8. That's not a negligible difference. With certain tricks you can display more, but the performance of this needs to be balanced against the rest of the game: SMB already has more complicated physics and more visible items on screen at a time. Giana Sisters was developed with the limitations of the C64 in mind. There's usually not more than one enemy on screen, the enemy typically moves slower, and animations equivalent to those on in SMB either have fewer frames or none at all.

jacobush 8y ago

Maybe the original game didn't always use all available cycles. But I imagine there is more to this story, I think it takes some great wizardry to make this at all. The NES and the C64 have very different graphics and sound chips.

Waterluvian 8y ago

The original had bad slowdown too at times if I recall.

recursive 8y ago
Not this bad.

tenebrisalietum 8y ago

The more significant advantage of the NES over the C64 is the way hardware scrolling works. The NES supports a 4-screen screen memory or "nametable", and the PPU, or graphics chip, can be programmed with one or two register writes to basically display any position within that 4 screens. Scrolling is just updates to the scroll registers and populating new video data on the incoming edge (which has to happen during VBLANK). Whereas the C64's VIC-II can only select a few fixed places to start reading video memory to render the screen (2k boundaries for text mode). It can finely shift the screen left or right up to 8 pixels, but scrolling past that requires a many, many cycle recopy of RAM to video memory. Throw in the need to recopy color memory as well and that puts the C64 at a serious disadvantage. Looks like this game on the C64 used some really advanced technique called VSP, which tells the VIC to I guess read from arbitrary memory addresses instead of the fixed ones it normally supports. This apparently exposed a VIC-II hardware bug that can corrupt RAM (since VIC-II is responsible for DRAM refresh). Really interesting. Seems some systems are more susceptible to this hardware bug than others, and there's difficult software workarounds for it.

vidarh 8y ago
Scrolling at most requires copying 2K. In practice much less - even without VSP, Mario levels usually have lots of long runs of the same tiles all over the screen that makes it simple to optimize the copying (or rather optimize which parts you don't need to copy). For that matter you could double buffer and spread the copying of the tiles (not the colors) over multiple frames. The normal approach if you for whatever reason could find a way to copy what you needed, though, was simply constraining the amount of the screen you used a bit and e.g. putting extra decoration top/bottom. But really, Mario should not be a challenge to do this for - the C64 had tons of platform games of similar complexity. Especially Giana Sisters - put this video of Giana Sisters side by side with the Mario version above from the start of level 1, and see why Nintendo threatened the publishers: https://www.youtube.com/watch?v=8teXm6723-g https://www.youtube.com/watch?v=8teXm6723-g (EDIT: I've not checked, but e.g. the clouds in Giana Sisters in some of the levels looks like they might be sprites - using sprites for some of the "background" objects, especially if mostly vertically separated from the main game area was certainly a common method of reducing the amount of background that needed to be copied; notice how the levels without clouds mostly have several lines worth of tiles that doesn't require colour updates near the top and bottom, and often hardly ever requires any copying at all - e.g. mostly unbroken runs of floor tiles; many of the levels requires pretty much no colour updates anywhere) The only reason I can see for using VSP here is because it means less need to actually figure out how to do the copying efficiently.
- djmips 8y ago
  you don't need to double buffer to amortize the copy time. That is you don't need to do all of the copying in the vertical sync time. As long as you stay ahead of the raster you can spread the copy over the subsequent frame. So in my scrolling routine I start copying the top portion and work my way down the screen to stay ahead of the raster. Interrupts still fire during this time and handle some game updates / joystick reads.

vidarh 8y ago

It's a very simple game, I'm more surprised that there'd be any slowdowns. Giana Sisters copied Mario to such an extent Nintendo threatened a lawsuit, and the C64 version is perfectly fine. The C64 had plenty of other equally complex platform games.

zapzupnz 8y ago
Giana Sisters was rather simplistic compared to Super Mario Bros, with many fewer elements on screen at once, fewer animations, simpler physics, and smaller stages. Giana Sisters was great at the time but it really isn't comparable to what the developers of this clone have managed.
- vidarh 8y ago
  Size of the levels is pretty much irrelevant to the performance. Fewer elements on screen at once matters very little for performance on the C64 if they're rendered with sprites. It really does not explain the difference. Especially not as Giana Sisters was rather simplistic compared to many other scrollers on the C64 as well.
  - zapzupnz 8y ago
    > Fewer elements on screen at once matters very little for performance on the C64 if they're rendered with sprites Videos of this game in action beg to differ. The only time the game seems to slow down is when there are two or more animated sprites, usually enemies, on screen at once. This is compounded by tile-based scrolling being available in NES' hardware but not the C64, so scrolling is a costly operation — AND there are more enemies on screen at any time. On top of this, the NES could have 64 sprites on screen at once, fully animated at full speed (barring any other slowdown). The C64 can only have 8. That's not a negligible difference. With certain tricks you can display more, but the performance of this needs to be balanced against the rest of the game: SMB already has more complicated physics and more visible items on screen at a time. Giana Sisters was developed with the limitations of the C64 in mind. There's usually not more than one enemy on screen, the enemy typically moves slower, and animations equivalent to those on in SMB either have fewer frames or none at all.