SNES Tilemap Editor?

You know, I just realized something: Is there not a tilemap editor for the SNES? I can think of some for the NES and the GBA, but I don't think I've ever seen one for the SNES before. I don't need it right now, but I bet I'll want one eventually if there is one, I'm mostly just curious.

Just so you know, I mean something like "NES Screen Tool" for the SNES.

It's not that hard to make your own editor. I think most developers do that rather than using a more generic freely available tool. Usually you want something specific to your needs rather than a one size fits all.

Plus if you are talking about level/stage data you are probably going to want your own data format the way you like it rather than just a strictly graphical representation.

For a static screen there is actually a tool out there, I think PCX2SNS or something like that. It's designed to do something similar to NES Screen Tool. It converts a bitmap image into tiles and provides a tilemap to load so you can display that screen.

I think making your own tools is best in this category. Now for sound stuff I personally think having a sound driver and tools for music and sound effects conversion would be very welcome.

Hard enough to where I have no clue how to do it.


I meant a strictly graphical representation, but yeah, now that I think about it, only being able to edit tiles wouldn't be way too useful. Actually, a lot of games have collision tied to the tilemap, but I don't think I want to do that.


Yeah, but it isn't that useful for if you're like me and you want to change out tile graphics during the level, because I have no clue how it is organizing the tiles. It's fine for something like a title screen, but I definitely wouldn't design a whole level off it.

You might want to consider learning a programming language and environment on the PC so you would be able to create these tools for your projects. If that is not possible then you might have to resort to creating map data by hand which can work but isn't as nice as you lack a visual of the actual screen.

There was mention in a topic relating to the NES that you could create a map editor (or other type of data editor) on the console itself and save the map data to SRAM. That way if all you know how to program for is the SNES you could still manage to get tools to help you. And SNES supports a significant amount of SRAM so you would have some potential.

I think PC based tools would be better, but console based tools would have a certain novelty.

I had kind of been thinking about the same thing when I saw the Neo Geo Sprite editor thing.

Was it this?

For a real game, you'll want to design a level format and make a level editor for that format. The good news is that half of your level editor's code can be shared with the game itself.

I've just started using Tiled myself to create maps for a snes game.
It isn't snes specific so I've created a small python script to convert Tile's .tmx files to a format that my game can read using the python library tmxlib.

I haven't finished the level loading routines yet so I can't show or share anything that works but the setup seems promising and less time consuming than creating a tool of my own from scratch.

I just tried 'Tiled', and I think I can use it to generate level data for my NES game. Thanks for the suggestion guys. I had to construct all the meta-tiles first, and create an image format (in Photoshop) that Tiled can import, but the TMX file is a really useful organization of that data (open it with Notepad or Notepad++). Now, if I can write a tool to convert the data to fit my data compression format, it should be a a snap to create levels with this tool.

Some possible options:

8x8 or 16x16 tiles
arranged by rooms, or full rectangle
stored in columns or rows
literal or indexed

I tried making one in excel to go with my other excel graphical tools, but in retrospect it wasn't terribly useful. When doing my own editing I usually forego all the fancy features I made and just type/copy/paste everything in Excel, then dump the spreadsheet to a .inc with a simple macro. I will say doing it that way is MILES better than trying to edit a map as simple text in notepad, for a number of reasons... But my tools didn't come in as handy as I'd hoped and it's still a royal pain in the ass. There is no way I'll be able to do the sheer volume of map editing I need to do that way without going insane or getting carpal tunnel; I need a better solution.

If there were only some possible way to have Excel display the map graphically as you edit it, I think I could get used to it enough... But having it actually draw the map takes a few minutes at best. I can think of a couple actually-useful features I could probably still implement that I never got around to, such as selecting a range of cells and and inverting/rotating them (either each tile individually or together as a block).

I've had Tiled suggested to me before, but immediately discounted it as a possibility due to the conversion work, and not being certain how it handles palettes/priority/etc. If you come up with some simple python tools to convert things to/from that format, I'd love if you shared them!

