optiroc / superfamiconv Goto Github PK

I think that offsetting palettes should have been supported from the get go,

This would make it easier to use multiple PNGs for different layers of graphics in a SNES video mode where palettes are shared, such as:

• Modes 1 and 2, where the first 2 4BPP layers share the same palettes, and where the 2BPP layer shares its 24 colours.
• Modes 3 and 4, where both the 8BPP layer and the other layer share colours(24 in the latter, 120 in the former).
• Mode 5, where both layers share 24 colours.
• Any mode with an 8BPP background will have to share 120 of the colours in the 2nd half with sprites.
• Sure, the 8BPP layer can use direct colour instead, not having to share anything, but SuperFamiconv doesn't support direct colour anyway, and that's something requiring its own issue filed.

Although there's a relevant piece of code that handles this. It's never executed if map splitting is not specified. So, command arguments like -i <png> -W 16 -H 8 -B 4 -R -t <4bpp> -m <map> will result in an incorrect map data.

In the code here: https://github.com/Optiroc/SuperFamiconv/blob/master/src/Palette.cpp#L93,
this check seems wrong when using 2 BPP or more that 1 palette. If the check fails, SuperFamiconv throws an exception and enters the catch block and tries to read the json palette as a binary palette with pretty random results.

In my case, I have a 16 colors palette in the original image that I expect SuperFamiconv to convert to 4 palettes with 4 colors each in 2 bpp mode. The check fails because 16 colors is greater than 4.

Using native binary palettes instead seems to work ok.

When a tilemap is used, the actual tile order in vram does not really matter.
So it would be cool to have an option to reorder them.

The easiest versions would be:

• for fun / obfuscation
• ordered by palette (would allow to get palette from the id instead of relying on attributes)

Those two could even get combined.

More complex versions would reorder them to improve tile compression:

• RLE (increase byte runs in general or per plane)
• LZ (increase runs and repeated byte sequences)

This would be an option of superfamiconv tiles, I'd call it --scramble or --reorder

I wasn't able to figure out, is there a way specify palette index during map generation?

Command:
superfamiconv.exe tiles -n "font_16x16.sfc" -o "font_16x16.png" -M snes -B 2 -W 8 -H 16

font is row-interlevead, then 8x16 but output is 8x8

If a tile has an ambiguous palette, it would be nice if the one would be preferred, that produces a duplicate.
I'm talking about tiles which don't use enough colors to be sure which palette it is.

Edit: this is meant for superfamiconv tiles and superfamiconv map

Say you have a 256 wide image, that you making into 16x16, so the map needs to be as if it is 512 wide, i.e a screen is still 32 tiles wide. However the tool will make it 16 tiles wide. Having a command line option to out pad the line width to be a "full" line so you can just DMA it and be happy, would be nice. I don't think it should be standard as you may want to use the smaller size to save some ROM.

When a palette had two same colors, the map was wrong, it missed some tiles. When I merged the colors, the result became correct.

This is the image used:

In the makefile, these arguments were used:

$(SUFACONV) palette -i $< -d bg0.pal -C 4 -v
$(SUFACONV) tiles -i $< -p bg0.pal -d bg0.pic -B 2 -v
$(SUFACONV) map -i $< -p bg0.pal -t bg0.pic -d bg0.map -B 2 -v

This is the error log I got:

superfamiconv -i bg0.png -p bg0.pal -t bg0.pic -m bg0.map -B 2 -v
Loaded image from "bg0.png" (60x160, indexed color)
Mapping optimized palette (8x4 entries for 8x8 tiles)
Setting color zero to #ffffffff
Generated palette with [4,4,4,4,4,4] colors, 24 total
Created optimized tileset with 118 tiles (discarded 42 redudant tiles)
Mapping 160 8x8 image slices
Error: Colors don't fit in palette
make: *** [Makefile:19: bg0.pic] Error 1

