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

[Aaendi]

3 hours 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 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.

That doesn't really help with the 16kB Sprite VRAM limit.  Even though I was able to get around it with a dynamic animation engine, it still restricts the way I use sprites because everything has to be treated like an animated sequence, even when it's not animated.

[CPUWIZ]

😝

[Kirk_Johnston]

10 hours ago, Aaendi said:

That doesn't really help with the 16kB Sprite VRAM limit.  Even though I was able to get around it with a dynamic animation engine, it still restricts the way I use sprites because everything has to be treated like an animated sequence, even when it's not animated.

Yeah, there's nothing that can ultimately get around the actual hardware limitations of any systems as they are what they are. So, my thinking in general with stuff like that is coming up with other ways to do cool things on the SNES that play to its specific strengths in that generation while still pushing those typical things are far as you can too.

 

One suggestion for getting the best from the limited sprite VRAM and how much you can DMA per frame, etc, would be doing something similar to what Maxwell and indeed RARE too did with the sprites, where they didn't try to do it all in a single frame (along with some other sprite management things), so the end result of there being giants sprites and/or a lot more animation was achieved. And no one just playing games knew any different; all they saw were huge sprites and/or lots of nice animation. Job done. Your dynamic animation engine is a great solution there similarly. And if you combined stuff like that with novel ways of using say the extra low-colour background layers and such for an extra large enemy or more animated tiles, or push the background overlapping and parallax effects to the absolute max, or sometimes have all that lovely sprite work playing out in a gorgeous 8bpp level or the like, and so on too, then I think you could have additional stuff there that conveys the same overall end illusion of there just being lots of dynamic motion in the game and so on.

 

Look at this little old NES game for example, where I think it's the backgrounds that often sell the game's overall spectacle far more than the sprites:

 

If you combine that level of background flair but pushed to absolute its limits on SNES alongside similarly pushing the sprites to their limits too . . .

 

The SNES is still great with sprites, but I've come to realise that it truly excels when it comes to the background modes combined with the likes of HDMA, colour math, all the colours, row/line/column scrolling, Mode 7, and everything around that stuff, and I think those elements are still yet to be fully exploited and taken advantage of beyond the kinda obvious and/or bare minimum in most games to be honest, especially many modern indie/homebrew games. It seems most developers are still stuck in an old status quo paradigm where consoles tended to have maybe one or two background layers with a single mode and then the sprites, so the idea was to just draw a decent background as a backdrop for the action, maybe fake a little extra parallax and motion with the background(s), and then get to work on doing everything else with the sprites. Whereas I think the SNES actually kinda flips that entire focus on its head and is a pretty hardcore background engine that also just happens to do comparatively competitive sprite stuff too, and really playing into that opens up a lot of possibilities there, at least as I see it. So I'd personally say there's generally still lots to be achieved in that regard. That's just my thinking on it anyway.

 

Regardless, you're doing great work on your own game and certainly showing off what's possible with the sprites for sure.

Edited December 13, 2023 by Kirk_Johnston

[jeffythedragonslayer]

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

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

Your feeling is correct.  But the opposite of love is not hate.

[Aaendi]

8 hours ago, Kirk_Johnston said:

One suggestion for getting the best from the limited sprite VRAM and how much you can DMA per frame, etc, would be doing something similar to what Maxwell and indeed RARE too did with the sprites, where they didn't try to do it all in a single frame (along with some other sprite management things), so the end result of there being giants sprites and/or a lot more animation was achieved. And no one just playing games knew any different; all they saw were huge sprites and/or lots of nice animation. Job done.

...and that's exactly why doing a dynamic animation engine interferes with gameplay logic.  The objects routines themselves have no way of knowing if the intended sprites can be displayed properly until the next frame.  Everything has to be organized a certain way to keep track of the previous frames, which can result in a "one meta-sprite per object" limitation, unless you come up with a standard way of storing multiple meta-sprites per object, which eats up memory a lot quicker than being able to immediately call a sprite drawing code, and then forget about it.

Edited December 13, 2023 by Aaendi

[Kirk_Johnston]

2 hours ago, Aaendi said:

...and that's exactly why doing a dynamic animation engine interferes with gameplay logic.  The objects routines themselves have no way of knowing if the intended sprites can be displayed properly until the next frame.  Everything has to be organized a certain way to keep track of the previous frames, which can result in a "one meta-sprite per object" limitation, unless you come up with a standard way of storing multiple meta-sprites per object, which eats up memory a lot quicker than being able to immediately call a sprite drawing code, and then forget about it.

