Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?

It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.

However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.

I know the walking characters in Haunted: Halloween '85 (the player and the zombies) are the most algorithmically complex because they have to read the collision map four times (bottom center, left, and right, and head-height at leading edge), compared to everything else that reads it once (bottom center) or not at all.

Normally you can get away with just checking once per axis (usually the problems from that tend to be minor and self-correcting).

Players are notoriously more complex in general though. For starters, unless you're using the same routine for everything, they're the only ones to have full blown physics (collision all ways, acceleration, slopes, checks against background and platforms, etc.), while most objects usually just have the bare minimum for what they do. Also, players are the only ones to have many actions (idle, running, jumping, swimming, crouching, hurt animation, etc.) and potentially could switch between them at any moment, while most objects just have a couple of simple actions and maybe a collision check and not much else to worry about.

psycopathicteen wrote:

I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.

The problem with slopes is not so much that they're slower (it's not that bad) but the fact that they're notoriously hard to get right, and by "right" I mean "things don't suddenly jump when going downhill or suddenly stop when going uphill" (especially the jump part). That usually requires a lot of hacks to get working within your limited physics engine. No wonder they were usually avoided (and even into the 16-bit era, usually only players would handle slopes, since it was easier to have everything else just treating tiles as "solid or empty")

Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?

It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.

That's without factoring in the gain from 16-bit operations, which is substantial but can be a bit slippery as it is application-dependent. Movement code is an example - adding a 16-bit number to a 24-bit number is far quicker on the SNES than on the NES.

Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?

It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.

However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.

The 65816 is more cycle efficient than the 6502 as long as the programmer knows what their doing.

Sik wrote:

psycopathicteen wrote:

I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.

The problem with slopes is not so much that they're slower (it's not that bad) but the fact that they're notoriously hard to get right, and by "right" I mean "things don't suddenly jump when going downhill or suddenly stop when going uphill" (especially the jump part). That usually requires a lot of hacks to get working within your limited physics engine. No wonder they were usually avoided (and even into the 16-bit era, usually only players would handle slopes, since it was easier to have everything else just treating tiles as "solid or empty")

I don't remember seeing any game that doesn't allow enemies to walk on sloped platforms. Maybe I just never noticed it before because nobody ever pointed it out to me.

I don't remember seeing any game that doesn't allow enemies to walk on sloped platforms.

I wouldn't be surprised if they at least used a simplified form of slope handling for objects other than the player. I know that the Sonic games did this... Enemies are placed at the correct height on slopes, but the angle doesn't affect them at all, it's like they're always walking on straight ground. You can easily notice this if you use the debug mode to place enemies near loops or quarter pipes. They ascend insanely fast, because their horizontal movement isn't attenuated by the angle, and their Y coordinate is adjusted to match the height of the slope.

Quote:

Maybe I just never noticed it before because nobody ever pointed it out to me.

There are a lot of limitations games managed to hide from us pretty well. I'm pretty sure there are many cases where level design and object placement are carefully planned to avoid tricky situations.

Other ways SNES is more efficient...-Separate processor to handle music, don't have to waste CPU cycles running a music engine-tons more RAM, don't have to do things twice if you can store it in RAM for later-much more efficient moving large chunks of data around(DMA)-larger sprites, don't have to waste cycles contructing metasprites.

Downside of SNES dev...the expectations are much higher, it's assumed that an SNES game should look as nice as SMW.

_________________nesdoug.com -- blog/tutorial on programming for the NES

Downside of SNES dev...the expectations are much higher, it's assumed that an SNES game should look as nice as SMW.

This is the essence of what I was trying to say in points c (color use) and d (parallax layer use) of my first post. But most of this topic has been about the 65816 CPU, with only a few posts addressing the expectation of production values:

Bregalad wrote:

However you can always come up with cheaper graphics that don't push the system to it's limit.

tepples wrote:

And open yourself to "Why didn't you just make it for the NES?"

psycopathicteen wrote:

