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
Re: Crash results in 16x32 sized sprites?
Well, you usually don't want standard enemy bullets to be that large. Little orange bullets seem to be a staple in shooters:
Re: Crash results in 16x32 sized sprites?
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.psycopathicteen wrote:I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.
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...
Re: Crash results in 16x32 sized sprites?
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).
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 .
it's a game design choice, for exemple i dislike Wings of war/gynoug on Md mainly because of his small bullets /sprites .I think 16x16 bullets just look cooler IMHO, even if they are slightly more flicker prone.
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 .
Re: Crash results in 16x32 sized sprites?
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
I wish Gradius 3 didn't try to overlap several lasers on top of each other. It just looks like a flickery mess.
Re: Crash results in 16x32 sized sprites?
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...
...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...
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Crash results in 16x32 sized sprites?
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.93143 wrote: I don't remember anything else in the game that uses windowing, or the subscreen for that matter...
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.tepples wrote:It looks like Raiden 2 is flipping some of the bullets randomly anyway despite lack of symmetry.
Re: Crash results in 16x32 sized sprites?
Doesn't it use BG2 to render the lasers ?!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.
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: Crash results in 16x32 sized sprites?
Not always...Espozo wrote:in any reasonable situation where you would want to use 16x32 and 32x64/32x32, you're better off with 16x16 and 32x32.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
Is that picture photo-shopped?
Re: Crash results in 16x32 sized sprites?
Aside from having a ROM site's watermark on it, why would it be?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Crash results in 16x32 sized sprites?
I never seen a level in F-Zero where beams come out of the floor.
Re: Crash results in 16x32 sized sprites?
Oh, I didn't notice those before for some reason. Looks like they were just slapped on with the MSPaint line tool.
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: Crash results in 16x32 sized sprites?
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...
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...
Re: Crash results in 16x32 sized sprites?
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.
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.