The exact management part I don't really know about to be honest, but it seems like you're doing a great job of working with/around it with all the sprite stuff in your game, even though I'm sure it's not easy pushing these old systems to their limits, so keep up the great work and know that it's appreciated.

Edited December 13, 2023 by Kirk_Johnston

[turboxray]

On 12/13/2023 at 1:40 AM, Kirk_Johnston said:

Yeah, there's nothing that can ultimately get around the actual hardware limitations of any systems as they are what they are. So, my thinking in general with stuff like that is coming up with other ways to do cool things on the SNES that play to its specific strengths in that generation while still pushing those typical things are far as you can too.

 

One suggestion for getting the best from the limited sprite VRAM and how much you can DMA per frame, etc, would be doing something similar to what Maxwell and indeed RARE too did with the sprites, where they didn't try to do it all in a single frame (along with some other sprite management things), so the end result of there being giants sprites and/or a lot more animation was achieved.

This is literally a common thing. It's called scheduling and slot access. It's been happening since the 8bit consoles, btw. It's not novel or new, but that's just your thinking on it.. anyway.

 

On 12/13/2023 at 1:40 AM, Kirk_Johnston said:

And no one just playing games knew any different; all they saw were huge sprites and/or lots of nice animation. Job done. Your dynamic animation engine is a great solution there similarly. And if you combined stuff like that with novel ways of using say the extra low-colour background layers and such for an extra large enemy or more animated tiles, or push the background overlapping and parallax effects to the absolute max, or sometimes have all that lovely sprite work playing out in a gorgeous 8bpp level or the like, and so on too, then I think you could have additional stuff there that conveys the same overall end illusion of there just being lots of dynamic motion in the game and so on.

 

Look at this little old NES game for example, where I think it's the backgrounds that often sell the game's overall spectacle far more than the sprites:

 

If you combine that level of background flair but pushed to absolute its limits on SNES alongside similarly pushing the sprites to their limits too . . .

 No system is going to be pushed to its "absolute" limits. For one, you (as in you specifically, Kirk), don't even know what that looks like. You have this distorted view of what is means to push the system, and how it has 'not been pushed'. The system has been pushed in a lot of different ways in which you give the developers NO credit for... because again, you lack the technical understanding to evaluate such things. You simply focus on "flashy" and stylistic stuff as your measurement stick. Some of the most impressive pixel art (tiles for BG work) for that era was done by developers working on the SNES. I never see you once note this or gush over this. Why? Because you obviously lack any sort of programming/development experience where these sorts of things are obvious. Same with audio. It's like you're only ADHD hyper-focuses "busy" visual flare and can't appreciate/understand the finer details of what it means to push the system; a very simplistic view/understanding of things. Which is strange for someone that tries to where the SNES developer badge. I'm not saying flashy isn't good... but it's only one part. Aaendi is working on a dynamic allocation system for hardware sprite cells (vram) for meta-sprite handling. That's advanced level and noble effort. That's pushing the system. Oh well, that's just your thinking on it.. anyway.

 

 But yeah, absolute limits. It's kind of a ridiculous phrase and mentality. I'd say, given all the things commercial games HAVE done, and the frequency in which said thing have occurred (or in AAA titles), the SNES has pretty much demonstratively pushed into the ~90% range of its capabilities in one way or another. 90%.. and you think that's the "norm". So that means in your distorted view, the last 10% is everything and you'll settle for nothing less. This mentality is ridiculous - "I want all effects, from all these games, implemented at all times for an entire game". So basically you want a demo, not a game. And not to dismiss Maxell's demo, but there's not much special about his demo. He clipped the display to get more DMA bandwidth - other developers have done that many times over. What would drive that demo into game, is basically ALL rom size. So what's being pushed here is the rom size, not the system. But sure, that's just your thinking on it.. anyway.

 

On 12/13/2023 at 1:40 AM, Kirk_Johnston said:

The SNES is still great with sprites, but I've come to realise that it truly excels when it comes to the background modes combined with the likes of HDMA, colour math, all the colours, row/line/column scrolling, Mode 7, and everything around that stuff, and I think those elements are still yet to be fully exploited and taken advantage of beyond the kinda obvious and/or bare minimum in most games to be honest, especially many modern indie/homebrew games. It seems most developers are still stuck in an old status quo paradigm where consoles tended to have maybe one or two background layers with a single mode and then the sprites, so the idea was to just draw a decent background as a backdrop for the action, maybe fake a little extra parallax and motion with the background(s), and then get to work on doing everything else with the sprites. Whereas I think the SNES actually kinda flips that entire focus on its head and is a pretty hardcore background engine that also just happens to do comparatively competitive sprite stuff too, and really playing into that opens up a lot of possibilities there, at least as I see it. So I'd personally say there's generally still lots to be achieved in that regard. That's just my thinking on it anyway.