I have tried converting the palette, tileset, and tilemap separately, and it seems the problem starts to happen during the tilemap conversion.

This is the log I got for that:

superfamiconv map -i bg0.png -p bg0.pal -t bg0.pic -d bg0.map -B 2 -v
Loaded image from "bg0.png" (60x160, indexed color)
Loaded palette from "bg0.pal" ([4,4,4,4,4,4] colors, 24 total)
Loaded tiles from "bg0.pic" (118 tiles)
Mapping 160 8x8 image slices
Error: Colors don't fit in palette
make: *** [Makefile:22: bg0.pic] Error 1

So the palette was successfully generated, the tiles were successfully generated, but for some reason, the map wasn't?
I literally explicitly set the -B BPP command to '2'.

This one may be harder to test for you than the others, since I can't share the test image.

Using an 8-bit source PNG (for mode 3, over 16 colors), the map subcommand misses some tiles.
superfamiconv map -v -B8 --in-image $1 --in-palette $1.palette --in-tiles $1.tiles --out-data $1.map

The image does not have identical colors or a transparent index.

I want to transform a 256x448 png to tiles, map and palette. I can't because it gives me tileset exceeds maximum size 1792 of 1024 maximum.

I cannot split it in two, because i want to keep the same palette (image is quantized with 7 subpalettes) and
i must use the "no-discard" option.

Can we raise the tile limit?

-W 8 -H 16 would be the expected usage for -M gb and -M gbc

8x16 are stored as two consecutively following 8x8 tiles.
The tilemap still operates on 8x8 tiles and since 8x16 mode is only for sprites, they can be accessed as 8x8 for the background at the same time, since the can share tiles.

What does this mean?:

• 8x16 tiles have be stored consecutively
• each 8x16 tile has two tilemap entries (upper and lower half), even though sprites will only use the first one
• deduplication is not allowed to break 8x16 tiles apart, it's always upper+1==lower
• deduplication is allowed to combine two 8x16 tiles if the second starts with the 8x8 tile the first one ends with

EDIT:
I was wrong, the upper tile has to be on even indices and the lower tile on odd ones. The lowest bit is ignored.

The GBA 4bpp tilemap format is similar to the SNES 2bpp mode, but with a fourth palette bit instead of a priority bit:

FEDC BA98 7654 3210  SNES tilemap
|||| ||++-++++-++++- Character number (max. 0x03FF)
|||+-++------------- Palette
||+----------------- Priority
|+------------------ Flip horizontally
+------------------- Flip vertically

FEDC BA98 7654 3210  GBA tilemap
|||| ||++-++++-++++- Character number (max. 0x01FF)
|||| |+------------- Flip horizontally
|||| +-------------- Flip vertically
++++---------------- Palette

Also, each 16-color subpalette has its own color 0.

When starting the program, regardless of argv, it gets stuck in an infinite loop doing nothing but burning cycles.
Has anyone ran this successfully on Windows? Is this a known issue?

I discovered this a while back but I forgot about it, I'll get to debugging it proper later, just posting this as a reminder.

Windows 8.1 x64, tdm-gcc (mingw-w64 5.1.0, I forget threads/exceptions used, probably posix+dwarf)

So the SNES still does 8x8 maths on tile locations when in 16x16 mode.
so if you have 16x16 tiles mapped like so in VRAM

001122334455667788
001122334455667788
99AABBCCDDEEFFGGHH
99AABBCCDDEEFFGGHH

then in the map you need to do

00020406080A0C0E
20222426282A2C2E

as a tile of 1 will get you a tile that looks like

12
12

a tile of $10 will get you

12
AB

The VDP only allows 16 bit writes and the m68k CPU is big endian.
Currently, using SGDK for example, binary palettes and tiles from Superfamiconv are uploaded to the VDP with the bytes swapped.

In shorthand mode the -m flag behaves slightly differently from -t and -p. -t tiles and -p pal work, but -m map does nothing, you have to write -mmap.
Run $ superfamiconv -i freyja.png -t tiles -m map -p pal and only tiles and pal are created.

