Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Swifty on June 12, 2012, 03:57:10 am

Title: go_even_faster
Post by: Swifty on June 12, 2012, 03:57:10 am
Download: http://www.mediafire.com/?42048h3w1oghgr2

In this build:

Bugs fixed as of 8/1/2012 (Based off of Trunk Revision 9069)

Bugs fixed as of 7/26/2012 (Based off of Trunk Revision 9031)

Bugs fixed as of 7/4/2012 (Based off on Trunk Revision 8972)


Bugs fixed as of 6/24/2012


Main Features:


Help me out by testing this! FRAPS Benchmarks and pretty charts will greatly help.

Patch is inside the ZIP file if you need to know how this demonry was achieved.
Title: Re: go_even_faster
Post by: MatthTheGeek on June 12, 2012, 04:09:20 am
Ooo I need to test this.
Title: Re: go_even_faster
Post by: Firartix on June 12, 2012, 04:09:50 am
Can we haz binary ?
EDIT: Disregard
Title: Re: go_even_faster
Post by: niffiwan on June 12, 2012, 06:18:57 am
Here's a small update so this can compile on Linux (gcc 4.6.3).  It seems that gcc doesn't include hash_map in the std library - my change is a rough hack which may not work correctly in Windows or OSX.

The other two changes are for us folks with case-sensitive filesystems :)

Code: [Select]
Index: fs2_open/code/globalincs/vmallocator.h
===================================================================
--- fs2_open/code/globalincs/vmallocator.h    (revision 8874)
+++ fs2_open/code/globalincs/vmallocator.h    (working copy)
@@ -120,7 +120,11 @@ bool operator!=(const SCP_vm_allocator<T1>&, const SCP_vm_allocator<T2>&) throw(
  return false;
 }
 
+#ifdef SCP_UNIX
+#define SCP_hash_map __gnu_cxx::hash_map
+#else
 #define SCP_hash_map std::hash_map
+#endif // SCP_UNIX
 
 #else
 
@@ -135,4 +139,4 @@ bool operator!=(const SCP_vm_allocator<T1>&, const SCP_vm_allocator<T2>&) throw(
 
 #endif
 
-#endif // _VMALLOCATOR_H_INCLUDED_
\ No newline at end of file
+#endif // _VMALLOCATOR_H_INCLUDED_
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 {

As for testing, from a few quick runs through BP2 Artemis Station I'd say that it seems a bit faster in the slow bits, not up to a stable 60 fps all the way through, but maybe 5-10 fps faster than before in some places (e.g. the Nelson flyby).  With the "merged index buffers" turned on you get major graphical glitches, but that's probably due to shader issues since BP2 includes its own which would overwrite those in the patch.

Lastly, I noticed when existing the game it takes much much much longer to exit now, previously it was < 1 sec, now maybe 10-15 seconds, perhaps longer.

(ps - does anyone have a good BoE type mission that can be used for testing and that isn't related to BP2?)
Title: Re: go_even_faster
Post by: MatthTheGeek on June 12, 2012, 06:29:10 am
Open FRED, Ctrl-click warships like mad all round the map. Done, you have your BoE.
Title: Re: go_even_faster
Post by: Spoon on June 12, 2012, 06:42:29 am
go_even_faster!? how badly will the sound code get screwed over this time?  :P
Title: Re: go_even_faster
Post by: Valathil on June 12, 2012, 06:54:32 am
We need to go to ........ LUDICROUS SPEED!!!!
Title: Re: go_even_faster
Post by: niffiwan on June 12, 2012, 07:03:04 am
Open FRED, Ctrl-click warships like mad all round the map. Done, you have your BoE.

umm... FRED - Linux - wine, I understand it has some problems :)
Title: Re: go_even_faster
Post by: pecenipicek on June 12, 2012, 07:07:37 am
niffiwan, well, i always just use the massive battle thats packed in BP. worked out well so far :p


speaking of, compared to the usual counter stuck at 4 fps and the actual framerate being something like "do i count this in frames per second or seconds per frame?", its getting to around 17-18 fps with no beams firing and 8 fps when metric ****tons of beams start firing.

[edit] fraps or something coming at some point.
Title: Re: go_even_faster
Post by: MatthTheGeek on June 12, 2012, 07:21:09 am
umm... FRED - Linux - wine, I understand it has some problems :)
Boot on windows, open FRED, Ctrl-click warships like mad all round the map, save somewhere, reboot on linux. Done, you have your BoE.
Title: Re: go_even_faster
Post by: Spoon on June 12, 2012, 07:21:22 am
I'm getting actual frames per seconds now instead of a slideshow in bp massive battle but the Solaris looks like a shell of its former self. (http://imagebin.org/216065)
Title: Re: go_even_faster
Post by: X3N0-Life-Form on June 12, 2012, 07:32:19 am
umm... FRED - Linux - wine, I understand it has some problems :)
Boot on windows, open FRED, Ctrl-click warships like mad all round the map, save somewhere, reboot on linux. Done, you have your BoE.
Or, if you can't boot on windows right now, just open up a regular mission with a text editor, copy/paste several object entries, change their name and one of their axis value, and voil133 (I think).
Title: Re: go_even_faster
Post by: Commander Zane on June 12, 2012, 07:43:38 am
Definite improvements with FPS, but caught these and wonder if anything in a log can help (Appears to be the same index buffer issue niffiwan mentioned).

