Series-8 said:
I think a Hybrid tile, pixel by pixel render is the way to go. (SNES may have a wimpy CPU~ but it has non-wimpy PPU chips)
Mind you it will be 100% ARM9 ASM. leveraging the MMSP2 2d hardware.
It would have to be many stages:
Stage 0:
Background Tiles;
Would convert all SNES background tiles into a 16Bit Type format,
(Paying attention to each tiles pallet (mid-frame pallet fiddling is argh!))
and buffer these in memory. (I'd rather have it create new tiles for pallet change than change all the tiles, burn, memory, burn!)
They just get fast, block moved to the frame buffer. (possibly using rotation of the 2D accel. too.)
There is a background tile map, that keeps track of what is where. If the background map is changed, but still only scrolling up/left/right/diagonnaly/down (e.g not a whole new screen) then the tile buffer is just shifted over with a MMSP2 memory block move
That's basically what I was going to try for gpSP. There are drawbacks to this approach though, you trade a lot of computational complexity for cache inefficiency down the road. However, you don't need to shift the map, that isn't how these updates work (at least not in GBA games). The games simply modify a row/column/both and update the horizontal/vertical offsets. This relies on the wraparound of the maps, but is much less expensive for the game than updating the entire thing.
But storing 16bpp isn't good because of midframe palette changes, and it uses more memory (again cache efficiency), it's better to expand the colors line by line.
Series-8 said:
There are actually 4? layers of background tiles, thus transparency / mask data is also stored in the tiles.
The MMSP2 2D Accelerator supports this. ( I think, the docs arn't the clearest)
If it supports colorkeyed blits then that can be used. SNES colors are "only" 15bpp so you can use the remainding pixel for this, but you want are paletted 8->16bpp blits (don't know if it supports these).
Stage 2 (0):
Series-8 said:
Mode 7.
Either brute CPU matrix transforms on the 'stock' layer rendered by stage 0, or possibly with some matrix transform help from the MMSP2 video??? decode hardware (????).
This Stage actually takes the output of stage 0 and messes with it basically.
I REALLY don't think that the 2D hardware on GP2X supports arbitrary linear transforms like SNES. However, transforming a bitmap is less computationally expensive when it isn't chunked into tiles (and again, less cache efficient too)
Stage 1:
Series-8 said:
Sprites;
They render right on top of the now background filled fb for that frame.
(in the render order the SNES uses of course)
Except they can appear beneath the background layers.
Series-8 said:
Trick A:
Areas that have not had any sprites cover the tile area are skipped over from the last frame.
(Assuming the Stage 1: tile buffer is not 'dirty' -- the background is the same)
This stage is actually using a modified version of the Stage 1 pipeline (Tiles), except sprites are like tiles that can be anywhere and have alpha channel information (true transparency)
and there are fewer of them, and they have more complex order. The MMSP2 may also handle sprite clipping(?)
I don't think so. Keeping track of how dirty the screen is sounds like overkill and it really shouldn't be necessary when the overall amount of work has been reduced. I also don't think that the MMSP2 can do all of these 2D tricks, but clipping can possibly be cheated by extending the scanline space and overdrawing.
Series-8 said:
only standard sprites with no colour addition or subtraction (only rotation and mask information)
Sprites on SNES don't rotate/scale.
Series-8 said:
Stage 3:
Transparency layer;
HDMA and other funky layered effects, especially colour addition.
(for sprites and backgrounds)
It may be possible to use lots of indexed pallets, thus transparency effects become 'cheap'~
It makes a cross-lookup pallet for each colour combination.
There are more palette combinations than there are pixels on the screen, and changing a palette entry or blend settings requires changing every last one of them.
Series-8 said:
Or not as the SNES has a 15-bit total pallet...
(MMSP2 supports 16-bit in hardware) -- but only for games without any transparency / colour addition...
Thus no nasty colour addition math per pixel / line. Just fast lookup of a pre-cooked value in a table somewhere. (assuming sprite A does not cover Sprite B and Sprite C, just background 1/ 2/ 3/ 4, ect...)
Do any SNES games have sprites that use colour addition / subtraction with MANY sprites?
E.g: More than 2?
The thing here is that even with saturation control performing color addition/subtraction in software probably isn't going to be slower than looking it up in a huge cache inefficient table (remember, only 16KB of dcache here)
If SNES is like GBA in this regard then overlapping sprites don't blend correctly. But color addition/subtraction is usually used for a background layer.
Series-8 said:
I just had a stupid idea.
The LCD makes colour addtion rather tricky... (RGB5:6:5 conversion, pallet lookup insanity,ect... and SNES many and strange pallets)
The TV output has all kinds of video --nee scanline type fiddling capabilities...
Why not have colour addition ~ and perhaps HDMA like effects on that instead of messing about with a frame buffer (s).
Okay, that one totally lost me, doesn't that mean you'd have to use the TV output? And I somehow doubt it'd support what you want, HDMA can refer to a whole lot of things on a per scanline basis, like windows, the palette, scroll registers (wavy effects), matrix registers (3D effects), etc.