I also thought about the SRAM trick, and that might well be what I end up doing.... It really shouldn't be too hard for me to build an in-game map editor. I mean, a couple days of work to get it set up I'm sure but being able to see the map, jump around in it and test it as you build would be amazing.

I have the same idea with my theoretical levels... make a level editor, perhaps test them in real time, and save them to SRAM for importing later into the game.

In-game editor would be ideal, but couldn't you just load new data into the starting point of the game, and see how it looks / plays?

I just thought of an obvious problem with the SNES game level editor thing: Getting information out of it is fine, but how do you give it information? I mean, it'd be nice to have different tiles to work with, and you'd have to be able to import them unless you also want the tile editor to come with the ability to also create graphics along with palettes.

Poke it into the emulator hex editor?

Does anyone use the term "poke" anymore? Its an Apple Basic term. I mean 'type it in manually to edit the value'.

The same way I do with my graphics editor on NES: I write a program to create a .sav file, the counterpart to .srm files on Super NES. But then I also put a tile and palette editor into it, so it can theoretically be used standalone as well.

I think as far as graphics go, you'd put them into your newest ROM build and the editor would be able to choose which set of tiles to use. I don't think there is any need or reason to edit actual graphics on the console. Maybe something for defining your Level Data Blocks, defining which tiles make up the block and the physical properties of block. That would be something you'd want to be able to do visually.

Tiled does not support palettes/hFlip/vFlip. It does support multiple layers on top of each other but I ignored that. However this is a non-issue if your using a MetaTile format to convert tile IDs and their 4 8x8 tile/palette/order counterparts on the SNES.

I've written a python script (tmx2metamap1x16.py) that converts from tmx files into my metatile map format to include in an ca65 assembly.

The script also creates the necessary targets, events, and entities tables from the appropriately named object layers in tiled.

I'm not very happy with it, but it works.

I've been thinking of writing a map editor in qml/qt5 that has the appropriate data forms for tile animations, targets, events, entities and scripts.




Nice idea. I am thinking of using byuu's SNES USART idea to load the map from the editor into SNES WRAM for play-testing.

I just need to install a *nix on my laptop so the device drivers work and I can create a connection between the SNES and my system (Windows 8 is problematic).

It actually does support hFlip and vFlip (press x or y when placing a tile to flip it) and you can read out if it is flipped with tmxlib too (my_tile.flipped_horizontally and my_tile.flipped_vertically).

It doesn't support palettes as you mentioned, but that can be worked around by using just one palette per tilemap and using multiple tilemaps instead. You might get some tile redundancy but that could be fixed in an optimization step in the map file converter if rom space is the limiting factor (would probably be faster to implement than a new level editor from scratch). My project is free-time-limited, so I try to reuse tools if possible.

That said, I understand that it may not be optimal for all situations and as a gamer I love when games have in-game editors. So if you want to spend your time on implementing that: do it!

Would you look at that.
Tiled does support tile flipping. None of the menus or toolbars or tutorials I read even suggests that the program supports it. I knew it was part of the tmx spec, didn't think it the editor supported it.

Thank-you for letting me know.

I personally found Tiled to be miserably bad at letting you know how you're supposed to use it. I've installed it twice and spent like an hour dicking around, and I've never gotten anywhere.

I probably won't be able to make this, but I was just thinking of ways you could. I'd imagine you'd have a screen for editing palettes, a screen for editing the graphics, a screen for adjusting things like tilemap offsets and what color depth the BG mode you're using is, (would effect multiple things) and another screen for actually editing the tilemap. most of the screen would be the tilemap, but there could also be a window up at the top that would have all the graphics. Because you don't actually want to use any graphics for the tilemap editor screen, you could use the two window layers for a cursor:


One other thing that would be cool is if there was a screen for just viewing the tilemap and you could put multiple of them over each other, but then you'd have to deal with multiple tilemaps. I don't have a clue as to how you'd implement something like multiple screens of tilemaps.

