guiMenuBar.cc not in Torque Lib
by Tom Spilman · in Torque Game Engine · 08/14/2002 (10:29 pm) · 10 replies
guiMenuBar.cc is not included in the Torque lib build in VC++.
... also missing is guiBitmapBorderCtrl.cc and guiCrossHairHud.cc
... also missing is guiBitmapBorderCtrl.cc and guiCrossHairHud.cc
About the author
Tom is a programmer and co-owner of Sickhead Games, LLC.
#2
08/15/2002 (11:58 am)
I did that already... just reporting it as a bug. Tom 
#3
08/24/2002 (5:00 pm)
What are you using the torque lib for? ... just curious because I think there are a few files missing from that target. The only reason we have it is to link some of the tools and we don't really think of it as a "real" engine library. 
#4
08/25/2002 (8:16 am)
@Tim: i'm makin a real engine library from it :) and linked it with a WTL app... and it works i figure out some of the missing files + other things.
#5
08/25/2002 (2:01 pm)
Tim - I was trying to use it as an engine lib linked into my game. Still i ran into other troubles with doing that, so i've put that on the back burner for a while. It seemed a logical assumption to use it like that. Tom
#6
It's okay, though. I can get down on my hands and knees and furrow around in the code with the best of 'em. ;)
01/10/2003 (11:40 pm)
That's just hilarious. I found this thread by searching on "GuiMenuBar," because of linking errors when, I swear, I was trying to do the same darn thing. I'm used to SDKs that are nice, encapsulated libraries with well-defined interfaces. This is what I get for going in with both guns blazing, before double-checking my mark's address.It's okay, though. I can get down on my hands and knees and furrow around in the code with the best of 'em. ;)
#7
01/11/2003 (7:52 am)
It would be nice to have the Torque lib really be a standalone library, with a simple well defined interface :) One of our long-term goals is to re-organize the engine so that this is possible, it will be a bit of work though.
#8
I think I'm going to tell my developers to check out our codebase in a folder parallel to their Torque folder, and then use relative file paths to include all the unchanged files (and headers and libs) directly from the Torque source tree into the project, and then store only the files we've made custom modifications to in our own source tree. This has a number of advantages. One advantage, from GarageGames' perspective, would be that it naturally enforces the requirement that each programmer have her own Torque SDK license. ;)
01/11/2003 (10:20 am)
Heh, yeah, and I know you guys are pretty bogged-down, as it is. I'm pondering how best to organize my project so that merging Torque engine updates won't be an unholy nightmare. There are lots of issues that complicate this (especially since I maintain my own CVS for my project), but I think that I've muddled out how I want to handle it.I think I'm going to tell my developers to check out our codebase in a folder parallel to their Torque folder, and then use relative file paths to include all the unchanged files (and headers and libs) directly from the Torque source tree into the project, and then store only the files we've made custom modifications to in our own source tree. This has a number of advantages. One advantage, from GarageGames' perspective, would be that it naturally enforces the requirement that each programmer have her own Torque SDK license. ;)
#9
01/13/2003 (10:34 am)
You might also think about checking in the Torque into your repository as a vendor branch. Updates from GarageGames are simply checked into this branch and merged with your main development line. This has the advantage of producing a single complete CVS with a history of GarageGames updates/merges.
#10
01/13/2003 (11:51 am)
You know, I totally forgot about vendor branches. This is exactly the sort of thing they're for! Thanks for the tip. 
Torque 3D Owner Frank Bignone
Darkhand Studio