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

[Aaendi]

On 12/5/2023 at 6:41 PM, johannesmutlu said:

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.

Instructions on 68000 take 4+ cycles, and use 4 cycles per memory access.

 

Instructions on the 65816 take 2+ cycles, and use 1 cycle per memory access.

[TrekkiesUnite118]

54 minutes ago, Aaendi said:

Instructions on 68000 take 4+ cycles, and use 4 cycles per memory access.

 

Instructions on the 65816 take 2+ cycles, and use 1 cycle per memory access.

Now Aaendi we both know this is incredibly misleading on both sides. Yes the fastest instruction on the 65816 is two cycles, that's not every instruction and many of them take as much or more than their 68k equivalent. Secondly you're going to write code differently for both CPUs. On the 65816 you will be accessing memory directly a lot because that's how the CPU is designed. On the 68k you're going to be loading values into its registers and working against those instead of constantly accessing memory. That will have an impact in performance. And that's not even touching on the differences in clock speed.

 

Trying to directly compare the two CPUs like this is an apples to oranges comparison and only serves to fuel console wars.

[Aaendi]

He probably already knows that.  He already mentioned that the 68000 has a bigger data bus.

Edited December 7, 2023 by Aaendi

[CPUWIZ]

On 12/6/2023 at 8:52 AM, Austin said:

A proper downvote button would be useful too. 🤔

That's why we don't have one, negativity is spreading in this world so rapidly, because a lot of people jump on internet "bandwagons", without thinking, just BECAUSE.

[johannesmutlu]

18 hours ago, TrekkiesUnite118 said:

Now Aaendi we both know this is incredibly misleading on both sides. Yes the fastest instruction on the 65816 is two cycles, that's not every instruction and many of them take as much or more than their 68k equivalent. Secondly you're going to write code differently for both CPUs. On the 65816 you will be accessing memory directly a lot because that's how the CPU is designed. On the 68k you're going to be loading values into its registers and working against those instead of constantly accessing memory. That will have an impact in performance. And that's not even touching on the differences in clock speed.

 

Trying to directly compare the two CPUs like this is an apples to oranges comparison and only serves to fuel console wars.

Well if this is true that the 65C816 cpu executes instructions faster then the 86000 cpu and if it is true that the snes not only does have twice the ram but also just slightly faster ram then that of the genesis,then maybe nintendo wasn’t bull claiming at all,because according to a dutch nintendo magazine,they claimed that programs could run faster on the snes as stated by a research team of data retrieval analysis,i don’t know if this is true or not but if this is all true,then that blast processing claim of the sega genesis just might be busted,if that slightly over twice the speed of the 68000 cpu makes little sense only just to keep up to be equal in terms of speed with that of the 65c816 cpu,then we might could conclude that the snes cpu does have an advantage over the genesis cpu,but so far i don’t know,as far i,ve seen games such as street fighter 2 and hard driving among others do run much faster on the sega genesis,BUT it may comes down to the fact that most snes games just use that cheap ass lorom chip wich slows things down on the snes,with hirom you can get the maximum speed out of the snes,so if we could compare 2 games on both systems with both using hirom chips and compare it’s speed then we may conclude wich system is faster,but again i don’t know,

so far i,ve seen some genesis games do have mode 7 trough software without dramatically slwing down the cou,other games do have some interesting 3D effects trough software in wich i haven’t seen on the snes,

and then theres the data bus difference between those two chips,if it is true that the 68000 cpu does have a 16bit databus as opposed to the 8bit databus of the 65c816 cpu,then i still do think that the 68000 does have a huge advantage over 65c816 cpu,well maybe not,maybe i do have it wrong,maybe if we could wrap things between those twp cpu’s and conclude wich cpu is really faster or if they are both just equal in performances.

another thing i found interesting is that nintendo and many thirth parties did  sneakingly used enhancement chips in many snes games (with the fx chip being only noted on the box art of certain games) this giving me the impression that the snes become sooo weak that it did needed extra chips for other tasks (for years i didn’t knew a stock snes couldn’t handle mario kart) whereas on the genesis there were no games with enhanced chips inside with the exception of virtua racing,

but again am very curious what could be done on a stock snes without slowing things down to a slide show or get it run to an acceptible level,hpw about mario kart,yoshi’s island,mega man X etc,,,

 

[Austin]