Also, just so I don't forget...


(Wait a minute though, using 4bpp tiles, you can't have a tilemap use all of vram for tile graphics?)

You would probably need high res mode in order to do that, with maybe a few different pages, just to avoid it taking up too much space onscreen.

I think it would also be a good idea if we used an indexed tile set, where there is a table of every pattern/palette/priority/flipping combination we'd be using so you can keep the grass green, and the dirt brown and the rocks grey.

Correct. In 4bpp mode, each tile is 32 bytes long, meaning only half of VRAM is available for each plane's tile graphics. But you can set planes 1 and 2 to different offsets, and you'll need to leave room for sprite cels, plane 3 (in mode 1), and tilemaps anyway. That's the tradeoff of having 8 background palettes instead of 4 like on the Genesis.


In other words, define metatiles.

Eh, it's still worth it. You know, how in the world did the Turbo graphics 16 go about this?


8bpp graphics though... You know, if I'm not mistaken, 1 high res 8bpp layer could have been possible under the same vram bandwidth, couldn't it? I guess they figured it would be useless considering the massive amount of graphics it would take up.

Anyway, I think about 4 screens of tiles in a 256x64 window would be fair: (There could also be a way to make the window disappear)


Anyway, If we want to get serious about this, do you want to make it a group project? We could communicate here. Offcourse, we should all use the same assembler and tools to make it. I vote on ca65.

Well, I just stripped my Game I was making into an empty shell for whatever you want (in this case, a tile editor). The only thing it really does it detect button inputs, (I have no clue how to actually program it to do so, I just hijacked someone else's code.) but I've left some of the "guidelines" left, although they're blank.

Should the levels be divided into 32x32 tile rooms, to match the way they're uploaded into vram, or should they be stored in a more game play friendly way? Alisha's Adventure stores level maps in vertical strips of tiles.

For whatever reason, I decided to make a little define thing for the controllers, because I had never done it before and I would often forget the buttons. (I tried to write "16Bit" instead of "Word", but the assembler kept fussing at me.)

;Button Numbers
RButton = 16
LButton = 32
XButton = 64
AButton = 128

RightDPad = 1
LeftDPad = 2
DownDPad = 4
UpDPad = 8
StartButton = 16
SelectButton = 32
YButton = 64
BButton = 128

WordBitRightDPad = 256
WordLeftDPad = 512
WordDownDPad = 1024
WordUpDPad = 2048
WordStartButton = 4096
WordSelectButton = 8192
WordYButton = 16384
WordBButton = 32768

Anyway, I personally think 32x32 tile rooms sounds better, but that's my opinion. Anyway, I'm really not to familiar with BGs, (which is why I probably shouldn't be working on this...) I just think it's the best for games that scroll up and down, like many of them do. I guess depending on the tilemap size, that's the size of the room grid? I mean like 32x32, 32x64, 64x32, and 64x64.

The latter, in the majority of cases. You'll usually want to store things in terms of metatiles (tiles in groups of usually 16x16 or 32x32 pixels), possibly with another layer of meta-metatiles (Mega Man; Blaster Master; Sonic the Hedgehog) or as a list of "objects" made out of metatiles (Super Mario series).


So does The Legend of Zelda. So does Wrecking Ball Boy, a game I wrote in Python. And so does my current NES project.

I seem like I have different goals than the rest of you, because I don't really want to deal with something like metatiles and whatnot because I don't really want to be held back by a made up restriction that doesn't even exist in hardware and I imagine it would take some excess CPU time to try to decode the metatiles into the useable format. I just feel that with how cheap memory is now a days, why even bother, but that's my opinion. I do think it would be cool if you had something like a 48x32 tile room using a 32x32 tilemap that you wouldn't have to have another whole half blank tilemap, but I don't know how you'd have 1 and 1/2 tile maps.

Actually, I'm stupid, vertical strips probably would be the best. Would you have like a thing that says how many vertical strips your level is comprised of, and then for each vertical strip, say at what tile it starts vertically, and how many tiles down it reaches? The vertical strips would be Seemingly Infinity x 1 tiles. The tile map editor would look at the giant tile map and read it from top to bottom, and go over one and then read it from top to bottom again and then would generate the other "guideline table" I'm talking about. The problem I can think of is that if you want a level in a "O" shape or something like that, the inside would have to be a blank tile map. Grrr... Does anyone have any other tile map ideas?

Metatiles exist in part for collision detection: they give properties such as solidity to a particular arrangement of tiles.

I mean, I'd say metatiles are fine for something like this:



but the time you reach this, I'd say don't even bother.



I'm probably just going to have a separate collision tilemap.

I'm not a big fan of metatiles either. I prefer using 16x16 tile mode.

Wait, 16x16 tile mode? Is it sad that I don't know what that is?

You can enable 16x16 tile mode to each of BG layer with $2105.

I thought you already knew this because you mentioned Metal Slug, which was on the Neo Geo which used 16x16 tiles.

No, I was just saying that with something like Metal Slug, there's so many unique tiles that I wouldn't bother sorting them into 32x32 tile chunks because you'll only ever use 1 chunk once.

Anyway, I used Google and I found this, which I never knew existed:


The one thing I'm curious about is that in 16x16 tile mode, for every character bit, does it go by 8x8 tiles, or does it then go to 16x16? This way, you could actually use tiles from all of vram. The fact that the mode can also actually make a 1024x1024 pixel tile map is also really cool. Honestly, I'd use it to if I didn't have to forfeit the 8x8 palette area (which would make BG 3 in Mode 1 totally useless.) I probably could use it for BG 2 or something if I was running out of space for a tile map though, as you said 16x16 tile mode can be enabled for each layer individually?

The 16x16 mode still goes by 8x8 pixel tiles. It just takes the next tile to the right and the next two tiles on the next row.

You know, forget it. Could we just have it to where the tile editor outputs a giant tilemap in left to right and then down (like a book) and also has 2 16bit registers for saying how many tiles vertically and how many tiles horizontally the giant tilemap is? this is the simplest way, even if it takes up the most space, which I already stated isn't exactly my top priority. (It's speed and flexibility.)

And even then, you can decompress level maps to $7F0000.

The one thing is I don't want to waste time tying to decompress the giant tilemap on the fly, (I'd rather spend the CPU time on other things that aren't a matter of space) and I don't think it will reasonably fit in a 128KB area. Could you have it compressed, and have a ton of SRAM specifically for holding the uncompressed tilemap? I'm talking like 256KB of SRAM or something like that, (if that's even possible) except it doesn't actually need to save or anything.

I don't think that level editors running on old consoles is the best idea, mainly because of the amount of RAM they have. A while ago, I came to the conclusion that the simplest generic map editor would do the following:

1- allow you to place blocks in a 2D array;
2- allow you to copy and paste rectangles of specified dimensions, optionally aligned to a grid of those dimensions;
3- optionally propagate changes made within a cell in another type of grid to all cells that look the same;
4- output maps as huge 2D arrays;

These 2 types of grid (one for editing and one for propagation) should make it easy to draw levels that use multiple depths of metatiles, while still generating a simple, huge 2D array, that you'd have to put through a script in order to generate the final binary files.

The reason this can't work well on old consoles is that they don't have enough memory to hold huge 2D arrays, so you need to compress them somehow, and compression is game-specific, and goes against the idea of having a generic editor.

There's no reason this actually has to run on a real SNES, is there? Couldn't you just write a custom cartridge manifest for bsnes that gives you nearly 12 MB of RAM (you'd probably want a bit of ROM to put the editor in)? (Actually, I can see no reason that wouldn't work on a real SNES, but I have no idea if any existing flash cart could handle it...)

Well, how much ram can you cram (sounds like a bad rap...) on an SNES cartridge? I'm assuming you can use SRAM just like regular work RAM. Heck, you won't even have to upload the tilemap to SRAM because that's where it will be created anyway.

New post incoming:


I was thinking the same thing.

There's several different practical limits for the amount of RAM you can fit on a SNES cart:
1- 1MiB, is the largest single IC static RAM you can buy right now ... above that, you need to convert some kind of lower-voltage DRAM into a format the SNES can directly use. (Fortunately, modern DRAMs are fast enough that the SNES's asynchronous interface is still manageable.
2- 8MiB, the largest power of two that leaves space for a boot ROM and doesn't need a complicated memory mapper
3- Yeah, sure, whatever. It'd be hard to use 1GB+ of RAM on a 3MHz 65816, but you could do it.

Hence PSRAM, which is DRAM with a built-in DRAM controller that makes it look like SRAM to the surrounding system.


Which is fine because that's how much RAM the 65816-based Apple IIGS could be expanded to.

Considering that if I'm correct in that that's the exact size of a 2048x2048 tile tilemap, (4096 32x32 screens) that's way more than enough.

I just thought of another problem... If you added one more row horizontally, wouldn't the data for everything need to be shifted, and couldn't this take a crazy long time? Also, what happens if you start the tilemap at the coordinates 0x0, and then you decided that you wanted the level to go up more? I mean, you could do it by having ram wrap around, but I'd imagine you'd want it to fix itself when it's done, which would still probably take a crazy long time. Could you do a DMA transfer from SRAM to WRAM, and then back in a different location? Would this be good? Of course, with the wrapping around thing, you don't need to do this until you want to save it, but for adding more tiles horizontally, you do.

Inserting a row is just a memory copy, and at 7 cycles per byte copied using MVP or MVN, they go pretty fast. Sometimes a game programmer's intuitive sense of "what is slow" may be distorted by the difference between what is slow when done 60 times a second and what is slow when done only once.

True. In the worst case scenario, (increasing a 2048 x 2047 tile layer one row more) How long do you think this should take?

You need a "resize" tool with options for anchoring the existing data to a corner. A tool for rotating the map should be pretty useful too.

I'm just now figuring that if you go up one tile strip, all the data gets shifted down. I'd like it to where the tilemap automatically increases in size with every new tile you put down. You could have it to where a blank color 15 tile represent out of the tilemap, because you wouldn't want to use color 0, because that could just look like a clear tile in the tilemap. Actually, wait, this blank tile will still take up a tile spot, so I don't know. You could have it to where the tile map has to at least be 28x32 tiles, (why would you want less than the screen anyway?) and there would be a tool for adding and subtracting a row from the top, the bottom, left, and right. By adding a row to the top, all the data gets shifted down the equivalent of one row, and the data also gets shifted when you add to the left or the right, but not down because there's nothing ahead of it. One tricky thing I though of is that in ram, a blank tile and nothing are both #$0000, so you'll have to manually calculate the size of the tilemap yourself (tiles tall x tiles wide x 2. the editor should show how many tiles tall and wide the tilemap is) and not take anything after it.

I think I figured out a good format that would be good for size flexibility, collision detection, and VRAM updating.

Divide the level into rooms that are 16 by Y tiles big. To find a tile, for collision, you can do this:

With Y being the height? Usually, you put the Y first, like "Y by 16 tiles big". Sorry, I'm just a freak.

Anyway though, I'm probably going to stick with the format I came up with until I've finally made a demo using it. For testing purposes, does anyone have a sheet full of tiles with letters and numbers on them?

Since when is height put first in English? True, it's put first in C because of its array syntax, but the size of an HDTV is generally quoted as "1920 by 1080".


You mean like 8x8s.png, Fizzter 8x16, Fink 8x16, or Wasted 8x16? Or for a bunch of 16x16 icons, you could pull the card emblems out of Concentration Room.

There's no single format that will be good for all games. It's not even because of the engine, since reusing an engine would be easy, it's actually because of the different types of level designs that exist, each more suited to a different format. An RPG has very different requirements from a platformer. A screen-by-screen platformer has different requirements from a speed-based platformer.

I thought of an idea. While loading a level, the CPU can generate a lookup table pointing to the beginning of every row of tiles, to avoid having to use multiplication.

You're right... Today just isn't my day.


That sounds fine. I personally like the ideas of the "book style" tilemap the best, just because it's so easy to visualize and probably the most simple to make.

I guess this would be fine for a test? (I find it slightly amusing that no actual work has been done yet...)

I do this to read screens off my level maps.

The Capcom/Konami programmers probably would've wasted their time here doing 16bit multiplication, poking it through the $42xx registers.

A game with a solid horizontal status display, like Super Mario Bros. 3, could well get by with fewer than 28 rows per screen, especially if it didn't scroll vertically as SMB3 tends to. Alternately, a solid vertical status display would reduce the effective number of columns per screen. Similarly, a game with an extended VBlank or a border around the playfield, or both, might end up using fewer rows and/or fewer columns.

If you were using 16x16 tiles, one screen would be 16x14.

Since the tilemap data is in row format in VRAM, it isn't all that useful to have maps less than 32 tiles wide, but maybe the program could automatically pad the output, or at least provide an indicator on screen so you don't get confused and start using the wrong width...

I was trying to write code for a tile selection window on top of the tilemap editor, and I just thought of something... How would you necessarily set up how the tiles are arranged in the window? I mean, you could just go from left to right and then down like a book, but then 16x16 tile mode would be all weird. I've been thinking of the possibility of instead having a vertical window like this:


This looks better in my opinion, as the tile map window is closer to a square than a rectangle now, and the way tiles are arranged in it aren't as weird. You could have it to where in 8x8 tile mode, the rows in the 64 pixel wide viewing window are in a 0, 1, 2, 3, order, while in 16x16 mode, they'd go like 0, 2, 1, 4.

Right now, I'm going to just make it to where you can place the tiles shown above being 4bpp and using one palette to create a tilemap. This will just be the "demo", not even close to the finished product. I want to have it to where you can edit the graphics and the palettes as well as import them, and also edit 2, 4, and 8bpp layers and possibly even the packed pixel mode 7 layer if I ever get to it. for the actual display though, it wouldn't use mode 7, it would a regular 8bpp layer being restricted to 256 tiles and no flipping.

Edit: Dang it, I know why I didn't have the window vertical: I wanted to use hdma to create a bar between the window and the tilemap to tell them apart. Wait, why can't I still just use a window layer and have it be vertical? Oh yeah, I wanted to have a cursor thing made of two window layers, but I can really just have one translucent box for a cursor. One big problem I've been thinking about how is how you can use up all the tiles in vram with a 8bpp layer, which would leave no more tile room for numbers for information like tilemap size, but I supposed you could use forced blanking to replace the tiles somewhere down the screen.


It looks kind of awkward, but it will do.

Edit: Oh, 93143, you're right. I guess it would make the most sense to where the you could make the tilemap whatever size, and that whatever is outside of the tilemap but still in display also be tile 0. Once the tilemap is larger than the viewing area, you can't go into the non tilemap area as the screen won't scroll anymore. You can only just increase the tilemap size, which in that case, it's still going to be tile 0 because that's what it defaults to. Does that sound good?

Sounds reasonable. Unless you want to put black or a "blank" pattern in unused areas instead...

Actually, it occurs to me that padding a tilemap with zeros if it's less than a multiple of 32 tiles wide might not be something a ROM-limited game would be especially likely to do. The absolute minimum level of compression would be to store the active part of the tilemap only, and have the CPU pad it live or use multiple DMA transfers. It's not like it would make updating it any harder; only loading the initial map, and that doesn't (usually) have to be fast.

Of course this is a separate consideration from the display map used by the editor, which has to at least fill the edit window or you'll get garbage...

I wonder if it would be too complicated to optionally allow the use of hires mode when editing Mode 0-2, to allow the user to get a bit of an overview... you'd probably want to use a normal HDMA split for the tile selector window in that case...

I was thinking about also implementing a mode for just viewing everything without editing tiles, and it could work there.

The different viewing modes would be:

2bpp 8x8 tile map
2bpp 16x16 tile map
2bpp hi res 8x8 tile map
2bpp hi res 16x16 tile map

4bpp 8x8 tile map
4bpp 16x16 tile map
4bpp hi res 8x8 tile map
4bpp hi res 16x16 tile map

8bpp 8x8 tile map
8bpp 16x16 tile map

and I would say mode 7, but if you scale out far enough, you can't hide the edges of the tilemap. I guess just don't implement scaling? I'm really kind of curious how to implement mode 7 at all because of how it's set up differently. How is it set up again? High byte for graphics, low byte for tilemap? Isn't there also a way to have it to where half of the pixels on the mode 7 tilemap overlap sprites called EXTBG or something? Also, I'm assuming 16x16 tilemap mode doesn't work for mode 7...

You could split it halfway across, couldn't you? Have the left side of the selector window be the top half of the tile address range, and the right side be the bottom half? That way you get correct 16x16 tiles; the only issue is that the tile numbers would be discontinuous across the middle, but does the user really care about that?

Also, this would allow you to do a mode switch partway down, so as to do the tile selector in normal res and the map display in hires. Interlace probably can't be toggled mid-frame, so the tile selector would be a bit jumpy, but it's probably better than trying to switch modes mid-scanline as you don't need a multi-tile buffer to cover the split...


Why is that a bad thing? This isn't a game; it's an editor. Besides, Mode 7 has a few options for what to do when you go off the tilemap (repeat the map, repeat tile #0, repeat colour #0) so it might be at least slightly useful to see how those look.


Yep. The graphics are bytemap rather than bitplane, and the tilemap is a simple 8-bit index map (hence the 256-tile limit) with no flipping or palette bits.

The nice part about the VRAM gate is that it's got one 8-bit register for each VRAM chip (at least, I'm pretty sure that's how the split works), and you can set it to increment the word address (by 1, 32, or 128) with a write to either one. This means that for Mode 7, you can use a single DMA transfer to update either the graphics data or the tilemap without touching the other one, meaning you don't have to store them interleaved in ROM, and you can render to Mode 7 (like Wolfenstein 3D) without worrying about skipping the tilemap bytes.


Yeah, as far as I can tell that adds a second BG layer to Mode 7, and this BG2 is exactly the same as the BG1 (scroll, matrix, etc.) except that the top byte in the colour index for each pixel is considered a priority bit instead of a colour bit. This page explains the priority sequence for all modes including Mode 7 EXTBG. I assume you could send one layer to the main screen and one to the subscreen and do transparency tricks, as usual. Also, apparently direct-colour mode only works with BG1.


It doesn't.

If you're wondering something, this is usually a good place to be. The other pages on that site are useful too, as I believe you know, but that one's really quite good.

Like I said, I've been trying to work on the menu, and I'm just curious, when it comes to menus where you don't drag around a cursor like a mouse and instead press up and down and stuff, do you generally move the visual identifying thing when you move to say what you're hovering over, or is one dependent on the other? I mean, when I was coding the menu, I was thinking of something like this:


vs this:

I was thinking that, except I wouldn't want the window to be that big.


Wait, what? You mean like you could have mode 1 on the left side of the screen, and mode 7 on the other?


Yeah, I guess you could have it to where it still updates when you move the tilemap, but you can see the edges, as it would give you a good idea as to how far out you can scroll. In fact, with viewing all the layers, maybe you could have it to where you can disable and enable updating so that it can look like an actual level, or just have it to where it looks exactly how the tilemap does. Offcourse, that means you would be able to adjust the tile map size.


Cool. So is one entry in mode 7 tilemap really just 8 character bits?


Would it have been any more difficult for them to have just made the second BG layer be a normal BG layer? Also, isn't the second BG in EXTBG just like a regular 8bpp BG in how the graphics and the tilemap are? I would have thought all of this would be too much for how fast the ppus can read from vram.

You know, how much silicon real estate does all this junk take up? The video hardware in just about any other 2D system I can think is way more straightforward. I mean, I look at the Genesis or the Irem M92 and it's like a few 4bpp BG layers with column scroll, and then I look at the SNES with its 2-4 2-8bpp BG layers made of 8x8 or 16x16 tiles.

Edit: Wait a minute, 93143, are you British? I just saw "colour" instead of "color". Sorry, I'm dumb,

How big? You don't want it all the way across the screen? It doesn't have to be especially tall as long as you can scroll vertically inside it...

It occurs to me that the user most certainly does care about tile numbers, if he's planning a VRAM layout, but that might not be incompatible with this idea as long as it's clear what's going on... Is there a tile editor in this scheme too?


Unfortunately, no; Mode 7 requires some initialization at the start of the scanline, which isn't done if the PPU is in some other mode, so the matrix won't work properly in that scenario. But it is possible to switch from Mode 7 to Mode 1 or 2, and probably from/to the other modes as well (I believe Mode 5 to Mode 1 has also been tried successfully).

However, it seems that switching modes mid-scanline causes artifacting. The Mode 7 -> Mode 1 switch seems to cause the rest of the current 8-pixel sliver (it seems the display works in 8-pixel columns) plus the next two 8-pixel slivers to be rendered as garbage, followed by correct Mode 1 rendering. You can put sprites on top of the garbage, but individual glitch pixels can still show through - I only get away with it in my display engine because the part of the sprite mask where the glitching happens is very dark, and I could still be in trouble if the glitch pixels change colour once I start getting fancy with the game itself. Even the Mode 5 -> Mode 1 switch seems to cause glitch pixels.

You can change scroll values mid-scanline, and there's no glitching - it just takes effect after a couple of 8-pixel slivers have elapsed (not sure of the details, but I think higan gets this right because a game used it).

When changing stuff mid-scanline, you have to remember that interrupts wait until the end of the current instruction before starting, and instructions can take several pixels - the longest seems to be 9 CPU cycles, which is 15.5 dots in FastROM or 18 dots in SlowROM or WRAM. So the split looks fairly ugly if not masked, and without timed code for jitter correction it can waste a fair bit of real estate. Also, this technique eats a lot of cycles, especially with jitter correction, since it involves an IRQ firing on every scanline (or worse, a whole screen full of timed code, which is even harder to pull off than it sounds)...

Long story short: you may not want to mess with it.


Yeah, it's just the tile number.


BG2 in EXTBG is literally the same data as BG1. No extra reading required.


禁則事項です。


...okay, no, that's not true. I'm Canadian.

Does that make me a hipster for saying Mega Drive instead of Genesis?

Well, would anyone like to share about how they deal with menus?

Slowly and painfully and probably the stupid way.

My in-game menu is on BG3 in mode 1, with priority bit set, so it appears overtop of everything. The menu only takes up the centre of the screen, everything else freezes while it's open. Since that BG3 is in front of everything, the cursor has to be on BG3 as well. My menu is loosely based on Zelda LttP's ingame menu except with more than just one screen for items. Anyways, the process goes like this:

-Open menu. Game stops. A blank menu pane is drawn to BG3 on the first vBlank
-Second vBlank, the contents of the active menu pane are drawn. All this writing to the BG3 tilemap is done manually through $2118 with piles of repetitive code.
-Every frame thereafter, the menu cursor position and its previous position are stored. Every vblank, the previous cursor position is erased and the new one is drawn in. Whenever anything is pressed that could cause the contents of the menu to change, the "second vblank" is called again which re-draws the pane contents. Whenever switching between menu panes, the "first vblank" is called doing a complete refresh.

If there's anything more specific you want to know feel free to ask. Building a menu was way more of a pain than I thought it would be.