An obvious way to improve FMV: changing colors per scanline

I just about got the whole idea of the thread done in the title. 8 palettes is really not the greatest, but you can't update enough of the screen if you're using 8bpp tiles. I haven't seen anyone try to help this by changing the colors per line though; is it because of the PC side of things, or has just no one thought about this? I imagine it would help a good bit. I've talked about how a just about pixel perfect Metal Slug port could be made by doing clever mid-screen palette swaps.

With the HDMA units, the best you could get is 8 colors changed per scanline.
... Huh, and you could cleverly abuse the X,X,X+1,X+1 HDMA mode to have it be an arbitrary 8 colors on each scanline. That actually has potential (rather than having to change 8 contiguous entries)

I'm not certain you're going to get a particularly better result than the quick tg16 hack sim I made: viewtopic.php?p=161230#p161230

I actually have to wonder; why does that look so, to put it lightly, not great? It sounds like it says 16 colors are being changed per line: just looking at the picture, are there only 16 colors per line total? (that's kind of what it looks like in the picture.) The result shouldn't ever look worse than if you didn't use it.

You could change up to 15 colours per scanline with HDMA, or more like 20 with a single DMA in an IRQ. The catch is that they do need to be adjacent.

Changing up to 8 arbitrary colours per scanline is much more flexible, but I found it difficult to put into practice. I managed to get a photograph up to 417 colours in 8bpp with a fairly primitive preprocessing algorithm, but that one frame took the better part of a minute to process in Matlab on a Pentium 4. It doesn't even dynamically re-quantize the colours; it just goes through a pre-quantized image and tries to schedule an HDMA pattern that will hit all the colours, and if it fails I have to quantize to a lower number of colours and try again.

It can be somewhat useful - I got the background image of the title screen for my game up to 548 colours this way, with the sprite layer and colour math boosting it to 806. But when I gave my HDMA scheduler an in-game graphic that needed to fit into 4bpp with most of the DMA channels otherwise occupied, the results were unsatisfactory, and I ended up doing it manually; after hours of frustration and eye strain I succeeded in cramming 51 colours into a 15-colour palette with just one HDMA channel...

I should seriously try to figure out what quantum computing is all about. Unless I'm missing something, and I very well might be, truly optimizing an image for Xbpp+NxHDMA is a Traveling Salesman-class problem, and adding multiple palettes only makes it worse...

EDIT: Misremembered the HDMA mode options. Again.

When you talk about HDMA, keep in mind that it's only about 268 cycles long. If you try and do 8 channels * 4 bytes, that works out to 256 cycles. If you throw in indirect HDMA, things aren't going to fit anymore before the PPU reasserts control over the CGRAM address bus.

If you're willing to give up framerate and/or resolution, you could use a 2bpp or 4bpp layer alongside an 8bpp layer and use pseudo-hires blending to produce much more color. You'd probably end up closer to quarter-screen video at that point, but it'd look sharp.

Well, unless 93143 is wrong, he said that's 8 arbitrary colors per scanline. The problem he said though, is actually making the image.


Well, I mean, it's a tradeoff between color depth and size/framerate of the image. I had thought that you could make a drawing application where you could use direct color mode with a 4bpp layer over it using color math for 12bit color, but still have 15 of the 16 color palettes left for everything else. That would be awesome. I think for FMV, the best tradeoff between speed and color is a 2bpp layer over a 4bpp layer using color math. If I'm not mistaken, you could, in theory, actually get up to 4096 colors this way if the first two palettes are used for both the 4bpp and the 2bpp layer, but in practice, I doubt you'd even get to 512 colors.

Not really related, but you know what I found out (mostly to 93143)? If I were to do a Metal Slug port, the one part where there are 3BG layers would actually be possible. The waterfall layer would be layer 2, but the wall in front of that would be made of sprites, BG3, and a window layer. (I'd sandwich it in between BG1 and BG2 like how DKC3 does.) The tree leaves on the top part of the screen could mostly be BG3, but the BG3 status bar is going to be there.

The bottom image has BG3 removed:


I also found that a large chunk of the waterfall is never visible either, so there are less tiles.

How? I've looked into this before and I only found a way to change up to 8. I couldn't find a way to transfer four bytes to CGDATA per channel with HDMA.

I did write a demo that displays 16 colors per scanline using a carefully timed hblank interrupt and MDMA (vanilla DMA). I also wrote a conversion tool to produce graphics in this 16 colors per scanline format. You can get 'em both here.

I also used this technology to make my Five Nights at Freddy's demo. Every image you see there uses 16 colors per scanline, except the static at the end.

You could possibly squeeze a little more than 16 colors per scanline, but when your art is 4 bpp, I don't see the point.

Ha! I keep tripping over this.

No, you need regular DMA to do that, because for some reason there is no HDMA setting that can write four bytes to one address, even though there are two duplicate transfer modes. You're quite right.

Sorry if I got your hopes up...