2 hours ago, CPUWIZ said:

That's why we don't have one, negativity is spreading in this world so rapidly, because a lot of people jump on internet "bandwagons", without thinking, just BECAUSE.

I don't disagree and I don't care for the focus on negativity myself either. That said, I think there are a handful of cases where it might prove useful. Pinside always shows both upvotes and downvotes on a post. It sort of lets you get an idea where the forum regulars stand on certain issues along with what the general consensus/feeling is with certain topics (since not everyone is going to respond with a written post). Also, there are some forums that do the, "This post has been hidden because it has been downvoted heavily; click here to see the original post", and I can choose whether or not to take a look at the post.

 

I know a downvote system here will likely never be implemented, so I just take the sadface option as, in most cases (like with this thread), to be the "downvote" button.

[TrekkiesUnite118]

14 hours ago, johannesmutlu said:

Well if this is true that the 65C816 cpu executes instructions faster then the 86000 cpu and if it is true that the snes not only does have twice the ram but also just slightly faster ram then that of the genesis,then maybe nintendo wasn’t bull claiming at all,because according to a dutch nintendo magazine,they claimed that programs could run faster on the snes as stated by a research team of data retrieval analysis,i don’t know if this is true or not but if this is all true,then that blast processing claim of the sega genesis just might be busted,if that slightly over twice the speed of the 68000 cpu makes little sense only just to keep up to be equal in terms of speed with that of the 65c816 cpu,then we might could conclude that the snes cpu does have an advantage over the genesis cpu,but so far i don’t know,as far i,ve seen games such as street fighter 2 and hard driving among others do run much faster on the sega genesis,BUT it may comes down to the fact that most snes games just use that cheap ass lorom chip wich slows things down on the snes,with hirom you can get the maximum speed out of the snes,so if we could compare 2 games on both systems with both using hirom chips and compare it’s speed then we may conclude wich system is faster,but again i don’t know,

so far i,ve seen some genesis games do have mode 7 trough software without dramatically slwing down the cou,other games do have some interesting 3D effects trough software in wich i haven’t seen on the snes,

and then theres the data bus difference between those two chips,if it is true that the 68000 cpu does have a 16bit databus as opposed to the 8bit databus of the 65c816 cpu,then i still do think that the 68000 does have a huge advantage over 65c816 cpu,well maybe not,maybe i do have it wrong,maybe if we could wrap things between those twp cpu’s and conclude wich cpu is really faster or if they are both just equal in performances.

another thing i found interesting is that nintendo and many thirth parties did  sneakingly used enhancement chips in many snes games (with the fx chip being only noted on the box art of certain games) this giving me the impression that the snes become sooo weak that it did needed extra chips for other tasks (for years i didn’t knew a stock snes couldn’t handle mario kart) whereas on the genesis there were no games with enhanced chips inside with the exception of virtua racing,

but again am very curious what could be done on a stock snes without slowing things down to a slide show or get it run to an acceptible level,hpw about mario kart,yoshi’s island,mega man X etc,,,

 

The issue is that it's not an absolute rule that holds true for every single instruction, which is why I said it's misleading. Here are the clock counts for each CPU instruction for both CPUs:

https://wiki.superfamicom.org/65816-reference

https://wiki.neogeodev.org/index.php?title=68k_instructions_timings

 

Yes, there are some on the SNES that take only 2 cycles. But a lot of them take 4, 5, 6, or even 7. Yes Memory access is faster on the 65816. But this is where the way you would program on each CPU comes into play. How you write code for the 6502/65816 is very different from how you would write code for the 68000. If you look at the 68000 cycle timings, you'll see that when working against registers it's a lot faster than when it's working directly against memory, and you have a lot more registers on the 68000 than you do on the 65816. So on the 68000 you're going to load values into the registers and work against those directly and only read in from memory when you have to, while on the 65816 you're going to be reading from memory more frequently because you don't have a ton of registers to work with. Which is why if you were to take pure 65816 code and port it directly to the 68000, it would probably be rather poor performing, same if you did the opposite. But the reality is any good programmer for either system wouldn't do that. They'd rework the code to be optimal for each system.

 

