can you actually put 128 sprites onscreen simultaneously?

I was trying as an exercise to put 56 sprites on screen at once (32x32px ones, 8 rows of 7), and after about 7 of those, they started to not be visible.

I think what I wanted to do makes much more sense to do with an animated background, but I am still curious if you can actually put 128 sprites on screen? Do they all have to be 8x8? I know I have played shooters where there are many enemy bullets and ships on screen at once, but haven't tried to check in an emulator how much sprite data is being used.

Slow-down is not an issue right now. I'm just curious about actually getting them up there.

It looks like you can set bit 6 in $213E "if there are over 32 sprites on screen", but haven't been able to try this yet, or seen much documentation about it.

It should be able to do a whole screen without flickering. Where are you placing unused sprites?

The SNES has a limit of 34 eight-pixel-wide segments per scanline, if you have any overlap.

I just left them in the upper left corner. I turned off the 9th X-coordinate bits trying to draw all the ones I needed.

I'm gonna look at the OAM in some shooters and see how many sprites get used, or try it again with 8x8 sprites.

My point was to just try a longer (8 frames) sprite animation and then arrange them in a grid to look cool. I think I will probably try this same idea but with background tiles, it makes more sense to do it that way, as none of them need to move around or collide.

Where is this documented?

In http://wiki.superfamicom.org/snes/show/Sprites
They say that "If there are more than 32 sprites on the scanline, set bit 6 of register $213e".

Does that allow more sprites somehow? That's all it really says about that register.

On that same page, go to the very end:

Maybe try to place the unused sprites offscreen at y=$e0. It's hard to tell what the problem is without posting some code.

Yeah I will just do some experiments and see what is up. I couldn't recall a game with 128 sprites just chillin' on screen which I assume is in part due to the issue that lidnariq brought up.



ha my bad

My question is if you set bit 6 or bit 7 of $213E what happens? It implies that it will allow you to have more than 34 sprites setting that bit allows more? Or is this section from the SNES perspective?

It's probably read-only. If it's not, it won't have any effect: you definitely can't get more than 34 8-pixel-wide sections per scanline.

The highest resolution (NTSC: 512x448i) will let you display 8.5 sprites horizontally (34×8÷32) and 14 (448÷32) vertically (for a total of 126), and you'll have to set the "video and sprites are interlaced" bits ($2133 & 3).

If you chose smaller sprites you could fit them all at the same time without using interlaced video. 16×16 sprites would let you display 17×14 simultaneously, which is more than 128.

The wording is what is confusing you. The bit that is set is an overflow flag. The PPU hardware will set it. The reason is so the software could (if it cares to) check it and do something about the sprites that were dropped. The NES has a sprite overflow flag too that is supposed to toggle with more than 8 sprites are on the same scanline.

The SNES can have as many sprites on screen as the Object RAM can fit. So yes you can have 128 sprites. Sprites can be different numbers of cells. 32 sprites can be on one line, any over that will be dropped and not drawn. However 34 cells can be drawn on a line. So that's enough to drawn 256 pixels + 16 more on a single scanline.

SNES games typically don't do what NES games did in regards to sprites. NES games cycled sprites in Object RAM so when the very common occurrence of more than 8 sprites on a line happened you would get flicker instead of drop. SNES games don't generally cycle objects though. Instead you'll notice in some cases in SNES games you have sprite drop.

128 sprites is alot of sprites. Ofcourse you still need to manage them well to avoid drop. Alot of games use the 8x8 and 16x16 sprite size settings but depending on what you are doing you may want to use something else. Another thing to note is that even a blank sprite tile is rendered. So if you had a 32x32 sprite but only some of those cells actually have solid/drawn pixels, the completely blank cells are taking away from your allotted number of cells that can be drawn.

Yeah I had come across the other documentation which you posted which was why I was confused in the first place. I discovered the No$SNS ("no cash") emulator has a VRAM viewer which is EXTREMELY helpful. Has a feature where you can view the OAM table, and then when you mouse over an entry, it will show you where that sprite is on the screen.

Also really cool seeing how real games did it (I looked at games with bigger sprites like Sonic Blastman 1/2, Fatal Fury and then some games with a high "sprite density" like R-Type III. They seem to use relatively few sprites.

I think my paranoia about what the SNES could actually do was never seeing anything like this on the SNES:
https://www.youtube.com/watch?v=cDR9cj_hAEE
(obviously with 128 instead of 256)

I actually got the grid of sprites to work! I will post the code below, and then probably update it later today when the animation and the animation loops are in there. I tested on Snes9x, No$SNS and BSNES, but not on real hardware yet, so I may have to tweak a few things. It is probably fine because there is no vblank code or anything that needs super precise timing.

The issue with understanding this stuff has been that I only get to work on it for a few hours when I am super tired. I took a day off of work today because I had to work really late last night and it is cool to work on this stuff at times when my mind is working properly. The problem was that I was not used to, in ASM doing what would equate to a "nested for loop" in a c-like language.

I got the effect I was looking for.

The code is a little janky in places (apologies in advance), but it is relatively well commented.

What it looks like:

Funky!

Nice effect ^^ Like a lot your gfx style ! Go on !!!