Author Topic: go_even_faster  (Read 20571 times)

0 Members and 1 Guest are viewing this topic.

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
New builds uploaded with some fixes. Check the OP.

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
First thing I noticed with this build is that there was a lot of audio skipping regardless of increased framerates.

I tested again without the commandline flags to be sure it wasn't that. Still got it. I switched to a latest trunk to try it again, just to compare freshly. Then I switched back to the go_even_faster builds. What I noticed is that everything seems a little laggy, including menus. The whole game just felt sluggish regardless of FPS increase. What it felt like was playing on Debug builds... I double checked to make sure I was using a normal build though.

Is there some special debugging going on in your builds? How do you want me to report this that's most useful to you? (Video, etc.)

EDIT: In-mission the lag happens everytime a higher poly ship is on screen. (HTL Typhon, Arcadia, Sathanas, etc.) Catch me on IRC and I'll see if we can get you any/all of those models to test with and may reproduce.
« Last Edit: July 05, 2012, 09:00:41 am by mjn.mixael »
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Updated go_even_faster builds. Check the OP for details.

If no one has any problems with these builds, I'll be commiting the new collision code, the vertex buffer particles code, and the OpenGL optimizations into trunk. Merged index buffers still needs some work however. Any bugs related to that optimization feature won't affect the status of the aforementioned features.

 

Offline Valathil

  • ...And I would have had a custom title if it wasn't for you meddling kids!
  • 29
  • Custom Title? Wizards need no Custom Title!
Any bugs related to that optimization feature won't affect the status of the aforementioned features.

May cause headaches, nausea or dry mouth. Please consult your Pharmacist or Doctor before use.
┏┓╋┏┓╋╋╋╋╋╋╋╋╋┏┓
┃┃╋┃┃╋╋╋╋╋╋╋╋╋┃┃
┃┃┏┫┃┏┳━━┓┏━━┓┃┗━┳━━┳━━┳━━┓
┃┃┣┫┗┛┫┃━┫┃┏┓┃┃┏┓┃┏┓┃━━┫━━┫
┃┗┫┃┏┓┫┃━┫┃┏┓┃┃┗┛┃┗┛┣━━┣━━┃
┗━┻┻┛┗┻━━┛┗┛┗┛┗━━┻━━┻━━┻━━┛

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Everybody, no problems? I'm going to commit go_even_faster by the end of tonight.

 

Offline niffiwan

  • 211
  • Eluder Class
A couple of issues I've encountered...

1) still need to remove capitals from #includes to compile on a case-sensitive filesystem :)
Code: [Select]
Index: fs2_open/code/object/objectsort.cpp
===================================================================
--- fs2_open/code/object/objectsort.cpp    (revision 8874)
+++ fs2_open/code/object/objectsort.cpp    (working copy)
@@ -18,8 +18,8 @@
 
 #include <list>
 #include "weapon/weapon.h"
-#include "Debris/debris.h"
-#include "Asteroid/asteroid.h"
+#include "debris/debris.h"
+#include "asteroid/asteroid.h"
 
 
 typedef struct sorted_obj {


2) more importantly, I'm having issues loading Tethis.pof in the 2nd mission, BP2.  FSO seems to go into an infinite loop, the debugger is telling me that it's running around at model/modelcollide.cpp:743, with the value of "chunk_type" being zero so it doesn't trigger any of the case statements - thus "i" never increments from zero.