The other factor that comes into play is the clock speed. The Genesis CPU is clocked at 7.6MHz, the SNES at best is 3.58MHz. So the Genesis CPU is a little over 2x faster in pure clock speed than the SNES, what this means in clock cycles is it has a little over twice as many to work with per second than the SNES does. So that instruction that takes 2 cycles on SNES, at it's clock speed you an do about 1.79 Million of them per second. On Genesis that instruction that takes 4 cycles you can do about 1.9 million of them per second.

 

This is why it pretty much becomes an apples to oranges comparison. Other bottlenecks of each system start to play a bigger role than just the CPU clock rate or how many cycles the CPU instructions take.

[CapitanClassic]

On 12/8/2023 at 7:38 AM, Austin said:

Pinside always shows both upvotes and downvotes on a post. It sort of lets you get an idea where the forum regulars stand on certain issues along with what the general consensus/feeling is with certain topics

And nothing bad will ever happen.

 

[johannesmutlu]

10 hours ago, TrekkiesUnite118 said:

The issue is that it's not an absolute rule that holds true for every single instruction, which is why I said it's misleading. Here are the clock counts for each CPU instruction for both CPUs:

https://wiki.superfamicom.org/65816-reference

https://wiki.neogeodev.org/index.php?title=68k_instructions_timings

 

Yes, there are some on the SNES that take only 2 cycles. But a lot of them take 4, 5, 6, or even 7. Yes Memory access is faster on the 65816. But this is where the way you would program on each CPU comes into play. How you write code for the 6502/65816 is very different from how you would write code for the 68000. If you look at the 68000 cycle timings, you'll see that when working against registers it's a lot faster than when it's working directly against memory, and you have a lot more registers on the 68000 than you do on the 65816. So on the 68000 you're going to load values into the registers and work against those directly and only read in from memory when you have to, while on the 65816 you're going to be reading from memory more frequently because you don't have a ton of registers to work with. Which is why if you were to take pure 65816 code and port it directly to the 68000, it would probably be rather poor performing, same if you did the opposite. But the reality is any good programmer for either system wouldn't do that. They'd rework the code to be optimal for each system.

 

The other factor that comes into play is the clock speed. The Genesis CPU is clocked at 7.6MHz, the SNES at best is 3.58MHz. So the Genesis CPU is a little over 2x faster in pure clock speed than the SNES, what this means in clock cycles is it has a little over twice as many to work with per second than the SNES does. So that instruction that takes 2 cycles on SNES, at it's clock speed you an do about 1.79 Million of them per second. On Genesis that instruction that takes 4 cycles you can do about 1.9 million of them per second.

 

This is why it pretty much becomes an apples to oranges comparison. Other bottlenecks of each system start to play a bigger role than just the CPU clock rate or how many cycles the CPU instructions take.

Well explained and it is something pretty interesting,now while it all depends on programming stuff,but to wrap it all up,i still do think that in terms of performances the genesis cpu does still do outshine the 65c816 cpu by just a little bit,

now about reprogramming the same game for a different system,at one hand i can understand that if a developer wants to port a game from the genesis to snes or vice versa,he has to rewrite the code all the way from scratch to make sure port of a game will run optimally on another system,at the otherhand i can imagine that this is a time wasting costly process so i do wonder sometimes,don’t they use a recompilor to recompile a source code into another languange and then debug & optimize it or use a similar code from another game from the target platform and moddifie that game engine to be more in line with the game you want to port that target platform just to save lot’s of time & money????

would be interesting if they did used (and do use) a semi automatic porting process to speed up the whole prcess,

same thing with graphics & sounds,you might think that they do convertor tools to convert graphical tile sets to be compatible with other systems,including color bit depth,stretch it into portret or landscape size depending on the system’s target resolution,rather having to redoing all tile sets,

or use those midi command from a game and replace those instruments with instruments for the target system and then listen to them at what sounds best to them just to avoid replaying those song all over again etc,,,

so am curious about all those things,and seeing how similar ported games could end up,i can’t imagine doing all stuff from scratch again without oversights and without missing the deadline,considering how many games did and do get popped up on the market!!!

