Why snes lacks sprite scaling while GBA does featuring sprite scaling???

[johannesmutlu]

I ask this because back in  1990 memory was expensive and so if you wanted to make a sprite look futher away from the player,you could just shrink down the sprite just in order to save on memory space,BUT since the snes does lack sprite scaling in hardware,you can’t do that,so in race games such as mario kart,f zero ,street racer etc,,, multiple identical sprites at different sizes were needed to give the ellusion of sprites at different distances from the player,had nintendo included sprite scaling on the snes,then they could,ve saved aloooot of memory space on certain snes games and use that remained memory space for something else,

sure you could do sprite scaling trough software on the snes but i can imagine that that will require more processing power on the cpu and it can slowdown the gameplay in such race games,

the GBA at the otherhand did contained sprite scsling builtin and since memory was more cheaper in 2001,game developers could not only save on memory space but they could even use more memory then ever before,

sure nintendo might could,ve go for sprite scaling onto their ppu chips but maybe they did know that other competitors already did that so maybe they decoided to go for mode 7 to stand out from the rest,sure they might could,ve implement both sprite scaling and mode 7 into their ppu chips but maybe it couldn’t do it all atonce so maybe sprite scaling could be only done in certain modes,but still,,, i was thinking had the snes also sprite scaling builtin and if it could do anything atonce,it could,ve be the best 2D system ever made,especially if nintendo opted for a much faster cpu,faster and more ram and fast rom as standard,

yes there is the fx chip and the sa1 chip wich could speed things up and they could do sprite scaling and even polygons as wellbut adding such chip into a game cartride is more costly,

yeah it’s just a minor complain,but am actually curious about the outcome had nintendo made the snes just a little bit more better along with nes compatibily,who ever knows how much better or woese the snes would,ve sold,it could,ve sold worse because of the added higher costs to it or it could,ve sold better since many perants wanted the snes to be compatible with nes ganes but once they knew that the snes wasn’t compatible with nes games,they refused to buy a snes for their kids (poor kids had to miss the 4th gen game console,ouch)

but apart from that i will always have good fond memories of the supernintendo,it reminds me of the better more exciting days of the 90’s.

 

[WavyGravy]

The SNES PPU was already complex enough that it had to be split into 2 chips on the early models. Adding the necessary logic for sprite scaling and rotation likely would have made it even larger and definitely more expensive. The SNES already has hallmarks of cost-cutting within the design. The slow WRAM and the PPU being designed to support 128kb VRAM while only shipping with 64KB are a couple of big ones.

The GBA's PPU has it because it's ten years newer, pretty much. Technology got better, faster, and much cheaper. Neither the GBA not the SNES can compete with the Saturn in pure 2D, though, and we will likely never see a home machine with tilemapped graphics that does because it just doesn't make sense to build a machine like that anymore.

Edited December 4, 2023 by WavyGravy
Grammar correction

[jeffythedragonslayer]

Nintendo wanted to keep the cost of the SNES down and move the heavy duty processing onto enhancement chips.  Check out the Super FX if you want sprite scaling.

[Wayler]

Huh, hadn't really even thought of the fact that there is a spread of smaller sprites for the racers in F-Zero or Super Mario Kart.

 

I have no technical knowledge in this, so allow for me to ask a stupid question: Isn't Mode 7 sprite scaling, along with other tricks? Like when you throw baddies on the screen in Turtles in Time, or when the level 2 boss lands on your head in Contra III? But if we go back to F-Zero, as the road surface is already in mode 7, is it then impossible to be used on anything else?

 

And J-Mu. You pose an interesting question somewhat coherently AND it's in the right subforum. That's 2/2! 

[jeffythedragonslayer]

49 minutes ago, Wayler said:

Isn't Mode 7 sprite scaling

No.  You may enjoy https://sneslab.net/wiki/Mode_7#Limitations

 

And, don't worry - there are no stupid questions, just stupid replies.

