Why does Snes slowdown more than Nes?

[dragonboy]

data that gets loaded into that reg (or whatever) gets loaded from some part of memory, and also that data is manipulated a lot... and that manipulation part is the cause of the slowdown (when the code is not fast, or not fast enough).

that sounds very unorganized; couldn't you make a psuedo sprite-attribute table, and make the CPU process every sprite one after another while filling up that psuedo sprite-attribute table sprite by sprite as you go along. Then when it's durring the V-blank time, DMA the psuedo sprite attribute table to the real sprite attribute table.

[TmEE]

its not that.... sprite doesn't jump itself, you have to make it jump in code by adjusting the coordinates (whether they go in a pseudo table, usually it happens)... its all math, and that is what causes slowdown

[j_factor]

We're not talking about scrolling, we're talking about slowdown due to sprites; you know, like when Sonic gets hit and ejects all his rings bringing the game down to a slide show for a few moments.

No, we're talking about slowdown. Sprites by themselves don't cause slowdown. Even Space Invaders has significantly more sprites on screen than many games that are plagued by slowdown.

Very little was taken out for the SNES version, there are dozens of enemy sprites, bullets, and pieces of shrapnel flying around in each arena with no slowdown. And when you actually beat the game, it starts over, with the sprites moving twice as fast.

A lot was taken out of the SNES version. Particularly, a lot of animation. Again, Smash TV was a game that was handled by NES and Commodore 64. Those ports aren't as good as the SNES version, as they're kind of ugly looking and the control options aren't very good, but they're adequate in terms of what we're discussing.

Smash TV is just Robotron 2084 with a new coat of paint. Robotron was originally powered by a 6809 processor at 1 MHz, and in the later levels it handles a very very large number of sprites.

[tomaitheous]

A lot of animation control/physics are prerendered tables. Enemies for example that move along a sine wave of sorts is just a series of LUTs. Games like Street Fighter 2 have a huge array of LUTs. LUTs are used for all sorts of animation from stuff like bullet patterns, wave patterns, enemy patterns, etc.

Jumping doesn't necessarily need a LUT, but it's not math intensive either. At the max frame update, it's one movement calculation per frame during mid air. That's pretty low resource.

[TmEE]

slowdown is still caused by slow code... or should be, unless HW is not too well designed

[dragonboy]

its not that.... sprite doesn't jump itself, you have to make it jump in code by adjusting the coordinates (whether they go in a pseudo table, usually it happens)... its all math, and that is what causes slowdown

that sounds very unorganized; couldn't you make a psuedo sprite-attribute table, and make the CPU process every sprite one after another while filling up that psuedo sprite-attribute table sprite by sprite as you go along. Then when it's durring the V-blank time, DMA the psuedo sprite attribute table to the real sprite attribute table.

As you read my post more carefully this time, you'll see I already knew that.

[esb09]

U.N. Squadron is by far the worst offender I've ever played with regards to SNES slowdown. Its horrible.

It could be such a good game, too. They should've done a Genesis port.

Shooters on the SNES=failure.

[Gentlegamer]

U.N. Squadron is by far the worst offender I've ever played with regards to SNES slowdown. Its horrible.

Yup, as a SNES launch game, its a poster child for the launch-era slowdown.

[dragonboy]

Maybe the slowdowns have something to do with converting the 68000-based arcade games to the 65816 code for the Snes.

The port of Smash TV must've came out great since it was originally writen on a 6809-based arcade machine. If I remember correctly, 6809 code is exceptionally easy to convert to 65816, but for the 68000, it's hard as hell.

[tomaitheous]

Maybe the slowdowns have something to do with converting the 68000-based arcade games to the 65816 code for the Snes.

The port of Smash TV must've came out great since it was originally writen on a 6809-based arcade machine. If I remember correctly, 6809 code is exceptionally easy to convert to 65816, but for the 68000, it's hard as hell.

The 6809 is related to the 65x, which makes it very similar to the 658x. The 6809 is basically a 65x with more instructions (and powerful ones too). Honestly, I'd take a 6809 over a 658x or a 68k at the same clock speed.

But I doubt they ran the code through a static re-compiler. Game logic is pretty easy to mimic/replicate as it's almost always based on 1/60 ticks.


Slow down in U.N Squadron wasn't too bad. There were worst examples on the SNES. Also, the game was better than the arcade (which I played the hell out of). Music was better on the SNES too.

I was playing Demon Crest yesterday (just picked it up) and man that game has inexcusable slow down with just four regular enemy ghosts on screen.

[dragonboy]

Did those old programmers do collision detection for every sprite on every sprite?, because not all sprites need to have collision detection applied for every sprite.

For example, a vampire is throwing 16 little skull heads at the player, every little skull head doesn't need to have collision detection applied with the rest of the little skull heads, they only need collision detection applied to the player sprite.

[TmEE]

programmers aren't that stupid...

[tomaitheous]

programmers aren't that stupid...

Well said (hehe). Though I've seen programmers make some stupid mistakes before. Optimization isn't always a priority for them. Konami is a good example. DragonBoy, guess you're going to have to trace through a specific SNES game with a debugger and locate the problem

[dragonboy]

programmers aren't that stupid...

If you have ( 3,600,000 cycles/second ) / ( 60 frames/second ) / (128 sprites) / (262 lines) x (224 visible lines) = approx 400 cycles per sprite at the max amount of sprites at the max framerate; you would have to be pretty stupid to mess up so badly.

[tomaitheous]

( 3,600,000 cycles/second ) / ( 60 frames/second ) / (128 sprites) / (262 lines) x (224 visible lines)

Why do you have the vertical lines in there? For a frame you have 3579545 / 59.94 = 59719 cycles per frame. You're average opcode is going to be 4 cycles. That's 14929 average instructions per frame.