On Thu, Jul 29, 2010 at 05:35:46AM +1200, Ralph Versteegen wrote: > On 29 July 2010 05:03, James Paige <[email protected]> wrote: > > On Thu, Jul 29, 2010 at 04:48:51AM +1200, Ralph Versteegen wrote: > >> On 29 July 2010 04:37, <[email protected]> wrote: > >> > teeemcee > >> > 2010-07-28 09:37:19 -0700 (Wed, 28 Jul 2010) > >> > 514 > >> > Support for variable record number and length .N## lumps, including > >> > variable number of NPC definitions. > >> > > >> > I have not actually changed the .N## record length yet. > >> > You can add or remove NPC definitions and delete all copies of an NPC on > >> > the map from the NPC editor; the default number of NPCs is just 1 (and > >> > old games no longer automatically jump to 100 NPC definitions). > >> > The meaning of max_npc_defs changed. I decided to set the limit to 500 > >> > for now, we should probably raise it when more NPC instances are > >> > possible. > >> > --- > >> > U wip/common.bas > >> > U wip/common.bi > >> > U wip/const.bi > >> > U wip/custom_udts.bi > >> > U wip/customsubs.bas > >> > U wip/game.bas > >> > U wip/loading.bas > >> > U wip/loading.bi > >> > U wip/mapsubs.bas > >> > U wip/moresubs.bas > >> > U wip/ohrhelp/pick_npc_to_edit.txt > >> > U wip/subs.bas > >> > U wip/udts.bi > >> > U wip/whatsnew.txt > >> > U wip/yetmore.bas > >> > U wip/yetmore2.bas > >> > >> Now I remember why I did not commit this: the binsizing of .N is > >> completely untested, I suspect that when I try to actually expand .N, > >> it will break. > > > > Hmmm. yeah. Since there is a different .N file for every map, I don't > > see how they could use the same binsize scheme as the other binsized > > files. > > I overcame that, I'm not too worried about that bit (but it is another > potential source of bugs). > > > Would it be better to convert the .N files into a reload format instead > > of binsizing them? > > > > --- > > James > > I'd love to resume discussion of a new map format (I posted something > to this mailing list long ago), because I'd love to finally implement > parallax map layers. At the time I propose switching most lumps except > .N to reload, and (upon rereading) I decided to stick to that for > simplicity of implementation. But if you're storing NPC definitions as > reload nodes in rsav anyway, it becomes natural to switch to reload > even if it isn't needed.
Okay, cool. (Full disclosure: I have entirely forgotten any previous conversations about new maptile formats, so I am starting from square one here) Does it make sense to put an entire map (layers passability, foemap, general, NPCs, doors whatever) in a single reload document? Or should the data remain multi-file? Regardless of where tilemap data is stored, does it make more sense to keep it in a binary blob? I think it does... I know bigger tilesets (or multiple tilesets in a single layer) is a future goal, so would this be a good time to allow for that? Or would it be better to add that after this conversion is complete? Do we want to compress tilemap data? RLE? zlib? Is there any downside to that other than load-time? (and would the reduction in disk-read time compensate for decompression time anyway?) Grandpa, why are there more questions than answers? --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