Edited December 4, 2023 by jeffythedragonslayer

[TrekkiesUnite118]

1 hour ago, Wayler said:

Huh, hadn't really even thought of the fact that there is a spread of smaller sprites for the racers in F-Zero or Super Mario Kart.

 

I have no technical knowledge in this, so allow for me to ask a stupid question: Isn't Mode 7 sprite scaling, along with other tricks? Like when you throw baddies on the screen in Turtles in Time, or when the level 2 boss lands on your head in Contra III? But if we go back to F-Zero, as the road surface is already in mode 7, is it then impossible to be used on anything else?

 

And J-Mu. You pose an interesting question somewhat coherently AND it's in the right subforum. That's 2/2! 

SNES video modes as far as I'm aware are background layer specific and don't have an impact on the sprite layer to my knowledge. They all focus on changing things like how many background layers you can have, their color depth, resolution, etc. so the way sprites work across them remains the same. So as a result in Mode 7 only the background layer is affected.

[Wayler]

37 minutes ago, TrekkiesUnite118 said:

SNES video modes as far as I'm aware are background layer specific and don't have an impact on the sprite layer to my knowledge. They all focus on changing things like how many background layers you can have, their color depth, resolution, etc. so the way sprites work across them remains the same. So as a result in Mode 7 only the background layer is affected.

I went back and looked at the throw sequence in TMNT IV. And looks like it is sprite-based too, with 3 different sized copies of the same sprite coming at you. It just goes so fast in real time that you don't notice and looks pretty smooth. I'm learning new things!

[Tanooki]

Well that's because the foot soldier is its own background layer, the MODE7 layer in that case.  The moment it's tossed and the size changes it's scaled and rotated MODE7 layer, a foot soldier specific layer and why you'll only ever have one of them doing that.  I believe that's what's going on there, but it has been a long long time since that was looked into when I had some semblance of a hand in things in early SNES era emulator beta testing days of the 90s.

 

If that isn't the case, then you'll notice from those frames you have the guy scaling up but it could be a bunch of sprites tiled together but that does make a bit less sense since background things and sprites are still going so it could hit the limit tiling that many.

 

Its layer is the same layer F-ZERO's floating roads are to the spinning background that PILOTWINGS uses as well.

Edited December 4, 2023 by Tanooki

[Aaendi]

You can't have a mode 7 layer overlapping 2 other background layers.

 

Sprite rotation and scaling can be done in software by filling up RAM with every rotation step beforehand.

[Wayler]

1 hour ago, Tanooki said:

Well that's because the foot soldier is its own background layer, the MODE7 layer in that case.  The moment it's tossed and the size changes it's scaled and rotated MODE7 layer, a foot soldier specific layer and why you'll only ever have one of them doing that.  I believe that's what's going on there, but it has been a long long time since that was looked into when I had some semblance of a hand in things in early SNES era emulator beta testing days of the 90s.

I got that throw sequence from a YouTube long play and that specific throw occurs at 1:43. I played the video at 0,25x to get all the movements to that prior picture. 

As you can see, at full speed it feels like a mode 7 effect but I think it's just 3 different size sprites of the soldier (there's actually a small sideways movement of the sprite mid-air as a neat effect that is hard to see in normal speed). Don't know if that soldier itself has been first blow up in mode 7 prior and cut/paste as 3 different sprites to the game? Or are there simpler tools at resizing sprites?

 

So in conclusion, wouldn't a Mode 7 effect be a smooth transition from small to in-your-face? And this is effectively the same as the racers in F-Zero or Super Mario Kart? 

Edited December 4, 2023 by Wayler

[WavyGravy]

I think they do the Foot Soldier the same way that Trials of Mana does some of its "scaling." Essentially, you have 15 BG tiles that are just solid colours that match the sprite, and you use each 8x8 tile as a pixel and write those to the tilemap of the background layer you want to use for scaling. The intermediate frame is probably actually drawn normally, just using a prescaled image. Oddly enough, the only game I know of to use both sprite scaling (done in software) and Mode 7 at the same time is Chrono Trigger. You can see it when racing the Jet Bikes and during some of the endings.

