[Cobra]

so, what do they do, anyway?

i mean, how do they help?

and is this on the same level as 3.6.5

[Nuke]

oh cool p4 optimisation, i hope it works

hey no crashy in this build, and i think the load time improved too.
yay!

[WMCoolmon]

I can't build for AMD specifically, only Intel processors, but according to MSDN, the /G7 option will also optimize for AMD Athlon processors.

Also, if anybody has any info about the warp bug, it's wanted.

[Cobra]

hey, i actually played through an SCP mission and it didn't crash! YAY! it wiped out my virtual memory, though.

[mrduckman]

I have amd64 and I get the memleaks when loading the mission:

Setting language to English
soundcard = EAX
** MAX_CHANNELS set to 64.  DS reported 64.
Failed to init speech
GR_CPU: Family 15, MMX=Yes
Using PURE D3D DeviceWindow in debugging mode... mouse clicking may cause problems!
Alpha texture format = ARGB, 4:4:4:4
Non-alpha texture format = ARGB, 1:5:5:5
D3D_32bit 1, bits_per_pixel 32Direct3D Initialized OK!
Size of bitmap info = 755 KB
Size of bitmap extra info = 52 bytes
ANI cursorweb with size 24x24 (25.0% wasted)
Using high memory settings...
ANI 2_radar1 with size 170x170 (33.6% wasted)
ML Freespace Multi Log - Opened Sun, Jan 23, 2005  at 04:06PM
----
----
----


Windoze reported 16 joysticks, we found 1
Current soundtrack set to -1 in event_music_reset_choices
cf_get_file_list_preallocated looking for type=7, filter="*-mus.tbm"
cf_get_file_list_preallocated looking for type=7, filter="*-wxp.tbm"
couldn't find particle pcx for Akheton SDG
found ani Akheton_Particle for Akheton SDG, with 11 frames and 25 fps
couldn't find particle pcx for Morning Star
found ani Morningstar_Particle for Morning Star, with 21 frames and 10 fps
couldn't find particle pcx for MorningStar D
found ani Morningstar_Particle for MorningStar D, with 21 frames and 10 fps
couldn't find particle pcx for Maxim
found ani Maxim_Particle for Maxim, with 21 frames and 10 fps
couldn't find particle pcx for Maxim D
found ani Maxim_Particle for Maxim D, with 21 frames and 10 fps
couldn't find particle pcx for UD-8 Kayser
ANI Kayser_Particle with size 80x80 (37.5% wasted)
found ani Kayser_Particle for UD-8 Kayser, with 7 frames and 30 fps
couldn't find particle pcx for UD-D Kayser
found ani Kayser_Particle for UD-D Kayser, with 7 frames and 30 fps
couldn't find pcx for Circe
found ani Circe_Bitmap for Circe, with 20 frames and 15 fps
couldn't find particle pcx for Lamprey
ANI Lamprey_Particle with size 86x86 (32.8% wasted)
found ani Lamprey_Particle for Lamprey, with 9 frames and 20 fps
couldn't find particle pcx for Shivan Heavy Laser
found ani Shivan_Laser_Stream for Shivan Heavy Laser, with 11 frames and 35 fps
couldn't find particle pcx for Shivan Mega Laser
found ani Shivan_Laser_Stream for Shivan Mega Laser, with 11 frames and 35 fps
cf_get_file_list_preallocated looking for type=7, filter="*-wep.tbm"
Wokka!  Error opening file (difficulty.tbl)!
Unable to parse 5ifficulty!  Code = 1242160.
cf_get_file_list_preallocated looking for type=7, filter="*-shp.tbm"
Wokka!  Error opening file (hud_gauges.tbl)!
Unable to parse hud_gauges.tbl!  Code = 5.
cf_get_file_list_preallocated looking for type=7, filter="*-hdg.tbm"
ML 01/23 16:06:30~   psnet_init() detected lan connection
ML 01/23 16:06:30~   psnet_get_ip() reports IP : 0.0.0.0

ML 01/23 16:06:30~   Receive buffer set to 4096

ML 01/23 16:06:30~   Send buffer set to 4096

ML 01/23 16:06:30~   Error on IPX startup 10047