Here's a backtrace:
Code: [Select]
(gdb) bt
#0  model_collide_parse_bsp (tree=0x461dcb0, model_ptr=0x4161c90, version=2117) at model/modelcollide.cpp:743
#1  0x000000000063e0f8 in model_load (filename=0x1e2363c "Tethis.pof", n_subsystems=34, subsystems=0x311c480, ferror=1, duplicate=0) at model/modelread.cpp:2680
#2  0x000000000078af89 in ship_create (orient=0x3bdd58c, pos=0x3bdd580, ship_type=164, ship_name=0x3bdd550 "Ranvir") at ship/ship.cpp:8607
#3  0x00000000005d464c in parse_create_object_sub (p_objp=0x3bdd550) at mission/missionparse.cpp:1750
#4  0x00000000005d4562 in parse_create_object (pobjp=0x3bdd550) at mission/missionparse.cpp:1709
#5  0x00000000005d94b6 in mission_parse_maybe_create_parse_object (pobjp=0x3bdd550) at mission/missionparse.cpp:3282
#6  0x00000000005dc433 in post_process_ships_wings () at mission/missionparse.cpp:4507
#7  0x00000000005dea1a in post_process_mission () at mission/missionparse.cpp:5389
#8  0x00000000005de949 in parse_mission (pm=0xffce60, flags=0) at mission/missionparse.cpp:5369
#9  0x00000000005df9ce in parse_main (mission_name=0x7fffffffdec0 "bp2-02.fs2", flags=0) at mission/missionparse.cpp:5742
#10 0x00000000005c5c4a in mission_load (filename_ext=0xc403a0 "bp2-02.fs2") at mission/missionload.cpp:107
#11 0x000000000040b72f in game_start_mission () at freespace2/freespace.cpp:1445
#12 0x00000000004152f0 in game_enter_state (old_state=1, new_state=52) at freespace2/freespace.cpp:5984
#13 0x00000000004b9748 in gameseq_set_state (new_state=52, override=0) at gamesequence/gamesequence.cpp:282
#14 0x00000000004141ba in game_process_event (current_state=1, event=1) at freespace2/freespace.cpp:5148
#15 0x00000000004b9c44 in gameseq_process_events () at gamesequence/gamesequence.cpp:397
#16 0x0000000000416a7a in game_main (cmdline=0x24d1bd0 "") at freespace2/freespace.cpp:7102
#17 0x0000000000416c74 in main (argc=1, argv=0x7fffffffe2e8) at freespace2/freespace.cpp:7236
(gdb)

In frame 1, in the for loop, "i" was 33, where pm->n_models was 102. 
Code: [Select]
for ( i = 0; i < pm->n_models; ++i ) {
pm->submodel[i].collision_tree_index = model_create_bsp_collision_tree();
bsp_collision_tree *tree = model_get_bsp_collision_tree(pm->submodel[i].collision_tree_index);

model_collide_parse_bsp(tree, pm->submodel[i].bsp_data, pm->version);
}

Is there anything else I can do to do to assist with troubleshooting this?

Lastly, I don't really think it's relevant, but this originally occurred with with some shaders in mediavps_3612/data/effects and valathil's shaders in blueplanet2/data/effect, I removed the mediavps shaders but it didn't make a difference.  I've also attached a log just for completeness sake.


[attachment deleted by a ninja]
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
It turns out the Tethis erroneously has a submodel with zero vertices in the latest BP2 public release. There was nothing to parse in the first place which confused the parsing loop. It's been fixed in my personal git repository but I'll upload a new build later.

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
New builds uploaded. Check OP. I fixed the infinite loop problem when loading a borked submodel.

Will commit on the weekend if no one reports any bugs.

 

Offline Echelon9

  • Moderator
  • 210
New builds uploaded. Check OP. I fixed the infinite loop problem when loading a borked submodel.

Will commit on the weekend if no one reports any bugs.
Thanks, I'll be able to shortly reconfirm this works cross-platform.

 

Offline niffiwan

  • 211
  • Eluder Class
Ummm.. I've found another issue  :nervous:

When running a debug build, exiting FSO can take ages, much longer than it does on latest trunk builds (which exit almost instantly in all cases).  The length of time varies. e.g.

Kentauroi Race (course complete): normal speed exit
The Plunder (played for 1-2 mins, died): exit in approx 1 min
BP Massive Battle (played for maybe 30-45 sec): gave up waiting after 10-15 mins and forcibly killed FSO

I think massive battle would have eventually exited, as you could see changes occurring slowly, e.g. gdb reporting threads ending, the fs2_open.log closing message, etc.  I also interrupted program execution with gdb and it was very slowly progressing - see below for stack traces taken at various times.  As can be seen, the interruptions often occurred while execution was in _vm_free(). 

