nesdev.org

93143 wrote:

lidnariq wrote:On the other hand, coming back to this after another 3 years I can see trivially how to do subpalette generation more easily (namely, don't use ppmquant, instead use pnmcolormap on the colorspace-reduced reference, and use pnmremap from the highcolor original, with floyd-steinberg dithering)

I understood some of those words... I'm still very userspace on this topic, but I'm sure it would make more sense if I read up on those resources.

Yeah, sorry, what I said was all jargon.

Unpacking it:

subpalette = the 16-color palette I'm using on each scanline
tools from the "netpbm" software suite:
ppmquant = tools that generate a colormap, remaps colors, and handles dithering all in one program.
pnmcolormap = a tool that just generates that colormap
pnmremap = a tool that just remaps colors and handles dithering
pnmquant= a convenience wrapper that runs both pnmcolormap and pnmremap. Doesn't handle pipes.

pertinently, my previous attempt:
1- Started with the original image
2- Converted it to X bpp (X=9 for TG16, 15 for SNES)
3- divided this depth-reduced version into single-scanline high bits
4- converted each depth-reduced scanline on its own into the final result (without dithering)
5- combined all of those slices.

This time, I instead
4a- only used the depth-reduced scanline for its resulting palette.
4b- I go back to the original image, extract the corresponding full-depth single scanline
4c- and reconvert that slice of the full-depth scanline using the palette generated in 4a (with dithering)

Using Floyd-Steinberg dithering (or any other error propagating type) is really limited by only being able to propagate error within its own scanline, as is happening here. Positional dither might be an easier way to get better results.

But I can't see any way to apply these techniques to something where the palettes across scanlines have to have some correlation, which makes CypherSignal's idea so interesting.

Señor Ventura wrote:

CypherSignal wrote:

Señor Ventura wrote:I've read from some programmers that snes has an amount of memory for sprites, and an amount of memory for backgrounds, so it is preselected.

Ah. That information may pertain more towards game-specific memory budgets, then - if you were doing modifications to an existing game like Super Mario World, that would be useful information. Tile data for sprites and backgrounds have to share the same 64KB of space, and for all intents and purposes, a developer would not want to mix the memory used for sprites and bg's. So, a developer would have to make a choice at some point to declare that they want to use some portion of the available VRAM for sprites (or some types of sprites - player sprites make have more memory allocated than sprites for enemies, for example) and some portion for backgrounds.

However, the examples I'm talking about here are independent of any game, and are just focused on displaying a single image. In this case, the entire VRAM is available to work with, and there are no restrictions on how memory can be allocated one way or another.

No, no, i mean that i've read from programmers that snes has a delimited and preselected memory for sprites and backgrounds.

It was a demo of the gunstar heroes for snes, and the programmer said that it could be impossible in that machine because the original game gets more memory for sprites than the snes dedicates.

P.D: The demo seems to not be in youtube anymore.


edit: Sorry for the off topic, it only was to commenting that.

I later figured out how to get around the 16kB sprite problem with my original homebrew game. I had to do a lot of trial and error.