Please help consolidate all info for pixel artists for SNES

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

psycopathicteen wrote: Tue May 17, 2022 1:17 pm
iNCEPTIONAL wrote: Sun May 08, 2022 4:55 am
93143 wrote: Sun May 08, 2022 4:36 am I already explained this in the other thread, but I'll do it one more time.

Your impression that the "sprites" the SNES can display 128 of are necessarily 8x8 is WRONG.

The SNES can display 128 sprites, and they can be 8x8, 16x16, 32x32, or 64x64, with any two of those sizes being available at a time. These are hardware sprites - "objects", as Nintendo puts it. The "sprites" in the artist sense are sometimes referred to as metasprites, and they are built out of these basic blocks, but the basic blocks are not necessarily 8x8.

This means your question was indeed ambiguous.
But, see, right here is the problem:

When someone who has very clealry stated they are an artist and not a programmer, asks if 128 "sprites" can be switched out per frame. It should be real easy for anyone else to know they mean the 128 8x8 "sprites" that are likely to ever actually be used in any real scenario.

You show me a single SNES game that has ever loaded up 128 64x64 sprites into the game "(flickering and disappearing all over the place), never mind then tried to switch them out every frame.

And all the SNES guides online say the SNES can display up to 128 8x8 sprites/objects onscreen, with the number being less anytime you get into bigger sprites made up of multiple smaller sprites [objects].
What "guides" are you talking about? The only places I've seen people saying that are Sega-16 forums and youtube comments.
God knows at this point what "guides". There's various and multiple, but those are certainly two of the many sources I used when trying to figure all of this out (along with asking a bunch of questions in SNESdev too).

Here's a few of them:

https://youtu.be/sheOZ-Dlleo
https://www.copetti.org/writings/consol ... -nintendo/
https://segaretro.org/Sega_Mega_Drive/H ... comparison
http://www.gamepilgrimage.com/content/s ... 21_no4temg
https://nerdbacon.com/super-nintendo-vs ... sis-specs/
https://megacatstudios.com/blogs/retro- ... guidelines

What I have learned by asking the very helpful RetroGameMechanicsExplained guy (along with some people responding in here too)--and hopefully I got this right (and these are my words based on what he said)--is that the SNES can in fact technically "put" 128 objects of any size "onto" the "display" BUT once you get into certain object sizes and certain object amounts, it ultimately can't truly display them in the obvious way most laymen would understand. I mean--if I have got this right--the SNES can show a few 64x64 objects onscreen, but, if you go past 16 or so, it starts going above the objects/sprites/tiles per scanline limit, so it ultimately can't truly display more than around 16 64x64 objects as they'll start flickering and/or just not showing at all. So--assuming I'm still getting this correct--in any real use, it's fair to say it can really only display around 16 64x64 objects onscreen, as anything after that largely becomes meaningless, or just wouldn't look great or make much sense.

And that goes back to me asking about 128 "sprites"--which are of course made up of objects--and therefor, it would be beyond stupid of me to be asking if it could switch out anything other than 128 8x8 "sprites" [possibly 16x16 too?] if, at any other object size than 8x8 [and possibly 16x16?], it literally couldn't even properly display 128 "sprites" anyway. Which, goes back to my original question when I simply asked if the SNES could switch out all 128 "sprites" every frame. Also, similarly, that wording should, imo, also make it clear that, as a layman, I'm not asking about how many "sprite tiles" on the "tile sheet" it can play around with (have internally loaded in VRAM or whatever it all means and how it works at a purely technical level), or whatever else, but just if it can literally have 128 8x8 [possibly 16x16 too?] "sprites" [actually objects] displayed onscreen and then literally change them for a totally different set of 128 8x8 [possibly 16x16 too?] "sprites" [actually objects] in the very next frame, and so on for each new frame. And there was even more context for my question based on prior discussion about first using a background to fake a single large character and then me further enquiring about instead using basically all the available "sprites" to make a single large character and switching them out every frame, which effectively took up around 128 8x8 tiles using the previous background method anyway, etc.

So, that kind of thing.

I do hope that makes some semblance of sense.

