nesdev.org

I have an idea of how to add hi-res mode. Use Mode-0 with psuedo-hi-res with BG0 and BG2 on main-screen, and BG1 and BG3 on sub-screen. BG2 and BG3 would have a "dot-interlaced" action screen and the HUB background, whereas BG0 and BG1 will be used for the HUB font. I don't know if the FX-chip is fast enough to calculate the most convenient set of color palettes for each tile though.

Oh, so you mean there's going to be more than 128 bullets on screen at the same time ?!
Even if that's the case, how's the CPU going to handle them ?

If you require the Super-FX chip I definitely can't test it, as the Super Power Pak only supports no chip or the DSP-1. I don't know how much the DSP-1 helps at rendering stuff on the screen, but I don't think it does help at all.

You can't have mode 7 and another BG, period. However, you could simulate mode-7 effets without using mdoe 7 at all. Especially if you have a Super-FX chip.

I would imagine that even if this worked, if mode 7 was on the right side of the screen (or just anywhere that's not the leftmost side) it's very likely that the deformation computations would be completely wrong since they weren't started at the left side of the screen. Or does the hardware compute it regardless of which mode is currently being displayed?

I would imagine this could screw up other modes as well in similar ways (e.g. tiles not being fetched correctly at the transition area, scrolling being broken, etc. - depends on how the hardware implements this).

It depends on how big the "mode-7" layer is, if it is scaling, rotation or both, and if it's a full 360 degree rotation, or just tilting. If it's small sprites, it could pre-rotate sprite frames in wram while the game is running, so it can smoothly rotate several sprites by the time they appear onscreen. Same for scaling, but both at the same time would eat up a lot of wram. If it is a larger object, that is 128x128 or 256x256, it can be smoothly tilted back and forth using MODE-2 offset-per-tile mode, and HDMA line-scrolling. You can use tilting to transition between large rotation steps, to make a full 360 degree.

I can't help but think that the simplest is to make 2 bullet in a single sprite. Then it'll be complicated to draw them of course, but at least you'll use only sprites.
With 8x8 sprites, you can have 64 sprites for showing 2 bullets in the same tile with all possibilities, assuming they're just a 1-pixel dot.

I have another idea. Use a 2bpp layer for bullet sprites, and have software sprites using 2 palettes, and use the 8 hardware palettes as gradients from one palette to the other, to create a glowing effect, when two sprites of different palettes are in the same tile.

tepples wrote:Perhaps the hardware you need is a Game Boy Advance, which has a 4x overdraw for sprites and the ability to rewrite OAM mid-frame.

Yeah, but as far as I know nobody's ever said it was impossible to do this on the Game Boy Advance.

This isn't some brilliant and original concept I'm trying to realize and should pick the appropriate platform for. It's specifically an attempt to cram an existing game onto the SNES (which has a much specialer place in my heart than the GBA, not to mention better sound). If I'm allowed to switch platforms, there's no point; I might as well go play the original.

I already know I won't be able to get it pixel-perfect. And I also know that a nerfed version is possible - worst case, I have to abandon both scaled/rotated backgrounds and 100% faithful bullet patterns. The question is how close I can get.

Do you have a screenshot of a comparable game in the same genre? Or should I just say "perfect cherry blossom" and leave it at that?

That's close enough, though I'm dubious about the GSU2 being able to handle that game. Same general idea.

That was a really good guess... was it that obvious?

The attached pics (from Perfect Cherry Blossom, because why not) show a case similar to what I'm worried about - a ton of bullets on screen, a line of enemies pouring in from the side (each side, in this case), and a lot of shots from the player (way more than I'll need to deal with) as well as some powerups (using the term loosely here), all on top of a scaling and rotating background. Don't worry about the snowflakes and cherry petals; the game I'm thinking of doesn't do that sort of thing.

