How can some code behave absolutely fine when being inspected under a debugger, and go absolutely nuts once running free!!?
Well, enter Real Time code which is synchronized with the time we measure! This happens in the Soshiant project. The project is real time, although "Soft Real-time" since it has to respond in a specific time frame, known as each Frame of the application which one main loop executes, and also dependent on the actual time which goes by in our real world. Every frame knows the time passed since the last one, for example 16ms. This time is used as an input value to different algorithms in the code, such as the animation code which uses it to find out about the correct transformations that needs to be applied to the characeter bones in the current frame.
What the debugger does is to first of all stop the execution of the program on a specific point, the break point, and enable you to trace the code line by line from that point on. Stopping the execution means stopping the main loop and bringing its frequency down but the real time which we sense is of course not going to stop so the result is loss of synchronization between the frames and the time. If in normal execution the 10th frame is performed at time 300ms, tracing line by line using the debugger will cause the 10th frame to be executed at time 900ms. This would mean that this frame would witness different states for functions which are dependent on the real time while debugging. A practical problem as a result of this problem would be when you see wierd behavior during two animations being blended into each other which happens during 0.2 seconds, but breaking the code execution at the start of the blend will not let you follow the logic as it happens since that 0.2 seconds of real time will pass as soon as your debugger stops the code for you to evaluate.
Solutions? Short answer, to output trace what you want to monitor while the application is running and not to use break points. Not a real nice solution and sometimes cumbersome. Other solution might be to decouple the algorithms which rely on time from the real time we measure and provide a virtual time system for the application. Speaking about time, we might not be able to find out which time is the real one and which is virtual, relativity anyone?
Well, enter Real Time code which is synchronized with the time we measure! This happens in the Soshiant project. The project is real time, although "Soft Real-time" since it has to respond in a specific time frame, known as each Frame of the application which one main loop executes, and also dependent on the actual time which goes by in our real world. Every frame knows the time passed since the last one, for example 16ms. This time is used as an input value to different algorithms in the code, such as the animation code which uses it to find out about the correct transformations that needs to be applied to the characeter bones in the current frame.
What the debugger does is to first of all stop the execution of the program on a specific point, the break point, and enable you to trace the code line by line from that point on. Stopping the execution means stopping the main loop and bringing its frequency down but the real time which we sense is of course not going to stop so the result is loss of synchronization between the frames and the time. If in normal execution the 10th frame is performed at time 300ms, tracing line by line using the debugger will cause the 10th frame to be executed at time 900ms. This would mean that this frame would witness different states for functions which are dependent on the real time while debugging. A practical problem as a result of this problem would be when you see wierd behavior during two animations being blended into each other which happens during 0.2 seconds, but breaking the code execution at the start of the blend will not let you follow the logic as it happens since that 0.2 seconds of real time will pass as soon as your debugger stops the code for you to evaluate.
Solutions? Short answer, to output trace what you want to monitor while the application is running and not to use break points. Not a real nice solution and sometimes cumbersome. Other solution might be to decouple the algorithms which rely on time from the real time we measure and provide a virtual time system for the application. Speaking about time, we might not be able to find out which time is the real one and which is virtual, relativity anyone?
No comments:
Post a Comment