PCX Palette Converter to SNES (C & C#)

I made a small program in C# that can convert palette data from a PCX file to SNES data. It's nothing too crazy special, and there are some improvements to be made, but I figure I get some feedback from you guys about it. Well, counting on the fact that all of you have the .NET framework or whatever.

The only real up-side about it is that it automatically puts files with .asm or .s extensions in .db format. Let's not get too pessimistic, though.

Included is a tar file with the Visual Studio solution, although as far as I'm aware the code is safe for MonoDevelop cross-platform users.

As said, feedback is appreciated, and enjoy.

UPDATE!

I learned a few techniques with C while working on a little program of mine which will not be disclosed . Decided in the process that I'd go ahead and try a conversion of pcx_pal2snes over to C.

All that I've yet to implement is the .db feature. Other than that it seems to have worked, so try it if you like. It's under pcx_pal2snesc.tar.

I don't know if you want anyone posting here, (Ill delete my post if so) but I am wondering if your program supports .gpl files. (Gimp color palettes.) If not, would you consider adding them in the future? I namely use pcx2snes for palettes because it creates a palette that goes with the graphics, but I could definitely see myself using something like this for creating palette swaps. By the way, is this a command line based tool and is there any assembly required?

Hehe, of course I want people posting here. Always want to hear what people think.

Anyway, it doesn't currently support gpl's. Guess I'll look into it. The program is run through command line, but I can make a tiny little interface for it if you want. Not sure what you mean by assembly being required. Far as I know, a SNES C compiler would probably support the palette, though exporting into C isn't implemented as of yet.

I don't mind using the command line, as you have to use it for pcx2snes anyway. (Frankly, I'm really not sure why I asked.)


There are some programs (like WLA DX) that have a bunch of .bin files and the like but don't have any .bat or any .exe files. I've been told you're somehow supposed to turn those files into an .exe file or something through some program, but I just didn't bother and got the program through a different website.


I'm not sure how different C is, (I'm guessing does not accept .db?) but I really wouldn't stress about making it C compatible because most of the people use ASM on this website (and on the SNES, in general) because it is more efficient.

Hm...seems I've found a bug in my own program.

The palette is converted correctly, but sprites are shown as pitch black for some reason in Neviksti's examples. Looks like I've got stuff to look into.

What examples? Also, How would the palettes be correct If they aren't? Does the program just spit out a .asm or a .s file with a blank table? It honestly sounds like there's just something wrong with Neviksti's CGRAM upload routine.

Neviksti had examples for pcx2snes, and I replaced the palette file of one of the backgrounds with one made by pcx_pal2snes. The background looked the exact same but the sprites on the screen were pitch black. So I did the same to the sprite palette to no avail. There wasn't much difference in the files, though.

Could I possibly see the file you are trying to put the new palettes in along with the palettes? It sounds like there is a problem with the code you are using more than the program.

walker.asm is what's causing problems.

I fixed it. I don't think there was anything wrong with the palette the program output, but I think it had to do with the way the palettes were uploaded to CGRAM. I replaced the "LoadGraphics" code with something much more usefull and changed a couple of things around to accommodate it and it works fine. Let me explain the new code. If you notice, after "LoadPallete" in Walker, there should be two new numbers; the first one saying where you want to upload the data, and the second saying how many colors you are uploading. Next, you will notice that "LoadBlockToVram" now has three words (2 bytes) instead of two. The third word controls where in the picture you have are you starting at.

Here's the download:


Give credit to bazz for making the "LoadPallete" code much more versatile and I added the small new offset feature on the "LoadBlockToVram" code.

Sweeeeet. So the program does work correctly, then. I have plans to make pcx_til2snes (tiles) and pcx_tlm2snes (tilemap) as well, which will probably be more difficult.

Thanks Espozo :3 And nice new offset feature

Btw, why are we still using PCX? Is there a more convenient format for us like GIF?? I understand indexed palette is the thing to go for, but PCX man.. I always had trouble with those files. Espesh on Mac OS X.

I had been looking for a library that can convert other image types to pcx and let the program work from there but found none that weren't gigantic. It's just the easiest format to use.

snesgrit supports png.

GIFs internally contain the uncompressed palette ( https://en.wikipedia.org/wiki/GIF#Example_GIF_file )

I've found a library called ImageMagick.NET that allows the conversion of nearly every image format to pcx, but am having trouble implementing it. Wish me luck with it.

So we can transport a non .pcx image file into an image file and then get the .pcx file to get the palette from?


Luck wished.

My Super NES sample project includes pilbmp2nes, a tile converter written in Python that converts an indexed image in any format that Pillow (Python Imaging Library) can load (namely BMP, GIF, PCX, and PNG) to any tile format that can be described as a planemap. Here's what I mean by "planemaps":

• NES: "0;1" (one bitplane of bit 0, then one bitplane of bit 1)
• Game Boy and Super NES 2-bit: "0,1" (bits 0 and 1, interleaved by line)
• Sega Master System: "0,1,2,3" (bits 0-3, interleaved by line)
• Super NES: "0,1;2,3" (bits 0-1, interleaved by line, then bits 2-3, interleaved by line)
• Super Mario World 3-bit: "0,1;2"
• Genesis: "3210" (four bits packed)
• Super NES 8-bit for modes 3 and 4: "0,1;2,3;4,5;6,7"
• Super NES mode 7 and GBA 8-bit: "76543210"
• Virtual Boy: "10", hflip, bytes reversed
• GBA 4-bit: "3210", hflip, bytes reversed

My program doesn't create palettes or nametables. Yet. I'm trying to think of a similarly extensible way to handle those. Any ideas?

What are you trying to say? If you say you are trying to find ways how to handle the palette files and nametables (tile maps?) you should look at the program pcx2snes. It has a whole list of options that you can select and it outputs files for tiles, palettes, and (optionally) tile maps for BGs. It can even output "special" mode 7 backgrounds. (The tiles and the tile map is interweaved, but I'm sure you already knew that. )

I don't know a thing about Python. Wanted to write the program for C (because extreme amounts of compatibility) but too many complications and I ended up with my head spinning.

ImageMagick is pretty awesome.

I took a look at Python. As simple and convenient as scripting languages can be, it seems inconvenient to open up a file expecting an executable just to find that it's a script and there's some interpreter needed. (Then again, I'm the one using .NET...)

Small update. (Read first post).

I can see your reasoning, I guess, but usually a GUI app is exactly what you don't expect/want from an asset pipeline tool.

The larger problem with SNES tools is that the average quality of free/open stuff out there is very low. There's some good stuff around (I guess? Not too sure when I think of it) buried among 20 years of bad hacks, DOS binaries etc. So most people around today realize this and build some custom tools fit to their exact purpose, so they can get going with the actual SNES hacking as quickly as possible. Which is completely natural in an "eco system" as small as the SNES hacking scene. I guess if the scene would be larger and more active, we would also see more people taking pleasure in refining good, modern, tools for it.

Anyway, a shortlist of actually usable tools would be great.. Is there such a thing?

There certainly needs to be. Perhaps we should gather things up? (If the broken links don't attack, that is).

Or if there are particular missing tools, perhaps we could describe how they should work and some smart cookie can put something together.