[taylor]

This is the same as the Linux build except that it's for Windows.  This is the first post merge build so be on the lookout for new bugs.  There were quite a few networking changes needed to be crossplatform so be sure to check that multiplayer works as expected and with other builds.  This does not include the D3D shinemaps fix from Bobboau.

This build should fix the memory related crashes but I don't know if it gets all of them.  Also the music VP related crashes should be fixed but it needs testing to know for sure.  This build is current CVS only and contains no other in-testing code.

The DevIL dlls are no longer needed as the decoders are built in now.  Please take note of any TGAs and/or JPGs that stop working and report them (filenames, model used on, where to get for testing purposes).


*UPDATED*

 - A few more memory related fixes are in it.
 - Some OpenGL VBO speedups and hopefully the crash is fixed too.
 - The problem Tolwyn reported with MAX_BUFFERS_PER_SUBMODEL should be fix.
 - The in-cockpit thing should work for OGL now but that's not really tested very much.
 - A proposed OGG fix is here but I don't now how likely it is to fix anything.

Not sure what the lockup problems are yet but see if you get the same thing with this build.

http://icculus.org/~taylor/fso/testing/20050212-win32.zip

Added to the website.//redmenace

[Alpha0]

Taylor, I have tried your build to check if the mv_music.vp problems were still there. Testing using the mission "Rites of Passage" from Derelict - my favorite test mission for anything, I found out that there are still issues with ogg support. FS hangs at the beginning of mission loading. No error messages, it just looks as if it is going in an endless loop. The Numbers soundtrack is used. I also tried the main campaign mission "The Sixth Wonder", editing the Soundtrack from Leviticus (no oggs present) to Joshua (almost half of the music is ogg format) and this caused an illegal operation crash at beginning of mission load. The related message from the errorlog is "Read from location 00000000 caused an access violation". The same happens with the campaign mission "Return to Babel", which uses Revelation as its soundtrack.

I will try to play a bit with the code and the debug build, as I feel something is not right with the ogg_mmio_seek callback. I will post back if I discover anything.

Having said that, this build appears to be more solid and stable than anything else so far, aside from the mv_music.vp issues. I take this opportunity to say that there has been some exceptional work going on in this project and everyone involved should be proud of it. Keep up the good work guys.

[phatosealpha]

Well, I'm having issues too.  About 30 seconds to a minute into any mission, FSO locks up in this build.

Also, I'm noticing the loadout screen has become extraordinairly picky about where you click the loadouts.  It took me 5 tries to pick up stilletto, and it's never done that before.  Not sure if it's just very finicky about where you pick it up or if it's just not responding most of the time though.

[vellanet]

I'm also having lockup isssues

[taylor]

For the lockup problems, what cmdline options are you using?  Are you testing with or without the music VP?  Post your error.log file entries too (just the top 7 or 8 lines from the last crash entry will be enough).

[Alpha0]

After some more thorough testing and experimentation with the new build and code, I have two observations to make:

1. Unfortunately my earlier statement about stability seems to not be correct. I also experienced quite a few lock-ups at various points, always in-mission. Only way out when this happened was to terminate FS with Task Manager. The thing is, I did not have anything like that happening the first time I tested. I guess I was lucky the first time. The command line options I use are -glow -jpgtga -fov 0.39 -ambient_factor 80 -env -alpha_env -fps. I was testing without the music vp at that time.

2. I believe I've found a pattern regarding the music vp issue, after experimenting with the source code and changing the return of the ogg_mmio_seek() callback to -1 in ogg.cpp: Lets assume that I have two missions, A and B. Mission A has a soundtrack containing oggs, while mission B has a soundtrack containing only wav files (according to mv_music.vp). When I try to load mission A immediately, it crashes. But if I load mission B first, which is using only wav, exit mission and then try to load A, everything goes well and ogg music plays perfectly. In fact, once I have loaded mission B first, I can load as many ogg soundtrack missions as I want, no problem. I am not sure why this happens, my understanding of the sound code is really very limited, but someone more acquainted with it could probably deduct something.

