nesdev.com

Well, yeah. I think Khaz made something, but it was somehow in Microsoft Excel?(!?) PCX2SNES can generate a tilemap from an image, but is near useless for anything other than a splash screen, as it can't generate a map larger than 256x256, if I remember correctly, and there's no way to have a reference charset or color map for it, so it puts everything wherever and arranges it however it wants (character and palette references always start at 0; you can change the starting character reference for a layer, but you can't do that with palettes, so you're screwed anyway.) Other graphics converters exist, but I don't know if they have any tilemap creating functionality at all.

I've talked about how simple it would be to make a converter for GBA to SNES tilemaps, but looking at it, while there are several options for creating tilemaps on the GBA, they really aren't, as most all of the ones I've found are game engine specific (meaning they have terrain data attached and work with metatiles). There's one called Nameless TileMap Editor that I found, but there's no way to zoom in on it, meaning it's damn near impossible on a 1080p screen.

Tiled, using pre-baked-in palettes, and writing a converter.

What is the format that Tiled outputs in?

Last I checked, Tiled actually has several different export formats (some of them engine-specific too) so the best approach would likely be to program a Tiled exporter rather than something that reinterprets a different Tiled export format.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

Tiled can export to CSV (comma separated values)...which Python has a module specifically to handle them.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Tiled's own map format can store the tile data as CSV wrapped in some XML or some other slightly more complicated formats. (e.g. "Base64" and "Base64 (zlib compressed)")

It can also export to bare CSV, json, or Lua.

The most obvious problem with just converting a PNG to a tile-based image in Super NES format is that packing 64-color tiles into eight 15-color palettes plus backdrop is equivalent to the VM packing problem, which "is hard to even approximate". That and a lot of designers expect to be able to use more than 1024 tiles between the foreground and background layers in a level, with different sets of tiles loaded during different portions of a level.

My tools can do plain tilemaps (no flips, only one palette), don't touch palettes, at unlimited sizes, can handle a reference chr or create one by removing duplicates. I use them for NES, Gen, GBA... Link in the png2chr topic.

My graphics tool (SuperFamiconv) does most, if not all, of the things you ask for. I'd be happy to add what you think is missing; it's use cases like what you describe I want it to be good for.

No binary?

Yes, with help from ARM9 I just recently got a build system for Windows up and running. These should work (not sure about what runtime libs may be needed that isn't shipped with the OS, but Windows is usually good at telling the user about any missing standard DLLs).
https://github.com/Optiroc/SuperFamiconv/releases/tag/v0.3.1

I've said this a few times in the past here, but if you're making a game, writing some tool software to go along with it should usually be part of the project.

A tile map editor is probably a pretty good learning project. The basic operations of just picking tiles and drawing them onto a grid are pretty simple.

...and once you have a custom editor made, you can add everything else is needs that's specific to your game! There's a whole lot of advantages to having something in-house that you can add things to whenever it would be convenient.


There are open source editors that you could add on to as well, and something like Tiled can do a lot of things already. Depends on the scope of your project and what it needs, but what I'm really saying here is that even writing one from scratch might not have a big barrier to entry (and has some advantages).

Absolutely. The investment in good tooling is well worth it.



I've done both, but I currently find now that for most types of games, it's easiest to use tiled, save the data in tiled's uncompressed format, then use a python/perl/whatever script as part of your build process to generate whatever you want from it. (and if you have a lot of content, use a proper makefile or other build system so that you're not wasting time reconverting everything every time)

Of course, that only works if tiled is close enough to what you want in terms of actual functionality.

_________________
My games: http://www.bitethechili.com

I don't like the XML format of Tiled but it sure beats writing a custom level editor.

Well, the reason I'm asking all of this right now is because I want to actually have a tilemap for text. However, what I figured is that I could actually use ASCII and just have any of the non-character commands be blank spaces, which obviously isn't ideal, but with the limited fidelity you have of arranging where tile data and tilemaps start for layers, it shouldn't matter too bad (especially for what I'm trying to do right now.) However, each character is a byte instead of two, which is a problem. However, I thought I heard there was a way to skip every other byte when using DMA to upload data to VRAM. Is this true, and what do you have to do if so?