Crash results in 16x32 sized sprites?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Crash results in 16x32 sized sprites?
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...
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.
For those who are curious, I created a link to the file that caused it, which is named Test2 in the folder.
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.
For those who are curious, I created a link to the file that caused it, which is named Test2 in the folder.
Re: Crash results in 16x32 sized sprites?
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...)
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...)
Last edited by 93143 on Tue Jan 06, 2015 11:32 pm, edited 1 time in total.
Re: Crash results in 16x32 sized sprites?
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?
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?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
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?
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.
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?
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
So one can use size $110 and size $111?
If so, is there a list of games that use this?
Is it advisable?i
...
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Crash results in 16x32 sized sprites?
Yes.olddb wrote:So one can use size $110 and size $111?
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:If so, is there a list of games that use this?
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.olddb wrote:Is it advisable?
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?
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.Espozo wrote:I don't even know of a single game that doesn't use either 8x8 and 16x16 or 16x16 and 32x32.
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...
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Crash results in 16x32 sized sprites?
93143 wrote:something important like direct colour mode
This would fill up the entire screen.93143 wrote:It occurs to me that one could port tepples' spritecans demo to the SNES using 16x32 sprites.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
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.
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?
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
By then you'd probably use an FX chip and do software rendering like 93143.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Crash results in 16x32 sized sprites?
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.