Today's master.

  No matching tile for position 248,56
  No matching tile for position 0,88

bug.png: https://anonfiles.com/x2D4O3r6z5/bug_png
(github attachments don't work for me, please attach it yourself if you intend to look at this after a long time, so it doesn't disappear)

Repro case:

superfamiconv palette -i tileset.png -M pce -0 000000 -d tiles.pal -v
superfamiconv tiles -i tileset.png -p tiles.pal -d tiles.chr -o tiles_chr.png -M pce -v

Error: No matching palette for tile at 16,0 in source image

Using json palettes instead of native palettes seems to work ok.

If an image is being converted which has a tile which is either the horizontal or vertical flip of a previous tile, the previous tile will be used but it will use both vertical and horizontal flipping, meaning it displays as if no flip has occured at all.

For example, consider the following 16 by 8 pixel image:

These two tiles could be encoded as the same tile, just with one flipped either horizontally or vertically.
Superfamiconv encodes the image as such:

The first tile is normal, but the second tile is both flipped horizontally and vertically. This means it looks the same as not flipped at all. In the above case the converter should pick either horizontal or vertical flip but should not pick both.

superfamiconv map -T 0x80 apparently treats the argument as 0, silently discarding the x80 part. I didn't check with other options.

C stdlib has strtoul which handles this correctly with a base of 0, and error checking is possible by checking the returned pointer. (Example.) I don't know if there's a C++ way of doing that, though.

It would be great if superfamiconv tiles allowed to use -i and -n at the same time.

That would allow to build a tileset based on what is given with -n and add all missing tiles from -i

This would allow:

• to build one tileset for multiple images (some might share a few tiles)
• build a tileset with multiple modes (gb and gbc) or different setting (not mirrored and mirrored) if they use the same native tile format

Given a source PNG, 8-bit, where one index is marked as transparent, superfamiconv's map fails to create a correct map. The tiles and palette commands work properly, but the map is missing all tiles that contain that transparent color.

You can create such an image in mtpaint:

• open an 8-bit PNG
• preferences -> files -> set transparency index to 0
• save

I'm trying out this tool to convert a 32x32 png file to a sprite I can load into my PCE game. The problem is that I'm getting the result on the right when the image on the right is the correct one (ignore the palette difference between the two images)

This is the command I'm running. What am I doing wrong?
.\superfamiconv.exe -i 04.png -t 04-conv.bin -p 04.palette -M pce_sprite -v

