TGEA 1.7 beta porting experiences
by Stephen Zepp · in Torque Game Engine Advanced · 04/02/2008 (4:17 pm) · 3 replies
One of the remaining docs we want to polish up is a porting process from both older TGEA (1.03, etc.) code bases, as well as TGE projects.
Matt and I have spent quite a bit of time making the process as seamless as possible, but we're both very interested in any difficulties, issues, questions that required research, or related difficulties you may have had with porting your project(s) over to TGEA 1.7 beta.
Please, if you have some time, fill us in on any information related to your porting process--we would love the feedback so we can make the final release candidate porting process as smooth as possible!
Matt and I have spent quite a bit of time making the process as seamless as possible, but we're both very interested in any difficulties, issues, questions that required research, or related difficulties you may have had with porting your project(s) over to TGEA 1.7 beta.
Please, if you have some time, fill us in on any information related to your porting process--we would love the feedback so we can make the final release candidate porting process as smooth as possible!
#2
You all have done a fantastic job making it easy. Thankyou. :-)
04/02/2008 (5:27 pm)
Aside from the 2 bugs I reported, (material not rendering (having to make a material.cs file) and the opcode problem, I've had no problems porting my game to tgea 1.7 beta. It's been a quite smooth transition.You all have done a fantastic job making it easy. Thankyou. :-)
#3
will be needing to take www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=10899
the instructionset
and re-evaluate that one based on the new void ProcessedCustomMaterial::setStageData() implementation, see if much else has changed,
will need to re-implement:
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4344
based on the new sfx systems. Might even suggest that one as a semi-simplistic "extending the sfx layer 101" tute there...
definately will want to re-evaluate
www.garagegames.com/mg/forums/result.thread.php?qt=64664
based on the newest change for null gfx devices running on dedicated. Should *in theory* mean being able to apply physics et al based on texture reguardless of dedicated or non-dedicated status (wich was the only major hitch there, aside from atlas)
seemed to notice a bit of wierdness with
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=10957 and light coloration for statics vs shapebase objects(shapebases not properly being colorised), so will need to crosscheck that one later (main usage theres for alternate skin rendering effects without requiring an additional texture file on top of simply being cleaner imo)
Will be needing to re-implement vehicles with thier own ai at some point to avoid the overhead of an aiplayer on top of the vehiclular physics as well... (that one keeps getting left out. Just glad i've still got a copy of 1.4.2 laying about)
Will note that segregating GFX->func from GFX->getDrawUtil()-> while the right move is likely to break quite a few things for folks dealing with customised gfx layers, but thats a simplefix so longs it's kept in mind...
Probably a few other minor things here and there that didn't leave enough of a lasting impression to represent more than a hiccup.
All in all, mostly minor stuff really, aside from what's already been noted in the forums thusfar.
(ya did ask :P)
edit: actually, will add that despite the supposed negative results from www.garagegames.com/mg/forums/result.thread.php?qt=63305 once thats incorporated, modified a bit for higher restitutions for ridgid vs ridgis collisions, _and the integrations set several orders of magnitude higher_ (as in integration = 32; entries vs integration = 8; found in the stock codebase) that still ends up being hands down better at catching 99.9% of collisions without the lockups of the default physics setup.
On a couple positive notes, having a shader model over-rides a pure joy for folks looking at trying to support marginal hardware without having the extra computers arround. Much apreciated that, and the new editor overhauls, while admitedly still a hair twitchier in spots, are worlds simpler to read through in terms of extending em.
04/02/2008 (11:49 pm)
Lesee... *personal* checklist left to try with the secondary project tossed togeather just for upgrade eval prior to seeing about incorporating it back into the first game... (just notes for refference, by no means whining about expecting it done for us)will be needing to take www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=10899
the instructionset
In Material::setStageData(), near line 200, change:
if( baseTexFilename[i] && baseTexFilename[i][0] )
to:
if( guiTextureCanvas && baseTexFilename[i] && !dStrcmp( baseTexFilename[i], "$gui" ) )
{
stages[i].tex[GFXShaderFeatureData::BaseTex] = guiTextureCanvas->getTextureHandle();
}
else if( baseTexFilename[i] && baseTexFilename[i][0] )and re-evaluate that one based on the new void ProcessedCustomMaterial::setStageData() implementation, see if much else has changed,
will need to re-implement:
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4344
based on the new sfx systems. Might even suggest that one as a semi-simplistic "extending the sfx layer 101" tute there...
definately will want to re-evaluate
www.garagegames.com/mg/forums/result.thread.php?qt=64664
based on the newest change for null gfx devices running on dedicated. Should *in theory* mean being able to apply physics et al based on texture reguardless of dedicated or non-dedicated status (wich was the only major hitch there, aside from atlas)
seemed to notice a bit of wierdness with
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=10957 and light coloration for statics vs shapebase objects(shapebases not properly being colorised), so will need to crosscheck that one later (main usage theres for alternate skin rendering effects without requiring an additional texture file on top of simply being cleaner imo)
Will be needing to re-implement vehicles with thier own ai at some point to avoid the overhead of an aiplayer on top of the vehiclular physics as well... (that one keeps getting left out. Just glad i've still got a copy of 1.4.2 laying about)
Will note that segregating GFX->func from GFX->getDrawUtil()-> while the right move is likely to break quite a few things for folks dealing with customised gfx layers, but thats a simplefix so longs it's kept in mind...
Probably a few other minor things here and there that didn't leave enough of a lasting impression to represent more than a hiccup.
All in all, mostly minor stuff really, aside from what's already been noted in the forums thusfar.
(ya did ask :P)
edit: actually, will add that despite the supposed negative results from www.garagegames.com/mg/forums/result.thread.php?qt=63305 once thats incorporated, modified a bit for higher restitutions for ridgid vs ridgis collisions, _and the integrations set several orders of magnitude higher_ (as in integration = 32; entries vs integration = 8; found in the stock codebase) that still ends up being hands down better at catching 99.9% of collisions without the lockups of the default physics setup.
On a couple positive notes, having a shader model over-rides a pure joy for folks looking at trying to support marginal hardware without having the extra computers arround. Much apreciated that, and the new editor overhauls, while admitedly still a hair twitchier in spots, are worlds simpler to read through in terms of extending em.
Torque 3D Owner Randy Condon
Default Studio Name
Good luck.