[turboxray]

 I think the focus on "8bit data bus" or "16bit data bus".. at whatever speeds - is completely irrelevant. Why? Because you're not engineering NEW hardware. You don't have a choice in anything - what you get is what is there and implemented. So talking about it like it you have some sort of control over it, is useless. We're talking about software development, not hardware development. We're talking about making games - so that's the ONLY thing that matters.. performant code; how performant is the code, right? That's literally it. I have no idea why people get wrapped up in the "here's the bandwidth transfer rate in 1 second for the bus". It's not like you can change this. The same goes for stuff like the ALU. Unless you're a hardware designer that develops processors - the actual size of the ALU is completely irrelevant. What you care about is the register size, instruction speed, and what can you do with it. The z80 reportedly has a 4bit ALU.. yet we don't go around proclaiming the z80 is a 4bit processor (because that would be ridiculous). Like wise, the original 68k to a software developer is no different than a 32bit processor.. because you have a support of 32bit operations. It IS a 32bit processor.. don't care what the ALU is or the bus size (it could be super fast 1bit serial for all I care). The only thing I care about is; do I need a 32bit operation, and if I don't does the 16bit equivalent perform faster? That's it.

 

 That said, the 65816 is basically the 8bit 65x design. Sure, a few extra nice stack interface instructions, but it's just an extension of the same design. And in that respect, the 65x design and the 68k design CANNOT be compared directly, nor can you compare it based solely on speed (mhz). 68k instructions on average take more clock cycles than 65x or '816 design, but you get more bang for your buck on the 68k. Where it matters, is when you don't get those "extended bucks" on the 68k for whatever operations. What do I mean by this? If you do 8bit operations on the 68k it has no performance improvement (i.e. less clock cycles) than the 16bit equivalent. By extension, some stuff HAS to be 32bit on the 68k (address vector stuff), so instructions supporting 32bit operations are used - even if you only need say 16bit or 24bit. The 65x and '816 can gain performance in these in-between areas. There's a lot of core logic that goes into a game in which fast small instructions get the job done; stuff like mask checking, JSR/RTS, etc - stuff like direct memory access and/or R-M-W related instructions. People like to focus on "16bit math", but a game isn't some giant ass page of "calculator like instructions" - there's a lot of other logic. 65x design is built on small simple but fast instructions. And in a game machine were a lot of the heavy lifting is done with auxiliary hardware (video, sound, dma, etc) - the scope of what the processor code looks like, comings down to more basic tasks and not "crunching" so much. So the realized gains on the 65x design needs a look at the holistic picture, because if you try to narrow the focus too much, you miss out on this important detail. The 68k is an amazing processor, MEANT for an OS with applications running on a small computer. The fact that it does not hog the bus, is by design for this very reason and is important in that context - as well as relocatable code, etc. That's not an issue on these consoles. The analogy I like to use is; the 68k is like a slower small truck - you can haul a lot of stuff in a single trip. The 65x design is like a two-seater sports car. It's fast, but you can't load much up in a single trip. So, optimize for what you can. It's not the best analogy, but it hopefully shows you can't simply boil things down to apples-to-apples comparisons. 

 

 All that techno jarble out of the way, what is the performance difference between these two processors in the context of similar gaming hardware setups? I'd say the '816 in the SNES (with optimal code) is roughly ~70% of the performance of the 68k - taking into consideration actual clock speeds, ram delays, and the SNES running with fastrom. Keep in mind, the '816 realized performance is NOT 3.57mhz in fastrom - it's about 3.08mhz because of slower work ram access. The point here, is that the SNES processor is not 50% the performance of the 68k in the MD. Depending on the game logic requirements, SNES could be a little less than 70%. But the important thing to note here is the catch; optimal code. What REALLY separates these two designs, is that you can get performant code out of the 68k pretty easily. The entry to barrier for performant code is pretty low on the 68k - it's almost automatic haha. That is NOT a true statement for 65x design, which extends to the '816. When time is a huge factor for development to release cycle, THAT matters. In my opinion, this is one of the main reasons why you see the 68k in sooo many arcade systems. It comes in high clock speeds, and you don't have to write convoluted code and come up with convoluted data structures for optimization like you do with the 65x design. Sega, being an arcade developer first and foremost - had to have known this and is most likely why they chose the 68k for the MD. There's "true performance" and then there's "realized/practical performance". And all these discussions love to talk about the potential to "true performance". But how realistic is that?

 

 The other side of that coin is.. how much performance is a game using per frame? Because it's probably rare that it's always using near 100%. And because of "frame locking", it's possible that a single instruction can cause "slow-down". The only thing gamers see is that either the game slowed down or it didn't. They have no idea about by what percentage did the game "missed its mark", but yet we love to talk about specs and capability. I dunno.. I think that's an important piece of the understanding, before you can claim this or that in broad context. If a game on the SNES blows the frame budget by 2-3% when it slows down... that is a big difference compared to something like 20-30% (even if the user experience is the same). That's a part of the performance conversation, but we never talk about it. And so I don't think you can really talk about performance if you don't have an accurate understanding of what impacts that performance and by how much. On the flip side, if you have processor X running at Y mhz/speed, but no game taxes the process for the full frame performance budget.. that number becomes less meaningful. As in, "this system runs at 12mhz".. but the system under load never requires that upper limit, say gets close to 75% of that limit, then that number doesn't have the context that it needs. Take the thought experiment of dropping a 12mhz 68k into the NES... what does that net you? After a certain point.. most of it is wasted/unneeded. Because the processor does not drive the audio and video in a "raw" sort of way. You'd have a lot of ideal time spinning on the frame lock. 