It would be a major challenge to fit all the moving objects into one 4bpp palette and still have them look halfway decent, especially with multiple different-coloured bullets present... but doing just the enemies might be feasible in spots, if I'm really stingy with the colours. The problem with doing the sidebar in sprites is that with a Mode 7 playfield I'd have almost no capability to have anything in it that wasn't part of either the blitted surface or the Mode 7 BG itself. Even if I were to use a constant colour for the overlay, which could be done with windowing, the HUD data would eat into the available sprite tile count.

Bregalad wrote:Oh, so you mean there's going to be more than 128 bullets on screen at the same time ?!
Even if that's the case, how's the CPU going to handle them ?

It's not. I'm hoping to have enough horsepower left over on the GSU2 to run the bullet engine and do collision checks. That way the S-CPU only has to run the rest of the game, which isn't especially demanding.

If you require the Super-FX chip I definitely can't test it, as the Super Power Pak only supports no chip or the DSP-1.

The final game would require a GSU, but a test ROM addressing the thread topic would not.

I'm not going to ask you to become a remotely-operated dev kit for a game. Among other issues, the logistics of that would be ridiculous. I'm hoping the sd2snes supports what I need by the time this project enters full-scale development (by which point I should have the spare cash to buy one); if not, I may have to take apart a copy of Doom or something...

You can't have mode 7 and another BG, period. However, you could simulate mode-7 effets without using mdoe 7 at all. Especially if you have a Super-FX chip.

If the Super FX were tasked with rendering the background too, the only way to get 30fps with this size of playfield would be to use 2bpp for both layers, which would look awful, and even then I doubt you'd have enough power to scale and rotate an entire layer that fast. For the same colour depth Mode 7 + sprites gives you (8bpp + 4bpp), the ceiling drops to 10fps.

Just blitting the bullets at 30fps takes up the bulk of the power available even at 21MHz. I'm still not sure it's even possible, but the way the GSU handles pixel plotting is rather nice and I may have a trick up my sleeve...