[Tanooki]

Hmm good point on both posts.

 

If it wasn't so late here, so I'll pass the buck on this, I'd fire up Mesen2 the replacement for Mesen (nes) and Mesen-S (snes) which has a whole tool suite of amazing things to fiddle with.  You can fire up that point in the game, save state it, then just tweak the various tools in the emulator to find out by re-loading that few seconds repeatedly each attempt.  You can isolate each individual background layer, sprite layer, etc both for visual points of reference and also a graph that'll pop up little colored dots to the actual code itself to give you the truths of what's going on.  Sharopolis has been using that quite a bit on those NES, SNES, GB, PCE (it runs a few things now the old mesen's didn't) to get into the details of such things in YT videos.

[johannesmutlu]

On 12/4/2023 at 7:41 PM, Aaendi said:

You can't have a mode 7 layer overlapping 2 other background layers.

 

Sprite rotation and scaling can be done in software by filling up RAM with every rotation step beforehand.

Interestingly enough,the GBA can do both overlappeing a mode 7 background on top of of other backgrounds,on the snes,you cannot do that,you can switch from mode to mode on the fly by using the scanline trick but you cannot have a mode 7 background on top over another background,maybe trough software?? But am not so sure about that,but as far as i do know you can fake an ectra background with mode 7 by using animated tile sets but i can imagine how much extra space that will take up while doing so,

another way to fake mode 7 over another background is to combine it with sprites to fake another background,in bowser’s room in marioworld,he became a background while the floor became a huge sprite,same thing in the reznor room i suppose,while in the wendy room,the rotating platform seems to become a background while the lave become a huge sprite/multiple sprites i suppose,,trough i wonder how that morton room was done because once he rotates after dying,the background doesn’t become black,so it seems like that room is made out of sprites as well,now if 128 sprites (depending on it’s size and at wich size the snes could handle so much of it),it might could take of half or the whole entire screen,am not sure about that,but if so then sprites could be indeed a great alternative for that,

also i wonder if a mode 7 background can be splitted into many different parts and rotate each part individually,would be great to fake many rotating sprites with it,unless it’s impossible or it has to be done trough software,mmm.

 

 

