Debugging platform specific errors
by Joe Bussell · in Technical Issues · 12/21/2007 (10:40 am) · 1 replies
One of the many issues that developers face when looking at a new product or technology is figuring out how to diagnose what happened when everything does not go according to plan. While working with TGE I have encountered numerous idiosyncrasies in my programming style that misguided me, and I ended up telling myself to rtfm ;-) There are some good tools that we have at our disposal.
Though I have not achieved the Zen of programming TGE systems yet, I have covered some of the bases. I found that the console.log file was my friend in most cases. I was able to use that log to determine in one case that the OpenGL drivers were not available for the old video card I was testing with. I have also found script errors, missing textures, lost preferences; a host of goodness for my programming consumption.
Now I come to my customer with a demo CD in hand. I am flush with the bravado of having tested my app on three different boxes, each with a different video setup. As hopeful as a novice programmer with his first app, I eagerly installed the demo: no errors detected. When the application failed to initialize I opened my good friend console.log. There were no clues to follow. The OpenGL driver was found, a device context was sought, then bupkis, no more information and no application window at all. I went to the Windows event viewer, again no clues.
So, the console.log tells me that the next step, which is setting up pixel formats on my working dev box is never reached. How can I determine where this process unraveled?
I will gather the relevant logs, specific hardware lists, operating system update level, video bios, and whatever data necessary to catalogue this specific error, but I wanted to open the topic of platform compatibility design and debugging generally as well.
What tools, techniques, tricks, and Torque-Foo are developers using when deploying their creations to the infinite combinations of hardware and software configurations out in the wild?
-- Joe
Though I have not achieved the Zen of programming TGE systems yet, I have covered some of the bases. I found that the console.log file was my friend in most cases. I was able to use that log to determine in one case that the OpenGL drivers were not available for the old video card I was testing with. I have also found script errors, missing textures, lost preferences; a host of goodness for my programming consumption.
Now I come to my customer with a demo CD in hand. I am flush with the bravado of having tested my app on three different boxes, each with a different video setup. As hopeful as a novice programmer with his first app, I eagerly installed the demo: no errors detected. When the application failed to initialize I opened my good friend console.log. There were no clues to follow. The OpenGL driver was found, a device context was sought, then bupkis, no more information and no application window at all. I went to the Windows event viewer, again no clues.
So, the console.log tells me that the next step, which is setting up pixel formats on my working dev box is never reached. How can I determine where this process unraveled?
I will gather the relevant logs, specific hardware lists, operating system update level, video bios, and whatever data necessary to catalogue this specific error, but I wanted to open the topic of platform compatibility design and debugging generally as well.
What tools, techniques, tricks, and Torque-Foo are developers using when deploying their creations to the infinite combinations of hardware and software configurations out in the wild?
-- Joe
Torque Owner Andy Rollins
ZDay Game
That only solves half the puzzle in that you know it "Will Work" on that operating system, but testing it on as many different hardware configurations is another matter and that is where you're beta testing comes in to try and iron out as many of those faults as possible.