Not that I need an answer anymore, as I think I now know what I wanted to know originally and [hopefully] understand how it works.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Please help consolidate all info for pixel artists for SNES

Post by psycopathicteen »

I'm making a table of just how many of each sprite size it can show onscreen and how many frames it will take to update all of them. 16x16 maxes out both OAM and VRAM but doesn't max out screen coverage. 32x32 and 64x64 maxes out both VRAM and screen coverage, but not OAM. Screen size is approximately twice as big as VRAM.

Code: Select all

size     per screen    % of screen size   unique    % of screen size   VRAM size   frames to update all

8x8      128           12.5%              128       12.5%              4kB         1 frame
16x16    128           50%                128       50%                16kB        3 to 4 frames
32x32    64            100%               32        50%                16kB        3 to 4 frames
64x64    16            100%               8         50%                16kB        3 to 4 frames
Last edited by psycopathicteen on Thu May 19, 2022 8:22 pm, edited 2 times in total.
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

psycopathicteen wrote: Thu May 19, 2022 6:26 am I'm making a table of just how many of each sprite size it will take to update all of them. 16x16 maxes out both OAM and VRAM but doesn't max out screen coverage. 32x32 and 64x64 maxes out both VRAM and screen coverage, but not OAM. Screen size is approximately twice as big as VRAM.

Code: Select all

size     per screen    % of screen size   unique    % of screen size   VRAM size   frames to update all

8x8      128           12.5%              128       12.5%              4kB         1 frame
16x16    128           50%                128       50%                16kB        3 to 4 frames
32x32    64            100%               32        50%                16kB        3 to 4 frames
64x64    16            100%               8         50%                16kB        3 to 4 frames
Thanks for that. That is extremely useful.

PS. I'm curious, is there a similar chart for switching background tiles in and out? As in, beyond just the tiles already "loaded into VRAM" (or however it's done), which I assume is how you normally do tile animation on backgrounds, how many [8x8] tiles you can literally replace every frame that aren't already there to be used as per usual (as in, not already in VRAM or whatever it is and however it works)?

Maybe that Tom and Jerry example would be a great source to see what I'm trying to ask about here, where, looking in an emulator, the Tom character appears to be made entirely out of background tiles, and it seems to be loading in all new tiles for the character every single frame (a lot of them): https://youtu.be/dnjH86GUVf8

Also, I presume I couldn't load both a lot of sprites [objects] and background tiles in/out at the same time, like say anywhere near 128 8x8 objects for the sprites plus a load of tiles for the background too (each frame or so)? Or can I?
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Please help consolidate all info for pixel artists for SNES

Post by dougeff »

128 unique 8x8 sprites @ 4bpp is $1000 bytes, which is fine. 1/16 of the VRAM

128 unique 16x16 sprites @ 4bpp is $4000 bytes, is also ok. 1/4 of the VRAM.

You will probably want a little of each size.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

dougeff wrote: Thu May 19, 2022 11:58 am 128 unique 8x8 sprites @ 4bpp is $1000 bytes, which is fine. 1/16 of the VRAM

128 unique 16x16 sprites @ 4bpp is $4000 bytes, is also ok. 1/4 of the VRAM.

You will probably want a little of each size.
The VRAM is shared with the sprites and backgrounds, right?

And is that all it's used for (I can't recall)?

