Okay, I don't know if this is sweet/awesome, or crazy, but I do know it is an idea. Anyways, I was thinking when I was making my game: "Gee, I wish I had a level editor for this. And I don't know C completely, or Qbasic, or any other programming language for the PC." Then I had a wonderful idea. A NES ROM that IS a level editor. How could this be done? Simple. Make the level editor ROM battery packed, and store the information in SRAM! Then just copy/paste the data from the .SAV file. This is a very wonderful thing, in my opinion. Now making level editors will be easy. Or easier. What do you all think of my idea? Has anyone already come up with this idea?
Celius wrote:
Has anyone already come up with this idea?
Excitebike. Lode Runner. And there was a J-only Vertical Shooter Maker game for the Famicom that was similar to RPG Maker (PS1) and Fighter Maker 2 (PS2).
...Oh... Now I don't feel special... But that's okay! It's still a great idea. How do you know excitebike does that?
EDIT: Also, this will be here, and people that are in my kind of situation that want to make a level editor can see this, and go oh, that's a good idea (if they think so.).
Good points :
- When testing your level, you're sure that it will be tested accurately by the same hardware than the final compilation
- You can do it while knowing only one programming language and one hardware setting
Bad points :
- While copy the sav game is the only solution to do this on a PC, it is a non-sence for the real hardware.
- Edit features would be pretty limited on the NES. I mean, you have no mouse, you you'll have to do all your editor trogh the NES controller.
I think it's a good idea also, I was going to do that a while back but never really did. Since I'd know how to do it rather than writing some PC program. It would work on the real system too, with an NES to RS232 adapter you could save/load files. Maybe even write them to flashrom.
I don't know... I think making the editor run on the target system creates unnecessary extra complication. The map will most likely take the whole screen, wich means you'll have to code the interface separatelly and switch between it and the editing area. Also, implementing multiple levels of zoom would pratically impossible.
And it would be overall harder, if you keep in mind the simplicity of coding point and click interfaces due to the so called "visual" way of programming.
I think the idea is interesting, but more in a novelty kinda way, as I think it isn't very practical at all.
Well, this would be a good idea for 2x2 meta tile level editors. And I would not be putting this on the real NES. It'd just be a ROM on my PC, because I CAN'T copy/paste data from the real hardware of course. But I'd have the screen for the level editor start out as a .nam file. Here's what it'll look like:
This is a .nam file that I made. Notice how there are 8x8 tiles. That's because it only shows the top left corner of each meta tile for the pattern table select thing. My 1 screen 2x2 meta tile level engine has it so you put like $80 in a .db string, and it will be loaded to the screen as:
$80,$81
$90,$91
So it allows you to select tiles: 0,2,4,6,8,A,C,E,10,12...etc. Because it is a 1 screen 2x2 meta tile level editor that uses the engine that I described to you all. And the tiles are 8x8 so everthing can fit on 1 screen. I'm sorry, I kinda need to get off this computer for a sec to go do something, so I explained that kinda really bad...
Bregalad wrote:
- While copy the sav game is the only solution to do this on a PC, it is a non-sence for the real hardware.
Could you program the editor to use a cable between the PC and the NES? Using real hardware would let you see for certain how colors interact.
Quote:
- Edit features would be pretty limited on the NES. I mean, you have no mouse, you you'll have to do all your editor trogh the NES controller.
NES and Super NES controllers are electrically compatible. Could you program the editor to use one of
these in port 2?
Hey! I've gotten my level editor up and running, I just need to make the finishing touch where it can save the level. That will be easy to do. But it's pretty good. You can see for yourself here:
http://www.freewebs.com/the_bott/cynthi.nes . This must be played with full view of the screen, like in Nintendulator. There are weird graphics choices, you can hack into it with a graphics editor to change the graphics of course. Instructions:
Press select to alternate between Pattern table and Level editor.
Go to pattern table, and put cursor over the desired tile.
Press select to go back to the Editor.
Move cursor to select desired position.
Press A to place tile there.
It's really simple. But I will have one where you can save it. But this is what it will be like. It's not the most user freindly thing, but it's pretty okay. Better than manually coding maps. I'm not making this for everyone's use, I'm making it for me, and showing it to people. If you wanna use it, go ahead.
Okay! It's done! Same link to it, and it saves when ever you put a tile down. It takes your position number on the level editor, and when you put a tile down, it saves the byte of that number in $6000+position on level editor. It's hard to explain. But it works! I'm so proud! I'm going to go make levels for my game now!
Pretty good. Now, you would probably improve it to be able to make custom format of levels, and add custom tiles ? Have a tile layer style programm running on the target system would also be cool !
You mean like have a 30x32 editor? Well, It'd be real annoying to code, though. I was feeling lazy last night, and I realized I could get the pattern table selection to be in 1 PPU section $2000-$20FF. if it were lower down, It'd be SO much harder to code. Well, it is pretty good I think. Like NSA, the meta tile version! I'm thinking of making more than just map editors like this. Like other types of editors, like item editors, enemy editors, things like that. I did make that editor in a day, so you have to at least give me credit for that. But I don't know if these other editors will be able to be whipped up like that in a day...
EDIT: What do you mean by custom tiles? Like tiles of your own? Or custom tile IDs? The editor is built around a format that allows you to put a byte down like this:
$80
And it would show on the screen:
$80,$81
$90,$91
And the pattern table just shows these tile IDs:
$00,$02,$04...$0E
$20,$22,$24...$2E
$40,$42,$44...etc.
Because those are the corners of each 2x2 meta tile. Do ya get it? There's a weird bug in this editor though. It allows you to press a over a tile on the pattern table, and it will show up where you just were on the editor. But, when you do it over tile 0, it the screen just shakes, and nothing happens. But you can still just press select and go put tile 0 down like a normal tile, just when you try pressing a over on the pattern table while the cursor is over tile 0, it doesn't work!
I meant that you could allow larger maps and test them with scrolling, and also make a homebuilt tile editor (trough it would be hard to edit tiles with the controller, you rather would do it with a real tile editor and paste it in your ROM). Are maps based on tiles or metatiles ? It would be better to be based on metatiles, so it can be used in an actual game.
Bregalad wrote:
Are maps based on tiles or metatiles ? It would be better to be based on metatiles, so it can be used in an actual game.
What do you mean by that? Like, are they written to memory as tile #s or meta tile #s? Well, if that was your question, They are written as the first tile in the meta tile. So if $36 is written to memory, this is what it will appear as when loaded on the screen:
$36,$37
$46,$47
Because my format takes 1 number, and shows the 3 around it on screen. Like what I said up there. I've made maps with this that I've loaded on my game, and they work just fine. My editor is successful. But yes, I want to make a 2x2 metatile map editor with scrolling and stuff like you suggested. I will use that for our project. And I'll probably make a magic editor, enemy editor, and all that stuff, because I don't know C yet, and it would be much harder for me to make a program with C than it would with the NES.
Celius wrote:
Because my format takes 1 number, and shows the 3 around it on screen.
But then you get only 64 blocks out of the 256 tiles, right? And you will not be able to share tiles between blocks (well, you may BE able, but will most likely get strange results). I think you should use only 6 bits to represent your blocks (since you have only 64 of them) and use the other 2 bits to represent some information regarding that block. Maybe if it's solid or not, and stuff like that. I know you didn't ask, but that was just an idea, that's what I'd do, you know?
Celius wrote:
Bregalad wrote:
Are maps based on tiles or metatiles ? It would be better to be based on metatiles, so it can be used in an actual game.
What do you mean by that? Like, are they written to memory as tile #s or meta tile #s? Well, if that was your question, They are written as the first tile in the meta tile. So if $36 is written to memory, this is what it will appear as when loaded on the screen:
$36,$37
$46,$47
I don't think that's quite what he meant. When we refer to meta-tiles, we refer to numbers which refer to a sequence of tile numbers AND a set of attributes.
For example, one could have three meta-tiles $05, $45, and $85, all displaying as $04,$05,$14,$15 ('brick'), while the first would be solid, the second would be a fake wall, and the third would be breakable. Incidentally, this is almost exactly how Metroid stores its blocks (though it also takes things a step further and stores 'objects', predefined groups of tiles for common structures such as platforms, walls, and doors).
Quietust wrote:
I don't think that's quite what he meant. When we refer to meta-tiles, we refer to numbers which refer to a sequence of tile numbers AND a set of attributes.
For example, one could have three meta-tiles $05, $45, and $85, all displaying as $04,$05,$14,$15 ('brick'), while the first would be solid, the second would be a fake wall, and the third would be breakable. Incidentally, this is almost exactly how Metroid stores its blocks (though it also takes things a step further and stores 'objects', predefined groups of tiles for common structures such as platforms, walls, and doors).
Okay, I get that, but what am I answering still? What exactly is the question? I'm sorry, I'm just a little confused (or aka retarded..).
The "question" is just that I found better to output that is totally usable by an actual game engine than an output that needs modifications to be incorporated in an usable game engine. So metatiles should comes with 4 tiles index, collision detection, two color bits, etc...
Okay, I'm thinking of making a music editor program like this. Except it would not use the target system, it would use a zapper system, so you can easily edit things with the mouse. This is just an idea, mind you. But this is not meant to be played on a real NES, as is my level editor. I'd feel pretty stupid sitting there shooting the screen with the zapper gun on a music editor. And It'd just cause more complications putting it on the NES. But do any of you think an editor, not just a music editor, using the zapper system could result in a good developing environment?
The Arkanoid paddle might be easier to integrate into a decent music editor than the Zapper, especially given that unlike the Super Scope, the Zapper is not a positional input device.
tepples wrote:
the Zapper is not a positional input device.
I'm sorry, I don't get what you mean. What do you mean by Positional Input Device? Sorry, just trying to clarify things...
A bit of theory:
Absolute position input (e.g. Nintendo DS touch screen, Super NES Super Scope, Arkanoid paddle): These return one or two dimensions of displacement from the origin of a coordinate system. Some operate through resistance; others operate through timing against a CRT monitor.
Relative position input (e.g. Super NES Mouse): These return an (x, y) displacement from the last read position. The software can integrate these to approximate an absolute position.
In-out input (e.g. NES Zapper): These tell whether the cursor is over a light area or a dark area. Iterating which areas are dark and which are light allows you to distinguish up to a couple dozen distinct regions. Distinguishing more regions takes longer and can lose accuracy if the cursor moves while the code is narrowing down which region was hit. Some can also return the Y coordinate of the absolute position using timed code, but generally not at the same time as hit testing.
Symbol input (e.g. Family Basic keyboard): These give a stream of symbols corresponding to "keys", or distinct absolute regions on the input device. The system is conceptually similar to in-out, except 1. the regions cannot be moved, but 2. the input is generally read closer to instantly even if the fingers are moving, making the input much cleaner than you would get with an in-out system that involves a TV monitor in the feedback loop.
How hard would it be to support the Super NES Mouse in an NES emulator?
Mind if I make some suggestions to improve this editor? If you're gonna work on it anymore.
It's great other than not being able to see most of the graphics.
What I'd suggest is using 4-screen for the nametables. The upper-right nametable could be the metatile selection screen for the cursor, then the other 3 nametables could be the editing area (and scrollable). That way they could be displayed properly with attributes and everything.
I suppose you're right. I am making a completely new editor for multiple screen levels. The pain of making the editor with actual size metatiles is that it seems like you are zoomed in like a mile. Everything's too far apart. My engine for loading these kind of maps is going to load attributes depending on what tile is being loaded. Like tiles from $E0-$F0 use pallete 2 or something. I don't know. I still need to think about this for a little bit more...
You could reserve a button to switch between the map preview and the editor.
You choose a metatile, then press the select button to land on the map, then click A where you want to paste that metatile.
You could also make an authomatic compression when you save your map to a .sav file. Google "compression algorithm" or something to get some fair ideas.
I just thought that, in my case, such editor couldn't work because my levels are quite large. So the 8kb of RAM an editor would be able to use would not be enough to edit a whole level. Maybe it'd work if I had editors for each part of the level, and the output of one editor is attached to the ROM of the next. Would only be useful with emulators, of course.
Could use a mapper with RAM bank switching too... since it's just an emulator thing.
But in your case, you said you're trying to fit everything in 16kb of ROM, so 8 may be anough for your level.