Crash results in 16x32 sized sprites?

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.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Crash results in 16x32 sized sprites?

Post by Drew Sebastino »

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

Image

Image
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Crash results in 16x32 sized sprites?

Post by 93143 »

psycopathicteen wrote:I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.
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...
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Crash results in 16x32 sized sprites?

Post by TOUKO »

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).
I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.
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 .
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Crash results in 16x32 sized sprites?

Post by tepples »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Crash results in 16x32 sized sprites?

Post by psycopathicteen »

I wish Gradius 3 didn't try to overlap several lasers on top of each other. It just looks like a flickery mess.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Crash results in 16x32 sized sprites?

Post by 93143 »

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...
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Crash results in 16x32 sized sprites?

Post by Drew Sebastino »

93143 wrote: I don't remember anything else in the game that uses windowing, or the subscreen for that matter...
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.
tepples wrote:It looks like Raiden 2 is flipping some of the bullets randomly anyway despite lack of symmetry.
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.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Crash results in 16x32 sized sprites?

Post by Bregalad »

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.
Doesn't it use BG2 to render the lasers ?!
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: Crash results in 16x32 sized sprites?

Post by Señor Ventura »

Espozo wrote:in any reasonable situation where you would want to use 16x32 and 32x64/32x32, you're better off with 16x16 and 32x32.
Not always...

Image
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Crash results in 16x32 sized sprites?

Post by psycopathicteen »

Is that picture photo-shopped?
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: Crash results in 16x32 sized sprites?

Post by Revenant »

Aside from having a ROM site's watermark on it, why would it be?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Crash results in 16x32 sized sprites?

Post by psycopathicteen »

I never seen a level in F-Zero where beams come out of the floor.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: Crash results in 16x32 sized sprites?

Post by Revenant »

Oh, I didn't notice those before for some reason. Looks like they were just slapped on with the MSPaint line tool.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: Crash results in 16x32 sized sprites?

Post by Señor Ventura »

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...
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Crash results in 16x32 sized sprites?

Post by 93143 »

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