On 29 July 2010 06:27, James Paige <[email protected]> wrote: > 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?
I think either it should all go in one reload file, or in one lumped file. (Once the lump IO abstraction layer is in use, double lumping map lumps won't add any extra loading time.) I didn't feel like rewriting stuff that didn't need changing, so I suggested the later. However, of all the map lump formats, .N is the only sane one!! And when I actually went to add some new NPC features, it was depressing that I first had to go on a big detour to make .N variable length. I think replacing all our crappy file formats would provide a big productivity boost to this project. > Regardless of where tilemap data is stored, does it make more sense to > keep it in a binary blob? I think it does... Definitely; storing individual tiles as RELOAD nodes would be ridiculous. > 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? Yes, this is an excellent time to add that. It was in my proposal (and I'm still happy with that bit). > 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?) Lump compression can and should be done completely transparently by the lumpfile layer. I proposed that any lump suffixed with ".gz" be gzip compressed. Alternatively we could use zlib streams, which are identical to gzip files IIRC, but with the gzip header (which adds some stuff we don't need) removed. Both are just accomplished with different APIs in zlib. zlib streams are what are normally used internally in applications. When unlumping a file, we could just always decompress all compressed lumps, avoiding the problem that there's no common command-line utility to decompress zlib streams. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