what’s really disappoints me is that the snes cpu only runs at 3,5mhz,along with slower ram and it only has an 8bit data bus as opposed to a 7,9mhz genesis cpu along with fast ram along with a 16bit data bus,and because of that i sometimes still wich that nintendo opted for a sa1 chip inside the snes,then sega couldn’t use it’s ‘blast processing’ argument against nintendo at all,(but sadly, since genesis games also used hirom chips while most snes games just used the cheaper but slower speed and slightly laggy lorom chips instead,the genesis became just more faster then the snes

oh well, if platform games in japan were just more popular then rpg games at that time,then maybe nintendo would,ve opted for a 10mhz cpu instead,

why am saying this,that because i clearly remember how a nintendo magazine did said that the snes was the fastest 16bit game system,,,thus not.

 

[CPUWIZ]

You should team up with Kirk.

[+GoldLeader]

 

Seriously it's a miracle the SNES outsold  the GBA...

 

 

Or it was a miracle the GBA outsold the SNES...

 

I don't know anymore

 

 

Just that it's a miracle!

[Kirk_Johnston]

Oops! Wrong thread. That's moved to the proper Mode 0 fighting game thread now. Again, this is why a proper delete option would be useful.

 

 

 

 

Edited December 5, 2023 by Kirk_Johnston

[KulorXL]

31 minutes ago, johannesmutlu said:

maybe trough software??

The SNES doesn't have a framebuffer. It's a tile/sprite-based scanline renderer, meaning the only thing being drawn is the current scanline being shown by the display. You can kludge a framebuffer into it, which is what Super FX 3D games like Starfox or Stunt Race FX had to do, but the DMA bandwidth to the PPU is going to be the bottleneck for that, because you only have enough vblank time to transfer about 6 KB per frame, and one fullscreen 4bpp frame is 28 KB.

34 minutes ago, johannesmutlu said:

you can fake an ectra background with mode 7 by using animated tile sets but i can imagine how much extra space that will take up while doing so

There's plenty of cartridge space and RAM for preshifted tiles. The main bottleneck with that approach is again gonna be DMA bandwidth, because each 8x8 tile you need to update is a whopping 64 bytes -- so if you wanted a repeating 32x32 pixel pattern as tile-animated parallax, that would be 1 KB, or 1/6th of your total DMA bandwidth for a frame.

Faking a background layer with sprites was by far the most common approach, along with switching graphics modes mid-screen.

38 minutes ago, johannesmutlu said:

also i wonder if a mode 7 background can be splitted into many different parts and rotate each part individually,would be great to fake many rotating sprites with it

As long as the two (or more) elements don't overlap vertically, totally doable.

41 minutes ago, johannesmutlu said:

what’s really disappoints me is that the snes cpu only runs at 3,5mhz,along with slower ram and it only has an 8bit data bus as opposed to a 7,9mhz genesis cpu along with fast ram along with a 16bit data bus

You can't directly compare clock speeds across architectures like that. The RAM in the Genesis is actually slower than the RAM in the SNES; the 68000 in the Genesis only gets bus access every 4 cycles, whereas the SNES CPU gets bus access every single cycle. The SNES has RAM that can keep up with 2.68 MHz accesses (actually 3.58 MHz in practice, though you can't really use RAM very effectively at that speed), but the Genesis only needs RAM that can keep up with 1.9 MHz accesses. This is also why the 68000 has longer opcode clock cycle counts on average compared to the SNES CPU, which is the biggest reason you can't directly compare clock speeds. The 68000 is probably faster, but you're rarely (if ever) actually getting work done at twice the speed.

The data bus thing is another thing that's really misunderstood. The SNES CPU only has an 8-bit bus, yes, but it's specifically designed to be a 16-bit CPU on an 8-bit bus -- a lot like the 68008 variant of the 68000. The actual consequence of the 8-bit data bus is, on the Genesis, operations with bytes (8-bit values) vs. words (16-bit values) take the same number of cycles, but on the SNES, operations with words take one more cycle compared to operations with bytes. For example...

lda $ABCD

...in 8-bit mode, would require one cycle to fetch the opcode, two cycles to fetch the address, and one cycle to fetch the byte value, for a total of 4 cycles. In 16-bit mode, it would require one cycle to fetch the opcode, two cycles to fetch the address, and then two cycles to fetch the word value, for a total of 5 cycles. I believe the equivalent instruction on the 68000 would require 12 cycles.

In my experience, it usually ends up quicker to just stick to 16-bit mode whenever possible.

 

55 minutes ago, johannesmutlu said:

what’s really disappoints me

On 11/27/2023 at 9:52 AM, johannesmutlu said:

curious about the outcome had nintendo made the snes just a little bit more better along with nes compatibily,who ever knows how much better or woese the snes would,ve sold

See, this is the sort of thinking I just don't really get...

What's so disappointing about it? Sure, I guess it would've been nice (for my purposes at least) if the SNES was a bit faster, though honestly it's not even the first thing I would change about the hardware, but at the end of the day, what would've changed? "Alas, maybe if the hardware was a little bit better, the SNES could've been one of the most popular consoles of its era...maybe it would've even had one of the most legendary libraries of beloved games that are considered all-time greats to this day! Sadly we'll never know..."

I don't know man, sometimes I get the feeling SNES fans hate the thing more than the Sega zealots!

[johannesmutlu]

56 minutes ago, GoldLeader said:

 

Seriously it's a miracle the SNES outsold  the GBA...

 

 

Or it was a miracle the GBA outsold the SNES...

 