If I were to use say all 128 16x16 objects (not really gonna happen, but let's pay pretend), how much room would I have left for the four background layers in Mode 0, in terms of the amounts of unique tiles I'd be able to have for each layer and not run out of VRAM (if anything else needs to use a bit of VRAM too then take that into account just so it's actually plausible)?

I hope I'm not asking something dumb here that doesn't really make practical sense in terms of how a game is built using these things.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Please help consolidate all info for pixel artists for SNES

Post by dougeff »

VRAM is for tiles (both BG and sprites) and tilemaps (BG)

OAM (a separate RAM) handles the position of sprites, size of sprites, etc... which controls how many sprites you will see on screen. Having 5 sprites or 128 sprites on screen doesn't affect the BG in any way. (except that you also need to have sprite tiles loaded, if that's what you mean)
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

dougeff wrote: Thu May 19, 2022 3:11 pm VRAM is for tiles (both BG and sprites) and tilemaps (BG)

OAM (a separate RAM) handles the position of sprites, size of sprites, etc... which controls how many sprites you will see on screen. Having 5 sprites or 128 sprites on screen doesn't affect the BG in any way. (except that you also need to have sprite tiles loaded, if that's what you mean)
OK, I think I've got it: The VRAM is really just the space that's available to store the various sprite tiles, background tiles and tilemaps that will be used to create the stuff we eventually see onscreen in terms of the levels and players and enemies and such, which can be accessed basically immediately rather having to go load in something new/different from the ROM cartridge such as a the tiles for a whole other level for example. And the OAM is kinda another bit of instantly accessible memory where the actual code is stored that is used for some/all sprite attributes and positions and such (although not the rest of the game code).

Is that correct?

Yeah, I was getting a little confused with how many sprites are displayed onscreen vs how many of those sprites might be using unique sprite tiles or just reusing a few of the same sprite tiles over and over.

