[Verse-dev] New version

[Eskil Steenberg]

Hi

I just emailed Emil  a new version that could potentially be R4, So if 
you want to move over to R4 now is the time to do so. Unless Emil finds 
something bad this version has my stamp of approval.

R4 is a major Release because verse can now do everything i want it to 
do, with the exception of a future Physic node. We got the bones, the 
timing, the curves, Subsurface scattering, the animation, the audio, its 
all there. R5 is not likely to make any real changes to the API.

 The changes for R4 are:

+ Major rewrite of connections
+ Major rewrite of networking
+ Major performance boost
+ Data encryption added
+ Verse now only uses one port.
+ added verse_host_id_create and verse_host_id_set
+ verse_send_connect takes "expected_host_id" param
+ verse_send_connect_accept takes "host_id" param
+ new verse_send_connect_terminate replaces terminate and deny commands
+ verse_send_node_create now takes "VNodeOwner" param
+ New function to get a sessions time: verse_session_get_time
+ new functions: verse_send_o_anim_run and verse_send_o_anim_stop
+ All transform commands updated for new time format
+ verse_send_a_stream commands updated for new time format
+ Method names can be longer.
+ bones now have "weight" and "reference" params
+ VMatFrag now uses enums instead of uint8s
+ New animation fragment
+ New volume fragment
+ output now has "label"
+ verse_send_b_layer_set_tile -> verse_send_b_tile_set
+ verse_send_b_init_dimensions now verse_send_b_dimensions_set
+ verse_send_c_curve_key_destroy renamed verse_send_c_key_destroy
+ Curves can now have up to 4 dimensions.
+ verse_send_c_curve_key_set -> verse_send_c_key_set
+ verse_send_c_curve_key_destroy -> verse_send_c_key_destroy
+ Audio blocks added

Things that are not done:

- testing.
- Login Encryption.
- Ping command not properly implemented.
- Physic node (dont hold your breath on that one)
- Some server implementation.

One thing that I wanted in R4 was login encryption, But i have not had 
the time to work on an implementation of math for large numbers (does 
any one have a simple implementation on can look at?). How ever the API 
for this is in place so it shouldest be a big thing to add in R5.

There is one more thing on my mind: Performance.

The Performance has improved a lot with version R5, but i have found a 
new bottle neck. Packing. This is most notable when subscribing to large 
texture maps. In one particular test that i did i created a so large 
image that once the server was done packing it, the clients had timed out!

I have attempted to fix this in a variety of ways.

One  way of fixing this is to have larger tiles: 16*16 pixels, this will 
help a bit, and will help even more if we have different sizes for 
different types. we could have 32*32  for 8 bit layers. This obviously 
only help with large bitmaps, not other types of data.

An other way is to in our server implementation not just loop the 
subscriptions but to push them out in parts. This will mess it up 
slightly in the server end, but It may have to be done.

Here how ever is a bolder idea, How about letting users "pre pack" 
commands, store them as pointers and then send them away.

VPackCmd *my_bitmap_call;

verse_pack_mode(TRUE);
verse_send_b_tile_set(node_id, layer_id, x, y,  z, VN_B_LAYER_UINT8, tile);
my_bitmap_call = verse_pack_get();
verse_pack_mode(FALSE);

verse_send_pack(my_bitmap_call);
verse_pack_destroy(my_bitmap_call);

Now this way a server can store the tiles (or any call) in a packed 
format, that will make it very quick to send the same data over and 
over. It would be not too hard to implement , but im a little reluctant 
to add an other way of sending data.

Any opinions?

E