I don't know anymore

 

 

Just that it's a miracle!

Either way it is a miracle,am mean in all seriousness,how could nintendo have produces a whopping 81 million GBA systems and 49+ million snes systems in such short time,just think about it how much components,workers and materials will be needed to produce those systems,am mean holy macaroni,

heck even the ps5 has already sold an amezing 40 million inuts,considering there was a chip shortage during the corona crysis and afterwards,how sony pulled this off such huge number in such short time is just incredible,it already surpassed the sales of the N64,atari 2600 and sega genesis etc,,and i guess it wouldn’t be long or the ps5 will surpass the sales of the snes and later on even the nes,but when?

it’s just sooo mind blowing considering the complexity of the ps5 to produce them,same with boththe ps3,ps4,xbox 360,xbox one xbox x etc,,, how they could produce such complex system in such huge amount of quantities,retro consoles weren’t that complex to produce,am mean holy shit. 

Edited December 6, 2023 by johannesmutlu

[TrekkiesUnite118]

Out of curiosity @KulorXL what would you say is the most disappointing part of the SNES hardare?

[WavyGravy]

1 hour ago, johannesmutlu said:

 

what’s really disappoints me is that the snes cpu only runs at 3,5mhz,along with slower ram and it only has an 8bit data bus as opposed to a 7,9mhz genesis cpu along with fast ram along with a 16bit data bus,and because of that i sometimes still wich that nintendo opted for a sa1 chip inside the snes,then sega couldn’t use it’s ‘blast processing’ argument against nintendo at all,(but sadly, since genesis games also used hirom chips while most snes games just used the cheaper but slower speed and slightly laggy lorom chips instead,the genesis became just more faster then the snes

oh well, if platform games in japan were just more popular then rpg games at that time,then maybe nintendo would,ve opted for a 10mhz cpu instead,

why am saying this,that because i clearly remember how a nintendo magazine did said that the snes was the fastest 16bit game system,,,thus not.

 

So, again, the thing is cost. Creating a chip with these capabilities in 1990 was expensive, in 2001 it was cheap. With 6502 and 65816 chips, the memory and CPU need to run at a compatible speed, so using a faster CPU costs more for both the CPU itself and the faster RAM you'd need to use. The variable speed on the SNES is actually quite clever engineering for cost-savings, but having the CPU and RAM be much faster would have required cutting something down somewhere else, like taking the 128kb WRAM down to 64kb or using a different sound chip. 

 

As far as being the fastest, it can be, depending on the situation. Want to rotate and scale a bitmap at full colour and resolution? Even with an ace programmer, the Genesis won't be nearly as fast as the SNES at that. Want to do 3D math and plot the results to the screen? Well, the Genesis makes mincemeat out of the SNES there. It's the fundamental difference between the two architectures and why comparing them is not always simple. The Genesis is designed more for flexibility, the SNES was designed to be really good at specific things. They're just not the same machines at all. I think a lot of the early slowdown issues on the SNES stem from the machine simply being quite exotic at the time, not necessarily the hardware itself being too slow.

[johannesmutlu]

14 minutes ago, KulorXL said:

The SNES doesn't have a framebuffer. It's a tile/sprite-based scanline renderer, meaning the only thing being drawn is the current scanline being shown by the display. You can kludge a framebuffer into it, which is what Super FX 3D games like Starfox or Stunt Race FX had to do, but the DMA bandwidth to the PPU is going to be the bottleneck for that, because you only have enough vblank time to transfer about 6 KB per frame, and one fullscreen 4bpp frame is 28 KB.

There's plenty of cartridge space and RAM for preshifted tiles. The main bottleneck with that approach is again gonna be DMA bandwidth, because each 8x8 tile you need to update is a whopping 64 bytes -- so if you wanted a repeating 32x32 pixel pattern as tile-animated parallax, that would be 1 KB, or 1/6th of your total DMA bandwidth for a frame.

Faking a background layer with sprites was by far the most common approach, along with switching graphics modes mid-screen.

As long as the two (or more) elements don't overlap vertically, totally doable.

You can't directly compare clock speeds across architectures like that. The RAM in the Genesis is actually slower than the RAM in the SNES; the 68000 in the Genesis only gets bus access every 4 cycles, whereas the SNES CPU gets bus access every single cycle. The SNES has RAM that can keep up with 2.68 MHz accesses (actually 3.58 MHz in practice, though you can't really use RAM very effectively at that speed), but the Genesis only needs RAM that can keep up with 1.9 MHz accesses. This is also why the 68000 has longer opcode clock cycle counts on average compared to the SNES CPU, which is the biggest reason you can't directly compare clock speeds. The 68000 is probably faster, but you're rarely (if ever) actually getting work done at twice the speed.