I used top to see the "resident set" memory usage - trunk builds report ~1GB of RAM usage,  go_ever_faster builds report ~1.1-1.2GB - an extra 200 MB by itself shouldn't cause this sort of slowdown though.

I've run out of time to investigate further tonight, but I was thinking of trying to time the various functions in game_shutdown() to see if I can further narrow down what is taking so long.  It'd also be good to know if anyone on Windows/OSX can reproduce this issue.

Code: [Select]
(gdb) bt
#0  0x000000000083566c in _vm_free (ptr=0x30df3f0, filename=0x939c73 "ship/ship.cpp", line=12894) at windows_stub/stubs.cpp:687
#1  0x0000000000797be9 in ship_close () at ship/ship.cpp:12894
#2  0x0000000000416de1 in game_shutdown () at freespace2/freespace.cpp:7335
#3  0x0000000000416a52 in game_main (cmdline=0x24d7bd0 "") at freespace2/freespace.cpp:7108
#4  0x0000000000416c3d in main (argc=1, argv=0x7fffffffe298) at freespace2/freespace.cpp:7236
(gdb)
(gdb) bt
#0  0x000000000083566c in _vm_free (ptr=0x2eb2130, filename=0x8a40f3 "./globalincs/vmallocator.h", line=62) at windows_stub/stubs.cpp:687
#1  0x0000000000448a0d in SCP_vm_allocator<char>::deallocate (this=0x7fffffffdeef, p=0x2eb2130 "\003") at ./globalincs/vmallocator.h:62
#2  0x0000000000447cae in std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >::_Rep::_M_destroy (this=0x2eb2130, __a=...) at /usr/include/c++/4.6/bits/basic_string.tcc:451
#3  0x00000000004473aa in std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >::_Rep::_M_dispose (this=0x2eb2130, __a=...) at /usr/include/c++/4.6/bits/basic_string.h:244
#4  0x0000000000446c1c in std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >::~basic_string (this=0x2ec4400, __in_chrg=<optimised out>) at /usr/include/c++/4.6/bits/basic_string.h:534
#5  0x00000000004be968 in game_snd::~game_snd (this=0x2ec4400, __in_chrg=<optimised out>) at ./sound/sound.h:39
#6  0x00000000004bf786 in SCP_vm_allocator<game_snd>::destroy (this=0xe8bb70, p=0x2ec4400) at ./globalincs/vmallocator.h:42
#7  0x00000000004befa6 in std::_Destroy<game_snd*, SCP_vm_allocator<game_snd> > (__first=0x2ec4400, __last=0x2ec5de0, __alloc=...) at /usr/include/c++/4.6/bits/stl_construct.h:145
#8  0x00000000004bf6dc in std::vector<game_snd, SCP_vm_allocator<game_snd> >::_M_erase_at_end (this=0xe8bb70, __pos=0x2ebcb10) at /usr/include/c++/4.6/bits/stl_vector.h:1255
#9  0x00000000004beef0 in std::vector<game_snd, SCP_vm_allocator<game_snd> >::clear (this=0xe8bb70) at /usr/include/c++/4.6/bits/stl_vector.h:1040
#10 0x00000000004be85a in gamesnd_close () at gamesnd/gamesnd.cpp:765
#11 0x0000000000416e51 in game_shutdown () at freespace2/freespace.cpp:7368
#12 0x0000000000416a52 in game_main (cmdline=0x24d7bd0 "") at freespace2/freespace.cpp:7108
#13 0x0000000000416c3d in main (argc=1, argv=0x7fffffffe298) at freespace2/freespace.cpp:7236
(gdb)
(gdb) bt
#0  0x00000000008356d0 in _vm_free (ptr=0x3b3c1b0, filename=0x8f07eb "model/modelread.cpp", line=4879) at windows_stub/stubs.cpp:686
#1  0x0000000000645408 in model_remove_bsp_collision_tree (tree_index=76) at model/modelread.cpp:4879
#2  0x00000000006359f6 in model_unload (modelnum=3, force=1) at model/modelread.cpp:240
#3  0x0000000000635c2d in model_free_all () at model/modelread.cpp:299
#4  0x0000000000416e5b in game_shutdown () at freespace2/freespace.cpp:7371
#5  0x0000000000416a52 in game_main (cmdline=0x24d7bd0 "") at freespace2/freespace.cpp:7108
#6  0x0000000000416c3d in main (argc=1, argv=0x7fffffffe298) at freespace2/freespace.cpp:7236
(gdb)
(gdb) bt
#0  0x000000000083566c in _vm_free (ptr=0xd88cb80, filename=0x8f07eb "model/modelread.cpp", line=4879) at windows_stub/stubs.cpp:687
#1  0x0000000000645408 in model_remove_bsp_collision_tree (tree_index=405) at model/modelread.cpp:4879
#2  0x00000000006359f6 in model_unload (modelnum=5, force=1) at model/modelread.cpp:240
#3  0x0000000000635c2d in model_free_all () at model/modelread.cpp:299
#4  0x0000000000416e5b in game_shutdown () at freespace2/freespace.cpp:7371
#5  0x0000000000416a52 in game_main (cmdline=0x24d7bd0 "") at freespace2/freespace.cpp:7108
#6  0x0000000000416c3d in main (argc=1, argv=0x7fffffffe298) at freespace2/freespace.cpp:7236
(gdb)
(gdb) bt
#0  0x000000000083566c in _vm_free (ptr=0x2673e30, filename=0x8dc311 "localization/localize.cpp", line=383) at windows_stub/stubs.cpp:687
#1  0x0000000000576b23 in lcl_xstr_close () at localization/localize.cpp:383
#2  0x00007ffff58d5921 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff58d59a5 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff58bb774 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x0000000000409e89 in _start ()
(gdb)
(gdb) bt
#0  0x000000000083566c in _vm_free (ptr=0x7fffd730fa20, filename=0x8ca0a0 "globalincs/fsmemory.cpp", line=19) at windows_stub/stubs.cpp:687
#1  0x00000000004c1c57 in operator delete (p=0x7fffd730fa20) at globalincs/fsmemory.cpp:19
#2  0x00000000006da7e8 in __gnu_cxx::new_allocator<__gnu_cxx::_Hashtable_node<std::pair<unsigned int const, collider_pair> > >::deallocate (this=0x116efe0, __p=0x7fffd730fa20) at /usr/include/c++/4.6/ext/new_allocator.h:98
#3  0x00000000006d9fb6 in __gnu_cxx::hashtable<std::pair<unsigned int const, collider_pair>, unsigned int, __gnu_cxx::hash<unsigned int>, std::_Select1st<std::pair<unsigned int const, collider_pair> >, std::equal_to<unsigned int>, std::allocator<collider_pair> >::_M_put_node (this=0x116efe0, __p=0x7fffd730fa20) at /usr/include/c++/4.6/backward/hashtable.h:297
#4  0x00000000006d9d3e in __gnu_cxx::hashtable<std::pair<unsigned int const, collider_pair>, unsigned int, __gnu_cxx::hash<unsigned int>, std::_Select1st<std::pair<unsigned int const, collider_pair> >, std::equal_to<unsigned int>, std::allocator<collider_pair> >::_M_delete_node (this=0x116efe0, __n=0x7fffd730fa20) at /usr/include/c++/4.6/backward/hashtable.h:619
#5  0x00000000006d9615 in __gnu_cxx::hashtable<std::pair<unsigned int const, collider_pair>, unsigned int, __gnu_cxx::hash<unsigned int>, std::_Select1st<std::pair<unsigned int const, collider_pair> >, std::equal_to<unsigned int>, std::allocator<collider_pair> >::clear (this=0x116efe0) at /usr/include/c++/4.6/backward/hashtable.h:1103
#6  0x00000000006d9053 in __gnu_cxx::hashtable<std::pair<unsigned int const, collider_pair>, unsigned int, __gnu_cxx::hash<unsigned int>, std::_Select1st<std::pair<unsigned int const, collider_pair> >, std::equal_to<unsigned int>, std::allocator<collider_pair> >::~hashtable (this=0x116efe0, __in_chrg=<optimised out>) at /usr/include/c++/4.6/backward/hashtable.h:357
#7  0x00000000006daf24 in __gnu_cxx::hash_map<unsigned int, collider_pair, __gnu_cxx::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<collider_pair> >::~hash_map (this=0x116efe0, __in_chrg=<optimised out>) at /usr/include/c++/4.6/ext/hash_map:84
#8  0x00007ffff58d5921 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x00007ffff58d59a5 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x00007ffff58bb774 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x0000000000409e89 in _start ()
(gdb)

