Can you restore PCX Screen Shots?

[larienna]

Would it be possible to restore the possibility to make screen shot in PCX or any other Indexed palette format to be able to grab pictures from games more easily. Here is my problem.

I am trying to grab monster pictures from the Wizardry 1-2-3 video game. I hide all layers and make my screen shot that looks like this:



Now since zsnes (btw i'm too stupid to learn the name of the emulator) support BMP and PNG screen shots, which are both RGB picture format, If I try to paint the black background to get only the sprite, I get the following results even if I use a threshold of 0 on my paint bucket.



This is probably due because the sprite has some black in it. While if the file was saved in PCX, I could simply change the color of index 0 in the palette and get the following results:



So far, the only way that I managed to extract these pictures as PCX, is to run the DOS version of Zsnes 1.42 in windows. But now I have another problem, some specific monsters in the game are displayed like this:



I don't know if it's because there is a bug in Zsnes 1.42 or if running the DOS version in windows create this bug. (If people know how to solve this bug, please let me know). It's only 5% of the monsters, but it's still 5% that I need.

So I was wondering, since PCX was working before, why was not it kept it in the more recent versions. There was no reason to remove that feature.

[kode54]

Try capturing save states and processing them with vSNES first.

[grinvader]

Compressed GFX typically require custom tools to be properly ripped, since they can be uncompressed in any fashion.

[Gil_Hamilton]

This is probably due because the sprite has some black in it. While if the file was saved in PCX, I could simply change the color of index 0 in the palette and get the following results:

That sounds like a bug in the PCX code, personally. Using multiple palette indexes for the same color is weird.

[larienna]

That sounds like a bug in the PCX code

The PCX works perfectly, it's the BMP/PNG that does not have any palette and the fact that ZSNES cannot save PCX anymore that is my problem.

Compressed GFX typically require custom tools to be properly ripped, since they can be uncompressed in any fashion.

This is why I make screen shots, no need to search and learn new tools.

Try capturing save states and processing them with vSNES first.

I'll see if I can restore the fuzzy monsters this way. Else, I'll use a recent version and extract them from the save state.

[Gil_Hamilton]

That sounds like a bug in the PCX code

The PCX works perfectly, it's the BMP/PNG that does not have any palette and the fact that ZSNES cannot save PCX anymore that is my problem.

You misunderstand me.

The fact that PCX assigns the same color to multiple palette entries, and uses different palette entries to construct the image, sounds like a bug to me.
Particularly as it's possible for an SNES image to have more colors in one scene than can be represented by 8-bit PCX, even without transparencies. Efficient palette entry assignments is thus important for screenshot functionality.

One black to rule them all, one black to find them, one black to bring them all and in the darkness bind them.



The fact that you personally find the behavior useful does not preclude it being a glitch.
Your methodology is dependent upon what is likely erroneous behavior.

[paulguy]

Probably just outputs as 8 bit color modes would, where the screen background layer is a separate color, apart from other possible blacks.

[Rashidi]

best probably to modify ZSNES code to output non-black-color when theres no-background layers to draw.

then its possible to convert then .PNG/.BMP screenshots it indexed color PCX format if total colors in that screenshot were <= 256.

[grinvader]

@gil: it's not a PCX bug. It's just how zsnes mapped the colours while being in 8-bit mode (the bg drop always was saved as index 0, then the other palettes were squashed down to fit the limit even if a new colour equated the bg drop).

@larienna:
PCX just doesn't work nicely out of 8-bit modes. So, no. Not going to add it back.
BMP won't cut it, since it's not smart enough in that regard.
Any format accepting multiple palettes would be able to pull it (like GIF), but editing that will probably be more of a pain than what you'd like (you'll end up with several dozen palettes to edit per pic, and not many image editors support multipaletted pics).

@Rashidi: there is always a bg drop.

[paulguy]

Would it be possible to use a PAR code to set whatever PPU register controls background color to some fixed value?

This is assuming vsnes didn't work, which I imagine it does?

[grinvader]

Would it be possible to use a PAR code to set whatever PPU register controls background color to some fixed value?

PAR codes work on cpu reads, not writes, and not on ppu reads.

Custom patch time for you ! :)

[Gil_Hamilton]

@gil: it's not a PCX bug. It's just how zsnes mapped the colours while being in 8-bit mode (the bg drop always was saved as index 0, then the other palettes were squashed down to fit the limit even if a new colour equated the bg drop).

Not reusing the backdrop palette entry seems like a bug to me. But whatever.

[kode54]

The actual renderer wouldn't reuse the backdrop color for black, either, since the hardware would have to use separate color entries for the two. Well, at least, if it's ever going to be composited over anything else, because the backdrop color would (likely?) be transparent, while the intended black would not be.

[Gil_Hamilton]

The actual renderer wouldn't reuse the backdrop color for black, either, since the hardware would have to use separate color entries for the two. Well, at least, if it's ever going to be composited over anything else, because the backdrop color would (likely?) be transparent, while the intended black would not be.

In 8-bit mode? Where transparencies weren't supported?

If I recall, PCX screenshots weren't available outside 8-bit color mode.

[paulguy]

