nesdev.org

Wait a minute... Does this "existing game" use 3D graphics and you're just using 2D on the SNES, or is the original game 2D?

2D, the SuperFX is because there are way too many bullets for the 65816 to render.

The original game is functionally 2D, but some of the backgrounds are good candidates for Mode 7. Meaning that in a lot of cases the bullet layer has to be tiled sprites. Meaning the sidebar can't also be done in sprites or there will be glitching the moment the player starts shooting.

That's what eats the majority of the CPU time - the jitter-corrected H-IRQ in the middle of the screen to change from whatever the playfield is in to Mode 1, reset the scroll, mosaic, and colour math registers, and decrement a counter to see if it's time to do one of a couple of other things I ran out of HDMA channels for. I had already decided to use the Super FX because of the bullet load, so I told myself the loss was acceptable in terms of total available computing power...

From what psycopathicteen is posting, I imagine that if his idea results in a game it will be designed to make efficient use of the console's existing capabilities rather than brute-forcing non-native graphical elements that don't actually affect gameplay in any way. It would be really cool to see an intense bullet hell game running on a Super NES with no special chip assistance...

93143: Did you ever consider to render the game exclusively in TATE orientation? Opens up a whole lot of possibilities for vertical shooters.

Come on, guys, can we talk about the subject of the thread? I knew I shouldn't have posted...

...

I had considered tate a bit, but not much because the original was yoko with a sidebar, and I was trying to be as unreasonably accurate as possible. Which is why I didn't just do it in yoko without a sidebar and stick the necessary information in the top and bottom borders. In fact, since my initial inspiration was some random website commenter who said this game was impossible on the SNES, anything that looked impossible on the SNES was actually a plus (one of the advantages of working on real hardware is that you don't have to stick to the console's "limitations" if you can trick it into ignoring them).

I will admit that there are a number of things this game does that would be much easier to pull off if they were flipped 90 degrees, the playfield/sidebar split being the most notable. But now that I come to consider the idea more fully, there are a lot that wouldn't; ironically the Mode 7 candidate backgrounds are in this category. Not only are a lot of them in perspective à la F-Zero, but using sprites for the bullet layer would result in the player's lasers glitching out pretty much the entire scanline. Sure, I could draw all that stuff on the Super FX if I kept the playfield at 144 or 152 pixels wide and put the sidebar data on top or something, which gives me enough bandwidth for 8bpp, or two 4bpp layers, at 30 fps - but wasn't the whole point of this to save S-CPU time and thus modestly reduce the load on the Super FX? And if I'm willing to toss the Mode 7 backgrounds entirely for the sake of a little extra compute time, why not just leave the screen in yoko and use Mode 1 for the whole thing?

Besides, who in 1995 would have been willing to flip a TV on its side to play a SNES game? I know shmup nuts do it now, but...

...

On topic: It strikes me that smaller bullets would render significantly faster than 8x8s. For example, 4x4 bullets could be nearly three times as fast, since they're half as tall and only require one sliver per line for the majority of horizontal positions (not sure if the current code has any way to take advantage of this). If the movement and collision code is fast enough, and judging by that demo it seems pretty quick, I imagine you could potentially get quite a swarm going even at 30 fps...

Also, if I've understood this technique correctly it should scale fairly well to 4bpp and 8bpp, though obviously the screen coverage per frame would get a lot worse. By temporarily stashing the mask in direct page and unrolling the sliver to avoid needing three index registers, it should be possible to somewhat limit the data storage requirements.

psycopathicteen wrote:This is 256 bullets moving at 20fps.

This is dope.

I do agree that the bullets should be smaller, which would allow you to do this faster.

How hard will it be to incorporate this layer with backgrounds, the player, enemies, and collision detection? I'd love to see a game come out of these techniques with awesome danmaku action for the SNES.

I'm guessing Radiant Silvergun 93143? I know you were talking about Ikaruga, but I don't see how that's possible. Alright, sorry...


Anyway...

lda buffer,y
and mask,x
ora pattern,x
sta buffer,y

Wait, how are you dealing when the bullet is between two tiles horizontally?

Espozo wrote:I'm guessing Radiant Silvergun 93143? I know you were talking about Ikaruga, but I don't see how that's possible. Alright, sorry...


Anyway...

lda buffer,y
and mask,x
ora pattern,x
sta buffer,y

Wait, how are you dealing when the bullet is between two tiles horizontally?

I draw two tiles.

Really now?

I'm wondering how you draw two tiles, more specifically which tiles you know to draw in.

darryl.revok wrote:I do agree that the bullets should be smaller

Oh, I never said they should be smaller. I'm sure there's room for an assortment of bullet sizes, maybe even big ones done with real sprites. I just noted that they could be smaller.

Most bullets I've seen on this kind of resolution are 5x5 or 6x6.

I think I'll move the screen up a bit, and use IRQ instead of NMI. Should I make the picture full screen? I'd have to double buffer it though.

psycopathicteen wrote:Should I make the picture full screen?

I would. You wouldn't really need both framebuffers to be fullsize, would you? Maybe you could have 1 full framebuffer, and then 2/3 a framebuffer but you'd need two tilemaps that you'd alternate between (assuming you don't want to update the tilemap). Wait, couldn't you use 1 32x32, 16x16 tile tilemap and just change the vertical scroll value to change between "two tilemaps"? I mean, in terms of data size, that's the same as an 32x32, 8x8 tile tilemap.

Also, just thinking, if you ever plan on making this into a game, I imagine you could do single pixel collision with the bullets to process everything faster. Maybe you could also have the option for the bullet layer to not check collisions against the background when you want it to. Generally in these games, if there are a ton of bullets, there isn't anything else to run into. (I never understood why. I always thought it would be neat to do a duck and cover sort of thing.)

There's already enough to worry about with having to dodge the bullets.

It would need double buffering on the CPU side, so it can work on one frame while the previous frame is being uploaded.

I actually have a very sneaky trick with collision detection up my sleave.