AtariAge "CPU comparison"

[Bregalad]

BTW, why do people mention the fact that "some areas of memory slow the CPU down to 1.79Mhz," as if it is anything significant? The only thing at 1.79Mhz are the joypad registers, something that only gets read once in a frame. How is this anyway more significant than the Genesis's 68000 getting cycles stolen from the Z80 fetching stuff from ROM?

Beacause those people haven't the technical knownledge nor the intellectual level to understand something as "complicated". They're just fanboys of a Sega System and takes pleasure in bashing the SNES, they have barely any idea what a CPU is, know absolutely nothing about neither computer science and electronics, and that's it. You're really loosing your time with them.

Those are the kind of people who things a fast CPU will make the character move faster on screen, when it actually have absolutely nothing to do with it, but hey, they have no idea what they're talking about.

[Stef]

I mean, I guess I'm not one to talk as I don't know enough about the 68000, but that seems a little exaggerated? In the case of an actual game from the time period, not when you're trying to do software 3D rendering which makes use of 32 bit operations and multiplication/division (Even the video hardware on the SNES is less suited for 3D due to the graphics format).

....

Now uneven. But as I said, it's not always needed, so in the case where you're only doing 32 bit moves, it's definitely faster. However, you could also make a program that only does rts's . I honestly just want to know why you feel the 68000 is 2x as fast as a 65816 at half the clock frequency, as you've said you've worked with both (and I've seen you code for the 68000).

As you may notice i said

I barely estimate the 7.67 Mhz 68000 to be almost twice as fast than the 3.1 Mhz 65816 (so with fast ROM).

So i didn't said the 68000 is twice as fast than a 65816 working at half the frequency (which would mean the 68000 is as fast than a 65816 running at the same frequency). I said *almost* twice as fast than a 3.1 Mhz 65816... that is again just pure estimation but i think a 7.67 Mhz 68000 is equivalent to a ~5.5 Mhz 65816.
And now i can explain you why that is my estimation. If you really want to use these CPU at their maximum you will always tend to unroll and use very simple instructions in your code to execute bottleneck in an optimal way.
A good example is the psycopathicteen sprite rotation code but you have tons of possible examples (polygon fill, unpacking code, collision check...). At this point then you will get closer and closer to the maximum "data processing rate" of these CPU where you can almost reduces the view to sort of "read / modify / write" operation.
In which case you will obtain sort of:

Code: Select all

move.l (a0)+,d0
add.l d1, d0
move.l d0,(a1)+

for the 68000 which give you 12+12+8 = 32 cycles to process 32 bits (1 cycles per bit, practical :p)

and for the 65816 :

Code: Select all

lda $00uu,x
adc #xxx
sta $00uu,y

which give 5+3+6 = 14 cycles to process 16 bits (a bit less than 1 cycle per bit).

Of course you have to consider this as a very rough estimation but still it gives an idea and i think your understand the point. The 68000 also gives you some advantages as you don't have to deal with page crossing / boundary stuff but the 65816 has other advantages as fast branching.
Given these numbers you can see from where come my estimation. Of course it's not only numbers but also my experience working with many different CPU.

Even if the SNES is literally half the speed of the Genesis, if it's easy to get 80 sprites on the Genesis, then it should be pretty easy to get 40 sprites on the SNES (and it is), but for some reason tons of programmers have problems moving more than 4 or 5 sprites. It's like there's a book or something teaching people to program the SNES in a very discreet method that limits the programmer to 4 or 5 sprites.

I totally agree with that and i think your Alesha demo is a good example. Still you have to consider how much time you spent in your optimization process, you just couldn't ask every developer to push optimizations to that level during all development stages, it is very time consuming (and so very costly). Also even having a sprite engine capable of handling metasprite and resources allocation and being flexible enough to handle every kind of sprite is definitely not that easy. It becomes really hard when you want it to be really fast and handling many sprites at once. In SGDK my current sprite engine is very slow and you can observe slowdown with only 10 sprites (and that is on MD) ! Ok it's wrote in C and i'm doing resource allocation in a very lazy (and slow) way but i really understand that some games used that kind of engine because they did not had time to do a better one. I'm currently rewriting my Sprite Engine (still in C) to obtain better performance but it became very complex now and really for me it's quite difficult to offer a good and flexible engine and provide good performance at same time :-/

[psycopathicteen]

What exactly do you mean by resource allocation?

[Stef]

By resource allocation i mean VRAM and hardware sprite object and the underlying Sprite structure (small block of memory) which own current state of your sprite (the later one is not a big deal, you can even statically allocate it). My sprite engine allow you to just create a new sprite without having to worry about how VRAM and hardware sprite are being allocated or about sending data to VRAM, basically you just specify the position and the current animation frame and everything is done automatically... But it also let you the choice to manually define / allocate almost everything in case you want to have finer control (in case you want to use preloaded sprite data or static hardware sprite allocation...). All that flexibility has a cost... I understand that normally you tend to design your sprite engine around your game, but sometime you want to have something easy to work with and which does not give you any strict constraints about what you can do in your game.

[psycopathicteen]

I always thought it would be easier to manage sprite VRAM allocation on the Genesis because it's not as cramped, has slightly higher DMA, and isn't arranged in collumns and rows like the SNES. How much memory are you saving for backgrounds?

[tepples]

On the one hand, the Genesis has no BG3. On the other hand, BG1 and BG2 are optionally 20% wider, and the horizontal scroll table and sprite display list sit in VRAM instead of main RAM (for HDMA) and dedicated OAM respectively.

[HihiDanni]

The Genesis has a "window plane" (which doesn't support transparency). I prefer having an open-air HUD even if the tile data for it is only 2BPP.

I'm not wild about the 16kb sprite char limit. Sometimes I wish I could have been able to fit in just a few more explosion sprites. Instead, I think I will take this opportunity to make the backgrounds especially beautiful.

I'll be honest, I kinda wish the SNES was 320px wide, as it would make widescreen display a lot less awkward. Its display in 4:3 is fine though, and I like the slight fattening it does to the graphics - I think it's actually kinda cute and endearing? When seeing screenshots on a webpage or whatever, the aspect ratio means you're looking at squares. But I think they are very pretty squares.

[Stef]

I always thought it would be easier to manage sprite VRAM allocation on the Genesis because it's not as cramped, has slightly higher DMA, and isn't arranged in collumns and rows like the SNES. How much memory are you saving for backgrounds?

I think you have more freedom on the Genesis, as you can allocate sprite tile data anywhere in VRAM and you don't have size limitation except the VRAM size itself. But actually all these freedom can be a bit tricky to deal with : how much VRAM you allocate ? where allocate sprite in VRAM ? You have to deal with all that "flexibility".
Currently in my sprite engine i allocate a default of 384 tiles (12 KB) but you can change it as you want. Ideally you should always keep a good margin for background data and tilemap but i know some games can reserve a lot of VRAM just for sprites (Final Fight CD reserve almost half of VRAM just for sprites : ~30 KB).

The Genesis has a "window plane" (which doesn't support transparency). I prefer having an open-air HUD even if the tile data for it is only 2BPP.

The window plane of Genesis does support transparency, the problem is that it replaces the BGA plan so you can't have the 2 BG plans + the window overlapping on same area. For that reason many games just use an opaque color for window background to hide anything below it (and more importantly hide the missing BGA). Still some games were able to use it smartly so you don't even see that constraint.
Street of Rage 2 come in mind : player and enemies energy bars are rendered using the window plan so you never have 2 background plans overlapping on that area but levels were designed with that constraint in mind so you almost never notice it, really clever

I'm not wild about the 16kb sprite char limit.

I think 16 KB can be a limit in very specific cases. Beat'em all with large sprites is one of them though. I sincerely think the sprite limitation we observe in SNES Final Fight series is partially due to the sprite 16 KB limit. As i mentioned just before, the MegaCD version allocate ~30 KB just for the sprites. On SNES you could use the BG3 for HUD and lower the sprite VRAM requirement quite a bit though.

[HihiDanni]

What happens when you have all three planes overlapping in one tile at once? Does it just make the Plane A tile disappear? I wonder if this could be used for special effects?

[tepples]

The window plane of Genesis does support transparency, the problem is that it replaces the BGA plan

The Super NES equivalent of that would be setting up "window" parameters for BG1, then switching to "level" parameters in an hblank ISR.

[Drew Sebastino]

What happens when you have all three planes overlapping in one tile at once? Does it just make the Plane A tile disappear? I wonder if this could be used for special effects?

What are you even talking about? If you mean that BGs will get clipped due to overdraw, the answer is never, 3 BGs will always display as 3 BGs. What I believe you're trying to describe only applies to sprites, and sprite overdraw is only affected by other sprites.

Anyway, even if only 2bpp, you can make some nice status bars if you swap out a color or two per line.

This is actually a near perfect representation of the Metal Slug status bar in that it fits in a 256 pixel wide display. It works in 4 4 color palettes, with I think two colors being swapped per line:

2bpp status bar.png (5.12 KiB) Viewed 2911 times

The "Press Start" letters just barely don't work, but if they are even displaying, that means a player isn't even there so you could definitely use their resources for that.

Sometimes I wish I could have been able to fit in just a few more explosion sprites.

You should see the ambitious junk I tried to do in solving this problem, trying to fit each sprite into vram like a tetris piece, scanning through sprite vram to make sure there are no redundant tiles, stuff like that. About 50% (or more) of SNES games use 8x8 and 16x16 sized sprites, and in that case, it fits perfectly, as all 128 sprites could be 16x16 and have its own spot in vram. The problem with this could be bandwidth. In order to get any benefit from using 16x16 and 32x32 sized sprites, you'd need to check for redundant tiles when requesting tiles.

I'll be honest, I kinda wish the SNES was 320px wide

But this would get rid of BG3, because there's not enough bandwidth. Then, you'd basically have the Genesis. I'd rather have an extra BG, even if only 2bpp, as looking on a TV that's displaying in the 4:3 aspect ratio, the difference between the two isn't that big.

[HihiDanni]

What are you even talking about? If you mean that BGs will get clipped due to overdraw, the answer is never, 3 BGs will always display as 3 BGs.

That question was referring to the Genesis VDP. Sorry if that wasn't clear.

You should see the ambitious junk I tried to do in solving this problem, trying to fit each sprite into vram like a tetris piece, scanning through sprite vram to make sure there are no redundant tiles, stuff like that. About 50% (or more) of SNES games use 8x8 and 16x16 sized sprites, and in that case, it fits perfectly, as all 128 sprites could be 16x16 and have its own spot in vram. The problem with this could be bandwidth. In order to get any benefit from using 16x16 and 32x32 sized sprites, you'd need to check for redundant tiles when requesting tiles.

My game will use 16x16 and 32x32 sprites. I want a sizable portion of the char sprite space to be statically allocated. The top portion of table 1 (player sprite) and all of table 2 (enemies, maybe other things) are for DMA. One thing I'll probably end up doing to save space is using four-way symmetry with four sprites for sparkles and things like that.

[tepples]

And if you really want to optimize a Super NES game for a widescreen monitor, you can use mode 5 with its 512x224 pixel backgrounds. Total pixel count including borders is 560x240, giving a pixel aspect ratio of 240/560*16:9 = 16:21 = 0.762. That's close to the 0.75 PAR of the Apple IIGS (in super hi-res mode) and NTSC C64 or the 0.767 PAR of the CPS/CPS2 arcade board.

[HihiDanni]

I actually thought about making a game using Mode 5 once! I'm not sure if the background depth trade-off is worth it though, and presumably the sprites would remain at standard resolution.

[Sik]

The Genesis has a "window plane" (which doesn't support transparency). I prefer having an open-air HUD even if the tile data for it is only 2BPP.

Transparency or translucency? Because if the former, yeah it does, it's just that one of the scroll planes can't show under it (but the other can, as well as sprites). Beat'em-ups and fighting games generally show health bars using the window plane without an opaque background.

What happens when you have all three planes overlapping in one tile at once? Does it just make the Plane A tile disappear? I wonder if this could be used for special effects?

Plane A disappears (window plane replaces it), yeah. The other two planes aren't affected, layer priority even works the same way in fact.

As for special effects: the Dragon Ball Z game uses it for vertical split screen (only one background plane for each side but hey it works!), I wonder if Herzog Zwei does it as well. In Project MD I use it for the clipping in the level select, I imagine there are other games that do the same. In theory you could mix it with raster effects as well for funky stuff with plane A, but I haven't seen anything do it yet.