View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jul 13, 2010 12:49 am Post subject: Walking Through A Frame |
|
|
This is a mental exercise, maybe someone will gain from reading it. I wish there were a flow chart or if there is, I wish I could find it
Begin:
sys_win.c or sys_whatever.c
Main program loop:
1. Host_Frame (time); // host.c
-- 1a. _Host_Frame (time); // host.c
---- 1aa. IN_Commands // in_win.c on Windows, get mouse and joystick input
---- 1ab. Cbuf_Execute // Process console commands
---- 1ac. NET_Poll // net_main.c --- no idea what this does actually
---- 1ad. if (sv.active) CL_SendCmd ();
// Ok now this has to be single player or listen server
------ 1ada. CL_BaseMove (&cmd) // Get right, left, up, down and angles from keyboard
------ 1adb. IN_Move (&cmd) // Add mouse/joystick right/left/up/down and angles to movement
------ 1adc. CL_SendMove (&cmd) // Send the move to server (UNLESS we are playing back a demo)
------ 1add. NET_CanSendMessage // unless playing demo
------ 1ade. NET_SendMessage // unless playing demo
------ 1adf. SZ_Clear (&cls.message); // I guess this is clearing the message for next time
// End single and listen server send input
// Back to _Host_Frame
---- 1ae. Host_GetConsoleCommands (); // Not 100% sure.
---- 1af. if (sv.active) Host_ServerFrame ();
------ 1afa.SV_ClearDatagram (); // I don't know what a datagram is.
------ 1afb. SV_CheckForNewClients (); //
------ 1afc. SV_RunClients (); // Read client messages
------ 1afd. SV_Physics (); // Obvious
// Begin physics
-------- 1afda. PR_ExecuteProgram // Run the QuakeC
-------- 1afdb. Physics: Loop thru all entities and run physics based
on MOVETYPE
// End physics - back to Host_ServerFrame ();
------ 1afe. SV_SendClientMessages (); // Send messages to clients
//End of Host_ServerFrame -- back to _Host_Frame
---- 1ag. if (!sv.active) CL_SendCmd (); // If client only, send commands
---- 1ah. if (cls.state == ca_connected) CL_ReadFromServer (); // If connected read from server
---- 1ai. SCR_UpdateScreen (); // Worthy of exploration
---- 1aj. S_Update (r_origin, vpn, vright, vup); // Sound update from current position
---- 1ak. CL_DecayLights
End _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Tue Jul 13, 2010 2:50 am Post subject: |
|
|
Fixing the frame cycle is actually one of my final objectives with Makaqu.
All the different subsystems shares a lot of data structures and functions in a way that affects the flow of each frame too much. The countless calls to VID_LockBuffer, VID_UnlockBuffer and S_ExtraUpdate are just an example; their usage is too vague, they're too intrusive, and it isn't clear enough when we should use it, specially when we're adding new drawing functions.
This was a simple example, there are ones that are a lot worse. An example is JoyMenu's "body view", which is a QC hack to make chase_active works better in engines that didn't fix it. This hack sets the player view to a secondary entity while chase_active is 1, so the engine will draw the player model correctly, and it updates the camera's entity position at PlayerPostThink, to avoid lag in the movement. However, there are some moving platforms where it still lags, like the one in e1m1 that we activate with a button to cross over the first acid pool.
This happens because PlayerPostThink is processed after the player's physics, but before the physics of the other entities, and those platforms changes the player's position after the player's physics have been run. Quake's physics updates are a mix of synchronous and asynchronous, even inside a single frame.
This also caused several very annoying bugs in Fightoon, because of there having a single frame of difference between the physics of the first player and the physics of the second player. And in fighting games, this means the difference between a player being able to defend attacks right upon waking up from the ground and the other being not.
And no, EndFrame couldn't work around that. I don't remember why.
In a sense what I want is to reenginer all subsystems enough so they can be more modular and abstract, which in turn will make it possible to reenginer and refactor the frame cycle code in a way that makes it easier to fix and to avoid this kind of problem. _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jul 13, 2010 4:09 am Post subject: |
|
|
mk wrote: | Fixing the frame cycle is actually one of my final objectives with Makaqu.
All the different subsystems shares a lot of data structures and functions in a way that affects the flow of each frame too much. The countless calls to VID_LockBuffer, VID_UnlockBuffer and S_ExtraUpdate are just an example; their usage is too vague, they're too intrusive, and it isn't clear enough when we should use it, specially when we're adding new drawing functions. |
Well ... for sure the software render sure likes to lock and unlock the buffer a ton  _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|