On 9/17/2010 12:23 AM, Ralph Versteegen wrote:
On 17 September 2010 16:11, Mike Caron<[email protected]> wrote:
On 9/17/2010 12:01 AM, Ralph Versteegen wrote:
On 17 September 2010 15:46, Mike Caron<[email protected]> wrote:
On 9/16/2010 11:43 PM, [email protected] wrote:
teeemcee
2010-09-16 20:43:54 -0700 (Thu, 16 Sep 2010)
372
Last minute change to the zonemap file format: switch to a span-based
format (as already documented on the Wiki)
This format is easier to write, but surprising slower to read and write
(about half), and the file size is now mostly RELOAD overhead (wish Mike
hadn't rejected my suggestions for better space efficiency).
Which ones were those? :S
-Use a VLI instead of an INT for node size. Even if you reserve 4
bytes whenever the node has any children, and then write the size
later, you can probably use a single byte for leaf nodes.
Except, the reason I use four bytes is because:
1. It's very difficult to "slide" the rest of the file over to get rid of
the extra space. Even if that were easy,
2. It would create a cascading effect on the sizes of all other nodes.
You misunderstood. I meant: if the node has no children, determining
the size is easy; otherwise reserve 4 bytes (27 bits: 134MB) and come
back and write the VLI later.
Both those problems would be solved if we rendered the file into memory
first, but I'm not particularly enthused about writing this code.
We do already write the file to memory first, but of course it's not
designed to do this.
The technique I've used in the past (albeit, in C# with MemoryStreams)
is to create a buffer for the node's children, render the children
(passing this buffer), and then rendering the node itself + the buffer
into the parent's buffer.
The advantages are that you can do nice optimizations like the VLI
thing. The downside is that it's a lot of memory management (especially
without a garbage collector working behind the scenes!)
-Add a bit to the type byte that indicates whether or not there are
any children, so that you can skip the VLI for number of children for
leaves.
This is reasonable, since I don't foresee having to add any new types.
You'd still be able to have up to 128 types.
Yup, I was agreeing with you
Those reduce the overhead from 7 bytes per leaf to 3. So if the
average size of a .Z 'spans' data node is 3 bytes (guessing), it's a
significant saving.
I forgot that strings also have a size VLI, so it's actually 8 vs. 4.
I agree that it's significant.
An alternative, however, might be to forgo the size counts entirely. The
reason they exist is to allow efficient scanning of the file in cases where
you only care about part of the file. However, this is impossible with the
current API, so...
Huh? The sizes are used to skip over nodes when using delay loading.
Wasn't that exactly their intention? And that seems worth keeping.
Oh, yeah. Wow it's been a while. But, now I remember...
Hmm...
Another option would be to only include the sizes if the node has
children, but that's getting a bit messy.
Unfortunately, you don't know in advance whether a node has children or not.
Proposal: Bump the version to 2 and omit the size parameters entirely.
Thoughts?
I figured we would eventually create a new version, and that I would
not let my suggestions be excluded again; however there's no hurry to
do so now. I guess it's it wouldn't be much work though.
Honestly, though, does it really matter that much that there's 8 bytes
of overhead instead of 4? I think the law of diminishing returns is
kicking in here...
Also finally added zonemap support to map resizing.
---
U wip/loading.bas
U wip/loading.bi
U wip/mapsubs.bas
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