ML 01/23 16:06:30~   Network
ML 01/23 16:06:30~   Found no RAS connections
cf_get_file_list_preallocated looking for type=25, filter="*.pcx"
cf_get_file_list_preallocated looking for type=32, filter="*.pcx"
loading animated cursor "cursor"
ANI cursor with size 24x24 (25.0% wasted)
Ships.tbl is : VALID
Weapons.tbl is : VALID
cfile_init() took 31
Got event GS_EVENT_TEAM_SELECT (49) in state NOT A VALID STATE (49)
Loading 2_ChoosePilot-m.pcx for the first time.
MEMLEAK DEBUG: lock pcx
cf_get_file_list_preallocated looking for type=28, filter="*.pl2"
cf_get_file_list_preallocated looking for type=28, filter="*.plr"
Loading 2_ChoosePilot.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_CPB_060002.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading cursor.ani for the first time.
ANI cursor.ani with size 24x24 (25.0% wasted)
Loading 2_CPB_050001.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_CPB_050002.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Got event GS_EVENT_MAIN_MENU (0) in state GS_STATE_VIEW_CUTSCENES (0)
Loading 77th.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_MainHall1-m.pcx for the first time.
MEMLEAK DEBUG: lock pcx
ANI 2_mainwalk.ani with size 477x477 (6.8% wasted)
ANI 2_mainflyby.ani with size 189x189 (26.2% wasted)
ANI 2_maincrane.ani with size 116x116 (9.4% wasted)
ANI 2_mainexit.ani with size 174x174 (32.0% wasted)
ANI 2_mainbarracks.ani with size 158x158 (38.3% wasted)
ANI 2_mainreadyroom.ani with size 145x145 (43.4% wasted)
ANI 2_maintechroom.ani with size 119x119 (7.0% wasted)
ANI 2_mainoptions.ani with size 206x206 (19.5% wasted)
ANI 2_maincampaign.ani with size 190x190 (25.8% wasted)
Loading 2_MainHall1.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Creating surface for front buffer of size: 1024 768Frame  0 too long!!: frametime = 0.872 (0.872)
Loading 2_Pop3.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_Pop_020000.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_Pop_030000.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_Pop_040000.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_Pop_020001.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Loading 2_Pop_020002.pcx for the first time.
MEMLEAK DEBUG: lock pcx
Got event GS_EVENT_WEAPON_SELECTION (26) in state GS_STATE_MAIN_MENU (26)
Got event GS_EVENT_START_GAME (1) in state GS_STATE_MAIN_MENU (1)
=================== STARTING LEVEL LOAD ==================
Freeing all existing models...

[taylor]

MEMLEAK DEBUG: lock pcx

Isn't a memory leak.  It's just a notice that a PCX was loaded into memory.  There is no check to see if it's ever free'd and it doesn't keep track of them anyway.

I run everything through Valgrind ever few months or so.  That will catch any memleaks that aren't platform specific so if a leak is hiding somewhre it will be found.  There are no known leaks still in the code in general.  The D3D code was gone through with a fine toothed comb during the last big memory leak.  If anything is still hiding in there it's really hiding.

[Taristin]

I have a problem with wmcoolmon's latest builds...

Actually, 2:

Often I cannot enter the techroom with the game in full screen mode. The game will crash. The few times I have been able to enter the techroom, there were no ships listed, not even the ulysses which was rotating in the display. The next and previous buttons for the tech room ship select did nothing either.

In windowed mode, the game runs, the techroom works and everything is nice, except that screenshots don't work. I cannot take screenshots in windowed mode.

Kinda annoying when the game will only run in windowed mode, and you want to take screenies to show off something.

[Bobboau]

has seen this as well.

[WMCoolmon]

It would be EXTREMELY helpful if people would run a debug build at least once when reporting a bug. Knowing what exactly went wrong is much much much much MUCH easier to debug than just knowing when it wrong.

Also, anything involving the techroom I at least need to know your command line options.

Unfortunately, taylor, it looks like there is a memory leak; I've been trying to debug that today, but it's been eluding capture. Basically, every 1-2 missions the game will CTD in a release build. It may be because I'm not freeing models correctly in the selection screen.

But back to the crash, I had a problem playing with Bobb's orion, the symptoms were similar to what you described. Eventually I just removed it, as it was having the same problem as the corrupt Perseus POF. (See my post near the bottom of this page)

[WMCoolmon]

Forgot to mention, I also had to recreate my pilot a few times as the switching between inferno and normal pilots seems buggy...I didn't lose any progress (Since I used the same name as the old pilot) but I did have to reset my options.

[Taristin]

I have run debug builds.

When in windowed mode, the debug build reports an assertion error when I click on the techroom. When I try to click any of the buttons (accept, retry, abort, or whatever) I cannot. It goes straight to the desktop. Alt - tab brings me back to the game, but it still has the assertion error dialogue and I cannot continue until I seleect an option. Tab doesn't work for selecting buttons, nor does the spacebar or enter button.

It's b0rked.

[WMCoolmon]

Well, it'd be nice to know the assert. The trick with those things is that when your mouse moves over, the cursor disappears, but you can still click the buttons. Knowing what the text says could help greatly.