So, if I had say 128 8x8/16x16 objects onscreen, all using unique sprite tiles (or the max unique tiles possible if it's not quite enough to cover 128 16x16 objects with unique tiles), then how many unique background tiles would I be able to have in VRAM for each of the four background layers (assuming some is going to be needed for tilemaps and whatever else)?

Edit: I feel like I'm asking a silly question there and it's basically always the same answer: The 16kb for sprites (so, up to 512 unique sprite in VRAM, and I'm not sure how many unique sprite tiles are allowed onscreen at once) and the 48kb for backgrounds (so, up to 1024 unique background tiles per layer in VRAM, and I'm not sure how many unique background tiles are allowed onscreen at once per layer [in Mode 0]), right?
Last edited by iNCEPTIONAL on Thu May 19, 2022 5:15 pm, edited 1 time in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Please help consolidate all info for pixel artists for SNES

Post by dougeff »

code
OAM is a table of data, tech term is "object attributes", used by the PPU
I'm not sure how many unique sprite tiles are allowed onscreen at once
512 unique 8x8 sized for sprites.
how many unique background tiles
how many do you need? let's start there and work backwards to the "is it possible" question
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

dougeff wrote: Thu May 19, 2022 4:41 pm how many do you need? let's start there and work backwards to the "is it possible" question
Literally, as many as possible, and I would ideally try to use them all to make the backgrounds as detailed and varied as possible. Kinda like how I'm ultimately going to try to use every single available colour for both backgrounds and sprites in Mode 0 in order to make it look less like a NES game than it might seem it would have to otherwise because of the colour limitations of that mode (and the way most people seem to talk about it).

I mean, if I have up to 128 objects onscreen and say I've only used twenty so far, then I'd like to think I'd have the ambition to go through my level and keep adding more right up until just before the point it becomes detrimental, i.e. pushing the SNES as far as possible while maintaining the framerate and quality and feel and gameplay and so on. If I have potentially up to 1024 unique tiles per layer to use, then I'd like to think I'd try to use them all, unless there's some reason someone has yet to tell me why I shouldn't? If I can add more row/line scrolling, then I'd like to think I would, until just before it has a negative effect on the game. If I can added some animated tiles and haven't maxed them out yet, then I'd like to think I'd add in some more animated tiles, right up until just before it's going to have a negative impact on the game. If I can add some colour math or window/shape masking and haven't done so yet, then I'd like to think I would, so long as it doesn't negatively affect the game. And so on.

So, working from that premise, how many unique tiles can I get on each background layer in Mode 0 when taking into account the other sprite/sprite tile stuff we've already discussed in previous comments (leaving a reasonable amount of space for typical tilemaps, and before I do any of the other stuff I just mentioned).
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Please help consolidate all info for pixel artists for SNES

Post by dougeff »

I feel like we've discussed this already, though I don't feel like reading through previous threads.

Mode 0 is all 2bpp layers. Each layer can have its own tiles. Max tiles available to a layer is 1024. If each layer used 1024, that's 4096 tiles for BG, @ 2bpp that' would use up the entire VRAM (no good, leaves no room for sprite tiles or maps), so... maybe... limit to 512 per layer, or 2048 total BG tiles, or half of the VRAM.

Somewhere around 2048 unique BG tiles, possibly a little more.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

dougeff wrote: Thu May 19, 2022 6:11 pm I feel like we've discussed this already, though I don't feel like reading through previous threads.

Mode 0 is all 2bpp layers. Each layer can have its own tiles. Max tiles available to a layer is 1024. If each layer used 1024, that's 4096 tiles for BG, @ 2bpp that' would use up the entire VRAM (no good, leaves no room for sprite tiles or maps), so... maybe... limit to 512 per layer, or 2048 total BG tiles, or half of the VRAM.

Somewhere around 2048 unique BG tiles, possibly a little more.
It really is possible.

Because I still don't fully understand all this stuff, I may be asking the same or very similar questions at times, but I probably have a different reason for asking them again and only understand the answer(s) in the context of the specific question(s) I asked at that particular time. Either way, the more I ask the same question(s) in different ways, the more I understand the things I'm asking about, which is good from my perspective at least. Apologies if you feel like you're repeating yourself. Just think of it like someone trying to learn math or a new language or programming or whatever: You don't just tell someone something once and they suddenly know and understand it completely and perfectly. That's me--someone.

Thanks for repeating yourself. :D
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Please help consolidate all info for pixel artists for SNES

Post by tokumaru »

If you're really worried about having as many unique tiles as possible for the background, I imagine you could use the same technique that Sonic 3D Blast on the Genesis uses: https://youtu.be/ZPoz_Jgmh-M

That game basically uploads one entire row and/or one entire column of graphics to VRAM every frame with the new patterns that are scrolling into the screen, instead of updating the tilemap to use the tiles that are already in VRAM. This allows you to use as much of the ROM as you want for tiles, but there are obviously some drawbacks, as explained in the video.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Please help consolidate all info for pixel artists for SNES

Post by psycopathicteen »

I just realized that the first sentence in my last post didn't make any sense, so I fixed it.
iNCEPTIONAL

Re: Please help consolidate all info for pixel artists for SNES

Post by iNCEPTIONAL »

tokumaru wrote: Thu May 19, 2022 7:24 pm If you're really worried about having as many unique tiles as possible for the background, I imagine you could use the same technique that Sonic 3D Blast on the Genesis uses: https://youtu.be/ZPoz_Jgmh-M

That game basically uploads one entire row and/or one entire column of graphics to VRAM every frame with the new patterns that are scrolling into the screen, instead of updating the tilemap to use the tiles that are already in VRAM. This allows you to use as much of the ROM as you want for tiles, but there are obviously some drawbacks, as explained in the video.
Ah, interesting. I currently don't understand that enough to know how to think about it from a design/art point of view, but it's stuff I can keep in mind when talking to a programmer about working on the game properly. Thanks
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Please help consolidate all info for pixel artists for SNES

Post by creaothceann »

iNCEPTIONAL wrote: Thu May 19, 2022 3:29 pm VRAM is really just the space that's available to store the various sprite tiles, background tiles and tilemaps
That's what the hardware uses it for. (Technically speaking there's nothing stopping the programmer from uploading any kind of data and then later reading it back, but that doesn't make much sense.)

iNCEPTIONAL wrote: Thu May 19, 2022 3:29 pm can be accessed basically immediately rather having to go load in something new/different from the ROM cartridge [...] And the OAM is kinda another bit of instantly accessible memory
Yes. The SNES data bus only transfers 8 bits at a time (and is hooked up to components unrelated to rendering), which is not nearly enough to render a pixel. VRAM, OAM, CGRAM and the various internal PPU registers are connected directly and can be accessed almost immediately; the two VRAM chips for example return 16 bits per clock cycle. It's the same reason why my PC's VRAM can be on a 256-bit interface and transfer 448 GB/s while main RAM is on a 64-bit interface and can transfer only 10.6 GB/s.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Post Reply