*** Error in `./superfamiconv': double free or corruption (fasttop): 0x000000000065fc20 ***
======= Backtrace: =========
...
Program received signal SIGABRT, Aborted.
0x00007ffff7a43428 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54

when running $ superfamiconv tiles and $ superfamiconv palette, but not superfamiconv or superfamiconv map, it crashes regardless of which combination of flags I use. If I run with -v I'll get something like:

$ superfamiconv palette -i bg.png -d out.pal -v
Loaded image from "bg.png" (128x128, indexed color)
Mapping optimized palette (8x16 color palettes, 8x8 tiles)
Setting color zero to #080417
Generated palette with [16] colors, 16 total
Saved native palette data to "out.pal"
Segmentation fault

Only tested on lubuntu 16.04 yet, if it's not a bug in one of your libraries it could have something to do with the way they handle c++ exceptions.

why is it taking a color and dividing each component by 8 and flooring instead of multiplying each component by 31/255 and then rounding?

invoking
.\superfamiconv.exe -i .\FxLogoPacked_1.png -p FxLogoPacked_1t.clr -t FxLogoPacked_1t.pic -m FxLogoPacked_1t.map -B4 -W16 -H16 -R -v
I get
Loaded image from ".\FxLogoPacked_1.png" (512x512px, indexed color)
Mapping palette straight from indexed color image
Created palette with 36 colors [16,16,4]
Created optimized tileset with 130 entries (discarded 894 redundant tiles)
Mapping 1024 16x16px tiles from image
No matching tile for position 224,16
No matching tile for position 272,16
No matching tile for position 288,16
No matching tile for position 336,16
No matching tile for position 352,16
No matching tile for position 416,16
No matching tile for position 16,32
No matching tile for position 32,32
No matching tile for position 208,32
No matching tile for position 224,32
No matching tile for position 288,32
No matching tile for position 336,32
No matching tile for position 352,32
No matching tile for position 400,32
No matching tile for position 416,32
No matching tile for position 464,32
No matching tile for position 480,32
No matching tile for position 0,48
No matching tile for position 16,48
No matching tile for position 32,48
No matching tile for position 48,48
No matching tile for position 64,48
No matching tile for position 80,48
No matching tile for position 96,48
No matching tile for position 112,48
No matching tile for position 128,48
No matching tile for position 144,48
No matching tile for position 160,48
No matching tile for position 176,48
No matching tile for position 192,48
No matching tile for position 208,48
No matching tile for position 224,48
No matching tile for position 240,48
No matching tile for position 256,48
No matching tile for position 272,48
No matching tile for position 288,48
No matching tile for position 304,48
No matching tile for position 320,48
No matching tile for position 336,48
No matching tile for position 352,48
No matching tile for position 368,48
No matching tile for position 384,48
No matching tile for position 400,48
No matching tile for position 416,48
No matching tile for position 432,48
No matching tile for position 448,48
No matching tile for position 464,48
No matching tile for position 480,48
No matching tile for position 496,48
No matching tile for position 0,64
No matching tile for position 16,64
No matching tile for position 32,64
No matching tile for position 48,64
No matching tile for position 64,64
No matching tile for position 80,64
No matching tile for position 96,64
No matching tile for position 112,64
No matching tile for position 128,64
No matching tile for position 144,64
No matching tile for position 160,64
No matching tile for position 176,64
No matching tile for position 192,64
No matching tile for position 208,64
No matching tile for position 224,64
No matching tile for position 240,64
No matching tile for position 256,64
No matching tile for position 272,64
No matching tile for position 288,64
No matching tile for position 304,64
No matching tile for position 320,64
No matching tile for position 336,64
No matching tile for position 352,64
No matching tile for position 368,64
No matching tile for position 384,64
No matching tile for position 400,64
No matching tile for position 416,64
No matching tile for position 432,64
No matching tile for position 448,64
No matching tile for position 464,64
No matching tile for position 480,64
No matching tile for position 496,64
No matching tile for position 0,80
No matching tile for position 16,80
No matching tile for position 32,80
No matching tile for position 48,80
No matching tile for position 64,80
No matching tile for position 80,80
No matching tile for position 96,80
No matching tile for position 112,80
No matching tile for position 128,80
No matching tile for position 144,80
No matching tile for position 160,80
No matching tile for position 176,80
No matching tile for position 192,80
No matching tile for position 208,80
No matching tile for position 224,80
No matching tile for position 240,80
No matching tile for position 256,80
No matching tile for position 272,80
No matching tile for position 288,80
No matching tile for position 304,80
No matching tile for position 320,80
No matching tile for position 336,80
No matching tile for position 352,80
No matching tile for position 368,80
No matching tile for position 384,80
No matching tile for position 400,80
No matching tile for position 416,80
No matching tile for position 432,80
No matching tile for position 448,80
No matching tile for position 464,80
No matching tile for position 480,80
No matching tile for position 496,80
No matching tile for position 0,96
No matching tile for position 16,96
No matching tile for position 32,96
No matching tile for position 48,96
No matching tile for position 64,96
No matching tile for position 80,96
No matching tile for position 96,96
No matching tile for position 112,96
No matching tile for position 128,96
No matching tile for position 144,96
No matching tile for position 160,96
No matching tile for position 176,96
No matching tile for position 192,96
No matching tile for position 208,96
No matching tile for position 224,96
No matching tile for position 240,96
No matching tile for position 256,96
No matching tile for position 272,96
No matching tile for position 288,96
No matching tile for position 304,96
No matching tile for position 320,96
No matching tile for position 336,96
No matching tile for position 352,96
No matching tile for position 368,96
No matching tile for position 384,96
No matching tile for position 400,96
No matching tile for position 416,96
No matching tile for position 432,96
No matching tile for position 448,96
No matching tile for position 464,96
No matching tile for position 480,96
No matching tile for position 496,96
No matching tile for position 0,112
No matching tile for position 16,112
No matching tile for position 32,112
No matching tile for position 48,112
No matching tile for position 64,112
No matching tile for position 80,112
No matching tile for position 96,112
No matching tile for position 112,112
No matching tile for position 128,112
No matching tile for position 144,112
No matching tile for position 160,112
No matching tile for position 176,112
No matching tile for position 192,112
No matching tile for position 208,112
No matching tile for position 224,112
No matching tile for position 240,112
No matching tile for position 256,112
No matching tile for position 272,112
No matching tile for position 288,112
No matching tile for position 304,112
No matching tile for position 320,112
No matching tile for position 336,112
No matching tile for position 352,112
No matching tile for position 368,112
No matching tile for position 384,112
No matching tile for position 400,112
No matching tile for position 416,112
No matching tile for position 432,112
No matching tile for position 448,112
No matching tile for position 464,112
No matching tile for position 480,112
No matching tile for position 496,112
No matching tile for position 0,128
No matching tile for position 48,128
No matching tile for position 64,128
No matching tile for position 112,128
No matching tile for position 128,128
No matching tile for position 176,128
No matching tile for position 192,128
No matching tile for position 240,128
No matching tile for position 256,128
No matching tile for position 304,128
No matching tile for position 320,128
No matching tile for position 368,128
No matching tile for position 384,128
No matching tile for position 432,128
No matching tile for position 448,128
No matching tile for position 496,128
No matching tile for position 128,176
No matching tile for position 144,176
No matching tile for position 224,176
No matching tile for position 240,176
No matching tile for position 32,192
No matching tile for position 48,192
No matching tile for position 64,192
No matching tile for position 112,192
No matching tile for position 128,192
No matching tile for position 144,192
No matching tile for position 160,192
No matching tile for position 224,192
No matching tile for position 240,192
No matching tile for position 256,192
No matching tile for position 352,192
No matching tile for position 368,192
No matching tile for position 16,208
No matching tile for position 32,208
No matching tile for position 48,208
No matching tile for position 64,208
No matching tile for position 112,208
No matching tile for position 128,208
No matching tile for position 144,208
No matching tile for position 160,208
No matching tile for position 208,208
No matching tile for position 224,208
No matching tile for position 240,208
No matching tile for position 256,208
No matching tile for position 336,208
No matching tile for position 352,208
No matching tile for position 368,208
No matching tile for position 384,208
No matching tile for position 400,208
No matching tile for position 16,224
No matching tile for position 32,224
No matching tile for position 48,224
No matching tile for position 64,224
No matching tile for position 112,224
No matching tile for position 128,224
No matching tile for position 144,224
No matching tile for position 160,224
No matching tile for position 208,224
No matching tile for position 224,224
No matching tile for position 240,224
No matching tile for position 256,224
No matching tile for position 320,224
No matching tile for position 336,224
No matching tile for position 352,224
No matching tile for position 368,224
No matching tile for position 384,224
No matching tile for position 400,224
No matching tile for position 16,240
No matching tile for position 32,240
No matching tile for position 48,240
No matching tile for position 64,240
No matching tile for position 112,240
No matching tile for position 128,240
No matching tile for position 144,240
No matching tile for position 160,240
No matching tile for position 208,240
No matching tile for position 224,240
No matching tile for position 240,240
No matching tile for position 256,240
No matching tile for position 320,240
No matching tile for position 336,240
No matching tile for position 352,240
No matching tile for position 368,240
No matching tile for position 384,240
No matching tile for position 400,240
No matching tile for position 16,256
No matching tile for position 32,256
No matching tile for position 48,256
No matching tile for position 64,256
No matching tile for position 112,256
No matching tile for position 128,256
No matching tile for position 144,256
No matching tile for position 160,256
No matching tile for position 208,256
No matching tile for position 224,256
No matching tile for position 240,256
No matching tile for position 256,256
No matching tile for position 320,256
No matching tile for position 336,256
No matching tile for position 352,256
No matching tile for position 368,256
No matching tile for position 384,256
No matching tile for position 400,256
No matching tile for position 16,272
No matching tile for position 32,272
No matching tile for position 48,272
No matching tile for position 64,272
No matching tile for position 112,272
No matching tile for position 128,272
No matching tile for position 144,272
No matching tile for position 160,272
No matching tile for position 208,272
No matching tile for position 224,272
No matching tile for position 240,272
No matching tile for position 256,272
No matching tile for position 320,272
No matching tile for position 336,272
No matching tile for position 352,272
No matching tile for position 368,272
No matching tile for position 384,272
No matching tile for position 400,272
Saved native palette data to "FxLogoPacked_1t.clr"
Saved native tile data to "FxLogoPacked_1t.pic"
Saved native map data to "FxLogoPacked_1t.map"

is it failing to map 130 unique tiles into 1024?
why does it make a 16,16,4 palette for an image that has 16 colours in it?

grit accepts providing multiple images as input and creating a combined palette or tileset as output.

SuperFamiconv lets you do things like provide a png that acts as palette or tileset and only generate a map from the other png file with the full image. This is very useful, but not the same thing as what grit does. You need to have created the combined palette or tileset beforehand.

It would be great if SuperFamiconv could support the first behaviour.

when you try to do it, it gives the error "Palette contains duplicates of color zero, treating color zero as transparent"

v0.9.2 is more than one year old, and lacks some changes made since then. *n?x users can fairly easily compile from source, but this is more problematic for Windows users, which usually fall back to 0.9.2's pre-built binaries. Would it be possible to make a release so that they benefit from the changes?

Super NES backgrounds have several modes with 2 bits per pixel: all planes of mode 0, the third plane of mode 1, and the second plane of modes 4 and 5. The Game Boy Color tile and palette formats are identical to those of Super NES 2bpp modes, but its tilemap entries arrange bits differently.

FEDC BA98 7654 3210  Super NES tilemap
|||| ||++-++++-++++- Character number (max. 0x03FF)
|||+-++------------- Palette
||+----------------- Priority
|+------------------ Flip horizontally
+------------------- Flip vertically

FEDC BA98 7654 3210  Game Boy Color tilemap
|||  +(((-++++-++++- Character number (max. 0x01FF)
|||   +++----------- Palette
||+----------------- Flip horizontally
|+------------------ Flip vertically
+------------------- Priority

Two other differences:

• Games are likely to store bits 15-8 and 7-0 in separate arrays because of how VRAM is accessed on that platform.
• Each 4-color subpalette has its own color 0. Instead of (say) palette 3 using colors 0, 13, 14, and 15, it uses colors 12 through 15.

Some Game Boy projects with Super Game Boy support may use SuperFamiconv for the SGB border. If SuperFamiconv also supported GBC tilemaps, this would let games use it for both SGB and GBC assets.

superfamiconv tiles -DFR -i twobit.png -d test.chr
superfamiconv tiles -n test.chr -o test.png

When twobit.png is 2-bit (as seen by "file", Gimp saves them like that if they have 4 colors), the output is all corrupted. When I convert it to 8-bit, superfamiconv correctly converts it, and test.png looks good.