Edited December 9, 2023 by turboxray

[jeffythedragonslayer]

7 hours ago, turboxray said:

I have no idea why people get wrapped up in the "here's the bandwidth transfer rate in 1 second for the bus".

I think people are just trying to get an idea of how far the system can be pushed.  That's why I've run numbers on DMA bandwidth limits on the SNES.

[Razzie.P]

1 hour ago, jeffythedragonslayer said:

I think people are just trying to get an idea of how far the system can be pushed.  That's why I've run numbers on DMA bandwidth limits on the SNES.

It only weighs about 2 pounds or so, so it shouldn't be hard to push it however far is needed.  Honestly, though, I'd just pick it up and carry the thing, but I'm no tech guru, so y'all do whatever you feel is best.

[CPUWIZ]

I am beginning to think that JM is a slightly buggy bot.

[Aaendi]

On 12/5/2023 at 7:01 PM, KulorXL said:

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!

The SNES would've either needed to remove BG3, or doubled VRAM bandwidth in order to read OAM from VRAM.

[Kirk_Johnston]

If find it interesting that the SNES, while still being very capable in the sprite department, is actually pretty dang awesome when it comes to backgrounds. In some ways it's better than competing systems in terms of its sprite capabilities and some ways not, but with the backgrounds it's pretty much top of the class almost across the board. And I think the background capabilities are where the SNES has still yet to be fully explored and utilized in so many ways. I don't mean it's still to be technically understood--that's all been documented multiple times over at this point--but just that not a lot of games truly take full advantage of an area the SNES excels at. And, when you combine that with its still great sprite capabilities plus just everything around colour really, I think that's when it's possible to really show off what the SNES is properly capable of.

 

In fact, returning to the title/question of the thread, the background capabilities are often the ideal solution to at least give the illusion of sprite scaling and rotation, if such effects are what you're looking for.

 

Watch the green lizard guys in the background jump and scale towards the camera from 4:02:

 

The jumping and rotating boss at around 1:25:45, who also scales smaller when defeated:

 

The scaling ship and planet from around 1:12:44:

 

The large scaling Kyote from around 7:15:

 

The scaling octopus that hits the screen at around 1:04:

 

The scaling boss and then his head shooting towards the screen too from around 1:48:53:

 

Etc.

Edited December 11, 2023 by Kirk_Johnston

[KulorXL]

2 hours ago, Aaendi said:

The SNES would've either needed to remove BG3, or doubled VRAM bandwidth in order to read OAM from VRAM.

Then they should've just doubled OAM. Doesn't seem like adding another 500-odd bytes would have added much to the cost of the system. I don't think that would affect sprite caching because it's still caching the same number of tile slivers per-row.

[Aaendi]

I think a while ago, we figured out that just 5 bytes per sprite would be enough for everything, with the addition of a transparency enable bit.

 

XXXXXXXX

SSSSPPTX

YYYYYYYY

NNNNNNNN

HVCCCNNN

[turboxray]

On 12/5/2023 at 6:01 PM, KulorXL said:

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!

