Torque 3D 3.6.1 preview build testing
by Daniel Buckmaster · in Torque 3D Professional · 10/03/2014 (9:48 pm) · 56 replies
Updated 13:00 7/10/2014 AEST
Hey everyone,
As you might have noticed, we think 3.6 is pretty much ready to go. However, we've had some trouble with our build-and-deploy process, so we'd really appreciate having some brave testers help out to check our binaries.
You can download the Full template with binaries here (140MB), or just binaries with a unit-testing script here (22MB). Note that the unit test script will just produce a momentary console window - unless you run it from the console you won't see anything happen. If you choose to download one of them, what we'd like is for you to test one or two runs with the different binaries included. There are two binaries:
The most common crash report we've had is trying the Outpost mission with the 64-bit binary in Windows 8 - but the issue should now be fixed. If you can give us that combination we'd appreciate it.
With love,
your Steering Committee
Hey everyone,
As you might have noticed, we think 3.6 is pretty much ready to go. However, we've had some trouble with our build-and-deploy process, so we'd really appreciate having some brave testers help out to check our binaries.
You can download the Full template with binaries here (140MB), or just binaries with a unit-testing script here (22MB). Note that the unit test script will just produce a momentary console window - unless you run it from the console you won't see anything happen. If you choose to download one of them, what we'd like is for you to test one or two runs with the different binaries included. There are two binaries:
- Torque 3D CMake.exe is a 32-bit executable compiled with CMake, so it's all-in-one (no separate DLL).
- Torque 3D CMake x64.exe is a 64-bit executable also compiled with CMake all-in-one.
The most common crash report we've had is trying the Outpost mission with the 64-bit binary in Windows 8 - but the issue should now be fixed. If you can give us that combination we'd appreciate it.
With love,
your Steering Committee
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#42
10/08/2014 (2:13 am)
No, sorry man. Only some minor warnings like: "Cannot re-declare object" and "bounds exceed that of shape" but that shouldn't do it. And there's "Failed to create resource: [tools/levels/BlankRoom.mis.decals]" but don't think to crash for... :(
#43
10/08/2014 (2:04 pm)
Weird. Do you work from the development branch? I assume the engine works when you compile it yourself? 
#44
10/08/2014 (2:09 pm)
I had added 2012 solution generation scripts to project generation a while back and I plan to add 2013 scripts shortly - if anyone is interested.... 
#45
I'm not sure what's going on, but x86 builds seem to be close to the same as before. I would have expected gains, not losses, with x64 builds though so that's why I'm reporting. The funny thing is, the very first binary you posted for testing was outright great performance in x64. I noticed an increase in performance on that very first x64 binary you posted up. Since then, it's gone and worsened.
Edit: Just noticed you updated dev branch a day ago. Last one I tried out was a couple days ago, as I've been very busy. I'm compiling the newest push as I type so I'll let you know if I'm still seeing the performance issues.
Edit2: Yep, definitely something amiss. It's like I'm not even using the same engine with an x64 build. Total performance hit on Windows 8.1. I'll run it on the Win7 machine and see if there's any difference.
Edit3: Not quite as noticeable on Win7 machine, but still seems to be a hit. Both 64 bit OS of course. I understand that the Outpost level turns on all the effects and what-not, but it wasn't performing anywhere close to that slowly in that first binary that was uploaded. I wish I knew a bit more about the changes made between then and now, but unfortunately I can't help too much without the experience with the inner workings of the rendering source. Anyways, a heads up to take a look at the most recent changes. I've gone from seeing an absolute performance gain in that first binary to an absolute performance hit currently.
10/08/2014 (2:47 pm)
@Richard: Could be useful so people don't have to use CMake. If they don't want to use another program to generate. At least as long as we still have the Project Generator. Quote:I assume the engine works when you compile it yourself?I've been updating my build here as the changes roll in on the dev branch and I have to be honest, I'm noticing performance losses with the latest builds. On Windows 8.1 x64 builds. Launching the new Outpost level on the x64 builds I'm seeing like 20-40fps. On Empty Terrain, losing about 40-50fps compared to where I was at prior to the most recent updates (within about the past week).
I'm not sure what's going on, but x86 builds seem to be close to the same as before. I would have expected gains, not losses, with x64 builds though so that's why I'm reporting. The funny thing is, the very first binary you posted for testing was outright great performance in x64. I noticed an increase in performance on that very first x64 binary you posted up. Since then, it's gone and worsened.
Edit: Just noticed you updated dev branch a day ago. Last one I tried out was a couple days ago, as I've been very busy. I'm compiling the newest push as I type so I'll let you know if I'm still seeing the performance issues.
Edit2: Yep, definitely something amiss. It's like I'm not even using the same engine with an x64 build. Total performance hit on Windows 8.1. I'll run it on the Win7 machine and see if there's any difference.
Edit3: Not quite as noticeable on Win7 machine, but still seems to be a hit. Both 64 bit OS of course. I understand that the Outpost level turns on all the effects and what-not, but it wasn't performing anywhere close to that slowly in that first binary that was uploaded. I wish I knew a bit more about the changes made between then and now, but unfortunately I can't help too much without the experience with the inner workings of the rendering source. Anyways, a heads up to take a look at the most recent changes. I've gone from seeing an absolute performance gain in that first binary to an absolute performance hit currently.
#46
10/08/2014 (4:03 pm)
Hmm. I'll see if I can reproduce this when I have time. If you want to help out before then, could you run the profiler using the before and after executables? I think the shortcut is Ctrl+F3 to generate a profile report in a file next to the engine executable.
#47
I can at least compare those two, but the one I have a backup of was prior to the x64 builds being released at all so I'd only be able to compare x86 builds. I remember specifically noticing, in that very first binary that you uploaded, that the performance was better with the x64 build. I was pretty excited, and had high hopes for the upcoming x64 release. Something has changed since then I think. Anyways yeah, I'll run the profiler on the build I have prior to this thread and the current(also as soon as I get a chance, been super busy).
Edit: You don't happen to still have a copy of that first binary you uploaded do you Danny? The one you posted initially when you started this thread. If you click that link in your first post(the word 'noticed'), that's the build I know was fantastic. 3.6.1 #808, 334 commits into master from development (6 days ago). Well, it had its own problems but I'm almost positive it wasn't suffering from this issue.
10/08/2014 (4:20 pm)
Of course I want to help! Gosh man, you have been walking me through some of the most crucial knowledge around the source I've ever been introduced to! I don't have the original binary you had uploaded anymore though. I do have the build of T3D backed up that I was using right before you started this thread. Atm, that is the best performing build for me. If I use 3.5.1, it's not quite as good as that one. If I use the current one, it's worse. I can at least compare those two, but the one I have a backup of was prior to the x64 builds being released at all so I'd only be able to compare x86 builds. I remember specifically noticing, in that very first binary that you uploaded, that the performance was better with the x64 build. I was pretty excited, and had high hopes for the upcoming x64 release. Something has changed since then I think. Anyways yeah, I'll run the profiler on the build I have prior to this thread and the current(also as soon as I get a chance, been super busy).
Edit: You don't happen to still have a copy of that first binary you uploaded do you Danny? The one you posted initially when you started this thread. If you click that link in your first post(the word 'noticed'), that's the build I know was fantastic. 3.6.1 #808, 334 commits into master from development (6 days ago). Well, it had its own problems but I'm almost positive it wasn't suffering from this issue.
#48
No, I'm just talking about the full template with binaries from the link you posted. Didn't had the chance to work with CMake yet. I assumed that the full template should just run like that.
Hope to find the time, will try some more!
10/08/2014 (9:11 pm)
Quote:Weird. Do you work from the development branch? I assume the engine works when you compile it yourself?
No, I'm just talking about the full template with binaries from the link you posted. Didn't had the chance to work with CMake yet. I assumed that the full template should just run like that.
Hope to find the time, will try some more!
#49
10/09/2014 (9:00 pm)
Sorry, just have gotten back here about those slowdowns. I never did get to run the profiler for comparisons, mainly because the basis of comparison I had wasn't an x64 build. The x86 seemed unaffected, and the official release seems to be alright. Outpost runs slowly, but I think that's kinda what it's designed to do. If it's not, I'll run the profiler on that and send it to you Danny. Otherwise, I'm considering it solid.
#50
The engine runs fine when I compile my self! :)
The only note I have is that the DAE to DTS conversion is taking such a long time that it might be the cause of the crash in the builds your provided. Not certain yet though, cos there are no errors to refer to.
Next time I read a bit more before I respond; thought I had to use CMake but apparently is almost like the good-old-method :) Thanks for all the hard work, good job!
10/09/2014 (9:11 pm)
Quote:I assume the engine works when you compile it yourself?
The engine runs fine when I compile my self! :)
The only note I have is that the DAE to DTS conversion is taking such a long time that it might be the cause of the crash in the builds your provided. Not certain yet though, cos there are no errors to refer to.
Next time I read a bit more before I respond; thought I had to use CMake but apparently is almost like the good-old-method :) Thanks for all the hard work, good job!
#51
Jesse, Outpost is definitely supposed to be a bit slower. Glad it seems okay now, but I'll definitely do some comparative testing at some point.
10/10/2014 (3:51 pm)
Hmm yeah, the engine always does get a bit twitchy when going through that DAE compiling stage. That's why we precompiled the DTSs for the Full template download :P. Hey, when you ran the downloaded binaries, did you have any zip files next to the executable?Jesse, Outpost is definitely supposed to be a bit slower. Glad it seems okay now, but I'll definitely do some comparative testing at some point.
#52
Thank you
10/11/2014 (4:51 pm)
Do you have to recompile the FPS Template to run the map editor on it??? Because it wont' work when i hit editor on the from end menu.Thank you
#53
10/11/2014 (5:12 pm)
Did you download the Full template binary? What happens when you click the editor button?
#54
Thanks
10/12/2014 (10:02 am)
Yes i did only download the full binary. I place the 64bit on the FPS Template folder call it and it open the from end menu I can access the Options run the game but not the world editor. Dont get any error msg the all by the way. My PC cfg is qua Xeon dual Nvidia Video Card 64mb of mem w solid state drivers on Windows 8. Thanks
#55
I found the source of the slowdowns; I should have caught it sooner :P It's just since I was doing testing on a debug build as opposed to the binaries you had originally released(which surely would have been release). So yea, man, the latest build runs faster than a scalded dog! Sorry I overlooked that before.
I'm getting 400+ fps on Empty Terrain mission with the x64 Release build!
I'm not entirely sure what this suggests about my initial comparison tests with OMNI...but the facts are I'm getting the same performance right here with T3D 3.6.1 master.
10/13/2014 (3:08 pm)
Quote:Jesse, Outpost is definitely supposed to be a bit slower. Glad it seems okay now, but I'll definitely do some comparative testing at some point.
I found the source of the slowdowns; I should have caught it sooner :P It's just since I was doing testing on a debug build as opposed to the binaries you had originally released(which surely would have been release). So yea, man, the latest build runs faster than a scalded dog! Sorry I overlooked that before.
I'm getting 400+ fps on Empty Terrain mission with the x64 Release build!
I'm not entirely sure what this suggests about my initial comparison tests with OMNI...but the facts are I'm getting the same performance right here with T3D 3.6.1 master.
#56
Ramon, could you put the contents of console.log into a pastebin or somewhere we can see them? I'm not sure what could be going on. Can you access the editor by opening a level normally then pressing F11?
10/13/2014 (3:23 pm)
Awesome to hear, Jesse :).Ramon, could you put the contents of console.log into a pastebin or somewhere we can see them? I'm not sure what could be going on. Can you access the editor by opening a level normally then pressing F11?
Torque Owner Daniel Buckmaster
T3D Steering Committee