[Verse-dev] changes in verse

[Emil Brink]

On Fri, 8 Apr 2005 09:48:51 +0200 (CEST)
"Eskil Steenberg" <eskil at obsession.se> wrote:

> Hi
> 
> > You didn't show a definition of vuint24, which can be problematic to
> > get right...
> 
> Well the sugested that we should have the int32, and then pack the 24
> bits in the higer end of the uint32. So you would ten be able you use
> it as a 32 bit value. if you only need i24 bits you divide it by 256.
> 
> The higest byte should be copyed to the lowest byte to get the full
> range. so: the 24 bit:
> 
> x15 A4 F3
> 
> should be:
> 
> xF3 15 A4 F3
> 
> not:
> 
> x00 15 A4 F3
> 
> this esxends the range form:
> 
> x00 00 00 00 to x00 FF FF FF
> 
> to:
> 
> x00 00 00 00 to xFF FF FF FF

Okay, interesting. But this only talks about the in-memory representation
that applications see, I meant that there's something needed for the wire
as well. But I catch your drift, we'll simply modify raw_pack/unpack_uint24()
to do the required fiddling; they already use uint32s for the interface.

> > I also feel we should formalize rotational representations, with:
> >
> > typedef struct {
> > 	real32 x, y, z, w;
> > } VNQuat32;
> >
> > Plus the same for 64 bits of course. This makes it easier to
> > document how quaternions are to be interpreted, and make it more
> > consistent automatically.
> 
> Good, there has been some confusion about this.

Precisely.

> > Perhaps we should also have vector types for positition, speed, and
> > so on... But quats are a bit easier to get wrong, there is more to
> > be gained there so let's start there.
> 
> Well i dont think so, every one understands the order of XYZ, and i
> dont want to impose a sructure for xyz on the users. most engines and
> 3d engines already have thier ovn structures for this.

True, we tend towards minimalism so let's delay that further.

> > Yeah... We should in that case document (or at least figure out) how
> > large the "ranges" are, it seems a bit risky to let users assign IDs
> > too far away from what is already existing.
> 
> it is very tricky...
> 
> You could have a maximum gap size, but it would have to be rather big,
> due to the network out of order problem. So if the gap size is 256 a
> evil user might create vertex 256, 512, 768... and fairly quickly use
> up too much memory. an other problem is what happens if you have a
> tight array of vertexes and then delete a big gap in it. how should
> the server react then?
> 
> It is tricky...

Yes... Not at all sure what a solution here would look like, except
perhaps not actually storing data in straight arrays. Using some kind
of tree structure does away with the expense of having large gaps in
the ID ranges, but cost some performance of course. It generally does
feel like a problem with the data structure though.

Regards,

/Emil