T3D 1.2 Pro - Zoom speed issue, with fix
by Bryce · in Torque 3D Professional · 03/16/2013 (11:37 am) · 15 replies
I'm not going to bother with the whole Build/Platform/Target titling... there's just a typo in the code.
In source/T3D/gameFunctions.cpp, in function GameUpdateCameraFov(), replace the following line:
with
We're replacing the "0.f" with "0.0f". This was preventing gradual zoom from working. In other words, if you used setZoomSpeed(2000) and then changed the FOV, the change would be instantaneous, when it should have been gradual. That line of code would always return true, which would skip the incremental code and go straight to snapping the FOV in place.
To demonstrate the fix:
Go into the console and type the following lines in one by one
Look at that smooth transition! Setting the zoom speed to zero, or just leaving it alone, will give us the instant snap that we've been living with for years. Hopefully someone finds this fix useful.
In source/T3D/gameFunctions.cpp, in function GameUpdateCameraFov(), replace the following line:
if((sZoomSpeed == 0) || (delta <= 0.f))
with
if((sZoomSpeed == 0) || (delta <= 0.0f))
We're replacing the "0.f" with "0.0f". This was preventing gradual zoom from working. In other words, if you used setZoomSpeed(2000) and then changed the FOV, the change would be instantaneous, when it should have been gradual. That line of code would always return true, which would skip the incremental code and go straight to snapping the FOV in place.
To demonstrate the fix:
Go into the console and type the following lines in one by one
setZoomSpeed(2000); setFov(20);
Look at that smooth transition! Setting the zoom speed to zero, or just leaving it alone, will give us the instant snap that we've been living with for years. Hopefully someone finds this fix useful.
#2
Feel free to do the same in the future so these things don't get lost.
- Dave
03/18/2013 (8:49 am)
Submitted to the GitHub Issues section for tracking: github.com/GarageGames/Torque3D/issues/258Feel free to do the same in the future so these things don't get lost.
- Dave
#3
03/18/2013 (9:10 am)
Ah, I wasn't aware. Thanks! 
#4
03/18/2013 (12:20 pm)
Nice find, this should make sniper zooming more realistic now. 
#5
Returns:
:S
03/18/2013 (1:26 pm)
Visual Studio: Find in files: search:0.f(notice the <space>0.f)
Returns:
348 matching lines
:S
#6
03/18/2013 (1:44 pm)
Just to point out, IRC thinks that 0.f and 0.0f shouldn't make a difference, and that it could be your compiler causing an issue. (eg: VS) 
#7
03/18/2013 (1:48 pm)
I just tested this case with gcc and it makes absolutely no difference between 0.f and 0.0f. If that change made a difference I seriously think whatever compiler you're using is either broken or the machine you're running tests on is having RAM problems.#include <stdio.h>
int main(int argc, const char *argv[])
{
float fnum, fnum2;
fnum = 0.f;
fnum2 = 0.0f;
printf(
"fnum: %f\n"
"fnum2: %f\n"
"same: %s\n"
,
fnum, fnum2,
(fnum == fnum2)? "Yes":"No"
);
return 0;
}
#8
03/18/2013 (1:49 pm)
Yeah, I'm running VS 2010. Whatever it was reading was causing the line below it to always be called, in this case, the line that snaps the field of view to the target without gradually decreasing it. 
#9
I am not saying what you observed is wrong. I am just showing what I observed by doing a simple test. Please try the following code in your compiler as part of your current codebase. I put mine in a custom TS object so I could observe.
03/18/2013 (2:17 pm)
@Bryce,I am not saying what you observed is wrong. I am just showing what I observed by doing a simple test. Please try the following code in your compiler as part of your current codebase. I put mine in a custom TS object so I could observe.
#define TESTFLOATVAL1 0.f
#define TESTFLOATVAL2 0.0f
float val1, val2;
val1 = TESTFLOATVAL1;
val2 = TESTFLOATVAL2;
if(val1 == val2)
Con::printf("val1(%f) == val2(%f)",val1,val2);
else
Con::printf("val1(%f) != val2(%f)",val1,val2);
if(TESTFLOATVAL1 == TESTFLOATVAL2)
Con::printf("%f == %f",TESTFLOATVAL1,TESTFLOATVAL2);
else
Con::printf("%f != %f",TESTFLOATVAL1,TESTFLOATVAL2);
U32* pval1 = (U32*)&val1;
U32* pval2 = (U32*)&val2;
Con::printf("0.f(%X) 0.0f(%X)",*pval1, *pval2);With VS2008 I saw no difference when I changed the values of TESTFLOATVAL1 and TESTFLOATVAL2. The values I tried were 0.f vs 0.0f and 1.f vs 1.0f. However, I did read this: stackoverflow.com/questions/12637581/must-i-initialize-floats-using-0-f which suggests different compilers may treat it differently or produce slightly different code that might effect how those are handled. I don't know if this is an issue of any versions of 2008. So I am curious as to which version you are running and what the results of the above could is.
#10
I'm glad you tested and got the same results in VC++ 9.0(VS2008) as I did with gcc (Debian 4.4.5-8) 4.4.5. Would be interested to know if those who have VS2010 are getting the same results as we are or something strange with 0.f as Bryce is getting.
03/18/2013 (3:34 pm)
Frank: That stackoverflow article you linked is talking about the difference between integer declaration (0, 0, -1) vs floating declaration (0.f,0.f,-1.f). It isn't directly related to what we're talking about here.I'm glad you tested and got the same results in VC++ 9.0(VS2008) as I did with gcc (Debian 4.4.5-8) 4.4.5. Would be interested to know if those who have VS2010 are getting the same results as we are or something strange with 0.f as Bryce is getting.
#11
03/19/2013 (12:24 am)
@Nathan, yeah, but some of the articles linked to that talked about how 0.0 and 0.0f are different. The first is a double and the second is a float. So I thought maybe there is something going on with 0.f with some compilers possibly even producing a double. 
#12
and the only issue at least on my end that i get when using that is
when a sunlight is in the level u get some strange shadowing when zoomed (might be a graphics glitch who knows)
If there is need i might do a video showing the issue mentioned above.
However i can test it with vs2008 aswell and see if there is a change or not.
i will ask Dushan if it makes a difference on his end as he is using vs2012 to compile on windows.
Edit: Dushan just tested this on a vs2012 compile and he confirms that it is actually working - now whats left is my vs2008 test and ye i might do a video/ just to show the issue i get with sunlight when using this
03/19/2013 (6:31 am)
as am using vs2010 i can confirm that the change mentioned by Bryce is working!and the only issue at least on my end that i get when using that is
when a sunlight is in the level u get some strange shadowing when zoomed (might be a graphics glitch who knows)
If there is need i might do a video showing the issue mentioned above.
However i can test it with vs2008 aswell and see if there is a change or not.
i will ask Dushan if it makes a difference on his end as he is using vs2012 to compile on windows.
Edit: Dushan just tested this on a vs2012 compile and he confirms that it is actually working - now whats left is my vs2008 test and ye i might do a video/ just to show the issue i get with sunlight when using this
#13
03/20/2013 (2:47 pm)
I don't see this issue in VS2012. However, 0.f looks dodgy and we should probably fix it just in case :P. 
#14
03/28/2013 (10:40 am)
Just working on some binoculars... this is a welcome fix! Thanks!
#15
03/28/2013 (10:59 am)
The pleasure is mine! 
J0linar
just compiled and tested :)
and i can already see how TAIK will use this.