(that last backtrace really looks odd...)
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Go to the Troubleshooting tab and check Use old collision detection system. See if this happens then.

Also see if this happens on Trunk Revision 9069.


 

Offline Echelon9

  • Moderator
  • 210
Something funky is going on in the game_snd destructor.

As noted, there has been a recent change to the way the game_snd is called, in revision 9086 http://svn.icculus.org/fs2open?view=rev&revision=9086

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
But that's not related to go even faster in the slightest....
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline niffiwan

  • 211
  • Eluder Class
nope - but it caused me grief in trying to test go_even_faster because I'd cloned swifty's git repo and it contains the game_snd changes which add a SCP_string to the struct. Damn you memset!!!!   :) 
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Echelon9

  • Moderator
  • 210
Quote
When I apply the current release_candidate.patch, I get the following compile errors in gropengltnl.cpp
Code: [Select]
gropengltnl.cpp:790 - Use of undeclared identifier 'glDrawElementsBaseVertex'
gropengltnl.cpp:792 - Use of undeclared identifier 'glDrawRangeElementsBaseVertex'; did you mean 'glDrawRangeElementsProcPtr'?

Echelon9, try and copy pasta this code into gropengl.h after applying go_even_faster.patch and see if it compiles and runs.

Code: [Select]
#ifndef GL_ARB_draw_elements_base_vertex
#define GL_ARB_draw_elements_base_vertex 1
#ifdef __APPLE__
typedef void (* glDrawElementsBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawRangeElementsBaseVertex) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawElementsInstancedBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (* glMultiDrawElementsBaseVertex) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);
#else
typedef void (APIENTRYP PFNGLDRAWELEMENTSBASEVERTEXPROC) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (APIENTRYP PFNGLDRAWRANGEELEMENTSBASEVERTEXPROC) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (APIENTRYP PFNGLDRAWELEMENTSINSTANCEDBASEVERTEXPROC) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (APIENTRYP PFNGLMULTIDRAWELEMENTSBASEVERTEXPROC) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);
#endif // __APPLE__
#endif // GL_ARB_draw_elements_base_vertex

