Online Gconvert JS

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Online Gconvert JS

Post 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?
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Online Gconvert JS

Post 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.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Online Gconvert JS

Post 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.
Post Reply