Seperation between engine and demo app?
by Andrew McDonald · in Torque Game Engine · 05/10/2005 (4:26 pm) · 3 replies
Hello all, just got the SDK and started poking through it. I'm having trouble finding the seperation point between engine layer and project-specific code though: for instance the DemoGame C++ class for the demo app is in the game directory with lots of other stuff that doesn't appear to be related to the demo program. Am I supposed to remove the DemoGame class and implement my own subclass of GameInterface? A DemoGame singleton is actually instantiated in main.cc, though it's wrapped by a macro guard (BUILD_TOOLS).
Also, how are the VC projects structured? There are 'Torque Demo' and 'Torque Lib' projects. However the lib project also includes the demo-app-specific files! It just seems to arbitrarily miss out certain files from the executable project - but they seem like reasonable things to have in the lib, at least at a glance (e.g. winGLSpecial.cc). The executable project also has .cc specified as the default filter for a number of folders which the library project doesn't, which makes the diff a bit messier.
Can anyone help point out the structure of these things? I'm using VC2003, but have 6 on hand as well if needed.
Ta,
Andrew
Also, how are the VC projects structured? There are 'Torque Demo' and 'Torque Lib' projects. However the lib project also includes the demo-app-specific files! It just seems to arbitrarily miss out certain files from the executable project - but they seem like reasonable things to have in the lib, at least at a glance (e.g. winGLSpecial.cc). The executable project also has .cc specified as the default filter for a number of folders which the library project doesn't, which makes the diff a bit messier.
Can anyone help point out the structure of these things? I'm using VC2003, but have 6 on hand as well if needed.
Ta,
Andrew
About the author
#2
05/18/2005 (1:24 pm)
Thanks for the info. How do CVS updates work if we're expected to start altering the 'Torque Demo' project itself though? Do we just have to merge each time and work it through if someone's introduced a conflicting change?
#3
You will find that collision between what you've implemented and what has been changed in a new update will be pretty low, as new releases are primarily new functionality, bug fixes, or the very occasional refactoring, while your changes will most probably be outside of the areas that will be modified by an update. Of course, if you are making major modifications to low level code instead of inheriting major classes and re-implementing, then yes, you'll have some merge and deconfliction work to do.
Historically, it hasn't been much of an issue for the average torque user.
05/18/2005 (1:46 pm)
TGE is no longer managed through CVS, so the question actually doesn't apply directly. TGE updates are released on a semi-quarterly basis, and most of the time you will simply diff the newest version against your modifications, and merge as appropriate.You will find that collision between what you've implemented and what has been changed in a new update will be pretty low, as new releases are primarily new functionality, bug fixes, or the very occasional refactoring, while your changes will most probably be outside of the areas that will be modified by an update. Of course, if you are making major modifications to low level code instead of inheriting major classes and re-implementing, then yes, you'll have some merge and deconfliction work to do.
Historically, it hasn't been much of an issue for the average torque user.
Associate Kyle Carter
Torque Demo is the place to start building your game. It isn't so much a demo as a reference game implementation. You're probably going to want to build off of it rather than trying to start from scratch at the very base level.