(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/th_UnknownGlitch.png) (http://s97.photobucket.com/albums/l223/SpootKnight/FreeSpace/?action=view&current=UnknownGlitch.png)

(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/th_KarunaEngines.png) (http://s97.photobucket.com/albums/l223/SpootKnight/FreeSpace/?action=view&current=KarunaEngines.png)

Code: [Select]
==========================================================================
FreeSpace 2 Open version: 3.6.13
Passed cmdline options:
  -spec_exp 15
  -ogl_spec 20
  -spec_static 1.5
  -spec_point 1.2
  -spec_tube 1.5
  -ambient_factor 35
  -missile_lighting
  -soft_particles
  -post_process
  -fxaa
  -fb_explosions
  -merged_ibos
  -cache_bitmaps
  -ballistic_gauge
  -dualscanlines
  -orbradar
  -rearm_timer
  -targetinfo
  -3dwarp
  -ship_choice_3d
  -weapon_choice_3d
  -warp_flash
  -snd_preload
  -mod blueplanet2,blueplanet,mediavps_3612
  -new_collision
Building file index...
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-adv-visuals.vp' with a checksum of 0x241c257f
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-audio1.vp' with a checksum of 0x51171798
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-core.vp' with a checksum of 0xe386a796
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-visuals1.vp' with a checksum of 0xd263c407
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-visuals2.vp' with a checksum of 0xd3552477
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-adv-visuals.vp' with a checksum of 0xbba0f03c
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-audio1.vp' with a checksum of 0xe79b67ce
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-audio2.vp' with a checksum of 0xb50d55b7
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-core.vp' with a checksum of 0x6b804787
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-visuals1.vp' with a checksum of 0x316467fa
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-visuals2.vp' with a checksum of 0x39fe8221
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Advanced.vp' with a checksum of 0x4b8b0f5a
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_AnimGlows.vp' with a checksum of 0x6a554026
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.3612.vp' with a checksum of 0x59649c21
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.vp' with a checksum of 0x529cc70f
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.3612.vp' with a checksum of 0x9c510aa0
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.vp' with a checksum of 0xb9a9a485
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Music.vp' with a checksum of 0xb3e21469
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_RadarIcons.vp' with a checksum of 0x31dd7781
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.3612.vp' with a checksum of 0x7c9d7e74
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.vp' with a checksum of 0x6ffd5c78
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\Root_fs2.vp' with a checksum of 0xce10d76c
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\smarty_fs2.vp' with a checksum of 0xddeb3b1e
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_fs2.vp' with a checksum of 0x164fe65a
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_hi_fs2.vp' with a checksum of 0xa11d56f1
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\stu_fs2.vp' with a checksum of 0xd77da83a
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango1_fs2.vp' with a checksum of 0x4c25221e
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango2_fs2.vp' with a checksum of 0x86920b82
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango3_fs2.vp' with a checksum of 0x705e8d71
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\warble_fs2.vp' with a checksum of 0xd85c305d
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\' ... 2 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-adv-visuals.vp' ... 31 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-audio1.vp' ... 156 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-core.vp' ... 72 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-visuals1.vp' ... 641 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet2\bp2-visuals2.vp' ... 2012 files
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\' ... 0 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-adv-visuals.vp' ... 358 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-audio1.vp' ... 41 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-audio2.vp' ... 683 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-core.vp' ... 52 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-visuals1.vp' ... 374 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\blueplanet\bp-visuals2.vp' ... 1488 files
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\' ... 8 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Advanced.vp' ... 1283 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_AnimGlows.vp' ... 1641 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.3612.vp' ... 315 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.vp' ... 1527 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.3612.vp' ... 10 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.vp' ... 1876 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Music.vp' ... 32 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_RadarIcons.vp' ... 24 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.3612.vp' ... 13 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.vp' ... 94 files
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\' ... 57 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\Root_fs2.vp' ... 157 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\smarty_fs2.vp' ... 10 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_fs2.vp' ... 3027 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_hi_fs2.vp' ... 1337 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\stu_fs2.vp' ... 2355 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango1_fs2.vp' ... 32 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango2_fs2.vp' ... 15 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango3_fs2.vp' ... 10 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\warble_fs2.vp' ... 52 files
Found 34 roots and 19785 files.
Setting language to English
TBM  =>  Starting parse of 'mv_core-lcl.tbm' ...
Initializing OpenAL...
  OpenAL Vendor     : Creative Labs Inc.
  OpenAL Renderer   : Software
  OpenAL Version    : 1.1

  Found extension "ALC_EXT_EFX".

  Sample rate: 44100 (44100)
  EFX version: 1.0
  Max auxiliary sends: 1
  Playback device: Generic Software on Speakers / Headphones (IDT High Definition Audio CODEC)
  Capture device: Microphone Array (IDT High Defi
... OpenAL successfully initialized!
Failed to init speech
Initializing OpenGL graphics device at 1920x1200 with 32-bit color...
  Initializing WGL...
  Requested WGL Video values = R: 8, G: 8, B: 8, depth: 32, double-buffer: 1
  Actual WGL Video values    = R: 8, G: 8, B: 8, depth: 32, double-buffer: 1
  OpenGL Vendor    : ATI Technologies Inc.
  OpenGL Renderer  : ATI Mobility Radeon HD 5800 Series
  OpenGL Version   : 4.2.11318 Compatibility Profile Context

  Using extension "GL_EXT_fog_coord".
  Using extension "GL_ARB_multitexture".
  Using extension "GL_ARB_texture_env_add".
  Using extension "GL_ARB_texture_compression".
  Using extension "GL_EXT_texture_compression_s3tc".
  Using extension "GL_EXT_texture_filter_anisotropic".
  Using extension "GL_ARB_texture_env_combine".
  Using extension "GL_EXT_compiled_vertex_array".
  Using extension "GL_EXT_draw_range_elements".
  Using extension "GL_ARB_texture_mirrored_repeat".
  Using extension "GL_ARB_texture_non_power_of_two".
  Using extension "GL_ARB_vertex_buffer_object".
  Using extension "GL_ARB_pixel_buffer_object".
  Using extension "GL_SGIS_generate_mipmap".
  Using extension "GL_EXT_framebuffer_object".
  Using extension "GL_ARB_texture_rectangle".
  Using extension "GL_EXT_bgra".
  Using extension "GL_ARB_texture_cube_map".
  Using extension "GL_EXT_texture_lod_bias".
  Using extension "GL_ARB_point_sprite".
  Using extension "GL_ARB_shading_language_100".
  Using extension "GL_ARB_shader_objects".
  Using extension "GL_ARB_vertex_shader".
  Using extension "GL_ARB_fragment_shader".
  Using extension "GL_ARB_shader_texture_lod".
  Using extension "GL_ARB_texture_float".
  Using extension "GL_ARB_draw_elements_base_vertex".
  Found special extension function "wglSwapIntervalEXT".

Compiling new shader:
   Loading built-in default shader for: soft-v.sdr
   Loading built-in default shader for: soft-f.sdr
Shader features:
   Depth-blended Particles
Compiling new shader:
   Loading built-in default shader for: soft-v.sdr
   Loading built-in default shader for: soft-f.sdr
Shader features:
   Distorted Particles

  Compiling post-processing shader 1 ...
  Compiling post-processing shader 2 ...
  Compiling post-processing shader 3 ...
  Compiling post-processing shader 4 ...
  Compiling post-processing shader 5 ...
   Loading built-in default shader for: fxaa-v.sdr
   Loading built-in default shader for: fxaa-f.sdr
  Compiling post-processing shader 6 ...
   Loading built-in default shader for: fxaapre-f.sdr
  Compiling post-processing shader 7 ...
   Loading built-in default shader for: ls-f.sdr

  Max texture units: 8 (16)
  Max elements vertices: 2147483647
  Max elements indices: 16777215
  Max texture size: 16384x16384
  Max render buffer size: 16384x16384
  Can use compressed textures: YES
  Texture compression available: YES
  Post-processing enabled: YES
  Using trilinear texture filter.
  OpenGL Shader Version: 4.20
... OpenGL init is complete!
Size of bitmap info = 742 KB
Size of bitmap extra info = 48 bytes
ANI cursorweb with size 24x24 (25.0% wasted)
GRAPHICS: Initializing default colors...
Game Settings Table : Using Standard Loops For SEXP Arguments
SCRIPTING: Beginning initialization sequence...
SCRIPTING: Beginning Lua initialization...
LUA: Opening LUA state...
LUA: Initializing base Lua libraries...
LUA: Beginning ADE initialization
ADE: Initializing enumeration constants...
ADE: Assigning Lua session...
SCRIPTING: Beginning main hook parse sequence....
Wokka!  Error opening file (scripting.tbl)!
TABLES: Unable to parse 'scripting.tbl'!  Error code = 5.
TBM  =>  Starting parse of 'mv_flak-sct.tbm' ...
TBM  =>  Starting parse of 'mv_dbrs-sct.tbm' ...
TBM  =>  Starting parse of 'mv_exp-sct.tbm' ...
TBM  =>  Starting parse of 'bp2-trigger-sct.tbm' ...
TBM  =>  Starting parse of 'bp2-tcard-sct.tbm' ...
TBM  =>  Starting parse of 'bp2-stupid-sct.tbm' ...
TBM  =>  Starting parse of 'bp2-debrisgrav-sct.tbm' ...
TBM  =>  Starting parse of 'bp2-csc-sct.tbm' ...
TBM  =>  Starting parse of 'bp2-betty-sct.tbm' ...
SCRIPTING: Inititialization complete.
SCRIPTING: Splash screen overrides checked
SCRIPTING: Splash hook has been run
SCRIPTING: Splash screen conditional hook has been run
Using high memory settings...
Wokka!  Error opening file (interface.tbl)!
WMCGUI: Unable to parse 'interface.tbl'!  Error code = 5.
TBM  =>  Starting parse of 'mv_effects-sdf.tbm' ...
TBM  =>  Starting parse of 'bp-sdf.tbm' ...
Windows reported 16 joysticks, we found 0
Current soundtrack set to -1 in event_music_reset_choices
TBM  =>  Starting parse of 'mv_music-mus.tbm' ...
TBM  =>  Starting parse of 'bp-mus.tbm' ...
TBM  =>  Starting parse of 'bp2-mus.tbm' ...
TBM  =>  Starting parse of 'mv_effects-mfl.tbm' ...
TBM  =>  Starting parse of 'bp-mfl.tbm' ...
TBM  =>  Starting parse of 'bp2-mfl.tbm' ...
Wokka!  Error opening file (armor.tbl)!
TABLES: Unable to parse 'armor.tbl'!  Error code = 5.
TBM  =>  Starting parse of 'mv_effects-amr.tbm' ...
TBM  =>  Starting parse of 'bp2-amr.tbm' ...
TBM  =>  Starting parse of 'bp-aip.tbm' ...
TBM  =>  Starting parse of 'bp2-aip.tbm' ...
TBM  =>  Starting parse of 'mv_effects-wxp.tbm' ...
TBM  =>  Starting parse of 'bp-wxp.tbm' ...
BMPMAN: Found EFF (exp20.eff) with 75 frames at 20 fps.
BMPMAN: Found EFF (ExpMissileHit1.eff) with 92 frames at 20 fps.
BMPMAN: Found EFF (exp04.eff) with 49 frames at 22 fps.
BMPMAN: Found EFF (exp05.eff) with 93 frames at 20 fps.
BMPMAN: Found EFF (exp06.eff) with 92 frames at 22 fps.
BMPMAN: Found EFF (capflash.eff) with 40 frames at 10 fps.
BMPMAN: Found EFF (Maxim_Impact.eff) with 23 frames at 30 fps.
ANI Lamprey_Impact with size 80x80 (37.5% wasted)
BMPMAN: Found EFF (explo3.eff) with 48 frames at 22 fps.
BMPMAN: Found EFF (HFlakExp.eff) with 48 frames at 22 fps.
BMPMAN: Found EFF (exp06b.eff) with 92 frames at 22 fps.
BMPMAN: Found EFF (bomb_flare.eff) with 69 frames at 20 fps.
TBM  =>  Starting parse of 'mv_core-wep.tbm' ...
TBM  =>  Starting parse of 'mv_effects-wep.tbm' ...
TBM  =>  Starting parse of 'mv_assets-wep.tbm' ...
TBM  =>  Starting parse of 'bp-wep.tbm' ...
TBM  =>  Starting parse of 'bp2-wep.tbm' ...
Ignoring free flight speed for weapon 'Trebuchet#Aegis'
Weapon 'Hornet#Weak' requires the "player allowed" flag, but it's not listed!  Adding it by default.
Weapon 'Harpoon#Weak' requires the "player allowed" flag, but it's not listed!  Adding it by default.
Weapon 'Hornet#Weak#Shivan' requires the "player allowed" flag, but it's not listed!  Adding it by default.
Weapon 'Harpoon#Weak#Shivan' requires the "player allowed" flag, but it's not listed!  Adding it by default.
TBM  =>  Starting parse of 'mv_effects-obt.tbm' ...
TBM  =>  Starting parse of 'bp2-obt.tbm' ...
TBM  =>  Starting parse of 'mv_core-shp.tbm' ...
TBM  =>  Starting parse of 'radar-shp.tbm' ...
TBM  =>  Starting parse of 'mv_effects-shp.tbm' ...
TBM  =>  Starting parse of 'mv_assets-shp.tbm' ...
TBM  =>  Starting parse of 'bp-shp.tbm' ...
TBM  =>  Starting parse of 'bp2-shp.tbm' ...
TBM  =>  Starting parse of 'mv_core-hdg.tbm' ...
TBM  =>  Starting parse of 'mv_root-hdg.tbm' ...
ANI support1 with size 108x24 (25.0% wasted)
ANI damage1 with size 148x25 (21.9% wasted)
ANI wingman1 with size 71x53 (17.2% wasted)
ANI wingman2 with size 35x53 (17.2% wasted)
ANI wingman3 with size 14x53 (17.2% wasted)
ANI toggle1 with size 57x20 (37.5% wasted)
ANI head1 with size 164x132 (48.4% wasted)
ANI weapons1 with size 126x20 (37.5% wasted)
ANI weapons1_b with size 150x20 (37.5% wasted)
ANI objective1 with size 149x21 (34.4% wasted)
ANI netlag1 with size 29x30 (6.3% wasted)
ANI targhit1 with size 31x21 (34.4% wasted)
ANI time1 with size 47x23 (28.1% wasted)
ANI targetview1 with size 137x156 (39.1% wasted)
ANI targetview2 with size 4x96 (25.0% wasted)
ANI targetview3 with size 7x20 (37.5% wasted)
ANI 2_energy2 with size 86x96 (25.0% wasted)
ANI 2_reticle1 with size 40x24 (25.0% wasted)
ANI 2_leftarc with size 103x252 (1.6% wasted)
ANI 2_rightarc1 with size 103x252 (1.6% wasted)
ANI 2_toparc2 with size 35x24 (25.0% wasted)
ANI 2_toparc3 with size 41x29 (9.4% wasted)
ANI 2_lead1 with size 26x26 (18.8% wasted)
ANI 2_lock1 with size 56x53 (17.2% wasted)
ANI 2_lockspin with size 100x100 (21.9% wasted)
ANI energy1 with size 12x41 (35.9% wasted)
ANI 2_radar1 with size 209x170 (33.6% wasted)
TBM  =>  Starting parse of 'mv_effects-str.tbm' ...
TBM  =>  Starting parse of 'bp-str.tbm' ...
TBM  =>  Starting parse of 'bp2-str.tbm' ...
loading animated cursor "cursor"
TABLES => Unable to find 'colors.tbl'. Initialising colors with default values.
TABLES => Starting parse of 'mainhall.tbl.
MediaVPs: Flaming debris script loaded!
MediaVPs: Explosions script loaded!
Ships.tbl is : VALID
Weapons.tbl is : VALID
cfile_init() took 3185
Compiling video-processing shader ...
   Loading built-in default shader for: video-v.sdr
   Loading built-in default shader for: video-f.sdr
Got event GS_EVENT_GAME_INIT (49) in state NOT A VALID STATE (0)
Got event GS_EVENT_MAIN_MENU (0) in state GS_STATE_INITIAL_PLAYER_SELECT (37)
Someone passed an extension to bm_load for file '42nd.pcx'
WARNING!, Could not load door anim 2_Exit in main hall
WARNING!, Could not load door anim 2_Pilot in main hall
WARNING!, Could not load door anim 2_Continue in main hall
WARNING!, Could not load door anim 2_Tech in main hall
WARNING!, Could not load door anim 2_Option in main hall
WARNING!, Could not load door anim 2_Campaign in main hall
Got event GS_EVENT_OPTIONS_MENU (8) in state GS_STATE_MAIN_MENU (1)
Frame  0 too long!!: frametime = 0.797 (0.797)
Frame  0 too long!!: frametime = 0.788 (0.788)
Got event GS_EVENT_PREVIOUS_STATE (7) in state GS_STATE_OPTIONS_MENU (5)
WARNING!, Could not load door anim 2_Exit in main hall
WARNING!, Could not load door anim 2_Pilot in main hall
WARNING!, Could not load door anim 2_Continue in main hall
WARNING!, Could not load door anim 2_Tech in main hall
WARNING!, Could not load door anim 2_Option in main hall
WARNING!, Could not load door anim 2_Campaign in main hall
Got event GS_EVENT_NEW_CAMPAIGN (26) in state GS_STATE_MAIN_MENU (1)
Got event GS_EVENT_START_GAME (1) in state GS_STATE_MAIN_MENU (1)

Second half of log in next post.
**** this character limit.
Title: Re: go_even_faster
Post by: Commander Zane on June 12, 2012, 07:43:47 am
Code: [Select]
=================== STARTING LEVEL LOAD ==================
Someone passed an extension to bm_load for file '2_LoadingBGM00.png'
BMPMAN: Found EFF (2_Loading.eff) with 14 frames at 15 fps.
Starting model page in...
Beginning level bitmap paging...
BMPMAN: Found EFF (particleexp01.eff) with 10 frames at 8 fps.
BMPMAN: Found EFF (particlesmoke01.eff) with 54 frames at 15 fps.
BMPMAN: Found EFF (particlesmoke02.eff) with 39 frames at 24 fps.
TBM  =>  Starting parse of 'mv_effects-fbl.tbm' ...
BMPMAN: Found EFF (WarpMap01.eff) with 30 frames at 30 fps.
BMPMAN: Found EFF (WarpMap02.eff) with 30 frames at 30 fps.
BMPMAN: Found EFF (Rock_Exp.eff) with 55 frames at 30 fps.
Loading warp model
Loading model 'warp.pof'
Compiling new shader:
Shader features:
   Lighting
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
Compiling new shader:
Shader features:
   Lighting
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Animated Effects
IBX: Found a good IBX to read for 'warp.pof'.
IBX-DEBUG => POF checksum: 0xbf802ad0, IBX checksum: 0xe7aa5a55 -- "warp.pof"
 300
BMPMAN: Found EFF (shieldhit01a.eff) with 23 frames at 21 fps.
BMPMAN: Found EFF (shieldhit02a.eff) with 45 frames at 30 fps.
BMPMAN: Found EFF (shieldhit03a.eff) with 22 frames at 30 fps.
SHOCKWAVE =>  Loading default shockwave animation...
BMPMAN: Found EFF (shockwave01.eff) with 94 frames at 30 fps.
SHOCKWAVE =>  Default animation load: SUCCEEDED!!
MISSION LOAD: 'bp2-00.fs2'
Hmmm... Extension passed to mission_load...
Starting mission message count : 294
Ending mission message count : 296
Current soundtrack set to -1 in event_music_reset_choices
Current soundtrack set to -1 in event_music_set_soundtrack
Loading model 'nighthawk.pof'
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Normal Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Normal Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Normal Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Normal Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Environment Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Environment Mapping
   Animated Effects
IBX: Found a good IBX to read for 'nighthawk.pof'.
IBX-DEBUG => POF checksum: 0xbbd23708, IBX checksum: 0x9b3d3ae9 -- "nighthawk.pof"
Submodel 'detail-1b' is detail level 1 of 'detail-1a'
Loading model 'KarunaMk1.pof'
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Glow Mapping
   Animated Effects
Potential problem found: Unrecognized subsystem type 'rotatora', believed to be in ship KarunaMk1.pof
Potential problem found: Unrecognized subsystem type 'Reactor02', believed to be in ship KarunaMk1.pof
Potential problem found: Unrecognized subsystem type 'Reactor01', believed to be in ship KarunaMk1.pof
Potential problem found: Unrecognized subsystem type 'Fighterbay', believed to be in ship KarunaMk1.pof
IBX: Found a good IBX to read for 'KarunaMk1.pof'.
IBX-DEBUG => POF checksum: 0xeb4d4687, IBX checksum: 0x03bd3b22 -- "KarunaMk1.pof"
Submodel 'engine01b' is detail level 1 of 'engine01a'
Submodel 'engine01c' is detail level 2 of 'engine01a'
Submodel 'engine01d' is detail level 3 of 'engine01a'
Submodel 'engine01b-destroyed' is detail level 1 of 'engine01a-destroyed'
Submodel 'engine01c-destroyed' is detail level 2 of 'engine01a-destroyed'
Submodel 'engine01d-destroyed' is detail level 3 of 'engine01a-destroyed'
Submodel 'engine02b' is detail level 1 of 'engine02a'
Submodel 'engine02c' is detail level 2 of 'engine02a'
Submodel 'engine02d' is detail level 3 of 'engine02a'
Submodel 'engine02b-destroyed' is detail level 1 of 'engine02a-destroyed'
Submodel 'engine02c-destroyed' is detail level 2 of 'engine02a-destroyed'
Submodel 'engine02d-destroyed' is detail level 3 of 'engine02a-destroyed'
Submodel 'engine03b' is detail level 1 of 'engine03a'
Submodel 'engine03c' is detail level 2 of 'engine03a'
Submodel 'engine03d' is detail level 3 of 'engine03a'
Submodel 'engine03b-destroyed' is detail level 1 of 'engine03a-destroyed'
Submodel 'engine03c-destroyed' is detail level 2 of 'engine03a-destroyed'
Submodel 'engine03d-destroyed' is detail level 3 of 'engine03a-destroyed'
Submodel 'engine04b' is detail level 1 of 'engine04a'
Submodel 'engine04c' is detail level 2 of 'engine04a'
Submodel 'engine04d' is detail level 3 of 'engine04a'
Submodel 'engine04b-destroyed' is detail level 1 of 'engine04a-destroyed'
Submodel 'engine04c-destroyed' is detail level 2 of 'engine04a-destroyed'
Submodel 'engine04d-destroyed' is detail level 3 of 'engine04a-destroyed'
Submodel 'rotatorb' is detail level 1 of 'rotatora'
Submodel 'rotatorc' is detail level 2 of 'rotatora'
Submodel 'rotatord' is detail level 3 of 'rotatora'
Submodel 'rotatorb-destroyed' is detail level 1 of 'rotatora-destroyed'
Submodel 'rotatorc-destroyed' is detail level 2 of 'rotatora-destroyed'
Submodel 'rotatord-destroyed' is detail level 3 of 'rotatora-destroyed'
Allocating space for at least 43 new ship subsystems ...  a total of 200 is now available (43 in-use).
Loading model 'LargeStarbase2.pof'
Potential problem found: Unrecognized subsystem type 'fighterbay1', believed to be in ship LargeStarbase2.pof
Potential problem found: Unrecognized subsystem type 'fighterbay2', believed to be in ship LargeStarbase2.pof
Potential problem found: Unrecognized subsystem type 'fighterbay3', believed to be in ship LargeStarbase2.pof
IBX: Found a good IBX to read for 'LargeStarbase2.pof'.
IBX-DEBUG => POF checksum: 0xc91f26cb, IBX checksum: 0x24217ca5 -- "LargeStarbase2.pof"
Loading model 'Torrent.pof'
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Specular Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Specular Mapping
   Environment Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Specular Mapping
   Environment Mapping
   Animated Effects
Compiling new shader:
Shader features:
   Lighting
   Fog Effect
   Diffuse Mapping
   Specular Mapping
   Environment Mapping
   Animated Effects
IBX: Found a good IBX to read for 'Torrent.pof'.
IBX-DEBUG => POF checksum: 0x8a9221fb, IBX checksum: 0x2e125f81 -- "Torrent.pof"
Loading model 'raynor.pof'
Potential problem found: Unrecognized subsystem type 'fighterbay', believed to be in ship raynor.pof
Potential problem found: Unrecognized subsystem type 'fighterbay', believed to be in ship raynor.pof
IBX: Found a good IBX to read for 'raynor.pof'.
IBX-DEBUG => POF checksum: 0x9b9ac3c6, IBX checksum: 0x9887f033 -- "raynor.pof"
Loading model 'corvette3t-03.pof'
IBX: Found a good IBX to read for 'corvette3t-03.pof'.
IBX-DEBUG => POF checksum: 0x9142af71, IBX checksum: 0xf793794d -- "corvette3t-03.pof"
Loading model 'corvette3t-01.pof'
IBX: Found a good IBX to read for 'corvette3t-01.pof'.
IBX-DEBUG => POF checksum: 0xd009b1ca, IBX checksum: 0xe057b300 -- "corvette3t-01.pof"
Allocating space for at least 32 new ship subsystems ...  a total of 400 is now available (204 in-use).
Loading model 'corvette3t-04.pof'
Potential problem found: Unrecognized subsystem type 'fighterbay', believed to be in ship corvette3t-04.pof
Potential problem found: Unrecognized subsystem type 'deck', believed to be in ship corvette3t-04.pof
IBX: Found a good IBX to read for 'corvette3t-04.pof'.
IBX-DEBUG => POF checksum: 0x4e2075ae, IBX checksum: 0x982c59c1 -- "corvette3t-04.pof"
Loading model 'cruiser3t-01.pof'
IBX: Found a good IBX to read for 'cruiser3t-01.pof'.
IBX-DEBUG => POF checksum: 0x1372f4a4, IBX checksum: 0x81089a12 -- "cruiser3t-01.pof"
Loading model 'FtUhlan.pof'
IBX: Found a good IBX to read for 'FtUhlan.pof'.
IBX-DEBUG => POF checksum: 0xa2610dfb, IBX checksum: 0x848a3cc5 -- "FtUhlan.pof"
Submodel 'Uhland' is detail level 3 of 'Uhlana'
Submodel 'Uhlanc' is detail level 2 of 'Uhlana'
Submodel 'Uhlanb' is detail level 1 of 'Uhlana'
Loading model 'jackal-e.pof'
Potential problem found: Unrecognized subsystem type 'gundoorbl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'gundoorbr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'gundoortl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'gundoortr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'guns', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'hullpodl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'hullpodr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'leftintake', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'leftventbl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'leftventbr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'leftventtl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'leftventtr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'rightintake', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'rightventbl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'rightventbr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'rightventtl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'rightventtr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tailbl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tailbr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tailtl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tailtr', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector1', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector10', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector11', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector12', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector2', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector3', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector4', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector5', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector6', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector7', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector8', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'tdeflector9', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'throttle', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'wingpodl', believed to be in ship jackal-e.pof
Potential problem found: Unrecognized subsystem type 'wingpodr', believed to be in ship jackal-e.pof
IBX: Found a good IBX to read for 'jackal-e.pof'.
IBX-DEBUG => POF checksum: 0xa48165d8, IBX checksum: 0xf96ee8f6 -- "jackal-e.pof"
Loading model 'fighter2t-04.pof'
IBX: Found a good IBX to read for 'fighter2t-04.pof'.
IBX-DEBUG => POF checksum: 0xe611ce17, IBX checksum: 0x97cf5fc2 -- "fighter2t-04.pof"
Loading model 'bomber2t-01.pof'
IBX: Found a good IBX to read for 'bomber2t-01.pof'.
IBX-DEBUG => POF checksum: 0x13bb548d, IBX checksum: 0xad039fff -- "bomber2t-01.pof"
Submodel 'bomb0x-d' is detail level 3 of 'bomb0x-a'
Submodel 'bomb0x-c' is detail level 2 of 'bomb0x-a'
Submodel 'bomb0x-b' is detail level 1 of 'bomb0x-a'
Loading model 'Wraith.pof'
Potential problem found: Unrecognized subsystem type 'gpodf', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'gpodl', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'gpodr', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'panelbl', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'panelbr', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'paneltl', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'paneltr', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'raill', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'railr', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'spiner', believed to be in ship Wraith.pof
Potential problem found: Unrecognized subsystem type 'throttle', believed to be in ship Wraith.pof
IBX: Found a good IBX to read for 'Wraith.pof'.
IBX-DEBUG => POF checksum: 0xf57e7c82, IBX checksum: 0xc002fce6 -- "Wraith.pof"
Loading model 'corvette2t-01.pof'
IBX: Found a good IBX to read for 'corvette2t-01.pof'.
IBX-DEBUG => POF checksum: 0x3aaebe96, IBX checksum: 0x42b3e9a3 -- "corvette2t-01.pof"
Loading model 'kadmos.pof'
IBX: Found a good IBX to read for 'kadmos.pof'.
IBX-DEBUG => POF checksum: 0x2bb9b07f, IBX checksum: 0x1349759e -- "kadmos.pof"
Allocating space for at least 11 new ship subsystems ...  a total of 600 is now available (404 in-use).
Loading model 'GTT_Corsair.pof'
IBX: Found a good IBX to read for 'GTT_Corsair.pof'.
IBX-DEBUG => POF checksum: 0x31d30f0e, IBX checksum: 0xd20321e3 -- "GTT_Corsair.pof"
Loading model 'florence2.pof'
Potential problem found: Unrecognized subsystem type 'Fighterbay', believed to be in ship florence2.pof
IBX: Found a good IBX to read for 'florence2.pof'.
IBX-DEBUG => POF checksum: 0x4f280215, IBX checksum: 0xc1a533bb -- "florence2.pof"
OpenGL: Created 512x512 FBO!
Loading model 'europa.pof'
Model europa.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'europa.pof'.
IBX-DEBUG => POF checksum: 0x401bf33d, IBX checksum: 0xaeae6faf -- "europa.pof"
ANI debris01 with size 51x38 (40.6% wasted)
ANI debris02 with size 26x19 (40.6% wasted)
ANI debris04 with size 36x27 (15.6% wasted)
=================== STARTING LEVEL DATA LOAD ==================
Loading model 'support2t-01.pof'
IBX: Found a good IBX to read for 'support2t-01.pof'.
IBX-DEBUG => POF checksum: 0x6512c7b6, IBX checksum: 0xc0ade8e6 -- "support2t-01.pof"
Submodel 'bodyb' is detail level 1 of 'bodya'
Submodel 'bodyc' is detail level 2 of 'bodya'
Submodel 'bodyd' is detail level 3 of 'bodya'
Loading model 'support2v-01.pof'
IBX: Found a good IBX to read for 'support2v-01.pof'.
IBX-DEBUG => POF checksum: 0xbca18023, IBX checksum: 0x16765db6 -- "support2v-01.pof"
Submodel 'hercb' is detail level 1 of 'herca'
Submodel 'hercc' is detail level 2 of 'herca'
Submodel 'hercd' is detail level 3 of 'herca'
Loading model 'uefsupport.pof'
IBX: Found a good IBX to read for 'uefsupport.pof'.
IBX-DEBUG => POF checksum: 0x63b67740, IBX checksum: 0xcc358647 -- "uefsupport.pof"
Allocating space for at least 510 new ship subsystems ...  a total of 1000 is now available (450 in-use).
About to page in ships!
ANI shieldft-04 with size 112x93 (27.3% wasted)
ANI shieldbt-01 with size 112x93 (27.3% wasted)
ANI shieldlancer with size 112x93 (27.3% wasted)
ANI shieldjackal with size 112x93 (27.3% wasted)
ANI shieldwraith with size 112x93 (27.3% wasted)
ANI shieldainsarii with size 112x93 (27.3% wasted)
BMPMAN: Found EFF (Subach_AniBitmap.eff) with 6 frames at 5 fps.
BMPMAN: Found EFF (PrometheusR_AniBitmap.eff) with 12 frames at 5 fps.
BMPMAN: Found EFF (Kayser_AniBitmap.eff) with 4 frames at 5 fps.
ANI Kayser_Particle with size 80x80 (37.5% wasted)
Loading model 'avenger3.pof'
Model avenger3.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'avenger3.pof'.
IBX-DEBUG => POF checksum: 0x8855f87f, IBX checksum: 0x08b235f9 -- "avenger3.pof"
Loading model 'VulcanGUN.pof'
Model VulcanGUN.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'VulcanGUN.pof'.
IBX-DEBUG => POF checksum: 0x67299b6b, IBX checksum: 0xa705cb68 -- "VulcanGUN.pof"
Loading model 'FB11a.pof'
Model FB11a.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'FB11a.pof'.
IBX-DEBUG => POF checksum: 0x987c87de, IBX checksum: 0x807e2c36 -- "FB11a.pof"
Loading model 'Talon.pof'
Model Talon.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'Talon.pof'.
IBX-DEBUG => POF checksum: 0x3716c44a, IBX checksum: 0x1d16f8c1 -- "Talon.pof"
Loading model 'TachyionGUN.pof'
Model TachyionGUN.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'TachyionGUN.pof'.
IBX-DEBUG => POF checksum: 0x93a351da, IBX checksum: 0x012e3508 -- "TachyionGUN.pof"
Loading model 'Redeemer.pof'
Model Redeemer.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'Redeemer.pof'.
IBX-DEBUG => POF checksum: 0x318c1042, IBX checksum: 0xb212a769 -- "Redeemer.pof"
BMPMAN: Found EFF (particle_blue.eff) with 11 frames at 22 fps.
BMPMAN: Found EFF (AAAbeamAglow.eff) with 35 frames at 30 fps.
BMPMAN: Found EFF (AAAbeamAB.eff) with 15 frames at 15 fps.
BMPMAN: Found EFF (particle_green.eff) with 11 frames at 22 fps.
BMPMAN: Found EFF (GreenBeamGlow.eff) with 30 frames at 60 fps.
Loading model 'Blip.pof'
IBX: Found a good IBX to read for 'Blip.pof'.
IBX-DEBUG => POF checksum: 0x8701ba27, IBX checksum: 0x3ee2fcac -- "Blip.pof"
Submodel 'blipb' is detail level 1 of 'blipa'
Submodel 'blipc' is detail level 2 of 'blipa'
Submodel 'blipd' is detail level 3 of 'blipa'
BMPMAN: Found EFF (BlueBeamGlow2.eff) with 60 frames at 26 fps.
BMPMAN: Found EFF (Particle_Yellow.eff) with 11 frames at 22 fps.
Loading model 'NewHornet.pof'
IBX: Found a good IBX to read for 'NewHornet.pof'.
IBX-DEBUG => POF checksum: 0x2c76000e, IBX checksum: 0x19f7f55e -- "NewHornet.pof"
Loading model 'bombardier.pof'
IBX: Found a good IBX to read for 'bombardier.pof'.
IBX-DEBUG => POF checksum: 0x11edee12, IBX checksum: 0x19816d20 -- "bombardier.pof"
Submodel 'realhornet-b' is detail level 1 of 'realhornet-a'
Submodel 'realhornet-c' is detail level 2 of 'realhornet-a'
Loading model 'crossbow.pof'
No subsystems found for model "crossbow.pof".
IBX: Found a good IBX to read for 'crossbow.pof'.
IBX-DEBUG => POF checksum: 0x19e682bb, IBX checksum: 0x885d0786 -- "crossbow.pof"
Loading model 'piranha.pof'
IBX: Found a good IBX to read for 'piranha.pof'.
IBX-DEBUG => POF checksum: 0x484195d2, IBX checksum: 0xf272dc8a -- "piranha.pof"
BMPMAN: Found EFF (missilespew04.eff) with 20 frames at 30 fps.
Loading model 'belial.pof'
IBX: Found a good IBX to read for 'belial.pof'.
IBX-DEBUG => POF checksum: 0x99bae2a2, IBX checksum: 0x77d1d113 -- "belial.pof"
BMPMAN: Found EFF (missilespew02.eff) with 20 frames at 30 fps.
Loading model 'helios.pof'
IBX: Found a good IBX to read for 'helios.pof'.
IBX-DEBUG => POF checksum: 0xc75db1da, IBX checksum: 0x60bd5c91 -- "helios.pof"
Loading model 'cmeasure01.pof'
IBX: Found a good IBX to read for 'cmeasure01.pof'.
IBX-DEBUG => POF checksum: 0x562739c3, IBX checksum: 0x76256515 -- "cmeasure01.pof"
Loading model 'Longbow.pof'
IBX: Found a good IBX to read for 'Longbow.pof'.
IBX-DEBUG => POF checksum: 0x9ed18a4a, IBX checksum: 0xab339ee0 -- "Longbow.pof"
Loading model 'dirk1pod.pof'
Model dirk1pod.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'dirk1pod.pof'.
IBX-DEBUG => POF checksum: 0xc39767db, IBX checksum: 0xc8c3d73f -- "dirk1pod.pof"
Loading model 'dart.pof'
IBX: Found a good IBX to read for 'dart.pof'.
IBX-DEBUG => POF checksum: 0x5c10bb69, IBX checksum: 0xdfc3e934 -- "dart.pof"
Loading model 'swarmpod.pof'
Model swarmpod.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'swarmpod.pof'.
IBX-DEBUG => POF checksum: 0x52a567ee, IBX checksum: 0xa04f292a -- "swarmpod.pof"
Loading model 'InterceptorT.pof'
IBX: Found a good IBX to read for 'InterceptorT.pof'.
IBX-DEBUG => POF checksum: 0x8d57e22a, IBX checksum: 0x34f751a7 -- "InterceptorT.pof"
Loading model 'DirkPodHC.pof'
Model DirkPodHC.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'DirkPodHC.pof'.
IBX-DEBUG => POF checksum: 0x1a57e9d9, IBX checksum: 0xd238d70f -- "DirkPodHC.pof"
Loading model 'Slammer.pof'
IBX: Found a good IBX to read for 'Slammer.pof'.
IBX-DEBUG => POF checksum: 0xa43d47ec, IBX checksum: 0x99fe9d26 -- "Slammer.pof"
Loading model 'SlammerPOD.pof'
Model SlammerPOD.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'SlammerPOD.pof'.
IBX-DEBUG => POF checksum: 0xb2f95f62, IBX checksum: 0xb2f3ac57 -- "SlammerPOD.pof"
Loading model 'paveway12.pof'
IBX: Found a good IBX to read for 'paveway12.pof'.
IBX-DEBUG => POF checksum: 0xfd1fbe88, IBX checksum: 0x06b8aa20 -- "paveway12.pof"
Loading model 'paveway12rack.pof'
Model paveway12rack.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'paveway12rack.pof'.
IBX-DEBUG => POF checksum: 0x91c338a9, IBX checksum: 0xc0a88b15 -- "paveway12rack.pof"
Loading model 'hellfire.pof'
IBX: Found a good IBX to read for 'hellfire.pof'.
IBX-DEBUG => POF checksum: 0x095d2434, IBX checksum: 0xbf74030a -- "hellfire.pof"
Loading model 'hellfireEXT.pof'
Model hellfireEXT.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'hellfireEXT.pof'.
IBX-DEBUG => POF checksum: 0x80933ea9, IBX checksum: 0xb4bff5af -- "hellfireEXT.pof"
BMPMAN: Found EFF (missilespew03.eff) with 20 frames at 30 fps.
Loading model 'MissileM.pof'
IBX: Found a good IBX to read for 'MissileM.pof'.
IBX-DEBUG => POF checksum: 0x00957668, IBX checksum: 0x7b7e1778 -- "MissileM.pof"
BMPMAN: Found EFF (missilespew01.eff) with 20 frames at 30 fps.
Loading model 'GBU-240.pof'
IBX: Found a good IBX to read for 'GBU-240.pof'.
IBX-DEBUG => POF checksum: 0xb388876a, IBX checksum: 0x7eebd3b1 -- "GBU-240.pof"
Loading model 'hornet.pof'
IBX: Found a good IBX to read for 'hornet.pof'.
IBX-DEBUG => POF checksum: 0x066a989a, IBX checksum: 0x8d7227a4 -- "hornet.pof"
Loading model 'SlammerCluster.pof'
IBX: Found a good IBX to read for 'SlammerCluster.pof'.
IBX-DEBUG => POF checksum: 0x615fcf8e, IBX checksum: 0x41858756 -- "SlammerCluster.pof"
Loading model 'debris01.pof'
IBX: Found a good IBX to read for 'debris01.pof'.
IBX-DEBUG => POF checksum: 0x974f214b, IBX checksum: 0x0cb49c79 -- "debris01.pof"
Loading model 'debris02.pof'
IBX: Found a good IBX to read for 'debris02.pof'.
IBX-DEBUG => POF checksum: 0x8e0eed50, IBX checksum: 0x3e979514 -- "debris02.pof"
BMPMAN: Found EFF (explode1.eff) with 43 frames at 25 fps.
BMPMAN: Found EFF (PWmuzzle.eff) with 4 frames at 30 fps.
BMPMAN: Found EFF (Gmuzzle.eff) with 5 frames at 30 fps.
BMPMAN: Found EFF (Bmuzzle.eff) with 5 frames at 30 fps.
BMPMAN: Found EFF (Cmuzzle.eff) with 4 frames at 30 fps.
BMPMAN: Found EFF (Rmuzzle.eff) with 4 frames at 30 fps.
Paging in mission messages
Stopping model page in...
ANI support1.ani with size 108x24 (25.0% wasted)
ANI damage1.ani with size 148x25 (21.9% wasted)
ANI wingman1.ani with size 71x53 (17.2% wasted)
ANI wingman2.ani with size 35x53 (17.2% wasted)
ANI wingman3.ani with size 14x53 (17.2% wasted)
ANI toggle1.ani with size 57x20 (37.5% wasted)
ANI head1.ani with size 164x132 (48.4% wasted)
ANI weapons1.ani with size 126x20 (37.5% wasted)
ANI weapons1_b.ani with size 150x20 (37.5% wasted)
ANI objective1.ani with size 149x21 (34.4% wasted)
ANI netlag1.ani with size 29x30 (6.3% wasted)
ANI targhit1.ani with size 31x21 (34.4% wasted)
ANI time1.ani with size 47x23 (28.1% wasted)
ANI targetview1.ani with size 137x156 (39.1% wasted)
ANI targetview2.ani with size 4x96 (25.0% wasted)
ANI targetview3.ani with size 7x20 (37.5% wasted)
ANI 2_energy2.ani with size 86x96 (25.0% wasted)
ANI 2_reticle1.ani with size 40x24 (25.0% wasted)
ANI 2_leftarc.ani with size 103x252 (1.6% wasted)
ANI 2_rightarc1.ani with size 103x252 (1.6% wasted)
ANI 2_toparc2.ani with size 35x24 (25.0% wasted)
ANI 2_toparc3.ani with size 41x29 (9.4% wasted)
ANI 2_lead1.ani with size 26x26 (18.8% wasted)
ANI 2_lock1.ani with size 56x53 (17.2% wasted)
ANI 2_lockspin.ani with size 100x100 (21.9% wasted)
ANI energy1.ani with size 12x41 (35.9% wasted)
ANI 2_radar1.ani with size 209x170 (33.6% wasted)
ANI debris01.ani with size 51x38 (40.6% wasted)
ANI debris02.ani with size 26x19 (40.6% wasted)
ANI debris04.ani with size 36x27 (15.6% wasted)
ANI shieldft-04.ani with size 112x93 (27.3% wasted)
ANI shieldbt-01.ani with size 112x93 (27.3% wasted)
ANI shieldlancer.ani with size 112x93 (27.3% wasted)
ANI shieldjackal.ani with size 112x93 (27.3% wasted)
ANI shieldwraith.ani with size 112x93 (27.3% wasted)
ANI shieldainsarii.ani with size 112x93 (27.3% wasted)
ANI Kayser_Particle.ani with size 80x80 (37.5% wasted)
User bitmap 'TMP256x256+8'
User bitmap 'TMP256x256+8'
User bitmap 'TMP512x512+8'
User bitmap 'TMP256x256+8'
Bmpman: 2556/4750 bitmap slots in use.
Ending level bitmap paging...
=================== ENDING LOAD ================
Real count = 790,  Estimated count = 425
================================================
MediaVPs: Flaming debris script ACTIVE!
SCRIPTING: Starting flashy deaths script loading

Received post for event GS_EVENT_START_BRIEFING during state transtition. Find Allender if you are unsure if this is bad.
Got event GS_EVENT_START_BRIEFING (15) in state GS_STATE_START_GAME (52)
ANI 2_BriefMap with size 918x400 (21.9% wasted)
ANI iconwing01 with size 32x28 (12.5% wasted)
Loading model 'Dirk1TECH.pof'
Model Dirk1TECH.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'Dirk1TECH.pof'.
IBX-DEBUG => POF checksum: 0xf5646d37, IBX checksum: 0x400509a3 -- "Dirk1TECH.pof"
Loading model 'SlammerTECH.pof'
Model SlammerTECH.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'SlammerTECH.pof'.
IBX-DEBUG => POF checksum: 0x3c502a43, IBX checksum: 0x5049ba9f -- "SlammerTECH.pof"
Loading model 'Paveway12tech.pof'
Model Paveway12tech.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'Paveway12tech.pof'.
IBX-DEBUG => POF checksum: 0x344be43d, IBX checksum: 0x75449096 -- "Paveway12tech.pof"
Loading model 'hellfireTECH.pof'
Model hellfireTECH.pof has a null moment of inertia!  (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'hellfireTECH.pof'.
IBX-DEBUG => POF checksum: 0x8c777831, IBX checksum: 0xab24a941 -- "hellfireTECH.pof"
Frame  0 too long!!: frametime = 48.551 (48.551)
Got event GS_EVENT_ENTER_GAME (2) in state GS_STATE_BRIEFING (10)
Entering game at time = 138.511
Compiling new shader:
Shader features:
   Diffuse Mapping
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
   
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Normal Mapping
   Environment Mapping
   
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   
Frame  1 too long!!: frametime = 0.703 (0.703)
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   
message 'evac' with invalid head.  Fix by assigning persona to the message.
ANI Head-CM14b.ani with size 160x120 (6.3% wasted)
Compiling new shader:
Shader features:
   Lighting
   Diffuse Mapping
   Glow Mapping
   Specular Mapping
   Environment Mapping
   
1386 frames executed in  30.033 seconds,  46.149 frames per second.
message 'roger that' with invalid head.  Fix by assigning persona to the message.
ANI Head-CM11b.ani with size 160x120 (6.3% wasted)
message 'good luck' with invalid head.  Fix by assigning persona to the message.
Got event GS_EVENT_END_GAME (4) in state GS_STATE_GAME_PLAY (2)
Unloading in mission messages
WARNING!, Could not load door anim 2_Exit in main hall
WARNING!, Could not load door anim 2_Pilot in main hall
WARNING!, Could not load door anim 2_Continue in main hall
WARNING!, Could not load door anim 2_Tech in main hall
WARNING!, Could not load door anim 2_Option in main hall
WARNING!, Could not load door anim 2_Campaign in main hall
Got event GS_EVENT_QUIT_GAME (5) in state GS_STATE_MAIN_MENU (1)
Freeing all existing models...
... Log closed, Tue Jun 12 07:29:40 2012
Title: Re: go_even_faster
Post by: pecenipicek on June 12, 2012, 07:58:58 am
engines and spinny bits seem offset forward and do not spin, in my case, disabling the merge index buffer flag helped here.
Title: Re: go_even_faster
Post by: Spoon on June 12, 2012, 08:07:51 am
I has graph
(http://img824.imageshack.us/img824/515/graphv.png)
For extra clarification: The Both line is when collision detection system and merged index buffers are enabled
Index is when only merged index buffers are enabled
Collision is when only blabla
Normal is with both disabled.

Recorded with fraps, first mission of WoD2. Unlike BP massive battle, the ships shooting at each other are not in very close proximity to each other so maybe that's why the new collision code isn't able to show its true colors in this case.

Bug report: One wierdness with the merged index buffers is this:
(http://img854.imageshack.us/img854/8350/screen0172.jpg)
The mission starts with a ship that is in a state of EXPLODING. A lot of its turrets are gone (turrets are set destroyed from the mission start)

(http://img341.imageshack.us/img341/8914/screen0171.jpg)
However with merged index buffers enabled all of the turrets are there.
Even the ones that are set to be destroyed by sexp a second later remain visible (there's the explosion and sound but the subobject remains untouched)
(Sowwy for the dark screenshots)
Title: Re: go_even_faster
Post by: pecenipicek on June 12, 2012, 08:13:26 am
okay, some data from me, fps benchmarks from fraps, using bp2-massive battle. no graphs yet, but have some raw data.

http://egzodus.com/dir/new_col_swif_build.7z  - using the new collision flag - Video (http://youtu.be/ZpoaPGtwhLo)

http://egzodus.com/dir/old_col_swif_build.7z   - same build, with the new collision disabled - Video (http://youtu.be/p8ReupYuIIw)

http://egzodus.com/dir/old_col_rc6.7z - taken with RC6 - Video (http://youtu.be/Aqhyt-_zArM)

videos and other shenanigans coming soon-ish

[edit] Have a fps graph. reference the names with the above.
(http://egzodus.com/dir/fps_graph.jpg)

[edit#2] have a frametime graph as well.
(http://egzodus.com/dir/frametime.jpg)
Title: Re: go_even_faster
Post by: Echelon9 on June 12, 2012, 08:18:15 am
Here's a small update so this can compile on Linux (gcc 4.6.3).  It seems that gcc doesn't include hash_map in the std library - my change is a rough hack which may not work correctly in Windows or OSX.

For OS X, following change in vmallocator.h, replace:
Code: [Select]
#include <hash_map>with:
Code: [Select]
#if defined __GNUC__ || defined __APPLE__
#include <ext/hash_map>
#else
#include <hash_map>
#endif

And in gropenglextension.h:245, add the following lines:
Code: [Select]
#define PFNGLDRAWELEMENTSBASEVERTEXPROC         glDrawElementsBaseVertex
#define PFNGLDRAWRANGEELEMENTSBASEVERTEXPROC    glDrawRangeElementsBaseVertex
#define PFNGLDRAWELEMENTSINSTANCEDBASEVERTEXPROC glDrawElementsInstancedBaseVertex
#define PFNGLMULTIDRAWELEMENTSBASEVERTEXPROC    glMultiDrawElementsBaseVertex

When all that is done, we still now have to get OpenGL.framework from OSX 10.7 to load and setup an OpenGL context for the four new gl calls above. Hrmm.
Title: Re: go_even_faster
Post by: jr2 on June 12, 2012, 08:25:27 am
For collisions, I think the 2nd or 3rd mission in Dimensional Eclipse would work nicely, right?  The one that starts with a cutscene zooming out, and they blow up the station where you were supposed to go to collect your pay?  IIRC I got ~10FPS max on that one.
Title: Re: go_even_faster
Post by: Kobrar44 on June 12, 2012, 09:28:01 am

(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/th_UnknownGlitch.png) (http://s97.photobucket.com/albums/l223/SpootKnight/FreeSpace/?action=view&current=UnknownGlitch.png)


This one happens to me without "merged stuff", I mean subspace portal behind everything in the scene.
Also, didn't know it was CPU that was holding FPS low on WiH intro, and gpu usage still isn't 100%  :eek:
Title: Re: go_even_faster
Post by: Spoon on June 12, 2012, 10:02:25 am
For collisions, I think the 2nd or 3rd mission in Dimensional Eclipse would work nicely, right?  The one that starts with a cutscene zooming out, and they blow up the station where you were supposed to go to collect your pay?  IIRC I got ~10FPS max on that one.
I tried that one just now but like valathil
First bug report. Game hangs on loading Tethis.pof in bp2-massivebattle with the released bp2 version. Spoon reports BP SVN seems to be working. I get one core 100% and then nothing no error etc.
the game hangs on loading the mission when the new collision code is activated
Title: Re: go_even_faster
Post by: Valathil on June 12, 2012, 10:53:08 am
Also, didn't know it was CPU that was holding FPS low on WiH intro, and gpu usage still isn't 100%  :eek:

Thats what most people around here don't seem to know. The game assests as they stand (polycount, texture size, ship count in mission) are not even close to what current or even 5 year old graphics hardware is capable of. It's just that the engine is soooo friggin ineffiecient to tell the gpu what to draw and some other things that are badly done which slow down the game. 
Title: Re: go_even_faster
Post by: pecenipicek on June 12, 2012, 11:41:45 am
updated my post with video links as well. the swifty build - new collision code disabled version is still uploading however.
Title: Re: go_even_faster
Post by: The E on June 12, 2012, 11:44:29 am
Issues I found (after editing the BP shaders to get them to use the new code):

(http://blueplanet.fsmods.net/E/pics/screen0099.png)
(http://blueplanet.fsmods.net/E/pics/screen0100.png)
(http://blueplanet.fsmods.net/E/pics/screen0102.png)
(http://blueplanet.fsmods.net/E/pics/screen0103.png)

I should note that most of these issues (apart from the subspace vortex one) are caused by the merged_ibo code.

In addition, the exe crashed due to something going wrong in the batch renderer while I was trying to load a second mission, for some reason, this code block from the beginning of batch_render_all() caused trouble:
Code: [Select]
if ( Batch_buffer != NULL ) {
vm_free(Batch_buffer);
}

Just for completeness' sake, here are the shaders I used:

main-v
Code: [Select]
#ifdef FLAG_ENV_MAP
uniform mat4 envMatrix;
varying vec3 envReflect;
#endif

#ifdef FLAG_NORMAL_MAP
varying mat3 tbnMatrix;
#endif

#ifdef FLAG_TRANSFORM
attribute float model_id;
uniform sampler2D transform_tex;
varying float blown_off;
#endif

#ifdef FLAG_FOG
varying float fogDist;
#endif

varying vec4 position;
varying vec3 lNormal;

void main()
{
mat4 orient = mat4(1.0);
mat4 scale = mat4(1.0);
 #if SHADER_MODEL > 2
  #ifdef FLAG_TRANSFORM
int idx = int(model_id);
vec4 column;
for(int i = 0; i < 3; ++i) {
column = texelFetch(transform_tex, ivec2(i, idx), 0);
column[i] *= column.w;
orient[i] = vec4(
column.x,
column.y,
column.z,
0.0
);
}
column = texelFetch(transform_tex, ivec2(3, idx), 0);
orient[3] = vec4(
column.x,
column.y,
column.z,
1.0
);
blown_off = column.a;
  #endif
 #endif

gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;
gl_Position = gl_ProjectionMatrix * gl_ModelViewMatrix * orient * gl_Vertex;
gl_FrontColor = gl_Color;
gl_FrontSecondaryColor = vec4(0.0, 0.0, 0.0, 1.0);

 // Transform the normal into eye space and normalize the result.
position = gl_ModelViewMatrix * orient * gl_Vertex;;
vec3 normal = normalize(gl_NormalMatrix * gl_Normal);
lNormal = normal;

 #ifdef FLAG_NORMAL_MAP
 // Setup stuff for normal maps
vec3 t = normalize(gl_NormalMatrix * gl_MultiTexCoord1.xyz);
vec3 b = cross(normal, t) * gl_MultiTexCoord1.w;
tbnMatrix = mat3(t, b, normal);
 #endif

 #ifdef FLAG_ENV_MAP
 // Environment mapping reflection vector.
envReflect = reflect(position.xyz, normal);
envReflect = vec3(envMatrix * vec4(envReflect, 0.0));
envReflect = normalize(envReflect);
 #endif

 #ifdef FLAG_FOG
fogDist = clamp((gl_Position.z - gl_Fog.start) * 0.75 * gl_Fog.scale, 0.0, 1.0);
 #endif

 #ifdef __GLSL_CG_DATA_TYPES
 // Check necessary for ATI specific behavior
gl_ClipVertex = (gl_ModelViewMatrix * orient * gl_Vertex);;
 #endif
}

main-f
Code: [Select]
#ifdef FLAG_LIGHT
uniform int n_lights;
#endif

#ifdef FLAG_DIFFUSE_MAP
uniform sampler2D sBasemap;
#endif

#ifdef FLAG_GLOW_MAP
uniform sampler2D sGlowmap;
#endif

#ifdef FLAG_SPEC_MAP
uniform sampler2D sSpecmap;
#endif

#ifdef FLAG_ENV_MAP
uniform samplerCube sEnvmap;
uniform bool alpha_spec;
varying vec3 envReflect;
#endif

#ifdef FLAG_NORMAL_MAP
uniform sampler2D sNormalmap;
varying mat3 tbnMatrix;
#endif

#ifdef FLAG_TEAMCOLOR
uniform vec3 base_color;
uniform vec3 stripe_color;
#endif

#ifdef FLAG_FOG
varying float fogDist;
#endif

#ifdef FLAG_ANIMATED
uniform sampler2D sFramebuffer;
uniform int effect_num;
uniform float anim_timer;
uniform float vpwidth;
uniform float vpheight;
#endif

#ifdef FLAG_TRANSFORM
varying float blown_off;
#endif

varying vec4 position;
varying vec3 lNormal;
uniform  bool desaturate;

#if SHADER_MODEL == 2
  #define MAX_LIGHTS 2
#else
  #define MAX_LIGHTS 8
#endif

#define SPEC_INTENSITY_POINT 3.3 // Point light
#define SPEC_INTENSITY_DIRECTIONAL 2.0 // Directional light
#define SPECULAR_FACTOR 1.75
#define SPECULAR_ALPHA 0.1
#define SPEC_FACTOR_NO_SPEC_MAP 0.6
#define ENV_ALPHA_FACTOR 0.3
#define GLOW_MAP_INTENSITY 1.5
#define AMBIENT_LIGHT_BOOST 1.0

void main()
{
#ifdef FLAG_TRANSFORM
if(blown_off > 0.9)
discard;
#endif

vec3 eyeDir = vec3(normalize(-position).xyz); // Camera is at (0,0,0) in ModelView space
vec4 lightAmbientDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightAmbient = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightSpecular = vec4(0.0, 0.0, 0.0, 1.0);
vec2 texCoord = gl_TexCoord[0].xy;

 #ifdef FLAG_SPEC_MAP
vec4 specColour = texture2D(sSpecmap, texCoord);
 #endif
 
 #ifdef FLAG_NORMAL_MAP
vec4 NormalMap = texture2D(sNormalmap, texCoord);
 #endif
 
 #ifdef FLAG_TEAMCOLOR
  #ifdef FLAG_NORMAL_MAP
    vec2 teamMask = NormalMap.rb;
  #else
vec2 teamMask = vec2(0.0);
  #endif
 #endif

 #ifdef FLAG_LIGHT
  #ifdef FLAG_NORMAL_MAP
// Normal map - convert from DXT5nm
vec3 normal;
normal.rg = (NormalMap.ag * 2.0) - 1.0;
   #ifdef FLAG_ENV_MAP
vec3 envOffset = vec3(0.0);
envOffset.xy = normal.xy;
vec3 envReflectNM = envReflect + envOffset;
vec4 envColour = textureCube(sEnvmap, envReflectNM);
   #endif
normal.b = sqrt(1.0 - dot(normal.rg, normal.rg));
normal = tbnMatrix * normal;
float norm = length(normal);
// prevent breaking of normal maps
if (length(normal) > 0.0)
normal /= norm;
else
normal = tbnMatrix * vec3(0.0, 0.0, 1.0);
  #else
vec3 normal = lNormal;
   #ifdef FLAG_ENV_MAP
vec4 envColour = textureCube(sEnvmap, envReflect);
   #endif
  #endif

vec3 lightDir;
lightAmbient = gl_FrontMaterial.emission + (gl_LightModel.ambient * gl_FrontMaterial.ambient);
float dist;

#pragma optionNV unroll all
for (int i = 0; i < MAX_LIGHTS; ++i) {
  #if SHADER_MODEL > 2
if (i > n_lights)
break;
  #endif

float specularIntensity = 1.0;
float attenuation = 1.0;

// Attenuation and light direction
  #if SHADER_MODEL > 2
if (gl_LightSource[i].position.w == 1.0) {
  #else
if (gl_LightSource[i].position.w == 1.0 && i != 0) {
  #endif
// Positional light source
dist = distance(gl_LightSource[i].position.xyz, position.xyz);
lightDir = (gl_LightSource[i].position.xyz - position.xyz);

  #if SHADER_MODEL > 2
if (gl_LightSource[i].spotCutoff < 91.0) {  // Tube light
float beamlength = length(gl_LightSource[i].spotDirection);
vec3 beamDir = normalize(gl_LightSource[i].spotDirection);
// Get nearest point on line
float neardist = dot(position.xyz - gl_LightSource[i].position.xyz , beamDir);
// Move back from the endpoint of the beam along the beam by the distance we calculated
vec3 nearest = gl_LightSource[i].position.xyz - beamDir * abs(neardist);
lightDir = nearest - position.xyz;
dist = length(lightDir);
}
  #endif

lightDir = normalize(lightDir);
attenuation = 1.0 / (gl_LightSource[i].constantAttenuation + (gl_LightSource[i].linearAttenuation * dist) + (gl_LightSource[i].quadraticAttenuation * dist * dist));
specularIntensity = SPEC_INTENSITY_POINT;

} else {
// Directional light source
lightDir = normalize(gl_LightSource[i].position.xyz);
specularIntensity = SPEC_INTENSITY_DIRECTIONAL;
}
vec3 half_vec = normalize(lightDir + eyeDir);

// Ambient and Diffuse
lightAmbient += (gl_FrontLightProduct[i].ambient * attenuation);
lightDiffuse += (gl_FrontLightProduct[i].diffuse * (max(dot(normal, lightDir), 0.0)) * attenuation);

// Specular
  #ifdef FLAG_NORMAL_MAP
mat3 tan_mat = mat3(tbnMatrix[2], tbnMatrix[1], tbnMatrix[0]);
mat3 bin_mat = mat3(tbnMatrix[2], tbnMatrix[0], tbnMatrix[1]);
vec3 tan = normalize(tan_mat * normal);
vec3 bin = normalize(bin_mat * normal);

float _AlphaX = 0.3;
float _AlphaY = 0.1;

float dotHN = clamp(dot(normal, half_vec), 0.0, 1.0);
float dotVN = clamp(dot(normal, eyeDir), 0.0001, 1.0);
float dotHTAlphaX = dot(half_vec, tan) / _AlphaX;
float dotHBAlphaY = dot(half_vec, bin) / _AlphaY;

lightSpecular += dotVN * exp((-2.0 * ((dotHTAlphaX * dotHTAlphaX) + (dotHBAlphaY * dotHBAlphaY))) / (1.0 + dotVN)) * (gl_FrontLightProduct[i].specular * attenuation) * specularIntensity;
lightSpecular += ((gl_FrontLightProduct[i].specular * pow(dotHN, gl_FrontMaterial.shininess)) * attenuation) * specularIntensity;
  #else
float NdotHV = clamp(dot(normal, half_vec), 0.0, 1.0);
lightSpecular += ((gl_FrontLightProduct[i].specular * pow(NdotHV, gl_FrontMaterial.shininess)) * attenuation) * specularIntensity;
  #endif
}

lightAmbientDiffuse = lightAmbient + lightDiffuse;
 #else
lightAmbientDiffuse = gl_Color;
lightSpecular = gl_SecondaryColor;
 #endif

 #ifdef FLAG_ANIMATED
vec2 distort = vec2(cos(position.x*position.w*0.005+anim_timer*20.0)*sin(position.y*position.w*0.005),sin(position.x*position.w*0.005+anim_timer*20.0)*cos(position.y*position.w*0.005))*0.03;
 #endif

 // Base color
 #ifdef FLAG_DIFFUSE_MAP
  #ifdef FLAG_ANIMATED
vec4 baseColor;
if (effect_num == 2) {
baseColor = texture2D(sBasemap, texCoord + distort*(1.0-anim_timer));
} else {
baseColor = texture2D(sBasemap, texCoord);
}
  #else
vec4 baseColor = texture2D(sBasemap, texCoord);
  #endif
 #else
vec4 baseColor = gl_Color;
 #endif

 #ifdef FLAG_TEAMCOLOR
vec3 base = base_color - vec3(0.5);
vec3 stripe = stripe_color - vec3(0.5);
baseColor.rgb += (base * teamMask.x) + (stripe * teamMask.y);
 #endif
 
vec4 fragmentColor;
fragmentColor.rgb = baseColor.rgb * max(lightAmbientDiffuse.rgb * AMBIENT_LIGHT_BOOST, gl_LightModel.ambient.rgb - 0.425);
fragmentColor.a = baseColor.a;

 // Spec color
 #ifdef FLAG_SPEC_MAP
  #ifdef FLAG_TEAMCOLOR
specColour.rgb += ((base * teamMask.x) + (stripe * teamMask.y)) * 0.3;
  #endif
fragmentColor.rgb += lightSpecular.rgb * (specColour.rgb * SPECULAR_FACTOR);
fragmentColor.a += (dot(lightSpecular.a, lightSpecular.a) * SPECULAR_ALPHA);
 #else
fragmentColor.rgb += lightSpecular.rgb * (baseColor.rgb * SPEC_FACTOR_NO_SPEC_MAP);
 #endif

 // Env color
 #ifdef FLAG_ENV_MAP
vec3 envIntensity = (alpha_spec) ? vec3(specColour.a) : specColour.rgb;
fragmentColor.a += (dot(envColour.rgb, envColour.rgb) * ENV_ALPHA_FACTOR);
fragmentColor.rgb += envColour.rgb * envIntensity;
 #endif

 // Glow color
 #ifdef FLAG_GLOW_MAP
fragmentColor.rgb += texture2D(sGlowmap, texCoord).rgb * GLOW_MAP_INTENSITY;
 #endif

 #ifdef FLAG_FOG
fragmentColor.rgb = mix(fragmentColor.rgb, gl_Fog.color.rgb, fogDist);
 #endif

//Commented out. If HDR makes a comeback, we may need this.
//fragmentColor.a = clamp(fragmentColor.a ,0.0,1.0);

 #ifdef FLAG_ANIMATED
if (effect_num == 0) {
float shinefactor = 1.0/(1.0 + pow((fract(abs(gl_TexCoord[0].x))-anim_timer) * 1000.0, 2.0)) * 1000.0;
gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);
gl_FragColor.a = fragmentColor.a * clamp(shinefactor * (fract(abs(gl_TexCoord[0].x))-anim_timer) * -10000.0,0.0,1.0);
}
if (effect_num == 1) {
float shinefactor = 1.0/(1.0 + pow((position.y-anim_timer), 2.0));
gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);
#ifdef FLAG_LIGHT
gl_FragColor.a = fragmentColor.a;
#else
// ATI Wireframe fix *grumble*
gl_FragColor.a = clamp((position.y-anim_timer) * 10000.0,0.0,1.0);
#endif
}
if (effect_num == 2) {
vec2 screenPos = gl_FragCoord.xy * vec2(vpwidth,vpheight);
gl_FragColor.a = fragmentColor.a;
float cloak_interp = (sin(position.x*position.w*0.005+anim_timer*20.0)*sin(position.y*position.w*0.005)*0.5)-0.5;
#ifdef FLAG_LIGHT
gl_FragColor.rgb = mix(texture2D(sFramebuffer, screenPos + distort*anim_timer + anim_timer*0.1*normal.xy).rgb,fragmentColor.rgb,clamp(cloak_interp+anim_timer*2.0,0.0,1.0));
#else
gl_FragColor.rgb = mix(texture2D(sFramebuffer, screenPos + distort*anim_timer + anim_timer*0.1*lNormal.xy).rgb,fragmentColor.rgb,clamp(cloak_interp+anim_timer*2.0,0.0,1.0));
#endif
}
 #else
gl_FragColor = fragmentColor;
 #endif
}
Title: Re: go_even_faster
Post by: Commander Zane on June 12, 2012, 12:33:47 pm

(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/th_UnknownGlitch.png) (http://s97.photobucket.com/albums/l223/SpootKnight/FreeSpace/?action=view&current=UnknownGlitch.png)


This one happens to me without "merged stuff", I mean subspace portal behind everything in the scene.
Also, didn't know it was CPU that was holding FPS low on WiH intro, and gpu usage still isn't 100%  :eek:
Wow I didn't even catch that. I was posting that to show the goofy blue "wall" that I'm guessing is covering a section of the skybox (?).
Title: Re: go_even_faster
Post by: Valathil on June 12, 2012, 03:19:19 pm
ok I found some bugs in the new bsp parser and fixed them up. Sry no patch (dont know how to make patch of patch) just the 3 files i modified.

[attachment deleted by a ninja]
Title: Re: go_even_faster
Post by: AndrewofDoom on June 12, 2012, 03:55:17 pm
So this is what I encountered:

I found that when running Dimensional Eclipse, and have the new collision code and/or merged index buffer enabled, it seems pretty much any mission that has the Tethys/Narayana as well as loading it in the Tech room just causes it to lock up when it starts to load it. Funny part is the old, unoptimized Tethys works perfectly fine.

Secondly, when I enabled the merged index buffer code, I get this:

(https://dl.dropbox.com/u/17350885/frees2-20120612-154314.png)

Fancy new cloaks they got there. So, just to make sure the collision actually worked, I ran into the invisible buddy Hurricane.

(https://dl.dropbox.com/u/17350885/frees2-20120612-154324.png)

Great success! I'm in intense pain. But...am I the only person who has all the ships go invisible?

But even with both of those features off, I got around a 12 FPS boost in the more intense missions of Dimensional Ecplise (22 - > 33 FPS on Nexus Station).
Title: Re: go_even_faster
Post by: Kobrar44 on June 14, 2012, 01:28:47 pm
I've just seen rakshaza firing a beam through sarynthon without harming it. Several times. I'll doublecheck it yet
edit: without merged index buffer I haven't noticed such a thing. Plus, pics:
(http://i48.tinypic.com/2akixdh.jpg)
Maxim in all its glory
(http://i47.tinypic.com/5le81s.jpg)
I guess it's visible that there is no hit. Reproduced many times, appears only with merged index buffer, or I'm blind. Project: Outreach, BTW. Mission 5
(http://i48.tinypic.com/solndf.jpg)
Right beam hasn't hit, but from this angle can't tell if it's bug or miss, haven't seen this again also. Probably sarynthon-specific issue.

edit:edit:Also, AFAIK, submodel translation was hard to implement because of the collision system. So it'd seem like now there's hope? :D
Title: Re: go_even_faster
Post by: MatthTheGeek on June 16, 2012, 06:59:42 am
(http://img525.imageshack.us/img525/5066/screen0020.png)

(http://img256.imageshack.us/img256/3558/screen0019.png)

EDIT: log (http://pastebin.com/AjzMLkaK)
Title: Re: go_even_faster
Post by: Swifty on June 20, 2012, 02:27:05 pm
I spent the past couple days debugging my collision code. I tried Valathil's patch but it doesn't seem to fix anything so I ended up scrapping that and look for what's really causing collision bugs.

What's going on is that bounding boxes in the collision data structure in POFs can hold multiple polygons for testing which I failed to account for. Because not all polygons are being tested in the bounding box tree, we're getting hit misses and worse yet, infinite loops when parsing the POF data structure.

So I fixed that last night. I haven't made new builds yet but that'll likely come sometime this week.
Title: Re: go_even_faster
Post by: headdie on June 20, 2012, 04:32:11 pm
good news, and nicely done tackling this
Title: Re: go_even_faster
Post by: Kolgena on June 20, 2012, 05:32:18 pm
Good to hear. Is that at all related to weird model rotations?
Title: Re: go_even_faster
Post by: MatthTheGeek on June 21, 2012, 02:41:52 am
So I fixed that last night. I haven't made new builds yet but that'll likely come sometime this week.
If you can, still send the svn patches our way. There are some of us that can actually follow and apply the tutorials for building your own stuff.
Title: Re: go_even_faster
Post by: Swifty on June 21, 2012, 04:03:09 am
I can't be bothered to make patches right now so I'll just point you to the git repository I'm making my commits to.

https://github.com/SamuelCho/Freespace-Open-Swifty/tree/go_even_faster
Title: Re: go_even_faster
Post by: Swifty on June 24, 2012, 03:30:36 pm
New builds. Read first post for more info.
Title: Re: go_even_faster
Post by: Spoon on June 24, 2012, 05:33:25 pm
Yayifications!
Title: Re: go_even_faster
Post by: Kobrar44 on June 26, 2012, 11:10:56 am
I have a weird impression like I've done something wrong
http://pastebin.com/jda1vMUH (http://pastebin.com/jda1vMUH)
I dunno what to do :( Thing obviously ctded.
Played Artemis, played Delenda Est and haven't finished Delenda Est because of CTD, it was quick and swift.
Title: Re: go_even_faster
Post by: Talon 1024 on June 28, 2012, 03:24:29 am
I've tested this build a little bit with the FS2 Retail campaign.

With merged index buffers enabled, the Psamtik is invisible in mission 1, and the Boadicea (asteroid base) does not break up properly in mission 2.

Here are some screenshots of the Boadicea in mission 2, before and after the asteroid "breaks up":
(http://www.ciinet.org/kevin/myimages/others/Boadiceabefore.png) (http://www.ciinet.org/kevin/myimages/others/Boadiceabefore.png)
(http://www.ciinet.org/kevin/myimages/others/Boadiceaafter3.png) (http://www.ciinet.org/kevin/myimages/others/Boadiceaafter3.png)
And here is a debug log of my playthrough of mission 2:
http://www.ciinet.org/kevin/myimages/others/fs2_open_m2_gef.log (http://www.ciinet.org/kevin/myimages/others/fs2_open_m2_gef.log)
Title: Re: go_even_faster
Post by: Swifty on June 28, 2012, 05:21:29 am
I wrote shaders that are needed to get this feature working. Make sure no SDR files are in your effects folder. MediaVPs also have their own shaders which might be a problem. You could try grabbing the SDR files Valathil posted in this thread and putting those in your effects folder.
Title: Re: go_even_faster
Post by: Spoon on June 28, 2012, 06:42:53 am
Whenever I die and hit restart with this build, the game crashes like 2 to 10 seconds ingame. Debug log records nothing of this event.

Edit: And not just that. When I visit the F3 ship lab it will load exactly one ship. After viewing the first, it will consistently crash on trying to view the second one.
Title: Re: go_even_faster
Post by: Swifty on July 04, 2012, 10:39:45 pm
New builds uploaded with some fixes. Check the OP.
Title: Re: go_even_faster
Post by: mjn.mixael on July 04, 2012, 11:04:52 pm
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.
Title: Re: go_even_faster
Post by: Swifty on July 27, 2012, 12:54:01 am
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.
Title: Re: go_even_faster
Post by: Valathil on July 27, 2012, 05:17:41 am
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.
Title: Re: go_even_faster
Post by: Swifty on July 29, 2012, 12:39:05 pm
Everybody, no problems? I'm going to commit go_even_faster by the end of tonight.
Title: Re: go_even_faster
Post by: niffiwan on July 30, 2012, 08:09:29 am
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]
Title: Re: go_even_faster
Post by: Swifty on August 01, 2012, 03:17:25 am
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.
Title: Re: go_even_faster
Post by: Swifty on August 02, 2012, 12:26:50 am
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.
Title: Re: go_even_faster
Post by: Echelon9 on August 02, 2012, 02:27:37 am
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.
Title: Re: go_even_faster
Post by: niffiwan on August 02, 2012, 07:16:45 am
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...)
Title: Re: go_even_faster
Post by: Swifty on August 02, 2012, 12:39:59 pm
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.

Title: Re: go_even_faster
Post by: Echelon9 on August 02, 2012, 11:02:23 pm
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
Title: Re: go_even_faster
Post by: The E on August 02, 2012, 11:04:22 pm
But that's not related to go even faster in the slightest....
Title: Re: go_even_faster
Post by: niffiwan on August 02, 2012, 11:07:49 pm
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!!!!   :) 
Title: Re: go_even_faster
Post by: Echelon9 on August 03, 2012, 02:27:17 am
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?
Title: Re: go_even_faster
Post by: niffiwan on August 03, 2012, 04:16:48 am
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;
        }

Title: Re: go_even_faster
Post by: Swifty on August 03, 2012, 01:05:47 pm
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.
Title: Re: go_even_faster
Post by: niffiwan on August 03, 2012, 06:36:51 pm
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.



Title: Re: go_even_faster
Post by: Echelon9 on August 03, 2012, 08:10:50 pm
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?
Title: Re: go_even_faster
Post by: Swifty on August 04, 2012, 01:09:47 am
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.
Title: Re: go_even_faster
Post by: niffiwan on August 04, 2012, 01:56:15 am
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.

OK - FSO running slow in debug isn't a bit deal to me (it's expected behaviour, right?  ;)), waiting 15 mins for it to exit kinda is though - although I haven't really seen any drawbacks to just killing it off - so that's probably an OK workaround.  It'll probably confuse a normal user trying to generate a debug log though.

I suspect that the function below is causing the problem, the entire file is wrapped in an #ifdef SCP_UNIX so you probably won't have seen the issue on Windows. There's a linked list (RamTable) keeping track of all the allocated memory and its size, with the old collision code RamTable has a max size of approx 19,000 entries, with the new collision code I've seen it as high as approx 263,000 - and that function has a woefully slow way of finding the pointer of memory it's looking for.  When the list is around 263,000 entries in size, it was taking approx a minute to remove 1000 entries from the list - obviously it gets faster and faster as you remove more and more entries.   I'll see if I can re-factor it to be more efficient when dealing with large number of entries.

tl;dr doesn't seem to be a problem with the new collision code itself, it's just triggering a different issue in debug.

Code: (code/windows_stub/stubs.cpp) [Select]
#ifndef NDEBUG
void _vm_free( void *ptr, char *filename, int line )
#else
void _vm_free( void *ptr )
#endif
{
    if ( !ptr ) {
#ifndef NDEBUG
        mprintf(("Why are you trying to free a NULL pointer?  [%s(%d)]\n", clean_filename(filename), line));
#else
        mprintf(("Why are you trying to free a NULL pointer?\n"));
#endif
        return;
    }

#ifndef NDEBUG
    RAM *item = RamTable;
    RAM **mark = &RamTable;

    while (item != NULL) {
        if (item->addr == (ptr_u)ptr) {
            RAM *tmp = item;

            *mark = item->next;

            TotalRam -= tmp->size;

            free(tmp);

            break;
        }

        mark = &(item->next);

        item = item->next;
    }
#endif // !NDEBUG

    free(ptr);
}
Title: Re: go_even_faster
Post by: Echelon9 on August 04, 2012, 10:20:03 pm
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.

It work successfully if the follow section in gropengl.h comments out the #ifndef GL_ARB_draw_elements_base_vertex section:
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

i.e. it's not an issue with the correct branch selection upon #ifdef __APPLE__, but the earlier check if GL_ARB_draw_elements_base_vertex is defined.

Could this because of also having at code/graphics/gl/GLext.h:6681:
Code: [Select]
#ifndef GL_ARB_draw_elements_base_vertex
#define GL_ARB_draw_elements_base_vertex 1
...
Title: Re: go_even_faster
Post by: Valathil on August 04, 2012, 11:04:38 pm
i think i see what is happening here. Swifty included those function prototypes because in his mac test he couldnt find the ProcPtr's in his glext headers. However he named the functions XXXXX instead of XXXXXXProcPtr like every other function prototype on mac so what happens now if your mac install has a newer glext in it it triggers the ifndef but the #defines in glextension.h look for the XXXXX format. I did a full Code Review of the go_even_faster patch as a courtesy to swifty and advised him strongly about changing the function prototypes to XXXXXXProcPtr so i guess either the next version he posts or the direct commit will have this in and should alleviate any leftover problems with the mac stuff.
Title: Re: go_even_faster
Post by: Echelon9 on August 05, 2012, 01:03:47 am
Yup, using XXXXXXXProcPtr form makes sense to me too.
Title: Re: go_even_faster
Post by: Spoon on August 05, 2012, 01:27:40 pm
Ganbatte Swifty-sama~
Title: Re: go_even_faster
Post by: Swifty on August 05, 2012, 01:52:23 pm
i think i see what is happening here. Swifty included those function prototypes because in his mac test he couldnt find the ProcPtr's in his glext headers. However he named the functions XXXXX instead of XXXXXXProcPtr like every other function prototype on mac so what happens now if your mac install has a newer glext in it it triggers the ifndef but the #defines in glextension.h look for the XXXXX format. I did a full Code Review of the go_even_faster patch as a courtesy to swifty and advised him strongly about changing the function prototypes to XXXXXXProcPtr so i guess either the next version he posts or the direct commit will have this in and should alleviate any leftover problems with the mac stuff.

That's not what's happening. #define GL_ARB_draw_elements_base_vertex 1 is getting called first in glext.h so regardless, the base vertex function pointers in gropengl.h won't get set.

I'll add ProcPtr to those function pointers for posterity but what's the real solution? Should I just remove those #defines? should I throw the #ifndef into the #else subconditional?
Title: Re: go_even_faster
Post by: Valathil on August 05, 2012, 04:05:24 pm
That's not what's happening. #define GL_ARB_draw_elements_base_vertex 1 is getting called first in glext.h so regardless, the base vertex function pointers in gropengl.h won't get set.

and because #define GL_ARB_draw_elements_base_vertex 1 is getting triggered you dont have anything that defines the #PFNGLXXXXX YYYYY conversions in glextensions.h just rename those to ProcPtr also leave the other stuff where it is and it should work with both old and new glext.h
Title: Re: go_even_faster
Post by: Echelon9 on August 11, 2012, 02:06:07 am
Worked this one through with Swifty today, and the code patch to go_even_faster here (https://github.com/SamuelCho/Freespace-Open-Swifty/commit/ba008350267e94d91f466a52ad60d945811df2f0), fixes the Mac compile issues.

Thanks Swifty and Valathil.

go_even_faster ready to commit?
Title: Re: go_even_faster
Post by: Swifty on August 11, 2012, 04:24:07 pm
It's done.