Page 1 of 3

Crash results in 16x32 sized sprites?

Posted: Tue Jan 06, 2015 10:45 pm
by Drew Sebastino
I had been testing ROMs in bsnes debugger and the second I started one of them up, the SNES crashed, but it appears that I got some strange results...
16x32.png
It could just be that the emulator freaked out and wrote that for some reason, or that I somehow "tricked" the SNES into using 16x32 sprites. Of course, I couldn't tell if it were actually doing so, because the screen was black. I wonder if this oddity is a result of writing one of the two unused values for different sprite sizes and I wonder if you could (I strongly doubt this) actually get this to work in a game. I'm probably getting worked up over nothing. :roll:

For those who are curious, I created a link to the file that caused it, which is named Test2 in the folder.
Metasprite Tests.rar
(204.13 KiB) Downloaded 203 times

Re: Crash results in 16x32 sized sprites?

Posted: Tue Jan 06, 2015 11:21 pm
by 93143
This behaviour is noted (and flagged as "undocumented") in both fullsnes and anomie's docs. Setting the size bits of OBSEL to 110 gives you 16x32 and 32x64 sprites. Setting them to 111 gives you 16x32 and 32x32 sprites.

I haven't tried it, but I see no reason it wouldn't work in a game.

At first glance, your code looks like it's setting those bits to 011. But of course if it's crashing before that happens, something else could end up in that register. (I can't remember when bsnes was modified to randomize memory on boot, but it was after v072...)

Re: Crash results in 16x32 sized sprites?

Posted: Tue Jan 06, 2015 11:26 pm
by tepples
According to Fullsnes and wiki.superfamicom.org, the unofficial sprite sizes are 16x32/32x64 and 16x32/32x32. Vertical flipping applied to the tall sprites flips not the whole sprite but instead the top half and bottom half individually. And I wouldn't count on them working the same way on the SNES Jr. because I've read that revision behaves more like a "super famiclone".

Re: Crash results in 16x32 sized sprites?

Posted: Wed Jan 07, 2015 7:08 am
by ccovell
Yeah, on my SFC Jr, Chohmakaimura (Super Ghouls 'n Ghosts) has juddery movement and glitching sprites... can somebody else test it on their Jr system to see if it's the system's fault?

Re: Crash results in 16x32 sized sprites?

Posted: Wed Jan 07, 2015 7:35 am
by psycopathicteen
That game judders a lot when I play it on BSNES. I don't remember seeing glitchy sprites.

Re: Crash results in 16x32 sized sprites?

Posted: Thu Jan 08, 2015 6:18 am
by Pokun
I'm not sure what judder is but I don't recall anything strange with that game on my 1-chip SFC either. Any particular sprites that are glitchy?

Edit: I just tested it on my 1-chip, and there are no glitches what I can see. The screen shakes when the landscape changes or similar things but not otherwise. I don't have SFC Jr though.

Re: Crash results in 16x32 sized sprites?

Posted: Sat Nov 25, 2017 2:05 pm
by olddb
Ok. I hope this is not considered necro posting.

So one can use size $110 and size $111?

If so, is there a list of games that use this?
Is it advisable?i

Re: Crash results in 16x32 sized sprites?

Posted: Sat Nov 25, 2017 6:15 pm
by Drew Sebastino
olddb wrote:So one can use size $110 and size $111?
Yes.
olddb wrote:If so, is there a list of games that use this?
Probably not. In fact, I don't even know of a single game that doesn't use either 8x8 and 16x16 or 16x16 and 32x32.
olddb wrote:Is it advisable?
Not really. First of all, whenever you flip the sprites vertically, all the SNES does it flip each 16x16 or 32x32 block individually. Second, and perhaps more importantly, 16x32 is just too prohibitive for a minimum size; in any reasonable situation where you would want to use 16x32 and 32x64/32x32, you're better off with 16x16 and 32x32.

The general rule with SNES sprite size, I think, is try and go with 8x8 and 16x16 if possible because it offers the best possible fit for objects to reduce data and DMA transfer size and alleviate the sprite pixel for scanline limit, but if you can't fill up as much of the screen as you'd like with sprites (you can only fill up a little over half assuming there are 128 16x16 sprites), then switch to 16x16 and 32x32. Personally, I'd just go with 16x16 and 32x32 because I don't want to have to worry about it. The other sprite sizes have extremely niche uses to be honest, and I just wouldn't recommend them. 32x32 and 64x64 is completely useless, however, as you can already fill up the whole screen with just 32x32 sized sprites.

Re: Crash results in 16x32 sized sprites?

Posted: Sat Nov 25, 2017 11:23 pm
by 93143
Espozo wrote:I don't even know of a single game that doesn't use either 8x8 and 16x16 or 16x16 and 32x32.
My in-development shmup port uses 8x8 and 32x32. 16x16 is too small for efficient faking of extra BG layers, and too big for shots, powerups and active entities (particularly with fake BG tiles eating up about three quarters of each scanline's sprite tile limit). 32x32 is also just right for load leveling between the Super FX and the S-PPU when a lot of large bullets are present, and it's barely wide enough to cover the garbage from my mid-scanline raster split.

So yeah - it's an edge case. It's probably possible to come up with an edge case in which the non-square sprite sizes make sense too, but I can't think of one at the moment. My understanding is that it was probably an accident, or at most a hardware feature that was dropped early and never finished.

Honestly, I wish they'd gone with a slightly more flexible OAM arrangement. No need to go for the full kilobyte, just use 128 bytes for the high table instead of 32. Presto - arbitrary sprite sizing, just like Genesis does... or would that have pushed something important like direct colour mode off the die?

...

It occurs to me that one could port tepples' spritecans demo to the SNES using 16x32 sprites. Double the size, double the sprites, double the flicker...

Re: Crash results in 16x32 sized sprites?

Posted: Sun Nov 26, 2017 10:32 am
by Drew Sebastino
93143 wrote:something important like direct colour mode
:lol:
93143 wrote:It occurs to me that one could port tepples' spritecans demo to the SNES using 16x32 sprites.
This would fill up the entire screen. :lol:

Re: Crash results in 16x32 sized sprites?

Posted: Sun Nov 26, 2017 11:37 am
by psycopathicteen
Or big Mario knocking down 127 Koopas in a row.

A lot of people say you need 8x8 sprites for a shmup, but it appears that the vast majority of shmups in arcades, Genesis, PCE and X68000 all use 16x16 sprites for bullets.

Re: Crash results in 16x32 sized sprites?

Posted: Sun Nov 26, 2017 1:42 pm
by Pokun
You don't need to but it's a waste of VRAM with so many transparent pixels in each sprite entry. For danmaku you also want lots of sprites on screen. For some of those like the PC Engine, 16x16 is the minimum sprite size so it can't be helped though.

Re: Crash results in 16x32 sized sprites?

Posted: Mon Nov 27, 2017 2:56 pm
by psycopathicteen
By then you'd probably use an FX chip and do software rendering like 93143.

Re: Crash results in 16x32 sized sprites?

Posted: Mon Nov 27, 2017 4:43 pm
by Drew Sebastino
I don't think space in vram is so much a problem as running into the sprite per scanline limit. R-Type III has a lot of problems with this because all the objects that could fit in an 8 or 24 pixel wide space are forced to be 16 and 32 pixels wide, despite the fact that I don't think the game ever goes beyond 64 simultaneous sprites. However, I do think there are several things the game could have done to get around this (stars in level 1 could be made from the window layers in conjunction with HDMA instead of sprites). Most machines where 16x16 is the minimum sprite size have a ton of overdraw so it doesn't matter, (x68000, CPS1&2 along with most arcade systems) with the PCE being the exception.

Re: Crash results in 16x32 sized sprites?

Posted: Mon Nov 27, 2017 10:58 pm
by psycopathicteen
I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.