Yeah, given all the capabilities of the color formats and BG layers, the amount of vram is weirdly small. Maybe doesn't have to be 128k, but something like 96k with the last 32k mirrored would have been fine. It's just soo cramped. And making the two sprite banks 16k and not 8k. The sharp X68000 is pushing the vram bandwidth, but it's has segmented/separate/dedicated sprite cell vram to help get it there. Nintendo could have gone with a similar route. I would love to know the detailed development history, and what was priority and when stuff was added/changed during the development cycle. It feels like the focus was primarily on BGs (from early shots), and what they ended up with sprites was probably what they started out with.. maybe originally only having 8x8 and 16x16 as the only two sizes (128 16x16 sprites is 16k.. maybe just a coincidence?). I'm a curious as to when they decided to add color math support during development. I feel like that could have been late in development.

 

 On a related note, a lot of arcade systems right around the late 80s up until '90, typically only have support for 16x16 cell size for sprites. CPS-1 arcade system CANNOT fill the entire screen with sprites, yet the SNES/PCE/MD can easily do this (and more). Where the CPS-1 shines with sprites, is the sprite pixel line limit. But that's about it. Sharp X68000 is like the CPS-1 in this respect but has even more limited total screen coverage for sprites with a bit of healthy sprite line limit (not close to the CPS-1, tho). This is a nice site delving into it: https://fabiensanglard.net/cps1_gfx/index.html

Edited December 12, 2023 by turboxray

[jeffythedragonslayer]

14 hours ago, turboxray said:

128 16x16 sprites is 16k.. maybe just a coincidence?

Excellent observation.  I should start mentioning that when I'm teaching people about VRAM limitations.

But this is not a coincidence!

Edited December 12, 2023 by jeffythedragonslayer

[Aaendi]

What's even more cursed than making sprite VRAM half the size of the screen, is that you can only update 1/4 of that per frame, under most circumstances.

[Kirk_Johnston]

44 minutes ago, Aaendi said:

What's even more cursed than making sprite VRAM half the size of the screen, is that you can only update 1/4 of that per frame, under most circumstances.

That's why trying to do something different with stuff like Mode 0 is very interesting imo, because you can use four full background layers there (alongside all 128 sprites if you like), so you could maybe use a couple backgrounds for larger enemies rather than lots of sprite-based enemies all the time or whatever (as just one example of many of how this mode can be used), and then you're able to update a lot more tiles per frame for those background-based characters than you could otherwise. All you have to do then is figure out how to work with 2bpp tiles to make it look good. But it's still 24 visible colours per layer (with their own dedicated palettes too), and that's from a master palette of 32,768, which does actually help with that 2bpp colour limitation to a degree. Plus, you can even use semi-transparency and row/line scroll effects, and I think even mosaicing too, on those background-based characters if you like as well. It's not typical and obvious, and it requires thinking about overcoming certain limitations of its own, hence it was very rarely used if at all, but it's certainly another option on SNES.

Edited December 12, 2023 by Kirk_Johnston

[CPUWIZ]

Roadrunner used pre-scaled sprites, @riffraff wrote it, ex-roommate and co-worker at ICOM.  IIRC, got some of my code in it.

[TrekkiesUnite118]

31 minutes ago, Kirk_Johnston said:

That's why trying to do something different with stuff like Mode 0 is very interesting imo, because you can use four full background layers there (alongside all 128 sprites if you like), so you could maybe use a couple backgrounds for larger enemies rather than lots of sprite-based enemies all the time or whatever (as just one example of many of how this mode can be used), and then you're able to update a lot more tiles per frame for those characters than you could otherwise. All you have to do then is figure out how to work with 2bpp tiles to make it look good. But it's still 24 visible colours per layer, and that's from a master palette of 32,768, which does actually help with that 2bpp colour limitation to a degree. Plus you can even use semi-transparency and row/line scroll effects on those background-based characters if you like as well. It's not typical and obvious, and it requires overcoming certain limitations of its own, hence it was very rarely used if at all, but it's certainly another option on SNES.

As @turboxray has pointed out multiple times, the issue with 2bpp is that you're limited to 4 colors per tile. That's a far more serious limitation and will cause some serious visible issues in the art. It's not really accurate to say you have 24 colors to work with as you can't use them all freely as you'd like.

Edited December 12, 2023 by TrekkiesUnite118

[Wayler]

As a sad side effect in all of this, I'm starting to hate lions. And parrots, because that's basically what he is.

 

Endless posts of "this x thing I understand nothing about would be a cool use of SNES capabilities. Hopefully we will see something in the future" 

 

" "

 

[OldSchoolRetroGamer]

2 hours ago, Wayler said:

As a sad side effect in all of this, I'm starting to hate lions. And parrots, because that's basically what he is.

😜