[Verse-dev] changes in verse

[Eskil Steenberg]

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


> 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.

> 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.

> 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...

Cheers

E