The data bus thing is another thing that's really misunderstood. The SNES CPU only has an 8-bit bus, yes, but it's specifically designed to be a 16-bit CPU on an 8-bit bus -- a lot like the 68008 variant of the 68000. The actual consequence of the 8-bit data bus is, on the Genesis, operations with bytes (8-bit values) vs. words (16-bit values) take the same number of cycles, but on the SNES, operations with words take one more cycle compared to operations with bytes. For example...

lda $ABCD

...in 8-bit mode, would require one cycle to fetch the opcode, two cycles to fetch the address, and one cycle to fetch the byte value, for a total of 4 cycles. In 16-bit mode, it would require one cycle to fetch the opcode, two cycles to fetch the address, and then two cycles to fetch the word value, for a total of 5 cycles. I believe the equivalent instruction on the 68000 would require 12 cycles.

In my experience, it usually ends up quicker to just stick to 16-bit mode whenever possible.

 

See, this is the sort of thinking I just don't really get...

What's so disappointing about it? Sure, I guess it would've been nice (for my purposes at least) if the SNES was a bit faster, though honestly it's not even the first thing I would change about the hardware, but at the end of the day, what would've changed? "Alas, maybe if the hardware was a little bit better, the SNES could've been one of the most popular consoles of its era...maybe it would've even had one of the most legendary libraries of beloved games that are considered all-time greats to this day! Sadly we'll never know..."

I don't know man, sometimes I get the feeling SNES fans hate the thing more than the Sega zealots!

True that,i,ve readed that the snes cpu despite running at 3,5mhz ,does execute each instruction in 1 clock cycle whereas the genesis cpu executes each instruction within 2 clock cycles,the genesis also does have less ram then the snes,but it makes up for it but running at over twice the speed of the snes cpu,

but as far i have noticed,there is less slowdown in genesis games then on the snes,or it was really the lorom chip used in most snes games that hinder it’s full fast performances,

yes,back then i really did loved my snes,but the more i learned about it’s weakness and limitations,the more i slowly got disappointed,but the more i learned about those tricks to get around those limitations,the more i loved the snes again,also the more i am able to retrieve those magic feeling and fond memories i got with the snes the more i do love the snes again like i did back then in the 90’s,it was a time when technology didn’t really mattered to me except for it’s games,nowadays i think in between,am curious about the technology of systems and games has to be fun,BUT it’s also a matter of creativity,if you as a developer could get more out of a hardware then what was originally intended,than that’s incredible,but if a game developer simply doesn’t know what to do with such powerful hardware and only puts the least power out of it,then that’s a real shame.

[johannesmutlu]

7 minutes ago, WavyGravy said:

So, again, the thing is cost. Creating a chip with these capabilities in 1990 was expensive, in 2001 it was cheap. With 6502 and 65816 chips, the memory and CPU need to run at a compatible speed, so using a faster CPU costs more for both the CPU itself and the faster RAM you'd need to use. The variable speed on the SNES is actually quite clever engineering for cost-savings, but having the CPU and RAM be much faster would have required cutting something down somewhere else, like taking the 128kb WRAM down to 64kb or using a different sound chip. 

 

