+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4)
+--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9)
+--- Thread: VDrift 2014-09-26 bug fix release (/showthread.php?tid=1839)
Pages:
1
2
VDrift 2014-09-26 bug fix release - NaN - 09-26-2014
The release fixes a crash bug in joe loader, I've run into during testing.
Additionally sound distance attenuation has been made less aggressive, and attenuation parameters can be tweaked from VDrift.config now.
Full download
Linux: http://sourceforge.net/projects/vdrift/files/vdrift/vdrift-2014-09-26/vdrift-2014-09-26.tar.bz2/download
Windows: http://sourceforge.net/projects/vdrift/files/vdrift/vdrift-2014-09-26/vdrift-2014-09-26.exe/download
Update for 2014-09-22 release
Linux (source only): https://github.com/VDrift/vdrift/archive/master.zip
Windows (vdrift.exe): http://sourceforge.net/projects/vdrift/files/vdrift/vdrift-2014-09-26/vdrift-2014-09-22-update.7z/download
The new default parameters for sound attenuation in VDrift.config are:
[sound]
attenuation_scale = 0.914607
attenuation_shift = 0.272928
attenuation_exponent = -0.231374
attenuation_offset = -0.28843
The attenuation is a power function y=a*(x-b)^c+d clamped to the range [0, 1]:
attenuation = scale * (distance - shift)^exponent + offset
The parameters are derived using least squares fit to a number of sampling poins using this great website:
http://zunzun.com/Equation/2/Power/X%20Shifted%20Power%20With%20Offset/
To get the old logarithmic attenuation the parameters are:
[sound]
attenuation_scale = 4.8694110473874862E+03
attenuation_shift = -2.3380252855054809E-02
attenuation_exponent = -2.9380304585176599E-05
attenuation_offset = -4.8686554410866866E+03
The 2014-09-22 release attenuation parameters are:
[sound]
attenuation_scale = 0.5
attenuation_shift = 0
attenuation_exponent = -1
attenuation_offset = 0
If you are curious about how the curves look like, take a look here:
http://fooplot.com/plot/sjwjocicxq
The black curve is the new, other two are the old versions. I've used fooplot to place the sampling points and fed them into zunzun solver. I know this is not exactly user friendly, but the user should not really mess with this settings.
RE: VDrift 2014-09-26 bug fix release - zunzun - 09-27-2014
I'm glad you found my zunzun.com web site useful, and thank you for the link. If I might be of any assistance in using the site, or might help with curve fitting in general, please do not hesitate to contact me directly. I will be glad to help anyone interested in this area.
Respectfully,
James Phillips
2548 Vera Cruz Drive
Birmingham, AL 35235
email: zunzun@zunzun.com
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-04-2014
I have uploaded a OS X build (http://sourceforge.net/projects/vdrift/files/vdrift/vdrift-2014-09-26/vdrift-mac-2014-09-26.dmg/download). However it only runs on 10.9 Mavericks and higher - something OpenGL related crashes it after "Loaded GUI successfully" on older versions. More thorough testing to come.
The main change on the OS X side from the last release is where the settings are stored, so to transfer everything:
* Open Finder
* Select 'Go' in the menu bar
* Hold Option (alt/⌥)
* Select 'Library'
* Copy the VDrift folder from Preferences to Application Support
Also, Mac OS X 10.4 "Tiger" is definitely not supported any more. 10.5 and 10.6 may or not work (when the issue above is fixed), I don't have any facilities to test them.
NaN, could you tag relevant commit on Github for the release - the versioning on OS X uses the tags. Also the links on vdrift.net need updating if joevenzon is around.
RE: VDrift 2014-09-26 bug fix release - NaN - 10-05-2014
(10-04-2014, 06:48 PM)Timo 6 Wrote: I have uploaded a OS X build (http://sourceforge.net/projects/vdrift/files/vdrift/vdrift-2014-09-26/vdrift-mac-2014-09-26.dmg/download). However it only runs on 10.9 Mavericks and higher - something OpenGL related crashes it after "Loaded GUI successfully" on older versions. More thorough testing to come.
The main change on the OS X side from the last release is where the settings are stored, so to transfer everything:
* Open Finder
* Select 'Go' in the menu bar
* Hold Option (alt/⌥)
* Select 'Library'
* Copy the VDrift folder from Preferences to Application Support
Also, Mac OS X 10.4 "Tiger" is definitely not supported any more. 10.5 and 10.6 may or not work (when the issue above is fixed), I don't have any facilities to test them.
NaN, could you tag relevant commit on Github for the release - the versioning on OS X uses the tags. Also the links on vdrift.net need updating if joevenzon is around.
Feel free to create a separate issue for the crashes. There is one thing you could try, assuming you are hitting gl2 path. In graphics_gl2.cpp lines 312-319 enable a workaround on Windows. Try removing the ifdef.
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-05-2014
Will do when I get some more info. Thanks, I'll try that. Cheers for doing the tag too.
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-06-2014
The log.txt for the crash is here: http://pastebin.com/q6A6UDnV, system crash log here: http://pastebin.com/3GiKBWEM. OpenGL 3.3 Core Profile is requested but fails because OS X 10.8 only has 3.2. The call in VertexBuffer:
raw to glDrawElements then fails when trying to show the loading screen.The crash starts happening at 101ee99, which is when glewExperiment is enabled - disabling it fixes it until glew is replaced in 5206da1. The workaround you suggested don't have any effect I can see.
Let me know if traces would be helpful.
RE: VDrift 2014-09-26 bug fix release - NaN - 10-06-2014
Looking into vertexbuffer.cpp there is another #ifdef _WIN32 (line 351) you would have to remove to enable the workaround, totally forgot about it, sorry.
It would be cool if you could set break points there (BindSegmentBuffer function), to see if you are hitting the use_vao path or the fallback (vbo).
Essentially, I'd like to know what gl calls have been made before DrawElements.
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-06-2014
Even removing that ifdef as well nothing changes. It never gets to BindSegmentBuffer.
RE: VDrift 2014-09-26 bug fix release - NaN - 10-06-2014
(10-06-2014, 05:35 PM)Timo 6 Wrote: Even removing that ifdef as well nothing changes. It never gets to BindSegmentBuffer.
Weird, at some point before it has to. Could you try to get a gl call trace?
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-06-2014
http://pastebin.com/Eag050si
Removing the if in 325 (which is evaluates to false otherwise) and letting it go in to BindSegmentBuffer I can see use_vao is true and bind_ibo is false.
RE: VDrift 2014-09-26 bug fix release - NaN - 10-07-2014
The trace seems to end before getting to drawing.
bind_ibo is set by the workaround, which expects "Intel" (gaphics_gl2.cpp line 316) but gets "Intel Inc." Try commenting out the ifdefs and also the vendor check, to make sure bind_ibo is set to true.
In vertexbuffer.cpp line 325, what are the values of: vbuffer, age, s.vbuffer, s.vcount, s.age?
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-07-2014
At line 325 https://flic.kr/p/phL9iK
bind_ibo is indeed true with the workaround and graphics_gl2.cpp line 317 commented out.
Btw, I noticed log.txt already has 'ERROR: OpenGL error "invalid operation" during: render output end' by this stage, don't know if that's important.
RE: VDrift 2014-09-26 bug fix release - NaN - 10-08-2014
(10-07-2014, 05:57 PM)Timo 6 Wrote: At line 325 https://flic.kr/p/phL9iK
bind_ibo is indeed true with the workaround and graphics_gl2.cpp line 317 commented out.
Btw, I noticed log.txt already has 'ERROR: OpenGL error "invalid operation" during: render output end' by this stage, don't know if that's important.
Seems like it fails to create a vertex array. You can verify it by setting a break point at vertexbuffer.cpp lines 88-89
glGenVertexArrays shoud set ob.varray to a nonzero value. Per OpenGL spec the function is allowed to return zero though, which means it failed...
I think I'll have to add a check for currently bound vao/vbo into the draw function (or simply disable vertex arrays for GL2+ drivers).
RE: VDrift 2014-09-26 bug fix release - NaN - 10-08-2014
I've pushed some code to handle this failure case.
RE: VDrift 2014-09-26 bug fix release - Timo 6 - 10-09-2014
Getting lots (and lots) of 'ERROR: OpenGL error "invalid operation" during: before FBO begin' (gl2/deferred.conf) or 'ERROR: OpenGL error "invalid operation" during: render output end' (gl2/basic.conf) in log.txt, but apart from that it seem to be working well
EDIT: There's a 'ERROR: OpenGL error "invalid operation" during: Texture ID generation' just after the car loads as well.