Re: [dink-develop] New map format

[Phoenix <ale...@br...>]

Well, this ain't a flame, it just got me thinking.. this map, in a space vs.
time comparison is very time-y, but non-space-y. Why? Well, if a user
decides to add a screen in the middle (lets say a screen that is um...
number 300 in the row, and there are a total of 700 maps - say there be 50
maps in front of map nr. 300 and 50 maps after map nr. 300. In Seth's
system, this'd be appended to the end of the file, which would cause no
speed issues. It'd be a quick thing to do. (I don't know if you're going for
an indexed map or a linear map, but to me, your idea seemed linear. Same
with adding sprites.. Seth's method would only require you to seek to a
point in the file, and then overwrite what's already there (be that a
previous sprite or just a whole bunch of 0'ed bytes...) with your method,
you actually would have to rewrite half of the file (unless you know a way
to.. um.. just shove all following data forward when adding a sprite... even
adding text at the start of the map would take quite some time... just
saying that you might want to think about speed a little too.. even the
ID3v2 tag system has padding, leaving space for additional tags/data, to
make editing/adding new tags faster.

Now, today, PCs are quick, so speed might not be that much an issue anyway..
but space is also something we have a lot of these days.. and it may be just
me, but I'd rather waste some space for a faster execution, than to wait a
lot just to have a smaller file. Compression programs will remove most of
the slack space when sending the file out on the internet anyway.

(This is meant to be constructive critisism. ;))

-Phoenix

----- Original Message ----- 
From: "Andrew" <ae...@co...>
To: "Dink Develop Mailing List" <din...@li...>
Sent: Thursday, June 03, 2004 3:06 AM
Subject: [dink-develop] New map format


> It turned out that the converter I wrote actually made Desplesda's map
> format LARGER than the original.  That's a no-no.
>
> I made a new map file format (this is probably going to turn out all
> garbled).  It replaces the old Map.dat, Dink.dat, DMOD.diz, and could
> very easily be accomodated for Hard.dat.  Someone let me know what I
missed:
>
<snip>
>
> So, that's it.  Send all flames to /dev/null.
>
> -- Andrew.
>