As far as being the fastest, it can be, depending on the situation. Want to rotate and scale a bitmap at full colour and resolution? Even with an ace programmer, the Genesis won't be nearly as fast as the SNES at that. Want to do 3D math and plot the results to the screen? Well, the Genesis makes mincemeat out of the SNES there. It's the fundamental difference between the two architectures and why comparing them is not always simple. The Genesis is designed more for flexibility, the SNES was designed to be really good at specific things. They're just not the same machines at all. I think a lot of the early slowdown issues on the SNES stem from the machine simply being quite exotic at the time, not necessarily the hardware itself being too slow.

True that,it’s eventually the costs you have to take into consideration and it is actually very interesting how companies not only try to cut costs down but also try to find ways around it to justify such low cost,

for example,i can choose between a 4 background layer chip,or i could go for a single background layer chip,but i can implement a irq counter request feature to fake a 4 background layer by deviding it into 4 parts,

instead for a digital sound chip i could go for a cheaper  psg sound chip but to fake digital sound,i could mix all 4 soundchannels together and then quickly alternate the volume to create a wave form to fake digital sound,i could go for a 64 color chip instead of a 256 color chip but to fake 256 colors on screen,i could implement color blending,color dithering & blurring or quick color alternating to fake a 256 color image etc,,,

it’s just sooo cool to see what can be done with limited technology,as they said,’limitations leads to creations’

[KulorXL]

27 minutes ago, TrekkiesUnite118 said:

Out of curiosity @KulorXL what would you say is the most disappointing part of the SNES hardare?

I don't know if I'd say it's a "disappointing part of the hardware" so much as "disappointing that they either didn't catch it in development or were too cheap to fix it"...so there's two big limitations that make sprites on the SNES more limited than other systems, and which somewhat nullify the advantage of having 128 hardware sprites: only being able to select between two different sizes, and only having a 16KB VRAM page for sprite graphics. But the reason those limitations exist is the worst part. Basically, if you look at the OAM (sprite table) layout, each sprite gets 9 bits for X position, 8 bits for Y position, 9 bits for tile, 2 bits for priority, 3 bits for palette, 2 bits for vertical/horizontal flipping, and then 1 bit for size: add it all up, and that's 4 bytes + 2 bits, with no space for anything extra. For 128 sprites, that means 512 + 32 bytes total, which they put off in a special portion of RAM that's exactly that large. The reason you can only pick between two sizes is because there's only that one bit to control it. Similarly, the reason you only get 16KB worth of tiles is because that's all you can address with 9 bits. Had they simply doubled the OAM RAM and put in 1KB instead of 512 + 32 bytes, neither of those limitations would have existed. And actually, had they taken OAM RAM out entirely and just had OAM live in VRAM like the Genesis, they wouldn't have even needed to have added any extra RAM for sprites...plus then you might have had the opportunity for sprite multiplexing, which doesn't work on the SNES at all because of the OAM RAM. It's literally less than half a kilobyte away from having totally fixed two of the biggest limitations of the system.

After that, I would add more VRAM, because really the 8bpp modes need more than 64KB. Gimme that, then we can start talking about bumping up the CPU speed...

EDIT: Also, adding to the less than half a kilobyte thing, I also have to waste about 10 lines of raster time fiddling bits to build the upper 32 byte table of OAM, and it's something every SNES game needs to deal with. Double the OAM RAM and you would also save a bunch of CPU time too!

Edited December 6, 2023 by KulorXL
addendum

[Tanooki]

3 hours ago, TrekkiesUnite118 said:

Out of curiosity @KulorXL what would you say is the most disappointing part of the SNES hardare?

My guess it lacked enough bits to fit the W into hardare.

[Austin]

17 hours ago, Kirk_Johnston said:

Oops! Wrong thread. That's moved to the proper Mode 0 fighting game thread now. Again, this is why a proper delete option would be useful.

 

 

 

 

A proper downvote button would be useful too. 🤔