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

My web based level/nametable editor

My web based level/nametable editor
by on (#180694)
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. :P Most other well-made tools seem to be primarily created for rom hacking purposes.

So I made this little tool in JavaScript.

Image

(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. :)
Re: My web based level/nametable editor
by on (#180699)
Quote:
Shiru's Screen Tool...crashes


I've never had any problems with it. What OS are you running?

Also, wouldn't it make sense for you to make the source available, so people could run your editor offline (and faster)?
Re: My web based level/nametable editor
by on (#180700)
It's running entirely in the browser, and completely "open source". The only external dependencies are the FontAwesome icon pack and the JQuery library (via Google's CDN), so you can just download the HTML file to run it on your computer, and view the (horrible) source code for that matter :)

I'm running Windows 8.1 btw.
Re: My web based level/nametable editor
by on (#180701)
dougeff wrote:
Quote:
Shiru's Screen Tool...crashes


I've never had any problems with it. What OS are you running?

The last version of it had a bad crash bug with loading and saving session files. (It had a mismatch between saving and loading various settings it was trying to save along with the other data.)

Usually had to get around it by saving the nametable/CHR/etc. separately.

I'm kinda surprised he hasn't fixed it by now, I'm pretty sure I talked to him about the bug like last year? Hmm...


Anyhow, this web tool looks interesting. I've been kinda wondering about using HTML5 to make tools lately, it's gotten to be a pretty viable for a lot of things.

I could really use a way to import binary files (i.e: 1k nametable, 4k CHR, 16 byte palette) so that I could use this to play with stuff I've already got rather than starting from scratch. (Being able to load and save these would make it interoperable with other tools.)
Re: My web based level/nametable editor
by on (#180703)
That's a very good idea. The palette may be a little superflous (it would take a few seconds just to edit it manually), but more import formats makes a lot of sense.

I made the tool primarily for non-programmers to use, but I found it a very effecient way to edit my levels, so I'll be adding features as I need them.
Re: My web based level/nametable editor
by on (#180732)
Thanks for sharing Sumez! Tested it out some this morning and it worked well.
Re: My web based level/nametable editor
by on (#180836)
This tool looks great! How would a noob such as I go about loading these in a game?
Re: My web based level/nametable editor
by on (#180902)
Well how to implement it is up to each individual - I'm pretty sure my own implementation could afford a few optimizations.
As I said, I'm open for suggestions for new ways to structure the level data, but as of now, everything is saved into the 16x16 and 32x32 metatiles you see in the editor when exported as a assembly file.
(of course, this is entirely created for homebrew use, the maps are not compatible with any existing NES games)

What I do, very squarely spoken, is:
- Find the coordinate of the row I want to load
- Use the high byte to identify which "screen" to load from and the low byte (divided by 32) to identify the index (column) of the metatile to load
- Add 8 to the index for each row and access each metatile using (inderect),Y
- For each metatile I read from two of the tables generated by the editor, the top left and bottom left, or top right and bottom right. Which two I use can be decided by one of the bits of the original coordinate.
- Repeat the same process for the smaller metatile, except this time I just load the left column on my first pass, and then the right column the second time, as I'm loading 16 pixels at a time.

You could also load in just one row of 8 pixels at a time (if you're using horizontal mirroring or want to save cycles), or the full metatile of 32 - but I don't think there's enough vblank time for that. You can also speed things up using a "secondary stack", which is what I actually do, and push into it from the bottom up.

There are a lot of threads with better advice on how to store/load level data on this forum, so that's as far as I can go into this :)
Re: My web based level/nametable editor
by on (#180904)
The only way I can see a generic level editor working is if it uses user scripts for exporting the data. A hardcoded format is OK for people who are just starting and don't know any better, so anything is fine, but experienced coders have to deal with the specifics of their scrolling engines, collision attributes, storage limitations, and so on.

I envisioned an editor where users could load their own JavaScript files containing a function that receives the raw data from the editor, and returns an array of downloadable binary files. Basic scripts would be supplied for straightforward formats, of course.
Re: My web based level/nametable editor
by on (#180914)
Should be very easy to do, since that's obviously what it does internally when exporting to CA65.
In fact, as it stands you can just export the session JSON and make a script to convert that :)

I created this only for my own needs, so at this point all it does is what I needed it to do. But it's clearly open for expansion.
Re: My web based level/nametable editor
by on (#180925)
You should host it on GitHub if it's open for expansion. AFAICT, if it isn't on GitHub or a private repo controlled by the main dev, it's not worth committing to. :)
Re: My web based level/nametable editor
by on (#180934)
Some people prefer GitLab or Savannah to GitHub for various reasons. Are you including those?
Re: My web based level/nametable editor
by on (#180936)
Is it suspicious to anyone that GNU.org rated GNU Savannah as the best code repository?

How about rating by... ease of use, functionality, etc?
Re: My web based level/nametable editor
by on (#180937)
I use Git for all of my programming stuff, mostly because I don't want to worry about deleting old code, and usually work from different computers.

Personally I prefer BitBucket because it allows private repositories, and my code tends to feel a bit "personal" to me. But GitHub is really good.
Re: My web based level/nametable editor
by on (#180938)
I'd not recommend them. Like them or not, Github is the biggest and basically only used repository site. I'd also not suggest using anything GNU, as people only pushing GNU are cancer to the Linux communities. I also do use BitBucket for my private repo's for me and my friends. Github for public projects.
Re: My web based level/nametable editor
by on (#180940)
I just use Fossil repositories. It is easy to set up on nearly any computer.

I think "GNU Ethical Repository Criteria" are extra restrictive, although they may be reasonable for GNU projects. Some of their criteria are good for anyone, though. Specifically, good to have are: C0, C1, C2, C3, C4, B3, A0, A4, A5, A+0, A+5. In many cases, C6 should also be recommended (note: this does not mean HTTPS-only or HSTS), and A1 certainly helps. Furthermore, possibility to download with free command-line tools should also be possible, and A+2 should be followed as much as possible.
Re: My web based level/nametable editor
by on (#196703)
Oh man, I was about to build something exactly like this, but decided to do a little more googling first. Glad I did, this looks like exactly what I've been looking for.

tokumaru wrote:
The only way I can see a generic level editor working is if it uses user scripts for exporting the data. A hardcoded format is OK for people who are just starting and don't know any better, so anything is fine, but experienced coders have to deal with the specifics of their scrolling engines, collision attributes, storage limitations, and so on.


Actually, I prefer what tiled (and this editor) seem to do: give me some text format that represents everything the level editor knows about (and can easily be saved/loaded). I'll store that in my git repo. My build process will then have a script to generate what my build needs from that text format.

Because at the core of it is this: if a human (me) has to do an export step, there's always that question of which version is the canonical/correct one? And remember how to export. And remembering if I did the export after that last edit. I much prefer just hitting save in the level editor, and my makefile calls scripts to do the conversion *

(I learned this the hard way in the GBA version of Anguna. Fiddling with graphic data exporters was a huge pain, and a big source of mistakes and bugs)

* That is, unless I've written the entire tool, then the canonical format can just be source code, skipping any sort of export or conversion step.
Re: My web based level/nametable editor
by on (#196713)
In the end I think it's always best to make your own tools for your own needs. (which is essentially why I made this)
But if you do end up using this and feel like there's something important missing, let me know.

My biggest problem with Tiled, which is an otherwise great program, is not the format that it saves its maps in (like everyone's saying, you'd still be making your own pipeline for converting it), but that it's obviously not built to take the NES's limitations into account. It doesn't expect you to have to compress the data into metatiles (as I do in this, and figure most people creating multiple maps with recurring themes are probably doing), and it definitely doesn't know what an attribute table is :3
Re: My web based level/nametable editor
by on (#196725)
For my ninja project. I used NES screen tool, and constructed the metatiles there. Took a screenshot. Saved it in GIMP. Opened that in Tiled. Each square in Tiled represents 1 metatile of data. Constructed the levels in Tiled. Exported as .csv. Wrote a Python script to re-organize the data and compress it.

The number of the metatile (high nibble) told my decompresser what attribute table each metatile should use.

It was a slow process.
Re: My web based level/nametable editor
by on (#196729)
I was going to suggest something like what dougeff described to solve the metatile issue: first create a map containing only the metatiles, then export an image of them so they can be used to construct the actual map. Whenever you need to edit the metatiles, just export a new image afterwards.

That wouldn't help much with my level format that has several depths of metatiles though, that would be completely impractical. What I need to solve that problem is an editor that lets me copy and paste custom sized blocks, with the option to align to custom sized grids. The editor wouldn't even know that blocks are being reused, the encoding script would be the one responsible for finding for all the redundancies and creating all the unique metatiles at every depth.

As for the palette issue, you can always store 4 versions of the tiles/metatiles, and use the highest bits of the tile/metatile indices to select palettes when converting the data.