It only took you 2 years to come to this conclusion, while others have been telling you this ever since. And the SNES sprites aren't "great". Of the 3 consoles (4 if you count the SGX), the SNES comes in last for sprites. It's adequate... but it's not "great". That's just how it goes; you won't find one system that's best in ALL categories. That's also what makes coding for them fun. Pyron did a recent video talking about sprites, but I'll be doing my own as well and much more in-depth (I've been collecting information on this over the past few years). But yeah, the SNES pretty much dominates in BG graphics.. but that's what makes it lop-sided when it comes to its sprite implementation. If it's "flipped on its head", it's only because it's lop-sided haha. Not only is it dead last overall, and in most use-cases compared to other systems, but given its prowess in all of its other graphical features - that makes the snes sprites even more disappointing relatively speaking. And let's put that into context; Nintendo released the SFC in Nov 1990. Three years after the PC-Engine.. two years after the Megadrive. So I don't see how you can objectively say it's great with sprites. I'm not exactly sure how your evaluation came to that conclusion (but I can pretty much guess hahah). This isn't a dig on the SNES.. this is 'matter of fact'. Case in point; why do you think Aaendi is trying to develop a more refined dynamic allocation system when that really isn't needed on PCE/MD? Also, I see you fail to note that Nintendo nurf'd the SNES in the vram department in relation to its BG capabilities - more capabilities requiring more space.. requires more vram. Most retro-devs recognize this.. weird that you don't. But yeah, that's just your thinking on it.. anyway.

 

Quote

especially many modern indie/homebrew games.

 And there's it is. Subtle-ish, but there's the dig against homebrew. I know it irritates you that snes homebrew scene doesn't focus on only "pushing" the SNES hardware. It's almost like most people who make retro games aren't AHDH/OCD obsessed with pushing the system to its "absolute limits", but more focused on wanting to make a game. Weird, huh? I for one, wouldn't fault any homebrewer for not pushing the system. It's their time and passion, they should do what they want. I won't be criticizing them for not pushing some retro dev console. But I guess, that's just your thinking on it.. anyway.

Edited December 14, 2023 by turboxray

[Aaendi]

2 hours ago, turboxray said:

This is literally a common thing. It's called scheduling and slot access. It's been happening since the 8bit consoles, btw. It's not novel or new, but that's just your thinking on it.. anyway.

I know that many games used slot scheduling, but did any game from back then actually give each individual hardware sprite it's own VRAM slot, as opposed to having fixed size slots for entire objects?

 

In retrospect, I do think copying X and Y coordinates to an intermediate buffer, was kind've pointless and over-complicated, and that I could've just used $2180-$2183 (WRAM read/write ports) as an extra address register so I didn't need to juggle index registers to draw sprites to OAM.  On the flip side, the fact that my animation engine can't ever update 32 sprites per frame anyway, I can get away with some metasprite compression without impacting CPU speed on all 128 sprites, and I don't know how much of performance drop that will make if I moved all the metasprite decompression to the OAM building code.

Edited December 14, 2023 by Aaendi

[Aaendi]

3 hours ago, Aaendi said:

I know that many games used slot scheduling, but did any game from back then actually give each individual hardware sprite it's own VRAM slot, as opposed to having fixed size slots for entire objects?

 

In retrospect, I do think copying X and Y coordinates to an intermediate buffer, was kind've pointless and over-complicated, and that I could've just used $2180-$2183 (WRAM read/write ports) as an extra address register so I didn't need to juggle index registers to draw sprites to OAM.  On the flip side, the fact that my animation engine can't ever update 32 sprites per frame anyway, I can get away with some metasprite compression without impacting CPU speed on all 128 sprites, and I don't know how much of performance drop that will make if I moved all the metasprite decompression to the OAM building code.

I meant to say "more than 32 sprites." I don't know why the edit button disappeared.

[Austin]

35 minutes ago, Aaendi said:

I meant to say "more than 32 sprites." I don't know why the edit button disappeared.

There's only a small window to edit posts (unless you are a paid subscriber).

[turboxray]

20 hours ago, Aaendi said:

I know that many games used slot scheduling, but did any game from back then actually give each individual hardware sprite it's own VRAM slot, as opposed to having fixed size slots for entire objects?

 I know of a few PCE games that did, but probably not to the level you're doing it (IIRC you allocation system doesn't require any contiguous memory). If you're dealing with just two sizes, that makes it a little bit easier.. but systems that have more than two sizes it gets complicated. 

 