He was probably referring to the fully transparent color index of a tile, not the color addition/subtraction stuff.

[larienna]

Finally, I decided to use ZSNES 1.36 and it does not have the display bug for the 5% of the monsters.

---

It's OK if the blacks does not get mixed up. The general idea of palette management is that you divide the palette in color set for each sprite, or group of sprite. Since each color set needs a transparent color, you actually lose 1 color for each color set.

So for example, if you divide 256 colors into 16 color set of 16 colors, you will only be able to use 15 of the 16 colors, since you need and extra color for transparency. On the NES, the color set only had 4 colors, this is why sprite could only have 3 colors + 1 for transparency.

So it's normal that there are multiple "blacks" and I rather want it this way, because else I would have not be able to extract the sprites correctly.

---

Being able to set another background color than black could be an interesting option.

---

It seems that PNG support the palette mode, I was wondering, if I set the screen resolution in 8 bit mode, will it save the PNG in palette mode instead of true color?

I managed to make screen shot in PCX in true color video mode with older DOS versions of ZSNES. Internally the SNES use a palette, it's just that the video card manage translucency directly in hardware, but the PC cannot do that. So it needs a true color video mode to emulate the results.

---

In the end, I only use pictures in true color mode. It's just that I need to use a palette mode to be able to accurately extract the sprite by setting the right transparent color. When that is done, I save everything as BMP for my game.

So yes, the easiest solution could be to change the background to the color I want directly in the emulator so that saving directly to BMP/PNG does not matter anymore since my sprite will already be extracted.

[Rashidi]

I want to know,
if manipulating the zsnes memory (the emulators not the emulated Snes RAM) using stuff like cheatengine would allow bg-drop changes.

so to find the memory address,
is there any known game that actualy make use of non-black bg-drop?

[Gil_Hamilton]

It's OK if the blacks does not get mixed up. The general idea of palette management is that you divide the palette in color set for each sprite, or group of sprite. Since each color set needs a transparent color, you actually lose 1 color for each color set.

So for example, if you divide 256 colors into 16 color set of 16 colors, you will only be able to use 15 of the 16 colors, since you need and extra color for transparency. On the NES, the color set only had 4 colors, this is why sprite could only have 3 colors + 1 for transparency.

So it's normal that there are multiple "blacks" and I rather want it this way, because else I would have not be able to extract the sprites correctly.

But when your system can generate 256 colors(or more!) in a single image, it's better to be efficient with your palette entries.


See where I'm coming from?

I managed to make screen shot in PCX in true color video mode with older DOS versions of ZSNES. Internally the SNES use a palette, it's just that the video card manage translucency directly in hardware, but the PC cannot do that. So it needs a true color video mode to emulate the results.

Technically, the SNES uses MULTIPLE palettes internally, not one.

Even ignoring transparency effects, it's possible to use all 256 palette entries in a single scene.

Also, there's apparently a direct color addressing capability, though it works with a subset of the SNES' full color resolution(11-bit color VS 15-bit color).

And you can change palette data between scanlines, too.



So a single 256-color palette is not enough to accurately recreate even all non-transparency SNES scenes, and efficient palette usage becomes more important than convenient palette usage.
Which is why I consider using multiple entries for the same color an error in the screenshot code. It's a behavior that introduces further error into the image.
Were there enough palette entries to go around, I would consider it primarily a convenience feature rather than a bug.

[paulguy]

I imagine it just reflected zsnes's 8 bit output mode, which didn't support any of that stuff. I'd see that in that context, it'd be mostly a waste of time to optimize the palette, since it'll never be able to properly convey all the possible colors no matter how much you try to crush the palette. Then you get in to nearest color matching or dithering which do more harm than good on low resolution, and often already low color/ditehred graphics. Given those limitations, I'd say it's more advantageous to be able to dump the SNES's palette as-is (at least at the point whenever a screenshot is taken).

It's really not worth arguing over for those reasons, and also the reasons for it not even being in any build that anyone uses at all anyway, and probably won't be in future versions at all.

[Gil_Hamilton]

I imagine it just reflected zsnes's 8 bit output mode, which didn't support any of that stuff.

It didn't support the SNES' 256-color mode?
I admit I never actually RAN in 8-bit mode back in the day, but I'd be surprised if it didn't support two graphics modes wholesale.

I'd see that in that context, it'd be mostly a waste of time to optimize the palette, since it'll never be able to properly convey all the possible colors no matter how much you try to crush the palette. Then you get in to nearest color matching or dithering which do more harm than good on low resolution, and often already low color/ditehred graphics. Given those limitations, I'd say it's more advantageous to be able to dump the SNES's palette as-is (at least at the point whenever a screenshot is taken).

But ignoring direct color addressing and transparencies, it IS possible to get a correct image in 256-color mode, unless I'm missing something.

[grinvader]

Just digging what exactly it could do is a waste of time. There are too many ways to output way more than 256 colours per sprite to care about PCX.

But ignoring direct color addressing and transparencies, it IS possible to get a correct image in 256-color mode, unless I'm missing something.

Brightness reg.
Writable anytime in a frame.

[Gil_Hamilton]

Well, then... Hooray!