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.
Tiled can export to CSV (comma separated values)...which Python has a module specifically to handle them.
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?
Espozo wrote:
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).
rainwarrior wrote:
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.
Absolutely. The investment in good tooling is well worth it.
rainwarrior wrote:
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).
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.
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?
Use ASCII, render the map to a buffer in main memory, and then DMA the map to VRAM.
While rendering the map to a buffer in main memory, you can interpret control characters such as newline and form feed. Thwaite, RHDE, the Action 53 menu, Haunted: Halloween '85, and The Curse of Possum Hollow all respond to the newline character (0x0A); some also do something special with form feed (0x0C).
Espozo wrote:
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?
The top bit of VMAIN ($2115) tells the PPU whether to increment the word address on a write to VMDATAL or VMDATAH.
Normally you set it to 1 (increment on VMDATAH/$2119) and DMA in a word pattern to $2118-$2119. But if you set it to 0 and DMA single bytes to $2118, you can write to just the low byte of a region in VRAM, and if you set it to 1 and DMA single bytes to $2119, you can write to just the high byte.
This is useful for Mode 7, since the low byte is map data and the high byte is pixel data. You can load either map data or tiles separately, without having to interleave them in software and perhaps waste time overwriting something that doesn't need changing.
I've also used this to display the OAM on screen, by setting up character tiles from 00 to FF and simply dumping the contents of OAM (loaded into WRAM from $2138) directly into VRAM via $2118.
Quote:
The top bit of VMAIN ($2115) tells the PPU whether to increment the word address on a write to VMDATAL or VMDATAH.
Normally you set it to 1 (increment on VMDATAH/$2119) and DMA in a word pattern to $2118-$2119. But if you set it to 0 and DMA single bytes to $2118, you can write to just the low byte of a region in VRAM, and if you set it to 1 and DMA single bytes to $2119, you can write to just the high byte.
This is useful for Mode 7, since the low byte is map data and the high byte is pixel data. You can load either map data or tiles separately, without having to interleave them in software and perhaps waste time overwriting something that doesn't need changing.
I've also used this to display the OAM on screen, by setting up character tiles from 00 to FF and simply dumping the contents of OAM (loaded into WRAM from $2138) directly into VRAM via $2118.
Interesting. Is the source of the DMA an array of single bytes, or word sized.
That is to say. If I unpack compressed tiles, of just the low bytes, will I have to unpack it to a buffer of every other byte being filled?
As far as the DMA unit is concerned, data is 8-bit. MDMA source options are pretty barebones: a stream of consecutive bytes, a stream of consecutive bytes in reverse order, or the same byte over and over. You can't skip bytes. It's the combination of DMAPx and VMAIN settings - how the DMA unit writes to the B bus and how the PPU distributes the received data, respectively - that allows you to send the whole byte stream to just one of the 32 KB VRAM chips instead of alternating between them.
In short, no. You don't have to leave spaces in your WRAM buffer.
...your post kinda sounds like you're talking about using NES format for sprites, or something like that. What exactly is the use case here?
I found this today...
(source, MIT)
https://github.com/Optiroc/SuperFamiconv(binary)
http://www.romhacking.net/utilities/1293/It appears to convert a PNG image to a 'palette', 'tiles', or 'map' for SNES.
I have absolutely no idea how it works, but it may be useful.
Yes, that was posted a page ago
Well, this isn't very related to this, but how do you put BG3 in front of BG1 and BG2 in mode 1? It looks like setting bit $08 (so writing $09) on $2105 should do it, but I've had no success. I'm only referencing $2105 once outside of the initialization routine, so overwriting the register isn't the problem. Is there any other register that influences this?
You have to set the tile priority bit.
For each entry on BG3's tilemap?
(I have to manually go through it again if so.)
I'm afraid so. Priority 0 just ends up behind everything regardless.
It can also still end up behind other layers if you put it on the subscreen.
The priority bit thing is likely so that you can have both a far BG and a HUD providing that the two never overlap the same vertical space.
Quote:
It can also still end up behind other layers if you put it on the subscreen.
Ok, this is completely different from my understanding of main screen / sub screen.
Can someone else confirm this info? I thought main/sub was independent of priority layers.
dougeff wrote:
Can someone else confirm this info? I thought main/sub was independent of priority layers.
It is, but you can add the subscreen to just the backdrop layer of the main screen, and that gives the appearance of the subscreen being behind the layers on the main screen.
What (I think) Nicole is talking about is most notably (only example I can think of) done in Donkey Kong Country 3, where they actually get BG3 to render between BG1 and BG2 in the canyon and factory level archetypes.
Anyway, the reason I wanted to know all of this information is that I made a rudimentary slideshow for my high school history class where we are supposed to give a summary of a person's life and determine whether or not they are a "hero or a zero". It's a bullshit end of the year project, and as such, my teacher was emphasizing creativity, with one example he showed us being a scrapbook someone made last year. I said screw that and decided to make this, which ended up being exponentially more work than I would have thought, and I never even ended up making the ability to display pictures in the slides, but there's so few words you can write in a 32x32 grid that pictures is all it would be anyway. The code is also really sloppy because I had to get this done in time.
I just realized that this is my first fully completed code of anything... Man, that's sad...
Attachment:
Slideshow.zip [1.07 MiB]
Downloaded 75 times
Oh yeah, what does the "Address Remapping" in $2115 (described here:
https://wiki.superfamicom.org/snes/show/Registers) actually do? Their description really confused me. I'm asking because I had to use it sometimes and othertimes I didn't to get everything to display properly.
I found
nocash's description to be the clearest one.
In short, it lets you address the SNES's memory as 256x1 pixel bitplanes instead of the odd interleaving per tile.
So what is a typical use case scenario for doing the 256x1 writes? I remember playing with these registers hoping to find a way to optimize for streaming new sprite graphics but it doesn't seem like that's what the address remapping is for.
Well, psycopathicteen used it to render some
2bpp bullet hell tests in software on the S-CPU; it's easier than dealing with tiles.