[WMCoolmon]

In debug builds, I get a 'stack around bit_16 corrupted'  message; the function is unpack_pixel, when bm_lock_ani is trying to lock the cursor. I've looked through the function but can't see anything obvious; the only thing I can come up with is that in  convert_24_to_16(), bm_set_components takes a ubyte pointer, and bit_16 is cast to it.

The error seems to occur in both D3D and OGL, and I can't continue past it.

[taylor]

Ignoring the OGG problem for a moment, when does the freezing tend to occur?  Is it random or always in a particular place?


@WMCoolmon:  Are you using 16 or 32 bit color in the Launcher?  If it doesn't happen when you select 16-bit then I know what the problem is.  I made a change with the Linux merge which probably caused this for D3D but should have always happened for OGL.  bm_set_components() has 16 and 32 bit versions but convert_24_to_16() assumes that it's only getting a 16 value sent back when it could be 32.  There was a change that someone made to the BM_SELECT_*_FORMAT() functions that forced it to use the 16bit version.  I'll have to check to know for sure but this should be as easy as making a bm_set_components_32() for 32-bit stuff and having bm_set_components() be 16bit only.  I'll go a ahead and do that today.

[Alpha0]

Freezing occurs randomly for me. It has happened at various missions, sometimes a minute into the mission, sometimes after quite a while. The only thing I am sure of is that it happens only during mission, not at menu screens. What I also noticed is that whenever it happened, it was just before executing an event, mostly a new wing/ship entrance. Unfortunately nothing gets registered in errorlog.txt at the time of the lock-up, so I can not be any more specific than this. I guess it is time to fire up the debug build and see if anything happens there.

[WMCoolmon]

Taylor: Yep, 16-bit mode fixed it.

[taylor]

Originally posted by WMCoolmon
Taylor: Yep, 16-bit mode fixed it.

Ok, I made change in CVS earlier so I think that will take care of it from now on.   I never noticed it before with OGL but thought it would likely be a problem.  Kinda curious as to whether or not it caused other weird issues too.  It was actually wrong in the original source release believe it or not.  Looks like someone tried to fix it later but they did a crappy job of it.

bm_get_components() has the same issue but it's only used in the neb.cpp code and that assumes 32-bit anyway.  I hadn't planned to fix that one but if you think it could be needed in other code I'll go ahead and make the change to that as well.

[Trivial Psychic]

I'm getting lockups in this build too.  I was playing TBP Raider Wars and it locked up just as a friendly ship turned hostile, LOCKUP.  The music continued to play in the background, which is reminiscent of an old bug I used to have, where it would lockup on me.  Dropping from AGP 4X back to 2 or 1X, or more recently 8X back to 4X, seemed to solve that problem (as well as others).  However, I'm currently running in 4X so its not that problem.

Later!

[Tolwyn]

Hmm, with the recent build a problem showed up, which I can not explain. One of our older models uses a lot of textures, but it worked flawlessly with all builds... up to this one. I am sure, that we have less than 16 maps used, maybe exact 16, but surely no more, since everything else would cause an immidiate CTD. Here is the error message

Error: Submodel detail1 on model TCS_Tallahasse-class.pof has more than 16 textures.
Find a high-limit build or remap the model.
File:U:\src\cvs\fs2_open.linux\code\Model\ModelInterp.cpp
Line: 5300

Call stack:
------------------------------------------------------------------
------------------------------------------------------------------

Taylor's build fs2_open_r-T365.exe works flawlessly.

[taylor]

Originally posted by Tolwyn
that we have less than 16 maps used, maybe exact 16, but surely no more

The error message got moved to a slightly different place but the logic wasn't changed to compensate.  Because of that the test will fail if you use exactly 16 textures.  Uber simple to fix and thanks for pointing it out as I don't think anyone else would have noticed until after the next official build.

[WMCoolmon]

Taylor, is your OGG code in CVS? I ran into a crash error involving the OGG code, the relevant section is:

Code: [Select]

