Here is a tile based map editor that I started some time ago. I add features as I need them, and its gotten to the point where I think others might find it useful.
Features include:
-metatile formats:
2x2
4x4, 4x4(2x2)
8x8, 8x8(2x2), 8x8(4x4), 8x8(4x4:2x2)
data can be sequential or interleaved
-metatile properties:
can be 1 to N bytes per metatile. these have no use within the editor, it's up to the programmer to determine what they are used for.
-map formats:
screen or area based
"screen": measured in screens. size of a screen is customizable
"area": measured in metatiles
data can be in rows or columns
data can be compressed with RLE, LZ77, or LZSS (variations denoted by the "a" or "as" suffixes).
-chr:
supports multiple small files (min size = 1K) or one big file
supports 1K, 2K, and 4K banking schemes
-palettes:
nothing fancy, 32 byte arrays.
The readme explains the formats of all the files the editor creates.
MapEd Pro.zip
Here are some demos I put together using different configurations. I recreated SMB's 1-1, CV2's Jova and Jova Woods1, and Ninja Gaiden's 1-1.
MEP Demo.zip
Bugs, comments, suggestions are welcome.
*Note: because of changes in the map format and a more flexible chr scheme, previous versions are not directly compatible with this one.
edit: uploaded v0.29.0
edit: uploaded v0.30.0
Seems really good! Has about all features that I would want from a map editor. So far I've been using
Mappy with custom hacky LUA scripts to export the data in NES compatible formats, but your tool seems better.
One problem I noticed with the examples, the CV2 and Ninja Gaiden example files have absolute paths in the MCF file so had to edit them before I could get them to open.
Sounds like AWESOME to me !!
So far I always did my maps with .db statements.
EDIT : Only the SMB demo works so far for me.
thefox wrote:
One problem I noticed with the examples, the CV2 and Ninja Gaiden example files have absolute paths in the MCF file so had to edit them before I could get them to open.
Whoops, I thought I got them all. Updated the zip with corrected files.
@Bregalad: It should work now, it was probably the same issue thefox was having.
Finally releasing this, huh?
This is an awesome and very useful utility, one of the best I've seen for helping with new game creation. Of course metatiles are only one way to do things, but they are common and efficient.
Like a lot of other people I've got my game ideas that still haven't taken off, but I'll definitely use this when I get to that stage.
Yeah, I've been sitting on this thing for awhile now. I would end up adding something new, and not having the time to test it with all the possible configurations.
I bought Kirby's Epic Yarn yesterday, so it was either now or New Years...
I tried installing "Microsoft Visual Basic 6.0 Common Controls" from MS support site (searched for the error on the net) but that didn't fix it.
Ok, to be honnest this editor sounds like revolutionary to me ! I always had to do my maps with pencil on paper, and port it to .db manually until now.
Then I had to check for erros in my .db statements (as I RLE compress the thing manually, so this is prone to errors).
The release of this flexible and NES specific tool was completely unexpected from me. I think I'll probably use it but I don't know for my current project as I started without it, and the exact compression format I use isn't featured so I'd have to either re-code decompression (including for older maps that I already encoded manually), or just finish my current project with the old method and use the new one for all my future projects.
EDIT : What is that proprety thing ? Collision detection ?
EDIT II : Sorry for the bother, but maybe the program should add more flexibilty / efficiency for compression. This could be left for another program but since compression is implemented I'd like to see it better implemented :
- RLE comression as used here is almost useless, because for every part of the map which is build with non-runs of metatiles, it will take a "lenght = 1" byte before it, which makes it terribly inefficient. There is several workarounds that would come in mind: Have one "run" flag in each byte, if clear it's a 7-bit litternal, and if set then the 7-bit litteral is followed by the # of times it's repeated.
Or you could have everything coded in 7-bit runs blocks, with the upper bit toggling between a block of a signle metatile, or a block of distinct metatiles.
Or eventually the solution I used in my game, the high 3 bits are the run size minus one, and the low 5 bits the metatile # (yes, I only have 32 metatiles to chose from).
The fact that you could use less than 8 bit for metatiles encoding should also be exploited in other compression shemes, especially those which are not byte aligned anyway (you don't want any useless '0' bits in your compressed stream).
The LZSS and LZSSa algorithms seems to produce exactly identical output to me.
The "export map to txt" feature seems to always export an uncompressed map (not that this feature is much useful anyway as you can just .incbin the binary map).
Finally, I guess in the case of screen-based maps, you'd want to stop the compression stream when the map is screen aligned, and be able to export pointers to each screens.
For area based maps, you'd want to do that for either rows or columns. The reason for this is to get a way to quickly acess the maps when scrolling, even with the compression.
In my project I have it screen based and stored like this for every level :
Code:
MapPointers
.dw Level1Map1
.dw Level2Map2
.dw ....
Level1Map1
.db $xx, $xx
Level2Map2
.db $xx, $xx
(I call a Map what is called a Screen in MEP), and those also have an header to know which maps/screen it warps to in each direction.
If doing it with this editor, it sound painful to have like 40 ".map" files for each level, so maybe it's better to have a ".asm" file automatically generated with labels, pointers and .db statements. Then it becomes possible to manually add more data, such as screen headers.[/code]
Awesome! Thanks a bunch!
EDIT:
That's not much more than a 'me too!' post, but although I can't use it, I appreciate the contribution!
neilbaldwin wrote:
:(
I tried installing "Microsoft Visual Basic 6.0 Common Controls" from MS support site (searched for the error on the net) but that didn't fix it.
Same. As a result, I'll pass. :)
Any chance that the UI could be improved in future versions?
I wonder if I should release the map editor I'm working on. It's in C#, and it's an abstract class designed to be inherited from. It also doesn't work on Windows 7 because I'm using Managed DirectDraw.
@neilbaldwin and koitsu
Are you by chance running Vista or Windows7?
@Bregalad
Properties can be collision detection, or whatever you want. The editor doesn't use it for anything, it just allows you to associate data with your metatiles.
The difference between LZSS and LZSSa is that LZSS is bit oriented and LZSSa is byte oriented. I use LZSSa because the decompressor was easier to code.
Thanks for the comments on RLE and compressing screen based maps. I'll have to add those to my todo list.
@thefox
What did you have in mind?
never-obsolete wrote:
@neilbaldwin and koitsu
Are you by chance running Vista or Windows7?
No. I run Windows XP SP3. You're not going to get me to "mess around" with random Visual Basic runtimes and other crap either. Sorry, I'm a total hard-ass about it; I Just Don't Do That. That's my own fault/problem/issue and not yours.
never-obsolete wrote:
Thanks for the comments on RLE and compressing screen based maps. I'll have to add those to my todo list.
Thank you, hopefully a newer version with those will be released !!
I have the program running fine in Windows 7. I haven't installed any runtime libraries or wathever (at least to my knowledge).
never-obsolete wrote:
@thefox
What did you have in mind?
Resizeable main window would be nice, although it's not a big deal. Overall I just felt it was a bit unintuitive and since there's no documentation...
For the record, I am using Windows 7 (64-bit) and it worked out of the box. I don't remember ever installing any VB6 runtimes or common controls either.
This is really good. This could replace the editor I had built into one of my old game projects, so maybe I can work on the actual game itself sometime.
neilbaldwin wrote:
I just downloaded the specific files it was complaining about and put them in the same folder as the program, that did the trick.
As for the program itself, it's an interesting approach to a map editor, but as expected it can't please everyone. Definitely a step in the right direction, but I can't help thinking that it should be more flexible. Specially the metatile arrangements, it shouldn't be that hard to allow multiple depths of metatiles of arbitrary sizes.
Another problem I had was the map size... What are the limitations in this program exactly? I tried to make a fairly large map and it wouldn't let me.
It also crashed randomly without telling me why, which was a bit frustrating, but that's expected from a WIP tool I guess. Another thing that bugs me is that you used Visual Basic 6 (a tool from 1998!) to make it, and that instantly makes your tool look and feel outdated.
Bregalad wrote:
never-obsolete wrote:
Thanks for the comments on RLE and compressing screen based maps. I'll have to add those to my todo list.
Thank you, hopefully a newer version with those will be released !!
I have the program running fine in Windows 7. I haven't installed any runtime libraries or wathever (at least to my knowledge).
It runs fine for me but since it doesn't appear to be resizeable I can't see the whole app on my tiny laptop screen. I can see just down to the "Loaded Files" area.
Nice app!
never-obsolete wrote:
I recreated SMB's 1-1, CV2's Jova and Jova Woods1, and Ninja Gaiden's 1-1.
Did you recreate them manually or did you write an extractor for the 16x16 metatiles from SMB1 [or does this tool extract the info]? When I was working on the map editor for NESICIDE I thought it'd be nice to offer an extractor feature but such a feature I soon found would require specialized routines for each game.
tokumaru wrote:
I just downloaded the specific files it was complaining about and put them in the same folder as the program, that did the trick.
I figured that would fix it, it's what I usually do when I have that kind of problem. What files were they, specifically? Maybe you could send them to never-obsolete and he could include them in the zip to appease people like koitsu?
By the way, I'm running XP SP3 with a majority of the Windows updates, and I didn't have any trouble opening it. (Actually, on two different computers.)
NESICIDE wrote:
never-obsolete wrote:
I recreated SMB's 1-1, CV2's Jova and Jova Woods1, and Ninja Gaiden's 1-1.
Did you recreate them manually or did you write an extractor for the 16x16 metatiles from SMB1 [or does this tool extract the info]? When I was working on the map editor for NESICIDE I thought it'd be nice to offer an extractor feature but such a feature I soon found would require specialized routines for each game.
I would assume he did it by hand, since I highly doubt those three games use the same specifications as his editor. I know that Mario 1 doesn't.
UncleSporky wrote:
NESICIDE wrote:
never-obsolete wrote:
I recreated SMB's 1-1, CV2's Jova and Jova Woods1, and Ninja Gaiden's 1-1.
Did you recreate them manually or did you write an extractor for the 16x16 metatiles from SMB1 [or does this tool extract the info]? When I was working on the map editor for NESICIDE I thought it'd be nice to offer an extractor feature but such a feature I soon found would require specialized routines for each game.
I would assume he did it by hand, since I highly doubt those three games use the same specifications as his editor. I know that Mario 1 doesn't.
One way to do it semi-automatically would be to offer a "generate map from picture" function. So it would look for metatiles in the picture, discarding duplicates. It could even support metatiles in metatiles. The palette would have to be organized properly to 16 colors like in NES (so it can detect metatile attributes) or it could be specified in the app. Mappy has a function like this, which I've used to convert maps from
http://www.vgmaps.com/Atlas/NES/index.htm.
koitsu wrote:
never-obsolete wrote:
@neilbaldwin and koitsu
Are you by chance running Vista or Windows7?
No. I run Windows XP SP3. You're not going to get me to "mess around" with random Visual Basic runtimes and other crap either. Sorry, I'm a total hard-ass about it; I Just Don't Do That. That's my own fault/problem/issue and not yours.
Same here. I'm running XP via Parallels Desktop (I only use it to run YYCHR and test my code on FCEUX).
neilbaldwin wrote:
Same here. I'm running XP via Parallels Desktop (I only use it to run YYCHR and test my code on FCEUX).
I agree. For those on Windows 7 or even XP who are concerned with screwing up their desktop, you could build a virtual machine dedicated to running older software and packages that require VB6 modules. Some of our developers do this to emulate older environments for testing purposes.
I use VMWare Workstation since we're a VMWare shop, but you could use a free alternative such as VirtualBox...
http://www.virtualbox.org/
Not a bad way to go unless you just enjoy having an old Pentium on your desk.
That's incredibly cumbersome when all it takes is literally including a couple files along with the zip.
I know what you're getting at, I like VMs too, but this is probably not the place to recommend it.
UncleSporky wrote:
That's incredibly cumbersome when all it takes is literally including a couple files along with the zip.
Provided that one has permission from Microsoft to redistribute said Windows components.
We don't even know what runtimes are needed for this program to begin with. Visual Basic 6.0 SP6 runtimes aren't sufficient, for example. MSCOMCTL.OCX isn't included here:
http://support.microsoft.com/kb/290887
As for the distribution licensing (tepples makes an excellent point) -- I'm not sure, but it needs to be verified. There has to be an answer to this out on the web somewhere though. Even if he can't legally include the files with his software, the bare minimum would be to tell people "You need to download <this> and <this> on Windows XP before this software will work", giving links directly to Microsoft.
EDIT: Apparently XP folks will need to download *two* packages from Microsoft to get this software to run:
* Microsoft Visual Basic 6.0 Common Controls
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=25437d98-51d0-41c1-bb14-64662f5f62fe&displaylang=en
* Microsoft Visual Basic 6.0 SP6 Run-time Redistribution Pack
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7B9BA261-7A9C-43E7-9117-F673077FFB3C&displaylang=en
Regarding the Common Controls, I had a nice LOL when I
read this.
Again, I didn't have to download anything. You use a 9 year old version of Windows so blame yourself.
Bregalad wrote:
Again, I didn't have to download anything. You use a 9 year old version of Windows so blame yourself.
This is a perfect example of why blargg started a thread asking which people had problems with him. This kind of response is highly inflammatory and completely unhelpful in every way shape and form.
Maybe instead you should be blaming the author of the software for using a
version of Visual Basic that came out in 1997-1998?
There's also great irony in complaining about "using an old operating system" on a web board that's about consoles made over 20 years ago.
I agree with Breglad, your using a old OS so just get over it. Times advance and so does technology. You need something a newer OS/VB basic needs or whatever, so be it. IE9 won't run on XP (Probably a good thing) but still, nobody's complaining about that.
tepples wrote:
UncleSporky wrote:
That's incredibly cumbersome when all it takes is literally including a couple files along with the zip.
Provided that one has permission from Microsoft to redistribute said Windows components.
Laughable. I would distribute with impunity.
EDIT: To clarify, I mean in this specific case, for several reasons:
1. It is free software
2. It appears to work for many people already, meaning it's unlikely that the missing files are specific to people who have bought VB6 or somesuch
3. Even if this would not normally be allowed, it is only going to be used by a few people and is highly unlikely to be noticed
I don't care what Microsoft has to say on any of these points. According to my personal moral compass, this is distributable.
I was able to recreate my metatiles the other night to make a few screens. One complaint I had was that it wasn't very intuitive to figure out how to load the CHR file when starting from scratch. Took me quite a while to realize it's in the MCF editor, you click on the '0', '1', etc. buttons. I guess it looks a little more obvious though after opening an existing project.
I also wasn't a fan of the windows "ding!" sound playing when it opened a project successfully, but that's my fault for having windows system sounds enabled (why, I don't know). I usually expect an error or something stopping if I hear that. No big deal.
I'm sure I'll have more comments after using it more.
Oh ok ok I'm sorry that the editor doesn't work on your PC, while I was happy to try it on mine.
You should make a clear barrier between the old system we're developing for and the new systems we use as a tool to make stuff for the old system. This is called cross development. There is people who code C64 demoes with a C64, but to be honnest, good luck. I really wouldn't do that even if I like the C64.
By using a modern PC (even a 1998 PC is "modern" compared to the NES), we really makes the job of developing a NES game much easier than the one that people had back then in the '80s. Just ask Neil Baldwin, they had to wait a dozen of minutes between each compilation of their game, while we can do it in less than one second.
This is kind of out-topic though. I didn't know the guy that made the editor did it with a really old VB version, but I don't think it matters if the executable binary is forward compatible with newer version of windows. What is ironical is that it has issues on older Windows and runs fine on seven. You could understand a win32 executable made with the latest tools would have issues on older windows, but not the other way arround. Oh well.
So back on the topic, after all that have been said in this thread, this editor is very promising, but it lack a few features that should be improved in a future version :
- Full compatibility with Windows XP
- Improvements on user interface.
- More flexibility in compression shemes (take the advantage of using less than 8 bit for metatiles indexes).
- Export maps with pointers to each screen (screen mode) or each row (area mode)
Hopefully those improvements will be made, and the editor will become like really great.
I'm just happy to be able to make even one screen with the data all organized, I have no trouble compressing it later of my own accord if I have to.
65024U wrote:
IE9 won't run on XP (Probably a good thing) but still, nobody's complaining about that.
Nobody complains because Google has released Chrome, both as a stand-alone browser and a plug-in for IE 6-8.
UncleSporky wrote:
It is free software
If it's
free software, then where's the source code? :þ
Bregalad wrote:
You should make a clear barrier between the old system we're developing for and the new systems we use as a tool to make stuff for the old system. This is called cross development.
I thought one advantage of cross-development for NES, as opposed to cross-development for something like iOS or Android, was that one could get away with using a platform that isn't the latest and greatest.
Bregalad wrote:
(even a 1998 PC is "modern" compared to the NES)
Oh, that's what you meant. So it would include the computer on which I developed LJ65, a Dell Dimension from fourth quarter 2000.
Anyway, you can probably get full compatibility with Windows XP, Windows Vista, and Windows 7 if you upgrade to
the latest version of Visual Basic for no charge.
tepples wrote:
Anyway, you can probably get full compatibility with Windows XP, Windows Vista, and Windows 7 if you upgrade to
the latest version of Visual Basic for no charge.
VB.NET, however, is not 100% backwards compatible with VB6.
Sorry that I didn't post any links to the files, it's just that I searched for them in a chaotic manner (I just went to Google and searched for their names) and didn't keep the links (I usually test new programs in a VM that resets its hard disk on power off, so there is no history).
I just saw that other people were having problems afterward, so I figured I'd tell them they could just download the files and put them in the same folder without having to install anything or make any system changes.
tokumaru wrote:
Specially the metatile arrangements, it shouldn't be that hard to allow multiple depths of metatiles of arbitrary sizes.
This is what I had in mind with my editor. There were too much bugs at the time to be releasable to the public. Now I couldn't work on it for a while so the code base feel quite "foreign". I will need to clean it up if I can find the time some day. I still want to finish it.
- Nobody wants to recompile/port it on/to Visual C++, for example!? I would do with pleasure, but I don't know VC++...
If you want, you could try porting it to the Allegro library that you have used for your RockNES emulator.
Thanks for all the feedback. I appologize for the lack of documentation. I'll have to work on that.
@NESICIDE
SMB1 was recreated manually, CV2 was directly imported (with a hex editor), and NG was slightly modified.
@tokumaru
As bad as it sounds, I'm not sure how large of a map you can make. I'll look into it. I've also been working on allowing as many levels of metatiles as the user defines. This will probably have to wait until I port it to a newer languange.
@Bregalad
I was watching (gridiron) football yesterday, so I had a chance to implement those compression schemes. I got to thinking about pointers to screens/rows in compressed maps. How would you relay the starting and stopping points to the assembler?
@Zepper
Converting to C++ doesn't means automatically a better software. The current "problem" is that there was no installer package for the required dependencies. Unless you have a good reason you should not try to convert a software if it works well already.
@Bregalad and 65024U
<rant>
All Windows OS does not contain any of the VB run time, none of them. If it happens to works well on Windows 7 of Windows whatever, it's because you installed another program that contained the run time with it. With software made it VB6, you're always stuck with dependencies, you have no choice. For C++, if you're lucky, the MSVRCTXX version may already be installed depending how recent is your version of windows but it still have dependencies.
Sorry to sound rude but you both were first to Koitsu and I don't think it was the right thing to do. Before saying to someone to use a newer OS you should get your fact right. And 65024U, you should be careful on how you say things because it felt to me that you were adding oil on fire for no real purpose.
</rant>
Sorry if I sounded like that, but depending on such items to be on a users PC is probably a bad idea (and makes me mad because M$ makes crap software), maybe if the source was released somebody or even the original programmer would do it, maybe program it with a graphics library, so this stuff doesn't happen and maybe it runs more efficient. Nice tool? HECK YEAH. I can't wait to need this, but yet....I'm so not downloading any VB for it. 0_o
This is because 10/20 years ago hard disk space was an issue. For getting around those, DLL/OCX libraries were made and program were sharing those library. Of course it brought other issues in the way (read about DLL hell) but at the time it was the way to save space. Now we don't have that space issue anymore.
Don't worry, you don't need to have VB on your computer to make it work: you just need the proper dependencies (ocx/dll whatever) in the same folder or system32 and it will work fine.
Maybe the author didn't realize about it since when you have VB6 installed on your computer you have all those files already installed in system32. This a common deployment issues, forgetting about dependencies. Since he has a license for it, he has the right to distribute them with the program.
65024U wrote:
Sorry if I sounded like that, but depending on such items to be on a users PC is probably a bad idea (and makes me mad because M$ makes crap software)
Ehhh? So it's Microsoft's fault that people don't ship the necessary libraries with their program? AFAIK VB6 even comes with an installer builder that can automatically detect the dependencies.
never-obsolete wrote:
I got to thinking about pointers to screens/rows in compressed maps. How would you relay the starting and stopping points to the assembler?
I'm really sorry but I don't understand your question.
In a compressed map that is decompressed screen-by-screen rather than whole-thing-to-WRAM, there needs to be some way for the program to quickly find each page as the camera enters it.
Yeah, therefore my point of having it compressed screen by screen (or row by row in the case of an area type map) and have a pointer on each screen/row.
I was thinking about it too a while ago. IMO, It seemed just to make one whole map that was lets say 255x255. Then have the RLE compression for each row be in a array of RAM that kept track how many in X place are done out of the RLE repeat byte. I know it's wasteful, but it seems the easiest way to me. :/
And yeah, so? Nobody needs Microsofts binaries for anything, theres more then one graphics library out there. 0_o
65024U wrote:
And yeah, so? Nobody needs Microsofts binaries for anything, theres more then one graphics library out there. 0_o
Let's explain it another way. If you make an application in Java, you need the java runtime (JRE), right? Another example, if you make an application in .net, you need the .net runtime (.net framework), right?
If you follow where I'm going, if you make an application in VB6, it does require a runtime, the VB6 runtime libraries. It's not a graphic library, it's the runtime to make the application run.
As for graphic library, many of them will require some dll to be delivered with the application.
So the point is, if you don't deliver with your application the required runtime or library or don't explain which one is required for you to download, it will be hard to use the application isn't it? So I'm not sure what your point is about.
Okay I am following you now, but something that would just be plain C and a graphics library that works in Mac and Linux would even better.
But oh well, I guess mac users are out of luck. :/
65024U wrote:
Okay I am following you now, but something that would just be plain C and a graphics library that works in Mac and Linux would even better.
But oh well, I guess mac users are out of luck. :/
I would expect "wine" to work on an Intel based Mac. I have never tried it though. My Mac is a Mac LC-II running system 7.5.3 with an Apple IIe card (although I can swap that for a 10mbit ethernet card).
http://www.winehq.org/
Ever heard of "Jabaco"? It's a (free) Basic programming language which is almost full compatible to Visual Basic 6.0 (a few changes are needed afaik), but compiles your code to java-byte-code, so it works on a lot of operating systems...
btw, hello. i'm new to nesdev
Welcome!
Java? Interesting...
The downloads appear to be broken... Does someone have a copy to repost, or fix the original link?
Hmmm...the host must be down again. I'll upload it somewhere else this evening when I get home from work.
Sorry for the delay. Here's an updated version and the changes are:
-edit/import palette definitions (*.pal files used by emulators)
-"wide" view for laptops
-pointers to rows/columns/screens when compressing map data
-some RLE variations (thanks Bregalad)
-some bug fixes
When you compress map data in blocks, the editor spits out another file (*.mpt) with a list of pointers in this format:
Code:
.dw $_ptr + #
where '$' is the map file title and '#' is an offset into the map data. In theory, it supposed to work like this:
"main.asm":
Code:
; main pointer table to each list of pointers
mapdata_ptrlo: .db <m00_blkptrs
mapdata_ptrhi: .db >m00_blkptrs
; pointers to each "block" of data
m00_blkptrs: .include "map00.mpt"
; the actual map data
map00_ptr: .incbin "map00.map"
"map00.mpt":
Code:
.dw map00_ptr + 0
.dw map00_ptr + 4
.dw map00_ptr + 11
; etc...
The goal was to be able to edit your maps without having to make changes to pointers or code.
edit: see first post for link
My Screen Resolution is too small to use the map editor (1366x768 Laptop screen), Can you do some adjustments for use at least in 1024x600 res or at least let the user choose resolution settings?
EDIT: I Must Read before talking... Sorry!
Thanks for relinking this and the updates!
Please include comdlg32.ocx and mscomctl.ocx in the next release package.
Does anybody have "MEP Demo.zip" from the first post?
thefox wrote:
Does anybody have "MEP Demo.zip" from the first post?
here:
cyc wrote:
thefox wrote:
Does anybody have "MEP Demo.zip" from the first post?
here:
Thanks!
I'd love the window to be bigger, I.E. optimized for full hd monitors. I feel like I could be seeing all metatiles without scrolling through them and also
see more rooms at once actually a 2x zoom on the screen edit area and only one screen at a time would be great.
Another feature that would be great is if it could load the rom directly instead of sepparate files. This would be great for hacking instead of development as everything already is on the rom. You'd just need to specify byte ranges in the rom for each specific thing so then you can save screen edits and metatile edits directly to the rom and test it right away. The way it is I need to save the map file, open an hex editor, remove the old map section and paste the map file's content in there everytime I want to test it.
That out of the way, I just need to say, this tool is FANTASTIC!!! I have already gotten it to work with super pitfall within an hour or so (not the attributes because in super pitfall they are not bit packed, it's 1 byte per metatile). It's very usable with just one palette anyway, so very very impressive work there, thanks!
edit: I have manuallly converted the attributes to bit packed sequence and it looks so nice. Thanks again!
edit2: sorry about my noobishness, but a simple batch file "copy /b file1 + file2 + file3 finalfile.nes" resolves the issue with quick testing. Now if only we could edit the interface a bit
I'll post a newer version of the program when I have access to my computer. Some of the additions include a larger viewing mode and an animation editor. I can add a zoom feature to the map editor.
Great! I just thought of another desirable feature: it'd be nice to be able to edit the metatile's attribute and have them saved to the mtp file.
Any news?
I've been using this tool non-stop on my super pitfall hack, it's just too good
I have organized the rooms from the original game and from my hack.
It would be interesting though if the editor could take a screen type map and display the screens based on another "big map" file. For example, the way it is now it displays screens sequentially screen 1, screen 2, screen 3, etc. But it could take another file that organizes these screens in a different order. This would be perfect for map previewing and could even be used to generate images of the map.
Here is how it is in Super Pitfall nes:
This is the "big" map. Each of these bytes represet a screen (or room). Notice how some rooms repeat. The whole map is 16 rooms wide and 13 rooms high.
Code:
1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F
1F 1F 1F 1F 1F 1F 1F 1F 09 0C 09 25 02 02 1F 1F
1F 21 34 09 00 01 01 02 03 04 0B 09 03 09 1F 1F
1F 15 3B 3A 1C 1D 0B 0E 06 07 09 02 09 0B 1F 1F
1F 19 2C 2B 12 20 30 2C 2B 13 0D 33 36 37 2F 1F
1F 1A 24 27 18 1E 30 26 25 0F 0A 0C 02 09 3E 1F
1F 1A 2A 34 31 1E 11 23 34 0F 0A 04 0B 34 3E 1F
1F 19 27 27 12 1E 1B 23 22 0F 0A 03 23 24 17 1F
1F 19 24 24 18 1E 1B 29 34 0F 0A 04 2A 03 3E 1F
1F 1A 28 28 32 20 11 29 28 10 0A 03 02 22 17 1F
1F 1F 06 05 08 14 06 08 06 08 06 07 02 02 17 1F
1F 1F 1F 1F 1F 15 39 38 2E 2E 2E 2E 3C 2D 16 1F
1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F
And then there's the metatile sequence. It works the same as the map type in MapEd Pro, breaking itself into rooms, sequentially. The first 16x15 metatiles form the first room (00) and so on.
So the way I have been editting the map is on each room separately, which is great enough, but if the editor displayed the real map that'd be insanely powerful.
Notice how the rooms are not positioned the same way they are in the game in relation to each other. I have set the map to be 31 screens wide and 2 screens tall so it would display 4 rooms at a time in the editor.
I have put gng's level 1 on mapedpro, for testing.
I'm starting to sound like a broken record, and I don't want to sound rude. The tool is incredible, I can't stress this enough, but could we get the source code? For hacking it would be incredible to edit the ROM directly. So instead of feeding it different files it would have fields to inform the editor about the offsets containing each data.
For example, instead of telling it to load a map file you would simply load the ROM and tell it "map starts on address 0x8000".
Having to work with separate files is not ideal when hacking a game. I understand this is the nesdev, not the neshack forums, so I'm just making a plea as there isn't a tool like this anywhere.
nesrocks wrote:
For example, instead of telling it to load a map file you would simply load the ROM and tell it "map starts on address 0x8000".
You might be able to make a small tool in Python or whatnot to initially extract the data files from the ROM at a given offset, and to inject them back. That would add just one extra step on top of saving the map in the tool.
Where can I unload the program?
Here (page 4 of this thread)
viewtopic.php?f=2&t=7111&start=45#p100500thefox: yeah, that is one of the possible workarounds (mine was to do it manually). The point is that a tool can be a lot more powerful and get a lot more users if it is self contained.
It would take me a long time to learn how to program this myself. So instead of doing that I prefered to do it manually as this was probably my only hack, at least in a long time. My requests are more because I'm seeing the potential here and I know that accessibility would mean more and better hacks being produced. It is of course up to the author to do whatever he wants with his work though, and I defend that.
Updated first post with v0.30.0. The big changes were adding an animation editor, defining objects and adding them as actors, and a basic text editor.
See the readme for a full list of changes and bug fixes.
This looks amazing.
Unfortunately, I can't figure out whether it doesn't run correctly on my computer, or if I just can't figure out how to use it.
I create a new project successfully, but then nothing I click really does anything. I think maybe I need to start with a new MCF? Doing file->new->new MCF doesn't do anything. New->Map prompts me for sizes, but doesn't do anything after that, the other entries under New don't do anything.
I can edit the map header, but if I try to edit the MCF I get "Run-time error '76' Path not found" and it crashes.
Is something not working, or am I just being too obtuse to use it properly?
Sorry for the delayed response. I have been fixing some bugs and writing up a user manual, so hopefully that will help.