HDMA images, but in mode 0

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
HDMA images, but in mode 0
by on (#229461)
Hey guys.

I was wondering for a project if anyone has an image converter like this one which allows for image conversion with hdma tables, but one that works in mode 0.

For an image I want to display I have to work in mode 0, and it's be way easier if I could use HDMA to increase the palette.

If not, how would I need to edit this one in order to implement this feature?

Thanks,
~Molive
Re: HDMA images, but in mode 0
by on (#229462)
Why do you have to work in mode 0?

Mode 0's constraints are strict enough that an automated converter is going to struggle.
Re: HDMA images, but in mode 0
by on (#229463)
So, for mode 0 (or just generally, anything 4/16 colours) the first big to-do item is creating some conversion to palettized tiles. If you want to use background-processor as is, note that even at a single 16-color palette for an entire image there's approximately zero difference adding or removing HDMA for photographic contents. It would need the image to be tiled to expand the palette sufficiently to get more interesting results.

Certainly, generating tiled images is on my distant radar, but getting decent results for that is a computationally hard problem that I haven't grappled with yet, and I've got more interesting fish to fry in the meantime. I am aware of that script Khaz wrote awhile back for generating 16-color palette images, which may be a point of inspiration, but I'd want to pick at the problem enough to get, at least, a more performant solution out of it - I'd really like to stay below a second or two total wall-time for the processing time of a single image, for example, not 2-3 minutes. Hopefully, also generate some slightly higher quality images. Their results are pretty good but there are still plenty of cases where it falls over a bit, with obvious discontinuities between tiles that I wouldn't consider of shipping quality.

(as an aside, even if, e.g., the DKC title screens had a lot of artist manipulation to make them fit for 16-colour tiles by moving elements around or tweaking colours of objects, that just underscores the need for rapid processing, and hence rapid iteration and turnaround time; doing mild tweaks becomes out of the question if you're waiting multiple minutes for a result)
Re: HDMA images, but in mode 0
by on (#229480)
I have the same question lidnariq has. Why is mode 0 a requirement? Why can't mode 3 or mode 4 (possibly 7 too, I forget) be used alongside direct colour mode ($2130 bit 0 == 1)?
Re: HDMA images, but in mode 0
by on (#229488)
I'm trying to display a sufficiently complex hires image. The image is much larger than 64k in mode 3/4, but in mode 0 it's just slightly under. (I stream part of it during V-blank to get around the limit)

It looks horrific with the amount of colours, though, so I thought I could increase them using something like this.
I don't need to increase the max res, because on my end I split the image into four in order to make it work, and then use four different backgrounds at normal res.

I'm going for higher res rather than colour here, but right now it looks like there's four over the entire image.

~Molive.
Re: HDMA images, but in mode 0
by on (#229489)
Quote:
Mode 0's constraints are strict enough that an automated converter is going to struggle.

You should see how complicated mode 0 hires' constraints are. It's like a fake dither over everything.
Re: HDMA images, but in mode 0
by on (#229499)
So not just mode 0, but specifically using two layers of mode 0 to produce a 512x224 image? Even more tricksy, then: that "dithering" that you've identified exceeds NTSC's bandwidth (thus all being blurred) and will cause luma-chroma crosstalk too.
Re: HDMA images, but in mode 0
by on (#229501)
For composite, 256x224 and 4bpp is probably a better choice in general.

But S-Video has enough bandwidth for the full 560-pixel luma signal. (That's 512 of picture plus 24 of side border in the nominal 4:3 frame.) S-Video does, however, blur pathological chroma signals such as alternating green and magenta pixels, as 560 pixels exceeds the theoretical 373 sample pairs of a QAM carrier centered at NTSC subcarrier frequency.