Sik wrote:I would imagine that even if this worked, if mode 7 was on the right side of the screen (or just anywhere that's not the leftmost side) it's very likely that the deformation computations would be completely wrong since they weren't started at the left side of the screen. Or does the hardware compute it regardless of which mode is currently being displayed?

I would imagine this could screw up other modes as well in similar ways (e.g. tiles not being fetched correctly at the transition area, scrolling being broken, etc. - depends on how the hardware implements this).

Possible, and I'm (kinda) prepared to be disappointed in this. But as Bregalad once said, "we're not going to re-invent the SNES PPU and this should be tested."

psycopathicteen wrote:It depends on how big the "mode-7" layer is, if it is scaling, rotation or both, and if it's a full 360 degree rotation, or just tilting. If it's small sprites, it could pre-rotate sprite frames in wram while the game is running, so it can smoothly rotate several sprites by the time they appear onscreen. Same for scaling, but both at the same time would eat up a lot of wram. If it is a larger object, that is 128x128 or 256x256, it can be smoothly tilted back and forth using MODE-2 offset-per-tile mode, and HDMA line-scrolling. You can use tilting to transition between large rotation steps, to make a full 360 degree.

I suppose I could look into that; it seems you've been doing some good work in that area...

There are parts where a large background consisting of almost entirely unique tiles (it pretty much fills up Mode 7's memory map) is scaled to fill the playfield and doing 360° rotation. There are also parts where the background is doing F-Zero-style perspective (or maybe even Pilotwings-style), though with fewer unique tiles. There's even a part where I was considering abusing HDMA to make Mode 7 look like polygon graphics with a minimum of CPU rendering involved...

I think that with tricks like those you describe, the sections with intricate rotating backgrounds would take too much memory unless they were redrawn to use vastly fewer tiles. DMA is pegged in the general case because of the bullet layer, so everything has to fit in VRAM.

Bregalad wrote:I can't help but think that the simplest is to make 2 bullet in a single sprite. Then it'll be complicated to draw them of course, but at least you'll use only sprites.
With 8x8 sprites, you can have 64 sprites for showing 2 bullets in the same tile with all possibilities, assuming they're just a 1-pixel dot.

That might work for an original game, but unfortunately these bullets are not just 1-pixel dots. (I'd have no doubt about being able to draw them with the GSU if they were...) Scaled to SNES resolution, they range from 4x4 to 32x32, with the bulk of them being 8x8. Also, your method limits you to 256 bullets onscreen if nothing else is happening and each one is next to at least one other, which is still too few.

Plus it doesn't do lasers. Did I mention there were lasers?

psycopathicteen wrote:I have another idea. Use a 2bpp layer for bullet sprites, and have software sprites using 2 palettes, and use the 8 hardware palettes as gradients from one palette to the other, to create a glowing effect, when two sprites of different palettes are in the same tile.

...buh?

Okay, I think I get it.

I'm a bit dubious; I think that there are bullets in this game that would suffer quite a bit with a colour limit that tight, especially some of the big ones that span multiple tiles. And while this scheme looks like it would enable 60fps without the drastic NESification of a monolithic 2bpp layer, I'm not sure the GSU could keep up... But it's something to keep in mind.

Hah, sounds like either Layer Section or Radiant Silvergun.

Anyway, doesn't the SNES have a windowing parameter that lets you set the right side of the screen to all black / BG off / whatever? Then you'd use sprites for the score only in that area.

The idea of splitting the screen or otherwise updating registers or video chip state mid-line has been used successfully on other systems. On the C64, where it's fairly easy for a seasoned programmer to target a specific cycle on a given line, I've seen it used to have one half of the screen (usually the left) in hires character mode and the other half in the software FLI mode (which also adds a requirement of changing the screen base address on each line and triggering a new badline to force the VIC-II to re-fetch said address. There are also "raster splits" which are more simple, and only consist of targeting specific cycles on each successive line. Also, the "direct color" technique on the Mega Drive is done, if I understand it correctly, by syncing to the beam using the FIFO and then using DMA to repeatedly stuff the desired backdrop color value into CRAM, which necessarily involves changing said values many times mid-line. I also know it's possible to update some registers on the MD successfully mid-line, such as the backdrop register itself, allowing the use of any of the 64 color slots arbitrarily at any position that one can construct cycle-exact code to target (which is different from the resolution possible with the DMA technique, as DMA can't target the VDP's registers, and thus you're limited to writing such data with the 68k). All such techniques obviously require either syncing to the beam (which C64 coders call getting a "stable raster"), or using sprites to mask the split (which may not be possible, depending on how the hardware switches modes, which is why splitting the screen between H32 and H40 on the MD is not useful, even when not done mid-line). If it's possible to reuse a given sprite slot after it's already been displayed on the screen, it may be possible to limit the sprite overhead for such masking to one or possibly two sprites (depending on whether there is any required delay on such reuse).

Exploration of such techniques can be useful in terms of demoscene effects, in some cases. The majority of the major C64 demoscene is based around finding such useful edge cases and documenting them, and then making cool shit with them.

You might as well keep the sprite layer 16 colors, if you need f-zero style background and your fine with 30fps sprite movement.

EDIT: If you trim the frame to 184, and have a 152x176 gameplay screen, you can pull off 256 colors at 30fps.

ccovell wrote:Anyway, doesn't the SNES have a windowing parameter that lets you set the right side of the screen to all black / BG off / whatever? Then you'd use sprites for the score only in that area.

Yes it does. Two sets of L/R coordinates that can be changed between scanlines and applied to different layers individually; hence all the big translucent coloured shapes and Looney Tunes screen transitions in SNES games... But the score has enough digits that without using a narrow font and rendering it down, I'd only save maybe four tiles that way, leaving six or seven total. I need more than that just for the player's shots. There are other sidebar elements that take a lot of tiles too, unless I sacrifice visual authenticity for low tile count. I'd prefer to have all that be background if possible; I need all the breathing room I can get...

LocalH wrote:If it's possible to reuse a given sprite slot after it's already been displayed on the screen, it may be possible to limit the sprite overhead for such masking to one or possibly two sprites (depending on whether there is any required delay on such reuse).

Great minds etc.... The trouble is that last I checked, no one knew if rewriting OAM outside VBlank was possible on the SNES. The system certainly goes out of its way to make it difficult...

But if it works, I wouldn't say no to saving close to 50 sprite slots on a pair of 8-pixel masking columns... and if bullets could be cloned this way, it might be possible to get 60fps with multiple 4bpp bullet palettes, only blitting when the scanline limit is exceeded (though it might be computationally intensive to schedule all this in real time, besides which exceeding the scanline limit is easier than I'd hoped). This was going to be the topic of another question thread, actually...

psycopathicteen wrote:You might as well keep the sprite layer 16 colors, if you need f-zero style background and your fine with 30fps sprite movement.

I think that's the path of least resistance.

Though now that I think about it, there is at least one spot where a boss fires nothing but a huge number of small, fast, identical bullets that would look fine in 2bpp and might be easier to dodge at 60fps... It's on a Mode 7 candidate background, though, and it might be too fiddly to try to DMA the first two bitplanes of a sprite layer by themselves...

Regarding 30fps, maybe I should try to engineer a way to play the original at 30fps and see what happens. I imagine it should look and play fine, but experimentum solum certificat in talibus... Even then, that doesn't tell me what it's like having the background and player's sprite stay at 60fps (should be a plus), or the effect of the coarser resolution (should be a minus)...

If you trim the frame to 184, and have a 152x176 gameplay screen, you can pull off 256 colors at 30fps.

I come up a bit short, even without any OAM access:

(262-184)*(1364-40)/8 = 12909
152*176*30/60 = 13376

Either way, the idea seems sound, but for this application the playfield is getting a bit small (not to mention a bit squashed; I'm trying to preserve screen aspect ratio). I don't think it's worth the loss of real estate for 8bpp, and I don't want to drop the frame rate below 30 (except maybe in special cases) if I can possibly avoid it...

Also, if I'm understanding the Super FX right (another topic that was going to be the subject of a question thread), 8bpp takes twice as long to blit as 4bpp. Of course, that only matters if I can code the renderer efficiently enough that the transfer between the secondary pixel cache and the GSU's work RAM is the bottleneck...

How will the sprite VRAM work? There is only 16kB of VRAM for sprites, and you would need to do some double buffering. Somewhere in the frame, there must be a page switch.

Wait, what?

See, that's the kind of thing it's easy to miss when you're trying to teach yourself something like this in a big hurry without any real pressure to use the knowledge right away... yeah, maybe I shoulda paid more attention in OAM class; this one's pretty basic...

Still, it seems that a 144x192x4bpp bullet layer fits in 16 KB with 2.5 KB left over, and which sprite table is being used is set per sprite, not per frame. Paging should be easy enough if you can write to OBSEL between frames, which you can... I'm not seeing the issue here.

152x200 fits too, but it doesn't leave nearly as much headroom in terms of either sprite memory or VBlank time...

What am I missing?

Yeah, you should be able to alternate between a 16K table at $4000 (main at $4000-$4FFF and alt at $5000-$5FFF) and a 16K table at $6000 (main at $6000-$6FFF and alt at $7000-$7FFF). But what tile ordering does the GSU expect? And what does the title screen of Yoshi's Island do?

Or (it seems to me) you could use three 8 KB tables at the cost of some OAM reshuffling. Fill the unused table first, then fill one of the ones you just got through using and use it again. I suppose this would glitch if the frame rate dropped...

The GSU in sprite mode has a 256x256-dot OBJ plane composed of four 128x128 sprite tables. I think you can PLOT across table boundaries, which would require some care to handle properly. It also has three monolithic BG modes: 256x128, 256x160, and 256x192, which it can plot to in 2bpp, 4bpp, or 8bpp. I presume one could DMA the results out of game pak RAM in any order one chose...

I have no idea what Yoshi's Island's title screen does, but I don't see anything that couldn't be accomplished with HDMA...

...who designed this chip? What are the S-CPU bus access enable flags doing in between the size selector bits in the Screen Mode register?