nesdev.org

Optiroc wrote:I’m finishing up full PCE support tonight, probably.

Done. PCE map output isn't really tested but "should work".

I'm still not confident that my Windows builds work as expected, so feel free to PM me if it doesn't work (or do work, for that matter!).

Thanks for the newest version. It seems to generate valid maps, palettes, etc for 24-bit and indexed PNGS. 1024x512-pixel-large images also seem to remap just fine.

I'll actually test the tool and images out on my PCE tonight or in a couple of days.

ccovell wrote:Thanks for the newest version. It seems to generate valid maps, palettes, etc for 24-bit and indexed PNGS. 1024x512-pixel-large images also seem to remap just fine.

I'll actually test the tool and images out on my PCE tonight or in a couple of days.

Awesome. There should be no particular size limit on the images used. For instance, a possible use case is to generate level maps out of severely large PNGs (which is probably not something you want to do in a “real life” scenario, but still).

Report any issues or questions you have, and I’ll try my best to address them!

Hi, sorry, but I have one important suggestion for any tile format (PCE, SFC...) and that is the ability to specify the starting VRAM address of the first graphics tile. Tiles can't all start at VRAM $0000, as often the MAP/BAT is located there. Thus the tile numbers in the MAP will be incorrect.

Optiroc wrote:There should be no particular size limit on the images used. For instance, a possible use case is to generate level maps out of severely large PNGs (which is probably not something you want to do in a “real life” scenario, but still).

Several NES games I've worked on for Retrotainment Games do exactly that, and then the tiles and map get postprocessed for compression. It beats making a custom map editor, porting it to Windows, and training artists two states away on its use.

ccovell wrote:Hi, sorry, but I have one important suggestion for any tile format (PCE, SFC...) and that is the ability to specify the starting VRAM address of the first graphics tile. Tiles can't all start at VRAM $0000, as often the MAP/BAT is located there. Thus the tile numbers in the MAP will be incorrect.

Ah, too true. I’ll add a tile-index offset option for map generation.

This might be of some use on SNES too, albeit not as often since tile base offset is configurable per BG (which is why there’s no such option here in the first place).

tile base offset is configurable per BG

Yeah, I can't imagine needing an index offset for SNES.

tepples wrote:Several NES games I've worked on for Retrotainment Games do exactly that, and then the tiles and map get postprocessed for compression. It beats making a custom map editor, porting it to Windows, and training artists two states away on its use.

Yep, it’s not completely unreasonable either, which is why I added options like custom splitting and column-major order for map output.

ccovell wrote:Hi, sorry, but I have one important suggestion for any tile format (PCE, SFC...) and that is the ability to specify the starting VRAM address of the first graphics tile. Tiles can't all start at VRAM $0000, as often the MAP/BAT is located there. Thus the tile numbers in the MAP will be incorrect.

As of this release there is a "--tile-base-offset" parameter to the main/map commands. It's simply an integer that will be added to all tile indices during map export, which I hope solves your issue.

--tile-base-offset 128 could help with Game Boy as well, as the most common background display mode uses tiles 128-255 then 0-127.