It shouldn't be that difficult to develop an SNES game that looks like an NES game.

MottZilla wrote:

The harder part is getting all of the artwork, sound, music, etc designed.

However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.

And thus almost twice as fast as the 68000? (I mean, the way you just calculated it there anyway.)

It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram. I'm not sure how anyone was able to manage with that given the general complexity of games on the system.

tokumaru wrote:

There are a lot of limitations games managed to hide from us pretty well. I'm pretty sure there are many cases where level design and object placement are carefully planned to avoid tricky situations.

The DKC games are carefully designed around the 8 sprite palette limit. There are situations like climbing a rope that stop you from doing things like carrying barrels too far, or ditches that stop enemies from traveling to far if you follow them. The tiles often get messed up because there's not enough vram for how they're managing it.

Actually, you know what I just thought of? If you're using 8x8 and 16x16 sized sprites, you don't even need to search every 8x8 block for a vram engine, because all 128 16x16 sized sprites just fit it. I mean, that's if you're using that much. You could even assign sprite a spot in vram.

Yeah, if each sprite is using individual tiles, then 32x32 sprites are actually kind of pointless.

I'd actually argue that it's even worse in terms of effort put in. There isn't that much shading, and the shading that exists isn't too spectacular, and the sprites aren't any larger than what you'd find on the NES (and the animation isn't any smoother because of the limited vram system), so the amount of effort it takes to do all this is less than trying to fit everything within the NES's constraints. I think SMB 3 actually looks better overall. The sprites are cleaner and the artwork is more consistent. Then again, I like SMB3 a whole lot better anyway.

I never understood, did Nintendo forget to outline this or something? It sticks out from the rest of the sprites like a sore thumb:

Attachment:

Lava Monster.png [ 735 Bytes | Viewed 1745 times ]

You want to know another thing that always looked weird to me in SMW? A lot of the color gradients are kind of poorly done. You'll see something like the green on the pipe have some red, then not have red, then have red again even if the green is increasing. Just an observation.

SMW uses lots and lots of 4-color and 8-color graphics, which is the reason it looks so simple compared to a lot of other contemporary/later SNES titles. Given the amount of time it was in development (supposedly ~3 years, probably close to the release of SMB3), I think a lot of the graphics were made before the technical details of the SNES had even come close to being finalized, so they just played it safe.

I was under the impression that the SNES was originally supposed to be more powerful, not the other way around. I really have no clue how that game took 3 years to make. I'm pretty sure DKC was made in about a year.

Not just technical though, a lot of the artwork, simple or not, just doesn't look that good. Maybe Irem just has me spoiled.

Aren't the BG tiles actually only 3bpp in order to save space on the cartridge? I mean, this doesn't justify the sprites though, which are the main problem.

It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram.

This is because the PCE has no restricted acces to VRAM, you can decompress or modify SAT/BAT directly in vram, without any RAM buffer .In fact is less problematic than it seems,but it is if you are coding like a system with allowed VRAM acces only in vblank .

Quote:

Other ways SNES is more efficient...-Separate processor to handle music, don't have to waste CPU cycles running a music engine-tons more RAM, don't have to do things twice if you can store it in RAM for later-much more efficient moving large chunks of data around(DMA)-larger sprites, don't have to waste cycles contructing metasprites.

Fast shortcuts here ..

Quote:

-Separate processor to handle music, don't have to waste CPU cycles running a music engine

Yes but without any mechanism for accessing ROM/WRAM to refresh his limited amount of RAM for a sample based sound processor, it's not really an advantage.PCE can do better samples without any dedicated sound processor .

Quote:

tons more RAM, don't have to do things twice if you can store it in RAM for later

Yes but too slow for 65xxx, better to have 32ko of fast ram than this shity DRAM imo ..

Quote:

-larger sprites, don't have to waste cycles contructing metasprites.

Yes but it's relevant with a descent SAT/OAM organisation and not with only two size allowed at the same time. In the snes's case,it'is a little bit useless .

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum