Interest in "modern" SNES Development Hardware?
Page 11 of 11

Author:  Optiroc [ Wed Feb 08, 2017 2:55 pm ]
Post subject:  Re: Interest in "modern" SNES Development Hardware?

tepples wrote:
[*]Graphics conversion: I made a tool that can convert an indexed PNG, GIF, or BMP to 2-, 4-, or 8-bit planar or 8-bit packed formats, which I included with my Super NES project template. It currently doesn't do anything related to palettes or maps though. Though I made a tool to convert a PNG title screen to tile and map data, converting an arbitrary PNG is a bit of a harder problem with 1+8x15 colors than with 1+4x3 because it's harder to handmake the palette and specify it on the command line.

I actually cleaned up and published the tool I've been using for graphics conversion recently: SuperFamiconv

It overcomes the shortcomings you mention and handles both indexed and RGB(A) images as input for either palette, tile and map generation. You can also feed (and output) palette data as JSON for easy tinkering or piping from some other format (like Photoshop ACT).

I've been pondering how to support the priority bit in generated maps. Without adding support for the monstrous (layered) TIFF or PSD formats as input the best way is probably to feed the tool an extra image with such metadata.

Author:  lidnariq [ Wed Feb 08, 2017 2:57 pm ]
Post subject:  Re: Interest in "modern" SNES Development Hardware?

Would it be a useful starting place to make a converter that starts with Tiled's tmx files?

Author:  Optiroc [ Wed Feb 08, 2017 3:16 pm ]
Post subject:  Re: Interest in "modern" SNES Development Hardware?

lidnariq wrote:
Would it be a useful starting place to make a converter that starts with Tiled's tmx files?

Oh, of course, I should absolutely add support for a Tiled workflow!

Author:  Oziphantom [ Wed Feb 08, 2017 10:50 pm ]
Post subject:  Re: Interest in "modern" SNES Development Hardware?

Command line converters are ok for a title screen or a small patch here and there, but when you start to get deep into development they really start to bite you.
As you add features you need to fix the order of things, or when you add things, have the maps and animations all update as well. When you modify an image and it adds a char here, the automatic conversion tools just happily rearranges everything. Then you have to go and edit your map blocks to match the new order, then you have edit all the anim data to match the new order. This turns add 1 tile into 4 days of boring slog. And that is on single layer, single map, 256 chars. I shudder to think what a 2 layer, 1024 char map would take.
If I have animating chars then I need to make sure they stay in a solid block, so I can just DMA in a slab of RAM. If I'm doing a rol/ror parallax effect then I can't have the tool mirror those 1 or 2 chars, and I need to make sure they stay in a fixed position. If I'm doing a palette cycle effect then I need to make sure that the colours are assigned to fixed locations on a fixed palette, and although I have other pixels that are the same colour, they then need to be assigned to a different entry. If I'm using the Char < X = solid, X < Char < Y = fall through, and Y < Char is no collide collision then I need to be able to have strict order control, be able to insert a char and have maps/blocks auto updated. If I have meta characters, like slope start, slope end etc then again.
The SNES way around this it to burn the ROM and RAM on a separate collision map, but then that is Y.A.T you need to make/update/maintain/document

Using an external tool to make the graphics is fine, there is no need to rebuild DP V or PS into the tool again, but it then needs to let me make a char into a file, import and convert it, then add it into the char set, map where I choose and set the params on it. The "old Skool way" is to put bounding boxes on your "sprites", and then you can encode data into said box. I.e colour 1 is used to denote Collision box, so you have two colour 1s in the top row and two on the left side. Then colour 2 might be anchor point. Colour 3 is 1+2 on the same pixel. Colour 4 might be used for another anchor point, say you are making a game like Alien 3, and you have N guns, you want the artist to be able to mark where the gun should be held, as each gun has its own sprites that have their anchor point. If you need more complex data, say you use AND masks for collision to achieve a more complex result, making the image Half-Bright, and then you paint the areas with the darker half. This then gives you a 6th plane for the AND mask, which you strip off and use the first 5 to generate the sprite data.
To avoid the PSD, TIFF mess I would recommend IFF, it is the battle warn, battle tested, won every victory, and still fighting file format. It's very light weight, very easy to parse and very flexible. Any "true" IFF tool will only edit the parts that it knows about and leave the rest of the file in tact. So if you have an ILBM chunk, and then you put your tile metadata into say a TLMD chunk, when a person opens the IFF file and edits the "image" the tool will save out the IFF file and keep the TLMD chunk intact.

Page 11 of 11 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group