It is currently Sat Oct 21, 2017 2:32 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Oct 11, 2016 5:11 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 252
Location: Denmark (PAL)
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. :)


Top
 Profile  
 
PostPosted: Tue Oct 11, 2016 12:17 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1783
Location: DIGDUG
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)?

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Tue Oct 11, 2016 12:34 pm 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 252
Location: Denmark (PAL)
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.


Top
 Profile  
 
PostPosted: Tue Oct 11, 2016 1:48 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5728
Location: Canada
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.)


Top
 Profile  
 
PostPosted: Tue Oct 11, 2016 2:06 pm 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 252
Location: Denmark (PAL)
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.


Top
 Profile  
 
PostPosted: Wed Oct 12, 2016 11:18 am 
Offline
User avatar

Joined: Mon Dec 07, 2009 11:08 am
Posts: 79
Location: USA
Thanks for sharing Sumez! Tested it out some this morning and it worked well.


Top
 Profile  
 
PostPosted: Sat Oct 15, 2016 8:55 am 
Offline

Joined: Sat Oct 15, 2016 8:52 am
Posts: 78
This tool looks great! How would a noob such as I go about loading these in a game?


Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 11:29 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 252
Location: Denmark (PAL)
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 :)


Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 12:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10066
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 4:56 pm 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 252
Location: Denmark (PAL)
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.


Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 11:40 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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. :)


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 8:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Some people prefer GitLab or Savannah to GitHub for various reasons. Are you including those?


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 9:43 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1783
Location: DIGDUG
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?

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 11:21 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 252
Location: Denmark (PAL)
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.


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 11:41 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group