cfp = mmioOpen(fullpath, NULL, MMIO_ALLOCBUF | MMIO_READ);
mmioSeek( cfp, FileOffset, SEEK_SET );

if ( cfp == NULL ) {
goto OPEN_ERROR;
}

if(!strnicmp(pszFilename + strlen(pszFilename) - 3, "ogg", 3))
{
Assert(true);
}

//Try to open the OGG
if(!ov_open_callbacks(cfp, &m_ogg_info, NULL, 0, mmio_callbacks))
{

The problem is that OGG seeks to the beginning of the file and then reads (I think).

Another problem is that in line 592 of Neb.cpp, I added a call to jpeg_read_header to handle nebula images in JPG format - or so I thought. Apparently img_cfp is NULL at the start of the call, triggering an assert.

Both of these are in debug mode, running The Great Hunt from the techroom. I've got the mediaVPs installed.

Edit: I think this also needs to be changed, its a little ways down the same function, in case a specified file isn't an OGG or a WAV file.

Code: [Select]

// Skip the "RIFF" tag and file size (8 bytes)
// Skip the "WAVE" tag (4 bytes)
mmioSeek( cfp, 12, SEEK_CUR );

That seek call is actually a modified version from the CVS file, as there's already a seek to the FileOffset (see above code sample) for the OGG code.

Edit 2: Okay, belay that. Turns out that causes problems when an OGG isn't found, because it seeks to the start of the file.

[taylor]

Originally posted by WMCoolmon
Taylor, is your OGG code in CVS? I ran into a crash error involving the OGG code, the relevant section is:

The problem is that OGG seeks to the beginning of the file and then reads (I think).

Yeah I got everything in, except what I'm testing now.  I was taking another look at it and I think we maybe need to test just using CFILE rather than mmio.  Another mmio test is to split that initial seek to FileOffset in order to have an ogg specific version.  That way have have the initial set setup for OGG already using ogg_raw_seek(), before the ogg_info() call.  Using CFILE we can get around that because CFILE manages all of that for us.  The only issue will be the performance cost for doing that.  I'd rather try getting mmio to work first though.  Another option is to just make it non-seekable but that's imposing some limits and would be more work for us.  I'd almost rather go with CFILE than do that.

For now that seek thing seems to work.  I played through The Great Hunt twice in two different loads with a reload in each without issue.

Another problem is that in line 592 of Neb.cpp, I added a call to jpeg_read_header to handle nebula images in JPG format - or so I thought. Apparently img_cfp is NULL at the start of the call, triggering an assert.

Crap.  Yeah I forgot to add the check and get the right filename if it's NULL.  I'll get that fixed right away.

[WMCoolmon]

Well, I already did the non-seekable thing. That was what my last major change to the OGG code did.

I'd rather not go with CFILE, if at all possible, it'll just slow things down.

The problem is that OGG doesn't seem to care about where the pointer is set when it gets the handle, if it can seek; it just seeks to the beginning of the file that music is stored in. If that's a VP, then that causes problems. (Are you testing with mv_music.vp, or individual OGG files?)

[taylor]

I'm using mv_music.vp.  I'm updating this build and we'll see if that seek change has any affect.  I works for me but the last change seemed to as well so I'll wait to pass judgement on the fix until someone else gives it a try.

[Setekh]

This build is pretty good for me taylor, cheers.

Hey vellanet, welcome to HLP.

[EVOSteven]

I get a hang up around the 3rd bar on the loading screen, i have -spec -glow -rlm -dualscanlines -ship_choice_3d -orbradar -3dwarp -ballistic_gauge -smart_shields -mpnoreturn on. Ill try a debug build and see what it says.

I did a debug and i got some stuff like


Wokka!  Error opening file (difficulty.tbl)!
Unable to parse 'difficulty.tbl'!  Code = 5.
Loaded modular ship table file ships.tbl
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"

and

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

ML 02/12 22:09:30~   Invalid socket id passed to nw_NewCloseSocket() -- -1

dont know if that has to do with anything, hope it helps