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.

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...)

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".

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?

That game judders a lot when I play it on BSNES. I don't remember seeing glitchy 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.

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

Yes.


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.


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.

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

This would fill up the entire screen.

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.

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.

By then you'd probably use an FX chip and do software rendering like 93143.

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.

I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.

Well, you usually don't want standard enemy bullets to be that large. Little orange bullets seem to be a staple in shooters:

I kinda wish I had the option, because at least one player shot type is going to look different from the original due to the lack of vertical height in an 8x8 and the lack of enough OAM entries to use two for each shot once everything else onscreen is accounted for.

But I have no choice. In the general case, when using a Mode 7 backdrop, I have at least 25 sprite slivers on each line before anything happens at all (but this includes the Super FX layer, so I can blit enemies if I have to). Add in five or six vulcan shots per spread and a couple of lasers, and what have I got room for? There's going to be flicker and/or cheese grater effect all over this thing if I'm not super careful...

This is the sort of thing that's making me second-guess my determination to make as graphically faithful a port as possible. Maybe I could have two graphics modes - one with all the bells and whistles, and one with boring Mode 1 backgrounds and possibly a 2bpp sidebar, with the bullet layer mostly targeting 2bpp60 instead of 4bpp30. Then again, maybe this project doesn't need any more feature creep...

8x8 bullets are really useful for maximising sprite bandwidth,and of course VRAM consumption(wich can be a problem for the snes if you're short).


it's a game design choice, for exemple i dislike Wings of war/gynoug on Md mainly because of his small bullets /sprites .
The devs wanted to display the maximum sprites they can be on screen, but they are small and flat, with a very limited number of animation patterns .
Personally it's no my cup of tea .

One can minimize the effect of bullets on adjacent scanlines by making two versions of the bullets, one occupying the top of the 16x16 box and the other the bottom. If it's vertically symmetric, it can be flipped. It looks like Raiden 2 is flipping some of the bullets randomly anyway despite lack of symmetry. I seem to remember Gradius III doing this for the laser weapon: half its segments are drawn with the top of the sprite box and the other half with the bottom.

I wish Gradius 3 didn't try to overlap several lasers on top of each other. It just looks like a flickery mess.

Maybe they should have used windowing with constant colour addition for the lasers. I don't remember anything else in the game that uses windowing, or the subscreen for that matter...

...oh, right. I remember now. The lasers are super slow compared to real ones, and you can mash the button to get a bunch of short shots off. Well, it might still be a good idea for a new-build horizontal shooter...

The subscreen is used for the water on stage 2; even though the background is solid black, the turrets shown blue tinted at their base.


The bullets aren't randomly flipping; they're "rotating". Something really stupid I noticed though, is that instead of just flipping the sprite, there are copies of the bullet sprite flipped. Even dumber, there are only three 16x16 sprites tiles instead of four, as there is not a rotation where the highlight of the bullet is in the upper right. The bullet actually is in the center of the sprite; there's no way they were at all concerned about hitting the sprite pixel per scanline limit given what specs this arcade board has. I don't know for sure, but it can display 4, 4bpp BG layers with at least 128 4bpp sprites and supports color math, which seems to have been relatively rare. It was specifically built for Raiden II/DX in 1993.

Doesn't it use BG2 to render the lasers ?!

Not always...

Is that picture photo-shopped?

Aside from having a ROM site's watermark on it, why would it be?

I never seen a level in F-Zero where beams come out of the floor.

Oh, I didn't notice those before for some reason. Looks like they were just slapped on with the MSPaint line tool.

Yeah, i'm sorry for disappoint you xD

Is only MS paint to expose the example, and not a beam, but a representation of objects that could go in... lamp posts, for example.

16x32 sprites are perfect to do that kind of graphic results with the minimal fill rate impact. Even with two row of lamp posts so high, and four/five cars, could be possible without flickering.


By the way, i have a question about the theme thread... if you set the obsel to consigure 16x32 and 32x32 (or 16x16 and 32x64), What it means is that locks all the entire OAM table with this configuration?, or is it possible to set sprite sizing individually.

I thought it was that in the 16x16 & 32x32 mode the sprites with the other configuration should set individually, achieving until 4 types of sprites sizes on screen (an OAM table with 16x16, 16x32, 32x32, and 32x64).


Dreams...

No, you only get two. OAM only has one size bit per sprite; it's used to select between the two sizes you specify in OBSEL.

I believe you can change the global size setting in OBSEL with HDMA (I tried it, and it looked like it was working), but if you think about how sprites are rendered for a moment you'll realize how easy it is to screw up and get crazy glitching when doing that. Not only can you end up cutting off large sprites if the new size is smaller, but you can end up with blocks of garbage right below the split if the new size is larger.

It could be possible to obtain 8x8 and 16x32 changing during a frame, after the drawing, the setting of the obsel?.


I explain myself:
-Setting the obsel to 111 to obtain 16x32 & 32x64
-Dividing the screen in to sections, and sending into the vram 16x32 sprites to be drawn in the upper screen.
-Now setting to normal 8x8, and sending to the vram to be drawn in the down part of the screen.

The point is, snes doesn't have frame buffer, so the line buffer passes in order from the first scanline to the last, one by one, and this can let you to change everything before all the line buffering passes be done.


So, 8x8 and 16x32 cant be done in the same scanline, being from different obsel valors. BUT, What if you interrupt the line buffering to change the obsel before to continue outputting the signal to the tv?.

I can't even explain myself in spanish, so i think i'm daring too much testing my english like that xD

Maybe. You'd want to test it to make sure it works - I only messed with it a bit*. Lots of stuff gets done by per-scanline raster effects in commercial SNES games (fun fact: Mode 7 can't do perspective on its own), but I'm not aware of anybody trying this.

And of course, even assuming it works, any 16x32s that overlapped the line on which the switch was made would be cut off, and any 8x8s that overlapped the line would have an extra garbage tile rendered on the lines above the switch. So you'd need strict separation of "small" sprites, and unless you were using 32x32 for the large size in both settings, you'd need strict separation of large sprites too.

This is not the easiest scenario to actually realize in a practical game engine. I'd recommend forgetting I said anything.

...also keep in mind that the non-square sprites don't do vertical flipping properly. There's a reason they're not in the manual.


* I was experimenting with OBSEL with a view toward proving that you can in fact change where in VRAM the 8 KB OBJ tables are assumed to be partway through a frame, without glitching like in First Try. This effort was successful; you can indeed change the OBJ table locations glitch-free outside of VBlank, as long as you do it during an active scanline while the PPU is scanning OAM (ie: you need an IRQ; you can't use HDMA). Changing the sprite sizes is presumably the opposite; I'd expect glitches if you try to change them during OAM scan, so it would need to be done during HBlank.