Re: [ZIG-users] pthreads and more general feedback

[<fc...@in...>]

tua...@fr... wrote:
> 
> I like zig's layout better too, and LGPL license is far cleaner that 
> their 'special' dual license.

I have just changed the ZIG license to a BSD-style license, which is
much smaller, cleaner and has none of the LGPL restrictions.
of course, you can choose either the old or the new license (but the
BSD license is better! :-)

> Nearly finished the gl port and the OgreOde demo, need to find/make a 
> server browser to make it usable

this is one of those features that will make it into zig "some day"
(master server/list server functionality)

> On the demo I'm working, here's what I do :
> 
> For now I typically send 5 rigidbody data per player from the server to 
> each client
> struct RigidBodyData
> {
>    Vector3 position;                //3 floats
>    Quaternion orientation;       //4 floats
> };
> struct VehicleData
> {
>    RigidBodyData chassisData;
>    RigidBodyData wheelData[4];
> };
> 
> In my  Optimisations list :
> - Send particular data to each client (only other clients it can see, 
> using some space partitionning technique).

in Outgun, for instance (http://outgun.sf.net) it is trivial to do so,
because it's a 2D game where the world is split into "rooms", so
the server only sends updates to a player about other players in the
same room. but if your 3D/physics code can determine, at the
server side, whether two objects can "see" each other, then the
netcode server can easily decide which objects to send to each
player.

> other clients can be just ushort int x,y on a Mini map.

that's what I do in Outgun too. the packet sent by the server contains
a record like this:

byte who
ushort x
ushort y

at each update sent to a player, the server chooses a new value
for "who" (the ID of some player) and then sends the x,y of that
"who" player so the player that receives the packet can have its
minimap updated. so, the trick is that the server doesn't send
the whole list of (x,y)'s in each packet to update the minimap
-- it updates just one (or, in the new Outgun versions, two) of
the minimap positions per each packet. with 10 packet/s and 32
players, a player is updated in the minimap every 3.2 seconds
then, which is enough.

> - Can update VehicleData, "Diff-ing" with last frame VehicleData,  to 
> send only "diffed" vars, with some header pointing wich var is updated 
> (a 35 bits bitfield, as they're is 35 var here.)

just be careful that the "frame data" sent by the server to the clients
(also valid for the "client inputs") all use unreliable transport, so
it might get lost. so it can happen that a client receives the diff,
but it does not receive the original data that the diff was supposed
to be applied on.

> - Simplify Data Sent : Front Wheel is  totally constrained on one axis 
> and partially on another (at least), only one is really free... Rear 
> Wheel is just rotating on one axis. no axes moves... (perhaps this 
> optimisation not needed, because of previous one, the diffing, but 
> wheels need to be in chassis coordinates system..)

these optimizations are usually safe.

> - Try to handle track collision Client-side and Car to Car collisions 
> server Side. (tricky, as physic must be absolutly deterministic between 
> all clients and server.) And if physic is totally deterministic, try to 
> make client run physics,  just sending speed and accel vector to server.

if you need determinism, then you generally cannot use
unreliable transport -- what if a client misses some physics input
info that is sent by the server?

the more safe approach is to design it so that each frame/packet
from the server contains all the necessary info for the client to
render it's game screen correctly. so, if a client misses a string
of 100 packets, when it gets the 101th packet, it can already
correct whatever extrapolations it was making and display the
latest "correct" world version.

> Questions about Zig :
> 
> - I'd like to send new input only if input changed, how can I achive that ?
> seems that zigclient needs to send input each frame...

the "input" methods in zigclient_c all use unreliable transport. so, if
you only send the client input when it changes, it could get lost.

the original design was this:
- application calls ZIG whenever the state of the client's input
changes (say, client is now holding the ATTACK button)
- periodically (using the same packet rate as the server) the zig
client sends the current state of the client's input

however, if the client is not just a "dumb terminal", this may not
be sufficient. we need to look what exactly is the role of the client
in your simulation logic.

> - Is there any form of 'timestamping' or packet timing in Zig that I 
> could get in client /server when receiving data. (to implement dead 
> reckoning (see wiki links I added))

you can use ZIG's get_time() (#include <zig/utils.h> to get the
current machine's real-time clock in seconds (it returns
a floating-point value). this can be used as basis for a
distributed time-stamping / event ordering scheme, but
unfortunately that is all ZIG gives.

> - I tried to lower server and client maxfps, but that also lower my 
> Drawing fps, do non-blocking mode do respect those limitations ?
> (running both server and client in non blocking mode)

sorry, this is currently badly documented. here is an explanation:

http://zige.sourceforge.net/phpwiki/index.php/NonblockingHowTo

there is no FPS control in nonblocking mode, the FPS-related
calls (set_max_fps, etc.) don't have any effect.

also, when running in nonblocking mode, ZIG will NOT call back
the render_frame() and poll_input() callbacks. of course, you
can still implement them and call them yourself in the main loop
(this is done in the "minigame_nb_src" nonblocking demo's main
loop)

actually, I think I will take a look at it now and see if I can
improve things...

> - There's no message queuing priority handling in server or client ?

for the reliable messages (send_message() etc.) there is currently
a rudimentary priority support. you can send a message with priority
RSP_HIGHEST or RSP_CRITICAL. ZIG will send and ack all
"critical" messages before it sends any of the "highest" messages
in the queue.

example for zigclient_c:

buffer_c msg;  // a message to be sent

send_message(msg); // send with default priority (RSP_HIGHEST currently)
send_message(msg, RSP_HIGHEST);   // send with the lower priority
send_message(msg, RSP_CRITICAL);  // send with the higher priority


Further priority handling can be implemented, some support is
already in place, but I didn't do it because of lack of demand.

>> and, of course, we could also work together on this and make it
>> a ZIG feature (P2P (client-client) TCP socket management)
> 
> I need it for at least Chat messages between players (also TCP)... so Yes.

question: do you think you would need UDP between clients? if yes,
do you think you would need retransmission of lost UDP packets too?

if you give me a list of stuff that you want running over P2P then
I can come up with an initial design of a solution.

Fabio