Hi! Selon PERRE Y SiseProIsaTig <[EMAIL PROTECTED]>: > Hi all, > > I have started some work on the following points : > - clock refresh only one time per refresh turn. > - add a timestamp in action object and check this timestamp in action_handler > to ignore action with future timestamp.
That's a good idea in my opinion! > > The only remaining things to do is to refresh the game with a fix rate (50 > fps as proposed by lodesi) and skip frames if the computer is not able to > compute enought frames. I'm not sure to understand exactly how it will work. Do you plan to use a separate thread for drawing ? how do you skip frames ? > This various stuff don't change much things (the diff is about 20-30 lines > which is not a bug amount of code) but it raise the following question : Are > we going to include this change now or waiting for a next release ? > > Later i will release a diff and then waiting for your reactions ;) I propose to commit it in a branch, to test it heavily and to apply it in trunk. While network is not nearly bug free, we can not release stable version, only alpha or beta and I don't think the good way is to made lot of hacks to debug all small problems so I prefer solution such as yours. Bye, Matt > > Regards, > > Drayan > > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la > part de Laurent Defert > Envoyé : lundi 30 octobre 2006 18:04 > À : Discution sur le développement de Wormux. > Objet : Re: [Wormux-dev] Network code > > > Re! > > But i think it will not solve all of our problems (for replay for example). > > We need also to write something like a game client event driven. Events are > > coming from a gaming server (local, ai, network) and each event update > > character position, weapon projectile explosion. In gaming server, object > > are refreshed and then send event like explosion, moving object etc. In > > game client, we read an event, then updating etc. For objects like > > particles (not fire particles !), classical game engine should be fine. > > Well, the code to store each characters position is almost there when we sync > the game at the end of each turn, but nothing is there for objects. > But, the aim of the modifications i'm proposing is to avoid to send the > position of each character/object, and send only the user actions (mainly > keyboard/mouse interaction) > As for replays, i'm not focusing on them yet! The first goal is to put the > network code out ofthe main game code. > > > Here is the advantages i can see : > > - separate graphic processing from physical engine. > Totally agree, it's not a big task most of objects have this code already > separated into ::Refresh() and ::Draw() > > > - write a real layer between keyboard, mouse and game engine. > Totally agree, see https://gna.org/task/?3638 :) > > > - run independant game server without game interface. > Not sure it's really useful, my aim is not to make all physics rendered by a > server that sends object position to all client (that would need to rewrite > almost everything).. So an independant game server wouldn't increase the > framerate on clients. The only use of such a mode would be to have better > speed to test the physic engine code (useful under valgrind), or to train a > neural network based AI (maybe in the future! :)) > > > - same code for local and network client. > That's the goal! :) > > > - replay ! Save the game context at the begining of the turn (map, > characters position etc), save the events as they come in a round buffer and > when you have a big explosion with big damage, replay each event on the > previously saved game context and add someone laughting :) (damn ! another > sound !) > > Well, to be honest, it will need a huge amount of work ... > Sure that's why i'm talking for after the 0.8 release ;) > > > Lodesi > > > > > > Drayan > > > > -----Message d'origine----- > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la > > part de Laurent Defert > > Envoyé : lundi 30 octobre 2006 16:45 > > À : Discution sur le développement de Wormux. > > Objet : Re: [Wormux-dev] Network code > > > > > > Hi! > > > > > > - Run the game loop at a constant rate by refreshing the main clock > (the > > > > Time class) at a constant rate, instead of having the physic engine do > > > > it. > > > > > > I'm not sure to understand what you speak about. How can you be sure that > you > > > ran the game loop at a constant rate ? On my computer, Wormux runs with > about > > > 20fps and is playable BUT sometimes, big explosion make it fall to about > 6 fps. > > > In my case, the only way to be sure that game loop is running at a > constant rate > > > is too ran it about 5 times by second making the game totally impossible > to > > > play. > > What I mean is, the game loop would run at a fixed rate, but independently > of the > > displaying rate. > > Practicaly, the class Time would store the current time in a member > variable, so > > each call to Time::GetTime() would give the same value for a same frame, > independently > > of the time elapsed since the last frame. > > In the game loop, we would put a Time::Refresh() that increase the value of > the time by > > 20ms or something like that (it limits the max frame rate to 50 fps, the > same limit > > we have currently in the physic engine). Then we compare the time variable > to the time > > reported by SDL, and there we decide wether we have enough time to display > the frame, or > > just skip it. > > The difference with the current main loop, is that we will run more often > the > > Refresh methods and check for keyboard and mouse interaction. Most of the > current Refresh > > methods is to call the physic engine loop, so the impact there is null, the > loop is just at > > an other place. So the main difference is that we'll check more often for > user interaction, > > which is negligeable I think. > > > > Also I forgot to tell, it's a future work, I don't intend to do any of this > before 0.8!! :) > > > > Lodesi > > -- _______________________________________________ Wormux-dev mailing list [email protected] https://mail.gna.org/listinfo/wormux-dev
