-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).

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.

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]

_________________Life is complex: it has both real and imaginary components.

Last edited by Bregalad on Sat Oct 30, 2010 10:19 am, edited 1 time in total.

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.

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.

Who is online

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