Arggh, using the latest (1 July) go_even_faster, I'm seeing this error again. See above for the previous fix that used to resolve this when hand applied. Has there been any other recent change with this section?

 

Offline niffiwan

  • 211
  • Eluder Class
Go to the Troubleshooting tab and check Use old collision detection system. See if this happens then.

Also see if this happens on Trunk Revision 9069.

It doesn't happen with "Use old collision detection system" selected.  In fact, debug runs faster with the old system than the new one (i.e. completely opposite behaviour to release).

It also does not occur in trunk 9069.

Lastly, I don't believe it's relevant, but in all tests I needed to remove an Int3() (see following patch) otherwise I get this after about 5 secs: Int3(): From weapon/swarm.cpp at line 387

Code: [Select]
diff --git a/fs2_open/code/weapon/swarm.cpp b/fs2_open/code/weapon/swarm.cpp
index 44e7370..fb5592b 100644
--- a/fs2_open/code/weapon/swarm.cpp
+++ b/fs2_open/code/weapon/swarm.cpp
@@ -384,7 +384,7 @@ int turret_swarm_create()
 
        if ( i >= MAX_TURRET_SWARM_INFO ) {
                nprintf(("Warning","No more turret swarm info slots are available\n"));
-               Int3();
+               //Int3();
                return -1;
        }

Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Can you be more specific as to what doesn't happen? The slow exit or just a general slowdown?

