It's easier to break than to fix...
by Daniel Buckmaster · in Torque Game Engine · 07/20/2007 (12:34 am) · 19 replies
Okay, please be warned. This post is brought about by frustration, but I guess it's my fault for diving into engine programming without a proper background in C++ coding. If this appears highly irrational, please ignore it or feel free to toast me.
Is it just me, or is Torque extremely easy to break and extremely hard to fix? I've started making modifications to the source code relatively recently, and I'm finding that mostly anything I try to do that's not part of a resource ends up breaking the engine in an odd way and forcing me to start over. For example, just yesterday, I made some changed to guiCrossHairHud. I don't want the default damage bar showing up whenever I look at anything, so I removed that bit. This morning, inspired by the advanced crosshair resource, I decided to ad some further changes. I added script callbacks to the crosshair, so that it would tell me when I move the crosshair onto or off an object.
Now, the engine compiled fine, but upon running it in debug mode, I got an unhandled exception in some odd file that I'd never heard of and that was completely incomprehensible to me. I hadn't even loaded a mission yet!
So I decided to restore the backup I had made of guiCrossHairHud.cc (I'm not that stupid... ;)). I did this, built it, and ran it. Th main menu actually got to load this time, but when I loaded a mission, I got a wierd error in bitstream.cc caused by the Ork model!
Now, I know that the resources are great, and they pretty much work as expected. But why, when I make similar changes, does everything come crashing down? (Or in this case, why does something completely unrelated to my work, that I've never seen before in my life, come crashing down?)
Is it just me, or is Torque extremely easy to break and extremely hard to fix? I've started making modifications to the source code relatively recently, and I'm finding that mostly anything I try to do that's not part of a resource ends up breaking the engine in an odd way and forcing me to start over. For example, just yesterday, I made some changed to guiCrossHairHud. I don't want the default damage bar showing up whenever I look at anything, so I removed that bit. This morning, inspired by the advanced crosshair resource, I decided to ad some further changes. I added script callbacks to the crosshair, so that it would tell me when I move the crosshair onto or off an object.
Now, the engine compiled fine, but upon running it in debug mode, I got an unhandled exception in some odd file that I'd never heard of and that was completely incomprehensible to me. I hadn't even loaded a mission yet!
So I decided to restore the backup I had made of guiCrossHairHud.cc (I'm not that stupid... ;)). I did this, built it, and ran it. Th main menu actually got to load this time, but when I loaded a mission, I got a wierd error in bitstream.cc caused by the Ork model!
Now, I know that the resources are great, and they pretty much work as expected. But why, when I make similar changes, does everything come crashing down? (Or in this case, why does something completely unrelated to my work, that I've never seen before in my life, come crashing down?)
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
07/20/2007 (7:17 am)
Thanks for the link ;). 
#3
07/20/2007 (7:26 am)
Also, make sure you do a clean rebuild when you recomplie your changes. Everything in programs are usually linked somewhere, so a change you make in *A* could affect *B* causing all sorts of havoc. Doing a clean forces compiler re-linking and object compilation so you don't get those weird, nasty errors.
#4
This is information that you would receive from the call stack while debugging your application, and is very important in finding out what happened during any crash.
07/20/2007 (8:07 am)
Finally, it's very important to learn how to use your IDE (Visual Studio most probably) to debug crashes. While you think the crash is totally unrelated to your work, what you will most probably find is that the crash occurs in code that was called by something you did, and you sent it invalid parameters or values that is causing the lower level code to not work as expected.This is information that you would receive from the call stack while debugging your application, and is very important in finding out what happened during any crash.
#5
07/20/2007 (8:14 am)
Also, the value of working with a Revision Control System such as Subversion cannot be overstated, even if it's just a one-person project. revision control is invaluable for going back to a known [working] state of your project.
#6
Stephen: I get the basics, but a lot of Torque's inner workings are pretty incomprehensible to me anyway - it was by browsing through the call stack that I tracked the latter problem to the player model, but I don't know anything more specific.
Orion: That sounds like a good idea :P. I'm actually going to start using this now that I'm starting to work on the engine code that will be final - up until now I;ve been messing around to see how things wok, and broken umpteen copies of the engine.
07/20/2007 (8:31 am)
Jason: Thanks for the tip. For this specific problem, I tried that, but no dice.Stephen: I get the basics, but a lot of Torque's inner workings are pretty incomprehensible to me anyway - it was by browsing through the call stack that I tracked the latter problem to the player model, but I don't know anything more specific.
Orion: That sounds like a good idea :P. I'm actually going to start using this now that I'm starting to work on the engine code that will be final - up until now I;ve been messing around to see how things wok, and broken umpteen copies of the engine.
#7
07/20/2007 (8:45 am)
Plus, I would *highly* recommend learning C++ and learning it well so that you can follow the source since you are making source-level changes to the engine. It is horribly easy to break *any* source code if you do not have a proper background in the language that it is written in. 
#8
It's been a Godsend to me even thought I'm the only one doing programming. It lets me get a little wild with actually trying stuff. Doesn't work, revert :)
07/20/2007 (9:23 am)
Throw a big "amen" to Orion on using SVN, CVS, Source Safe, whatever it may be.It's been a Godsend to me even thought I'm the only one doing programming. It lets me get a little wild with actually trying stuff. Doesn't work, revert :)
#9
I've downloaded Subversion and the book about it, but I have one question: does it take up a huge amount of hard disc space? The computer I'm uing is kind of lacking in the memory department.
Joseph: I got winmerge - looks like a great little program. But for guiCrossHairHud, my file is identical to an unchanged one. The only other file I modded was player.cc - I applied a simple resource. I have the resource working on another version of Torque, which I checked, and my changes there are the same. No other code was touched, and it's throwing this wierd error.
On the subject of this error, with closer examination of the call stack, the problem is in the preloading of Kork's animations. It starts in TSShapeConstructor::packData, when a call is made to stream->writeString(mSequence[i]);. It stops at i = 29, which means the thread is player_looknw.dsq. writeString seems to work, but the window showing variables, pointers, etc., it saying that stringBuffer is a bad pointer.
It goes on through a few other methods, before writeBits asserts a fatal - "Out of range write".
See, what I really don't understand is why this suddenly happens now, after tinkering with something totally unrelated, then restoring the code to normal.
07/20/2007 (12:16 pm)
David: I can program fluently in Java, and I do understand a lot of C++. The problem is that Torque is so hugely complex that 99% of the stuff it does is a mystery to me. The modifications I made to guiCrossHairHud were just handling one pointer and a few if statements - nothing too complicated :P.I've downloaded Subversion and the book about it, but I have one question: does it take up a huge amount of hard disc space? The computer I'm uing is kind of lacking in the memory department.
Joseph: I got winmerge - looks like a great little program. But for guiCrossHairHud, my file is identical to an unchanged one. The only other file I modded was player.cc - I applied a simple resource. I have the resource working on another version of Torque, which I checked, and my changes there are the same. No other code was touched, and it's throwing this wierd error.
On the subject of this error, with closer examination of the call stack, the problem is in the preloading of Kork's animations. It starts in TSShapeConstructor::packData, when a call is made to stream->writeString(mSequence[i]);. It stops at i = 29, which means the thread is player_looknw.dsq. writeString seems to work, but the window showing variables, pointers, etc., it saying that stringBuffer is a bad pointer.
It goes on through a few other methods, before writeBits asserts a fatal - "Out of range write".
See, what I really don't understand is why this suddenly happens now, after tinkering with something totally unrelated, then restoring the code to normal.
#10
Alternatively, you could just keep track of your changes (the old fashion way) which would also help you understand the code base better. That way you comment a ton, and always keep your original work back-up (naming them .bac or something like that) files as you make changes. This is really all svn or cvs servers do anyway, but in this case you are more proactive on whats going on until you get a better handle on the code.
As far as your dilemma on your source changes, most of the the stuff presented already can be at fault, those suggestions along with going over all the code again to see what areas *might* have gotten modified inadvertently. Winmerge is great for that too, as it will show you exactly which files are modified throughout an entire project (not just what you may think has changed) and you can closely examine them. Very often it's something very simple and slight that can cause errors (ie a comma changed to a period).
Sadly without your code base in front of them, it would be very tough for someone to just diagnose an error.
07/20/2007 (12:37 pm)
Subversion really doesn't take up anymore space then the amount of the original source + any revisions made. So small source code changes stay small. If you're doing a good deal of art changes you can fairly quickly eat up space though, while you go from revision to revision. Also, if you delete files (or the whole project) those count as revisions, so those can add up quickly as well.Alternatively, you could just keep track of your changes (the old fashion way) which would also help you understand the code base better. That way you comment a ton, and always keep your original work back-up (naming them .bac or something like that) files as you make changes. This is really all svn or cvs servers do anyway, but in this case you are more proactive on whats going on until you get a better handle on the code.
As far as your dilemma on your source changes, most of the the stuff presented already can be at fault, those suggestions along with going over all the code again to see what areas *might* have gotten modified inadvertently. Winmerge is great for that too, as it will show you exactly which files are modified throughout an entire project (not just what you may think has changed) and you can closely examine them. Very often it's something very simple and slight that can cause errors (ie a comma changed to a period).
Sadly without your code base in front of them, it would be very tough for someone to just diagnose an error.
#11
07/20/2007 (12:56 pm)
Quote:Sadly without your code base in front of them, it would be very tough for someone to just diagnose an error.I know, and I wasn't expecting that result from this thread - I was just trying to make the point that I seem to be playing with stones in a glass house, and wondering if it's just me.
Quote:Subversion really doesn't take up anymore space then the amount of the original source + any revisions made. So small source code changes stay small. If you're doing a good deal of art changes you can fairly quickly eat up space though, while you go from revision to revision. Also, if you delete files (or the whole project) those count as revisions, so those can add up quickly as well.Good to know, though I'll probably only use it for source code, not art assets.
Quote:Alternatively, you could just keep track of your changes (the old fashion way) which would also help you understand the code base better. That way you comment a ton, and always keep your original work back-up (naming them .bac or something like that) files as you make changes.Tht's what I currently do - any files I modify have a backup saved, and then when I verify that the changes worked, I get rid of the backup. In addition, I mostly just comment out code instead of deleting it, and leave tags enclosing the areas I modified. That way it's pretty simple to manually change things back. It just didn't work in this case :P.
#12
07/20/2007 (1:15 pm)
As an experienced Java developer, I'd recommend sitting down and getting the core C++ language down. You'll be annoyed at some of the major differences between the languages since Java is much tidier. But it will help you very much, especially in debugging. The engine source is *HUGE* as well. I don't see TGE so much as rattling stones around a glass house as wandering through a house of mirrors. There are so many things that are integrated into each other (work on the physics layer for example, like the ODE implementation to see some of the intricate hooks) and that is the most difficult part to grok.
#13
folks's comments about knowing C++ are true,
but what's more important IMO is being familiar with programming in general. the concepts are basically the same, it's just the syntax that differs.
07/20/2007 (1:51 pm)
Quote:I seem to be playing with stones in a glass house, and wondering if it's just me.i felt similarly in my first couple months with the engine. there's definitely a learning curve, but if you keep at it things will make sense and break less. ;)
folks's comments about knowing C++ are true,
but what's more important IMO is being familiar with programming in general. the concepts are basically the same, it's just the syntax that differs.
#14
Well, I'm off to reinstall the SDK (I should keep track of how many times I've done that :P) and figure out how to use Subversion.
07/20/2007 (11:48 pm)
Quote:i felt similarly in my first couple months with the engine. there's definitely a learning curve, but if you keep at it things will make sense and break less. ;)Well, that's good to know. I've heard that Torque has a hard learning curve, but I thought I was past it. Guess not...
Well, I'm off to reinstall the SDK (I should keep track of how many times I've done that :P) and figure out how to use Subversion.
#15
07/25/2007 (8:44 am)
Our SVN proved to be VERY usefull in cases like this. I've had to do a rollback a lot of times. Mainly because i'm stripping down half the engine, leaving nothing left then what we actually use.. and then rewrite that to scriptless c++ 
#16
You might find this helpful Daniel: Step by step source control setup
Shows you how to install Apache, Subversion, and TortoiseSVN. If you are serious about keeping track of your changes and being able to revert, this is the system for you. Good luck
07/25/2007 (8:50 am)
Quote:
...and figure out how to use Subversion.
You might find this helpful Daniel: Step by step source control setup
Shows you how to install Apache, Subversion, and TortoiseSVN. If you are serious about keeping track of your changes and being able to revert, this is the system for you. Good luck
#17
EDIT: Whoops, I got confused as to which thread this is. If you look at the engine forum, I have one baout my recent attempts to use SVN. I stuck the 'engine' folder in a repository, but when I checked it out (after deleting the original folder) and tried to build the engine, I got something like 35,000 errors and 1400 warnings.
07/26/2007 (12:13 am)
Hah, now why didn't the search find that? Ah, well - thank very much for the link. After looking over it, I don't know how much of it will apply to me. I won't be using my own server, since I'm developing alone (well, on the coding side of things - I'm working with a few artists). But I'll give it another go. This time I might include the VS2005 folder in the repository as well, and see what difference that makes.EDIT: Whoops, I got confused as to which thread this is. If you look at the engine forum, I have one baout my recent attempts to use SVN. I stuck the 'engine' folder in a repository, but when I checked it out (after deleting the original folder) and tried to build the engine, I got something like 35,000 errors and 1400 warnings.
#18
a clean copy of the engine compiles.
you should put into revision control anything you anticipate changing,
which is pretty much the entirety of anything you download from GG.
you'll need more than just the 'engine' folder.
anything else, like VS setup stuff, should probably not be checked in,
because if you find yourself modifying it you've probably taken a wrong turn.
it's true that setting this stuff up is time-consuming and may seem like
an inexorbitant amount of overhead, but if you're working on a largish project
it's pretty much essential.
edit ps i dunno if you're also concerned about system failure, but if you are then dreamhost provides SVN hosting as part of their standard $8/month web hosting.
07/26/2007 (12:41 am)
Daniel -a clean copy of the engine compiles.
you should put into revision control anything you anticipate changing,
which is pretty much the entirety of anything you download from GG.
you'll need more than just the 'engine' folder.
anything else, like VS setup stuff, should probably not be checked in,
because if you find yourself modifying it you've probably taken a wrong turn.
it's true that setting this stuff up is time-consuming and may seem like
an inexorbitant amount of overhead, but if you're working on a largish project
it's pretty much essential.
edit ps i dunno if you're also concerned about system failure, but if you are then dreamhost provides SVN hosting as part of their standard $8/month web hosting.
#19
07/27/2007 (5:08 am)
Orion: Well, I only checked in the engine folder because that was all I anticipated modifying - for now at least. Thanks for the tip about dreamhost - I don't think I'll bother for this project, though. Anyway, it's good to know about that option. 
Torque Owner Redacted