This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Is there a Universial Map editor for Homebrew NES games?

Is there a Universial Map editor for Homebrew NES games?
by on (#28115)
I am creating a platformer, And there is no Map editor.

Can anyone create a map editor

If you have Delphi 3/4 (I do not have a copy), You can get the Gameboy Mep Editor and possibly modify it for NES.

The source code for the Gameboy Map Editor is below (Not made by me, Harry Mulder made it!)

http://www.devrs.com/gb/hmgd/GBTD-Src.zip

At least make a map editor for me, and for all the NES developers!

by on (#28116)
We cannot create map editors for game that don't exist, nor one map editor for all games.

These threads of yours are very irritating.

by on (#28117)
doppelganger wrote:
These threads of yours are very irritating.


Hamtaro has a history of casually requesting (or rather, expecting/demanding -- based on how he phrases his posts) that people take up huge projects in order to make life a little easier for him. Not just on this board, but on other boards I go to as well.

I've learned to largely just tune him out.

by on (#28119)
Hamtaro, wouldn't it just be easier to conform your game to a map format of a games like SMB? Either way, I'm a little confused how someone who is creating a game can expect the impossible...
Re: Is there a Universial Map editor for Homebrew NES games?
by on (#28121)
Anyway, being the limited machine that the NES is, it would be very wasteful to have a universal map format that every game could use.

Everything with the NES must be planned carefully according to the type of game being made, and I don't mean just the genre (platformer, RPG, shooter, etc), as even within the same genre things can vary a lot. A lot of aspects of the game affect what would be the best layout for the level data. Things like the type and speed of scrolling your game uses, the desired size of the levels, the ammount of ROM you're willing to dedicate to them, how detailed you want them to be, what kind of compression will be used (you certainly need it!) and the type of the cart have a huge impact on the level format.

Why do you think very few commercial games share the same data formats (except games in the same series, and sometimes similar titles from the same company)? Because they are all different.

Most serious developers end up programming their own tools, based on the specs of their games.

by on (#28123)
If you just want a simple editor for simple tile based levels stored as one byte per tile, then that probably exists already, if not I could give you the source code to one I already have.

Of course, you'll obviously want to use compressed levels in any real NES game.

by on (#28124)
tokumaru is right. Each map editor should be customized for each game engine.

Someone wanted me to knock together a map editor for a Zelda II clone. So I made a PC-based map editor called "fded" that writes RLE-compressed output in a format called "cout",[1] with a sample decoder in 6502 asm. It's suitable for 256-metatile-wide by 12-metatile-tall maps in NES games that use PRG RAM.

The next map editor I make will be on NES for NES, for a different kind of level.

[1] Feel free to laugh out loud if you recognize these names from the Apple II monitor ROM.

by on (#28126)
Which Zelda 2 clone was this? I also made a Zelda 2 clone (incomplete) at one time (in 2000). I also made a level editor (in VB) for a different Zelda 2 clone project, and that editor's code has been the base for every single level editor I've written since.

by on (#28131)
The levels is my game are all made of 256x256-pixel blocks, arranged as you want. These can be chosen from 256 different types. My level will tipically be 16384x1024 (64x4 = 256 blocks), but you could actually have way more than that, up to a total of 2730 blocks (object definitions share the space with the level maps, so it's a matter of balance between the two).

This is all stored in ROM, and does not make use of PRG-RAM. This comes with a price though. As I said before, there are only 256 256x256-pixel blocks to choose from in a set of levels (acts, since this is a Sonic game). Each of these is formed by 4 of 256 128x128-pixel blocks, which are formed by 4 of 256 64x64-pixel blocks, which are formed by 4 of 256 32x32-pixel blocks, which are formed by 4 of 256 16x16-pixel metatiles. Quite complex, huh? That's a lot of indexing, but I found a way to quickly extract rows and columns of metatiles from the level map, and that's all that matters for the scrolling engine. I hope you'll all see it in action very soon.

Anyway, that format takes away a lot of the individuality of each screen, something that would be unacceptable in an RPG, but perfectly acceptable in a fast platformer such as Sonic. Even the original Mega Drive Sonic games used a similar principle for it's level maps, just with not as many types of blocks between the screens and the metatiles.

But it's not as repetitive as it may sound. Even though you only have 256 screen maps to pick from, that part only describes the terrain, and object placement is separated from the level map. This means that the level can use the same screen map twice, but each time it will have different objects placed in it, making it seem like a different area.

This crazy layout allows for very large levels, and many of them (5 or 6, all using the same metatiles) can be stored in a single 16KB ROM bank. For simpler levels, that don't need 256 types of blocks, you could even divide that number for more than 1 zone (again, Sonic terminology).

I still don't have a map editor though. Only when the engine is ready I'll bother with making one.

by on (#28132)
This seems like it could be easily expanded by having multiple tilesets and assigning 1 to each level. IE: rather than having only 256 "screens" (256x256 pixel blocks) to split across every level, you could assign a tileset to each level, and each tileset would have its own 256 screens to choose from.

If tilesets can fit in one 16k page -- you can take advantage of this without any speed loss by putting each tileset in its own page and just swap to the desired page when loading your level data.

by on (#28134)
Disch wrote:
This seems like it could be easily expanded by having multiple tilesets and assigning 1 to each level.

Yeah, I guess. I don't do that because each 16KB ROM bank holds: the 256 blocks of each type, the metatiles, the collision maps of the metatiles and the level headers. All of these use a total of 8KB, and the other 8KB are used for level maps and object definitions.

It shouldn't be hard to separate the block definitions from all the mapping, since those are not accessed at the same time (the level map is accessed only when the camera enters a new screen, to get the index of the new screens and to load their objects, but the blocks are accessed every frame, because of collision and rendering).

Quote:
IE: rather than having only 256 "screens" (256x256 pixel blocks) to split across every level

It's not across every level, just across all the levels whose maps are in the same ROM bank. Since this is a Sonic game, Each ZONE will have it's own bank, and all the ACTS of that ZONE will have their maps in the same bank, since ACTS of a ZONE do use the same metatiles and mappings after all.

I said I can fit about 6 levels in a ROM bank, all using the same blocks and metatiles. Since I have 2 characters the player can choose, each could have their own 3 ACTS in a zone easily, so I didn't see this as a problem.

Quote:
you could assign a tileset to each level, and each tileset would have its own 256 screens to choose from.


Your idea is indeed good. The way I'm doing right now forces each tileset to have a certain number of screens worth of level maps, but by separating them I can distribute the use of the tilesets less uniformly.

Quote:
If tilesets can fit in one 16k page -- you can take advantage of this without any speed loss by putting each tileset in its own page and just swap to the desired page when loading your level data.


My tilesets (metatiles + all blocks) use only 8KB of ROM, which I placed at $8000. The remaining 8KB of the bank is used for level maps and object placement (although it is possible to have them in the first 8KB too). If I keep this layout, I just have to remember in which ROM bank the tileset used by the level is, and in which bank the level map is, and they are not hardwired to each other anymore.

You had a great idea, thanks. I'll have to shuffle some data around (specially the level headers) to make this work though, but I'll see what I can do.