by
(See TraceManager (AS2) Update)
Finally I put some code up here:
“TraceManager.as”
“TraceManager Test.fla”
This is an AS file I put together for some big engine work. When your jamming together a lot of code and a big library of functions, it becomes difficult to keep track of what’s working and what’s breaking. For me, constantly turning traces on and off and having to figure out the meaning of traces that I wrote weeks (or even months) ago gets old fast.
Lately, my physics work has me running more functions than you can shake a stick at; functions within functions within functions, nesting like you wouldn’t believe. This leads to the most hideously complex tracing, almost nullifying the reason you trace data to begin with. So I put together this TraceManager to end such problems once and for all:
_________________________________________
Time(seconds): Depth: Function:
—————————————–
0________________+0____function1 (test1){
0________________+1________function2 (test1 1){
0________________+2____________function3 (test1 1 2){
0________________-2____________} function3—RESULT( test1 1 2 3 )
0________________-1________} function2—RESULT( test1 1 2 3 )
0________________-0____}function1—RESULT( test1 1 2 3 )
-This trace is from the example fla. It runs like so: function1 takes a string (“test1″) and adds a ” 1″ to it, then passes the result to function2; function2 adds a ” 2″ and passes the result to function3; function3 adds a ” 3″ to the string and returns it. Each function returns its own result to its parent function until all functions are complete.
The new system just requires that the file be initiated, then at the beginning of each of your functions you run “TraceCheck,” and at the end, you run “TraceResult.” Traces are automatically formatted to resemble AS code, including indentation to show function nesting.
Since you may not want to see all your functions traced at the same time, you can limit the “traceDepth”. This will determine how “deeply” your nesting will be traced out. If you don’t want to see all those nested math functions, just set traceDepth to 1 and only the highest level of functions will trace out, otherwise set it to Infinity and see every step in the greatest detail (or use 2 to see only the top 2 nested layers, etc).
Using the tracesUNIVERSAL element in the constructor will automatically define all traceDepths, while tracesTOP will only define traceDepths for functions that have an undefined traceDepth. In other words, you can easily go between tracing only a specific few functions, tracing all functions except for a few, and tracing every single function you have.
The “Time” values allow you to estimate the processing time spent on a single function. Time values will even change within a single frame of flash activity, so you can easily see what part of your code is lagging.
You can also save on processing power by delaying all your tracing until after your program is done running. All the trace data is saved as an array of strings until the “TracePrint” function is run and everything is converted to a solid string variable and outputted. This comes in very handy because constant tracing can slow your framerates way down. You can also use it to give your programs a “command line” kind of output by linking the TracePrint function to a key or manually accessing the outputted string (returned by TracePrint).
When your development phase is complete and you don’t want to spend any unnecessary processing on the TraceManager, you can set the constructor’s onSwitch variable to “false” and TraceManager functions will no longer run.
There’s a more specific explanation of the TraceManager in the comments at the top of the file. I’ve also included an example fla for experimentation. If you’re still confused, you found a bug, or want to share your own update to the file, comment here. I’ll comment whenever changes are made to the original files.
Those links again:
“TraceManager.as”
“TraceManager Test.fla”
