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: Select all
.db $xx, $xx
.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.