Hi NesDev.com!
I know there are a lot of other people already sharing their homemade tools for building level data to load into nametables, but after trying various different programs linked on the wiki, I really couldn't find anything that really worked for me. Shiru's Screen Tool is pretty good, but considering it crashes every time I try to load anything I save in it, it has pretty limited utility for me. Most other well-made tools seem to be primarily created for rom hacking purposes.
So I made this little tool in JavaScript.
(Why JavaScript? Sure, there's a ton of overhead in doing it like this, but it's an easy way to make a quick UI and having it work across multiple platforms with no need for installation or external software libraries. Everything is running entirely on the client, too.)
Most of it was made in just a few days, and only for myself, so the code is pretty sloppy, and several features are sort of half-assed as I just needed fast results, but I'm hoping to iron that stuff out over time, so let me know of anything you find if you decide to give it a go. Hopefully it's not too early to share it, but keep in mind everything is subject to change.
At the moment it's designed with horizontally scrolling stages in mind, but as long as you're building your stages from "screen-sized metatiles", most of the interface should be useful. It's also hardcoded to divide each screen into 16x16 and 32x32px metatiles, as those provide obvious advantages with the NES's hardware while still maintaining a great deal of flexibility in the level design. The 32x32 tiles contain the palette choices for each of the four contained 16x16 tiles, while collision data (also stored as 16x16 tiles) is saved as a stream of 2-bit values in a separate table for each "screen". (I'll probably have to change this format once my own engine gets further in development - my collision detection is terribly unoptimized at this point)
Since it's pretty subjective from a project-to-project basis what kind of metatiles you want to work with, I'm thinking of making this fully customizable, but it's a bit of a hassle to make configuration options for that kind of stuff. Any thoughts on this subject, or what you use personally, are very welcome - especially if you think my current choice of metatile partitioning is really stupid :3
Same goes for the export format - Originally, I didn't put much thought into optimizing load speed, but I've added the option to split metatiles into seperate tables for each "sub-tile", allowing faster access using indrect indexed loads (since you're limited to 256 metatiles for each set anyway).
There's really no reason to not use this format. Currently my scrolling/loading algorithm never spends more than 1200 cycles outside vblank, which I found to be pretty effecient.
Here's a link to the editor: http://nesdev.eternal.dk/
As a heads-up, here are some of the additions I already considered:
- export to other assembly formats, obviously (only CA65 supported at this point, but should be extremely simple to convert manually)
- overview of the usage of various metatiles, could be useful if you're approaching the limit and need to purge some
- selecting multiple tiles and distributing them randomly as you draw, similar to TilEd
- a "wizard" that helps importing any image and generate CHR data based on it (other tools do this well, but it would be nice to have built in, especially for less technical artists)
- placing stage objects (such as enemy spawns, destructible objects, etc.)
- custom variables for each stage's header (stuff like initial player coordinates, palettes, CHR banks etc. Should be easy to add in manually though)
For the record, this is not expected to work in any browser except from Chrome or, I guess, other Webkit browsers. The 5-10 seconds I spent testing it in IE didn't reveal any issues, but using it will be at your own risk.
I know there are a lot of other people already sharing their homemade tools for building level data to load into nametables, but after trying various different programs linked on the wiki, I really couldn't find anything that really worked for me. Shiru's Screen Tool is pretty good, but considering it crashes every time I try to load anything I save in it, it has pretty limited utility for me. Most other well-made tools seem to be primarily created for rom hacking purposes.
So I made this little tool in JavaScript.
(Why JavaScript? Sure, there's a ton of overhead in doing it like this, but it's an easy way to make a quick UI and having it work across multiple platforms with no need for installation or external software libraries. Everything is running entirely on the client, too.)
Most of it was made in just a few days, and only for myself, so the code is pretty sloppy, and several features are sort of half-assed as I just needed fast results, but I'm hoping to iron that stuff out over time, so let me know of anything you find if you decide to give it a go. Hopefully it's not too early to share it, but keep in mind everything is subject to change.
At the moment it's designed with horizontally scrolling stages in mind, but as long as you're building your stages from "screen-sized metatiles", most of the interface should be useful. It's also hardcoded to divide each screen into 16x16 and 32x32px metatiles, as those provide obvious advantages with the NES's hardware while still maintaining a great deal of flexibility in the level design. The 32x32 tiles contain the palette choices for each of the four contained 16x16 tiles, while collision data (also stored as 16x16 tiles) is saved as a stream of 2-bit values in a separate table for each "screen". (I'll probably have to change this format once my own engine gets further in development - my collision detection is terribly unoptimized at this point)
Since it's pretty subjective from a project-to-project basis what kind of metatiles you want to work with, I'm thinking of making this fully customizable, but it's a bit of a hassle to make configuration options for that kind of stuff. Any thoughts on this subject, or what you use personally, are very welcome - especially if you think my current choice of metatile partitioning is really stupid :3
Same goes for the export format - Originally, I didn't put much thought into optimizing load speed, but I've added the option to split metatiles into seperate tables for each "sub-tile", allowing faster access using indrect indexed loads (since you're limited to 256 metatiles for each set anyway).
There's really no reason to not use this format. Currently my scrolling/loading algorithm never spends more than 1200 cycles outside vblank, which I found to be pretty effecient.
Here's a link to the editor: http://nesdev.eternal.dk/
As a heads-up, here are some of the additions I already considered:
- export to other assembly formats, obviously (only CA65 supported at this point, but should be extremely simple to convert manually)
- overview of the usage of various metatiles, could be useful if you're approaching the limit and need to purge some
- selecting multiple tiles and distributing them randomly as you draw, similar to TilEd
- a "wizard" that helps importing any image and generate CHR data based on it (other tools do this well, but it would be nice to have built in, especially for less technical artists)
- placing stage objects (such as enemy spawns, destructible objects, etc.)
- custom variables for each stage's header (stuff like initial player coordinates, palettes, CHR banks etc. Should be easy to add in manually though)
For the record, this is not expected to work in any browser except from Chrome or, I guess, other Webkit browsers. The 5-10 seconds I spent testing it in IE didn't reveal any issues, but using it will be at your own risk.