It looks like this mem leak has something to do with Subsys_status - at least, I get an error in debug mode when FS2 tries to free it.

[Mr_Maniac]

Well... If I would find a bug that I want to report, I WOULD run the debug build...
... if the debug build would run!
Everytime I try to run a mission it gives me a "Visual C++ something" error...
I will make a screenshot of it...
Oh... This error isn't just in THIS build...
It appears in EVERY build...

[Taristin]

Originally posted by WMCoolmon
Well, it'd be nice to know the assert. The trick with those things is that when your mouse moves over, the cursor disappears, but you can still click the buttons. Knowing what the text says could help greatly.

It looks like this mem leak has something to do with Subsys_status - at least, I get an error in debug mode when FS2 tries to free it.

Ok, tried again... wasn't an assertion this time... but that something 'ext' was corrupted...

I tried to make a screencapture, but it didn't work, either.

[WMCoolmon]

Hmm,I thought (hoped) I'd fixed that already in my last update to the build. It's used in some of the eff-loading code...

[Taristin]

Perhaps. Did you upload two versions of that one build?

[taylor]

Originally posted by WMCoolmon
It looks like this mem leak has something to do with Subsys_status - at least, I get an error in debug mode when FS2 tries to free it.

Strange.  This is just recently right, after my change to make it dynamic?  Does Personas crash, since it's done the same way?  I made Subsys_status dynamic even before 3.6.5 was released so it's been tested pretty well before getting in CVS.  I keep getting a crash in audiostr when it tries to free the second conversion buffer.  Something has gotten a little fubar me thinks.  It's just been in the last two weeks when these weird memory errors started showing up and they usually involve freeing something.

[WMCoolmon]

Originally posted by WMCoolmon
This update, I basically tried to fix the warpout bug and played around with my fancy-pants compiler. The release build is globally optimized for P4 processors, if you get any significant speed increase/decrease please post it, along with your processor. I've noticed what seems to be a significant speed increase on loading with my AMD64.

Oh, and I fixed the ext memory error bug.

That was my last update.

Edit: taylor, actually, yes; both seem to have problems with the command to get the amount of space freed (int actual_size = something). Personas only happens when FS2 closes, though, so it hasn't been as much of a problem. I was having problems with the second audiostream buffer before either of these popped up (I think I may have posted a thread on it in the internal, and no one responded.)

I'm not sure if it was actually the cause of the crash, I also found that there seemed to be a problem in the sexpAlloc function, called with a string value of "pilot" I looked round a little but couldn't really figure out what it did or what would cause the error, as the rest of the functions in the call stack display all pointed to the freeing for Subsys_status up until that function.

[taylor]

Originally posted by WMCoolmon
I was having problems with the second audiostream buffer before either of these popped up (I think I may have posted a thread on it in the internal, and no one responded.)

Missed that thread I think.

I'm not sure if it was actually the cause of the crash, I also found that there seemed to be a problem in the sexpAlloc function, called with a string value of "pilot" I looked round a little but couldn't really figure out what it did or what would cause the error, as the rest of the functions in the call stack display all pointed to the freeing for Subsys_status up until that function.

I just started with me last week in my stable tree but before I moved the Subsys_status changes into stable for extra testing before going in CVS.  But both of them are crashing only on free() for you?  Subsys_status is used in a way that makes it a little weird to do dynamically (size requirements will raise and drop during parse) so the way I'm did it seemed to work the best without a lot of memory fragmentaion or rewriting more code.  Has Personas been causing a problem (it was in 3.6.5 and the betas) or did it just start?

[WMCoolmon]

I'm guessing both are crashing on free, because I've been getting an access violation error when debugging from VC++.net

Unfortunately, like I said, I also get one when sexp_alloc is called and Personas is freed on exit - so I can't determine which causes the ingame CTD, or if Personas causes one. If either error were to occur in a release build it'd be fatal.

I can actually continue past the sexp_alloc and the Subsys_status ones, haven't really tried with Personas.

As for when I noticed Subsys_status, that would be when I made the last update to the current build. I may have occured beforehand - I couldn't run fs2_open for awhile without texture switching occuring a few minutes into a mission (Usually resulting in a crash later on). I'm also being VERY hefty with memory requirements, running with *everything* on and the full mVP (Aside from aseffects). I can try running without these and seeing if it makes a difference.

Edit: Actually, it was later than that, when I noticed it was crashing every 1-2 missions reliably. Sorry, I haven't been making too many memory-allocation changes lately and haven't felt the need to take it slow... The things I think might be most troublesome would be the updates I made awhile back to try and make the ship tables dynamic (I didn't, really, I rolled back that change). I should go back and double-check those sometime, the online CVS browser would be very handy for that, but it's currently broken...