Page 2 of 2

Re: Online Gconvert JS

Posted: Mon Jan 21, 2019 4:44 pm
by nicksen782
Do you mean that a function would be exported out of Gconvert that would do the map drawing? That sounds good but wouldn't it be better to have this code as an #include for the game, or is that what you mean?

"Meta" seems to be more accurate than "mega". I figure it should be safe to change the name as right now I think only your games use the feature so you would be the only one inconvenienced by the change.

"meta-meta" tiles sounds like what Micro Mages was doing. They took huge, made it smaller, and then made it smaller again. Probably costs more in processing power but once the data is in VRAM it shouldn't matter, right?

Re: Online Gconvert JS

Posted: Mon Jan 21, 2019 9:09 pm
by L4rry
nicksen782 wrote: Mon Jan 21, 2019 4:44 pm That sounds good but wouldn't it be better to have this code as an #include for the game, or is that what you mean?
Yes, it would be an included source file. Just like the '.inc' files are for the tile sets and maps. I'll add this as an optional attribute to the 'meta-map' tag.
nicksen782 wrote: Mon Jan 21, 2019 4:44 pm Probably costs more in processing power but once the data is in VRAM it shouldn't matter, right?
Yes the space saving meta maps, or meta-meta maps bring, will come at a cost of processing cycles. It's for each game design to choose the best trade off for it. But yes, for scrolling levels, you generally only populate the VRAM once, then just add one off screen row or column at a time as you scroll through a level. For mode 3 anyway.

Re: Online Gconvert JS

Posted: Tue Jan 22, 2019 8:32 pm
by Jubatian
Processing costs for this sort of level packing is I think mostly negligible, the AVR is fast!

What I can think of as a downside is that this approach needs more consideration in your map design. If you go extreme with this type of compression (something like FoaD, huge maps), they could easily become very repetitive. Probably it would be easier of course if there was a tool for composing these types of maps, I mean a visual map editor. It was quite difficult to work with Gimp for everything. Of course if the maps are rather small, you could get away with simply compressing them without even thinking a lot about the underlaying approach, the algorithm will figure it out how it can reuse, then it really doesn't have any downside. If the map design is compressible, it is just good to have it compressed in this manner (unless you worried about understanding the code preparing it for display).

Just thoughts on the matter.