TGE 1.5.1 Released
by asmaloney (Andy) · in Torque Game Engine · 04/05/2007 (4:00 pm) · 52 replies
TGE 1.5.1 Release Notes
- allows use of DIFs created by Torque Constructor
- integrate fixes and changes from TGB 1.1.3
-- changes to StringBuffer class
-- changes for better UNICODE support
-- improvements to the font class
-- Mac console improvements
- merge in the majority of the Optimization Kit resource
-- rendering optimizations for texture fog
-- some Altivec improvements for terrain blending on PPC Macs
-- batch rendering of precipitation, splashes, and decals
-- eliminate a lot of object copying throughout the codebase
-- change constant doubles into constant floats to improve gcc PPC code
- Intel Macs now use the asm terrain blender
- added a couple of asm routines to Intel Mac build
- some code cleanup
-- removed/deprecated files
--- dgl/gNewFont becomes dgl/gFont
--- sceneGraph/lightManager.[h,cc] are deprecated in favour of lightingSystem/sgLightManager.[h,cc]
-- remove TORQUE_UNICODE from torqueConfig.h
-- const-ified member functions and arguments in many places
-- added a few asserts to catch problems in debugging
- added levels of detail to the interiors on the Stronghold mission in starter.fps
- added a barebones mission that is just a terrain, a path for the AI, and an interior which includes a static mesh
- bugs fixed:
-- integrate changes for ExtrudedPolyList resource to fix some collision issues
-- AudioEmitter looping
-- Two bugs in BitRender.cc
--- shadows are not drawn correctly for meshes containing triangle list primitives
--- runtime check failure
-- possible fix for fxShapeReplicator hard lock on Windows
-- fix for particle stream jumping around
-- TelnetDebugger fixes and additions
--- added file load updates
--- fixed crash on breakpoint in invalid codeblock
-- fix NetEvent ref count problem
-- fix cursor issues when saving the play gui
-- other miscellaneous bug fixes
We wanted you to be able to work with Torque Constructor interiors right away. There are a couple of known issues with Constructor integration which will be addressed in a future update.
Known Issues With Constructor Integration
- lighting of static meshes
-- static meshes only support static lighting
-- flipped objects (both brushes and static meshes) produce odd shading
Other Known Issues
- lighting the cottage in starter.fps using a debug build fails with an assert
-- workaround is to comment out the assert in lightingSystem/sgLightMap.cc line 554 for now - it is an issue with the DIF itself
- tools/fonttool/fonttool.cc includes dgl/gNewFont.h which no longer exists
-- fix: change include to dgl/gFont.h
- allows use of DIFs created by Torque Constructor
- integrate fixes and changes from TGB 1.1.3
-- changes to StringBuffer class
-- changes for better UNICODE support
-- improvements to the font class
-- Mac console improvements
- merge in the majority of the Optimization Kit resource
-- rendering optimizations for texture fog
-- some Altivec improvements for terrain blending on PPC Macs
-- batch rendering of precipitation, splashes, and decals
-- eliminate a lot of object copying throughout the codebase
-- change constant doubles into constant floats to improve gcc PPC code
- Intel Macs now use the asm terrain blender
- added a couple of asm routines to Intel Mac build
- some code cleanup
-- removed/deprecated files
--- dgl/gNewFont becomes dgl/gFont
--- sceneGraph/lightManager.[h,cc] are deprecated in favour of lightingSystem/sgLightManager.[h,cc]
-- remove TORQUE_UNICODE from torqueConfig.h
-- const-ified member functions and arguments in many places
-- added a few asserts to catch problems in debugging
- added levels of detail to the interiors on the Stronghold mission in starter.fps
- added a barebones mission that is just a terrain, a path for the AI, and an interior which includes a static mesh
- bugs fixed:
-- integrate changes for ExtrudedPolyList resource to fix some collision issues
-- AudioEmitter looping
-- Two bugs in BitRender.cc
--- shadows are not drawn correctly for meshes containing triangle list primitives
--- runtime check failure
-- possible fix for fxShapeReplicator hard lock on Windows
-- fix for particle stream jumping around
-- TelnetDebugger fixes and additions
--- added file load updates
--- fixed crash on breakpoint in invalid codeblock
-- fix NetEvent ref count problem
-- fix cursor issues when saving the play gui
-- other miscellaneous bug fixes
We wanted you to be able to work with Torque Constructor interiors right away. There are a couple of known issues with Constructor integration which will be addressed in a future update.
Known Issues With Constructor Integration
- lighting of static meshes
-- static meshes only support static lighting
-- flipped objects (both brushes and static meshes) produce odd shading
Other Known Issues
- lighting the cottage in starter.fps using a debug build fails with an assert
-- workaround is to comment out the assert in lightingSystem/sgLightMap.cc line 554 for now - it is an issue with the DIF itself
- tools/fonttool/fonttool.cc includes dgl/gNewFont.h which no longer exists
-- fix: change include to dgl/gFont.h
#22
I'm definitely seeing decreased framerates. I'm going to try undoing the optimization kit part (or since it's faster on Mac, at least putting in and ifdef for it). Also - the fog changes seemed to have changed for the worse, things don't look the same. I've emailed in some comparitive shots, hopefully they can figure out what went wrong.
04/06/2007 (7:50 am)
@Michael -I'm definitely seeing decreased framerates. I'm going to try undoing the optimization kit part (or since it's faster on Mac, at least putting in and ifdef for it). Also - the fog changes seemed to have changed for the worse, things don't look the same. I've emailed in some comparitive shots, hopefully they can figure out what went wrong.
#23
Yeah, my first run through just using Fraps and TGE's in game FPS gauge are showing decreased frame rates. They aren't too bad, but if the drop exponentially increases with more objects and FX, I'll probably end up doing the same.
My patching will be geared toward the AFX integration, though.
04/06/2007 (8:01 am)
@Jaimi -Yeah, my first run through just using Fraps and TGE's in game FPS gauge are showing decreased frame rates. They aren't too bad, but if the drop exponentially increases with more objects and FX, I'll probably end up doing the same.
My patching will be geared toward the AFX integration, though.
#24
Thanks.
04/06/2007 (8:02 am)
Humm for some reasion I do not get that update download in my profile. Is it just the ones who just got TGE?Thanks.
#25
My frame rate skyrocketed in the GUI sections, like the MainMenu and Options. From 300-400 fps, to 500-600 fps.
In game, without the glFinish mod, I never got past 48 fps. With the fix, I was getting as high as 60 or 70 on multiple renders.
If my testing keeps going in this fashion, I might end up leaving the Opt Kit stuff in unless I see some major slow downs during stress tests.
*EDIT*-All in all I'm happy with the list of improvements and bug fixes. Allow me to show my inner maturity and say GG April updates FTW! =)
04/06/2007 (8:09 am)
I know my results are probably preliminary and require more testing, but I just implemented the glFinish() fix from other threads, found in guiCanvas.cc.My frame rate skyrocketed in the GUI sections, like the MainMenu and Options. From 300-400 fps, to 500-600 fps.
In game, without the glFinish mod, I never got past 48 fps. With the fix, I was getting as high as 60 or 70 on multiple renders.
If my testing keeps going in this fashion, I might end up leaving the Opt Kit stuff in unless I see some major slow downs during stress tests.
*EDIT*-All in all I'm happy with the list of improvements and bug fixes. Allow me to show my inner maturity and say GG April updates FTW! =)
#26
EDIT: Sorry its my fault. Apparently during the merge a bracket disappeared?
04/06/2007 (9:30 am)
EDIT: Sorry its my fault. Apparently during the merge a bracket disappeared?
#27
Can you describe the performance hit you're seeing, your system specs, if both exes are built using the same dev env and run against the same missions/assets (both in the same directory), and the mission.
For anyone running missions with dynamic point lights or static point lights set to affect dts objects, there's a new feature in this drop that could affect performance:
Dynamic Lighting Occlusion
This new feature allows obstructions to block dynamic lighting to dts objects (from both dynamic lights and static lights set to affect dts objects). These are not crisp, defined shadows, but the occlusion does cause objects to look shadowed, as other objects obstruct lighting to the object.
This feature requires los testing between the object and any lights that affect it, this can be processing intensive, so the following rules are applied to minimize the impact:
-Only objects that cast static shadows can be occluders (TSStatics, ScopeAlwaysShapes, Interiors, and the terrain).
-Occlusion data is cached until either the light or the receiving object move.
-Static objects can disable lighting occlusion using the mission editor Advanced Lighting option 'useLightingOcclusion'.
-Occlusion quality can be adjusted per client using the pref '$pref::LightManager::sgDynamicLightingOcclusionQuality' and setting it to one of the following:
0 = high quality (full sample)
1 = medium quality (quad sample)
2 = low quality (single sample)
3 = no occlusion
04/06/2007 (10:46 am)
Hey guys,Can you describe the performance hit you're seeing, your system specs, if both exes are built using the same dev env and run against the same missions/assets (both in the same directory), and the mission.
For anyone running missions with dynamic point lights or static point lights set to affect dts objects, there's a new feature in this drop that could affect performance:
Dynamic Lighting Occlusion
This new feature allows obstructions to block dynamic lighting to dts objects (from both dynamic lights and static lights set to affect dts objects). These are not crisp, defined shadows, but the occlusion does cause objects to look shadowed, as other objects obstruct lighting to the object.
This feature requires los testing between the object and any lights that affect it, this can be processing intensive, so the following rules are applied to minimize the impact:
-Only objects that cast static shadows can be occluders (TSStatics, ScopeAlwaysShapes, Interiors, and the terrain).
-Occlusion data is cached until either the light or the receiving object move.
-Static objects can disable lighting occlusion using the mission editor Advanced Lighting option 'useLightingOcclusion'.
-Occlusion quality can be adjusted per client using the pref '$pref::LightManager::sgDynamicLightingOcclusionQuality' and setting it to one of the following:
0 = high quality (full sample)
1 = medium quality (quad sample)
2 = low quality (single sample)
3 = no occlusion
#28
Pentium IV 2.6 GHz
2 GB RAM
ATI Radeon 9550/X1050 Series 256 MB
Both were built in release, using the VS2K5 solution with no modifications or optimizations turned on. I ran the starter.fps.bat. I played through the Stronghold mission in fullscreen mode (1280x1024 ), default bit depth.
1.5.1 ran about 5-10 frames slower than 1.5.0, until I put in the glFinish change mentioned earlier.
I haven't had a chance to do more thorough testing with a better profiler, and on multiple machines. Just preliminary stuff.
04/06/2007 (11:01 am)
@John - I've only been able to test on one machine so far:Pentium IV 2.6 GHz
2 GB RAM
ATI Radeon 9550/X1050 Series 256 MB
Both were built in release, using the VS2K5 solution with no modifications or optimizations turned on. I ran the starter.fps.bat. I played through the Stronghold mission in fullscreen mode (1280x1024 ), default bit depth.
1.5.1 ran about 5-10 frames slower than 1.5.0, until I put in the glFinish change mentioned earlier.
I haven't had a chance to do more thorough testing with a better profiler, and on multiple machines. Just preliminary stuff.
#29
Great point, logs from Torque's profiler would be awesome. Again running the exes out of the same example folder (just to make sure the assets, scripts, and prefs are the same - with prefs being the biggest offender).
04/06/2007 (11:13 am)
Hi Michael,Great point, logs from Torque's profiler would be awesome. Again running the exes out of the same example folder (just to make sure the assets, scripts, and prefs are the same - with prefs being the biggest offender).
#30
04/06/2007 (12:02 pm)
Michael, can you toss a link to that glFinish fix pretty please?
#32
Also if someone could provide journals so we can compare apples to apples that would be great.
04/06/2007 (12:11 pm)
FPS is not a good indicator of performance, and using the FPS indicator in fraps is an even worse indicator of performance. What would be more helpful is profiler dumps and MSPF differences.Also if someone could provide journals so we can compare apples to apples that would be great.
#33
I set $pref::LightManager::sgDynamicLightingOcclusionQuality to 3, and saw no change in speed, nor did the colors brighten up as they were before (still dark and washed out on DTS). You should have the PNG's in your mailbox, if not send a mail and let me know, they were big and could have been bounced.
@Robert -
this is happening with the default builds from 1.5.0 and 1.5.1, you can see it yourself if you turn on a framerate display and run any of the default missions. I'm in the midst of changing compilers (and it's taking forever to get vs2005 from msdn), so I can't get a profile dump right now. I will get one out as soon as I'm set back up. Still, you should be able to see it on your default distributions. (if you can't see it, that would be interesting to hear also...)
04/06/2007 (2:37 pm)
@John -I set $pref::LightManager::sgDynamicLightingOcclusionQuality to 3, and saw no change in speed, nor did the colors brighten up as they were before (still dark and washed out on DTS). You should have the PNG's in your mailbox, if not send a mail and let me know, they were big and could have been bounced.
@Robert -
this is happening with the default builds from 1.5.0 and 1.5.1, you can see it yourself if you turn on a framerate display and run any of the default missions. I'm in the midst of changing compilers (and it's taking forever to get vs2005 from msdn), so I can't get a profile dump right now. I will get one out as soon as I'm set back up. Still, you should be able to see it on your default distributions. (if you can't see it, that would be interesting to hear also...)
#34
The discoloration is odd - it looks like the fogging is somehow messed up, however I didn't think any of the DTS rendering was updated in 1.5.1. Maybe it's related to the optimization changes?
04/09/2007 (10:51 pm)
Hi Jaimi,The discoloration is odd - it looks like the fogging is somehow messed up, however I didn't think any of the DTS rendering was updated in 1.5.1. Maybe it's related to the optimization changes?
#35
04/10/2007 (5:29 pm)
John - I was suspecting the fogging optimization. Now that I've got my system set back up, I can get a chance to look at the fogging optimizations, maybe I can find something...
#36
I am converting over to 1.5.1.
I have done very extensive modification to the 1.5.0 engine.
I was wondering if there is a "patch" for 1.5.1 rather than the full installation.
If I have to install the full package for 1.5.1 then I will need to re modify the engine again with all of the changes i have made, which i can say with absolute certainty, will be a royal pain in the butt.
If there is no patch or other simple update from 1.5.0 to 1.5.1, then is there some other means of integrating the new release with my old data?
Even a list of files that have been changed in the engine will help, then ill know which files i have to remodify and which ones i can just copy back into the engine folders after the update. I could use a compare program of some sort to help merge my data into the changed files.
Is there some type of merging software out there anywhere, that can take the 2 files, old and new, and report the differences, then allow me to do a selective merge of the data?
Thanks for any assistance in this matter. I am really dreading having to go back to the beginning and start over again.
04/14/2007 (10:13 am)
HelloI am converting over to 1.5.1.
I have done very extensive modification to the 1.5.0 engine.
I was wondering if there is a "patch" for 1.5.1 rather than the full installation.
If I have to install the full package for 1.5.1 then I will need to re modify the engine again with all of the changes i have made, which i can say with absolute certainty, will be a royal pain in the butt.
If there is no patch or other simple update from 1.5.0 to 1.5.1, then is there some other means of integrating the new release with my old data?
Even a list of files that have been changed in the engine will help, then ill know which files i have to remodify and which ones i can just copy back into the engine folders after the update. I could use a compare program of some sort to help merge my data into the changed files.
Is there some type of merging software out there anywhere, that can take the 2 files, old and new, and report the differences, then allow me to do a selective merge of the data?
Thanks for any assistance in this matter. I am really dreading having to go back to the beginning and start over again.
#37
Winmerge seems to be the product I need
If there is a list of changed files for 1.5.1 available, that will still be useful.
Thanks alot!!
04/14/2007 (10:24 am)
I think i just answered my own questionWinmerge seems to be the product I need
If there is a list of changed files for 1.5.1 available, that will still be useful.
Thanks alot!!
#39
A silly question : why the Torque Constructor source code is not available ?
Philippe C
04/18/2007 (10:46 am)
@ garageGames A silly question : why the Torque Constructor source code is not available ?
Philippe C
#40
04/18/2007 (11:16 am)
Last I heard, if you want the source code you have negotiate a license fee from the creators. Makes since. They give the product away for free, might as well hold on to something for sale later =)
Employee Michael Perry
GarageGames
I'm checking it out mainly because it doesn't seem to be a definitive fix. The reason for this, from my findings, has to do with how the code for the fxReplicators gets compiled, and results can vary depending on which compiler is used. There's some crazy stuff goin' on in the replicator code, and for those of you have never drilled into it before, do so.