FYI, the new collision code uses STL hash_map to cache timestamps which would explain a slowdown if using it in Debug.

Quote
When I apply the current release_candidate.patch, I get the following compile errors in gropengltnl.cpp
Code: [Select]
gropengltnl.cpp:790 - Use of undeclared identifier 'glDrawElementsBaseVertex'
gropengltnl.cpp:792 - Use of undeclared identifier 'glDrawRangeElementsBaseVertex'; did you mean 'glDrawRangeElementsProcPtr'?

Echelon9, try and copy pasta this code into gropengl.h after applying go_even_faster.patch and see if it compiles and runs.

Code: [Select]
#ifndef GL_ARB_draw_elements_base_vertex
#define GL_ARB_draw_elements_base_vertex 1
#ifdef __APPLE__
typedef void (* glDrawElementsBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawRangeElementsBaseVertex) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawElementsInstancedBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (* glMultiDrawElementsBaseVertex) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);
#else
typedef void (APIENTRYP PFNGLDRAWELEMENTSBASEVERTEXPROC) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (APIENTRYP PFNGLDRAWRANGEELEMENTSBASEVERTEXPROC) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (APIENTRYP PFNGLDRAWELEMENTSINSTANCEDBASEVERTEXPROC) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (APIENTRYP PFNGLMULTIDRAWELEMENTSBASEVERTEXPROC) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);
#endif // __APPLE__
#endif // GL_ARB_draw_elements_base_vertex

Arggh, using the latest (1 July) go_even_faster, I'm seeing this error again. See above for the previous fix that used to resolve this when hand applied. Has there been any other recent change with this section?

I already integrated that fix into go_even_faster on July 22nd: https://github.com/SamuelCho/Freespace-Open-Swifty/commit/1d1f337afb6943b1d5f14bb3e6abdbc899c28960

I took a look at the patch as well and it also has the necessary function pointers.

 

Offline niffiwan

  • 211
  • Eluder Class
Can you be more specific as to what doesn't happen? The slow exit or just a general slowdown?

FYI, the new collision code uses STL hash_map to cache timestamps which would explain a slowdown if using it in Debug.

I get the same result when using either:
1) go_even_faster debug build with "use old collision detection system" selected
2) trunk 9069 debug build

In both cases the game exits at normal speed (i.e. <1 sec).  In addition, the in-mission framerate is also faster - approx 6fps worst case compared with approx 4 secs per frame worst case.



Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Echelon9

  • Moderator
  • 210
Swifty, I agree that patch is integrated, but it is no longer having the previously observed effect of fixing the compile error.

Possibly something else has changed in that area?

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Swifty, I agree that patch is integrated, but it is no longer having the previously observed effect of fixing the compile error.

Possibly something else has changed in that area?

Try removing all the preprocessor directives and the non-APPLE function pointers so you only have this

Code: [Select]
typedef void (* glDrawElementsBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawRangeElementsBaseVertex) (GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex);
typedef void (* glDrawElementsInstancedBaseVertex) (GLenum mode, GLsizei count, GLenum type, const GLvoid *indices, GLsizei primcount, GLint basevertex);
typedef void (* glMultiDrawElementsBaseVertex) (GLenum mode, const GLsizei *count, GLenum type, const GLvoid* *indices, GLsizei primcount, const GLint *basevertex);

See if it compiles.

Quote
In both cases the game exits at normal speed (i.e. <1 sec).  In addition, the in-mission framerate is also faster - approx 6fps worst case compared with approx 4 secs per frame worst case.

As I said, new collision code is using STL hash map. STL doesn't run very well in Debug I noticed which has gradually been problematic as the code base continues to use STL containers in more parts of the code. Probably something that warrants us looking into ways to get STL containers faster in debug. But that's not within the scope of this thread.