20 hours ago, Aaendi said:

In retrospect, I do think copying X and Y coordinates to an intermediate buffer, was kind've pointless and over-complicated, and that I could've just used $2180-$2183 (WRAM read/write ports) as an extra address register so I didn't need to juggle index registers to draw sprites to OAM.  On the flip side, the fact that my animation engine can't ever update 32 sprites per frame anyway, I can get away with some metasprite compression without impacting CPU speed on all 128 sprites, and I don't know how much of performance drop that will make if I moved all the metasprite decompression to the OAM building code.

 You should talk about the details of your allocation approach here, why you're trying to do it and what does it solve. It's rare that you get discussion that get into the code on forums like this, but I'm sure people would be interested. Especially some history, like what did you try first, what did you change, what trade-offs you had to make (that never gets brought up haha), what type of games or level situations this would help optimize for, etc.

[Aaendi]

When it comes to my homebrew game, the dynamic animation engine, does everything it's supposed to do.

However, I also want to share my code with people, but I can't seem to figure out how to not make it look intimidating.

 

 

Maybe I'll post a youtube video explaining it in detail.

[Kirk_Johnston]

1 hour ago, Aaendi said:

When it comes to my homebrew game, the dynamic animation engine, does everything it's supposed to do.

However, I also want to share my code with people, but I can't seem to figure out how to not make it look intimidating.

 

 

Maybe I'll post a youtube video explaining it in detail.

I think that would be something very cool to share.

[+Biff Burgertime]

On 12/14/2023 at 10:47 AM, turboxray said:

You simply focus on "flashy" and stylistic stuff as your measurement stick. Some of the most impressive pixel art (tiles for BG work) for that era was done by developers working on the SNES. I never see you once note this or gush over this. Why? Because you obviously lack any sort of programming/development experience where these sorts of things are obvious. Same with audio.

In other words, visuals are ultimately all he ever comments on... because it's the only thing he has the qualifications to interpret. (two eyes. hell, even one)

[+Biff Burgertime]

I lurk a lot of retrogaming forums, AA's just the only one that's enticed me into activity...

22 hours ago, Austin said:

There's only a small window to edit posts (unless you are a paid subscriber).

Thank fuck for that. Imagine trying to have a conversion with someone who edits their posts minutes, hours, days after posting! What are you even replying to at that point?

 

...and this doesn't even consider posts that were outright deleted when they became too embarrassing!

Kirk's posted a few times about how he laments the inability to delete posts here at AA, which ironic since he's the living example of why it isn't possible to delete posts here at AA.

[Aaendi]

Here is a flow chart of what my dynamic animation does.  I didn't even get into details yet of how it finds VRAM slots, or find memory to store VRAM slots yet.

 

 

animation.txt

[jeffythedragonslayer]

7 hours ago, Biff Burgertime said:

I lurk a lot of retrogaming forums, AA's just the only one that's enticed me into activity...

Thank fuck for that. Imagine trying to have a conversion with someone who edits their posts minutes, hours, days after posting! What are you even replying to at that point?

 

...and this doesn't even consider posts that were outright deleted when they became too embarrassing!

Kirk's posted a few times about how he laments the inability to delete posts here at AA, which ironic since he's the living example of why it isn't possible to delete posts here at AA.

I think not being able to delete forum posts isn't always a bad thing.  I've seen too many examples of information I wanted to read being being deleted by the author, for whatever reason.

[+Biff Burgertime]

I agree, there are few legitimate reasons that require a post to be deleted. Therefore the best policy is to disallow users from deleting their own posts, and instead require contacting an admin/moderator with their reasoning and let them make a judgement call about it.

[CPUWIZ]

On 12/15/2023 at 8:22 PM, Biff Burgertime said:

I agree, there are few legitimate reasons that require a post to be deleted. Therefore the best policy is to disallow users from deleting their own posts, and instead require contacting an admin/moderator with their reasoning and let them make a judgement call about it.

 

Users can not delete posts and editing expires after 12 hours, or something like that.

[roots.genoa]

My pet peeve is people deleting videos. The whole point of creating videos for your game is to document its development. It doesn't matter if an old video doesn't reflect the actual state of a game; that's what dates are for (and you can even specify it in the description or even the title).

[jeffythedragonslayer]

13 minutes ago, roots.genoa said:

My pet peeve is people deleting videos. The whole point of creating videos for your game is to document its development. It doesn't matter if an old video doesn't reflect the actual state of a game; that's what dates are for (and you can even specify it in the description or even the title).

Yeah, anyone who is that worried about other people getting the wrong idea of what their game is like permanently lodged in their head is probably too introverted to work with others.