Crashing while starting game (SVN)

[Psyco Diver 69]

I dled SVN verison today and every time I try to play it I get the load screen with music, then it flips to a black screen with the windows cursor in the middle with the music still playing. This is on Vista (sigh I hate vista). it seems to stop when the load in the bottom corner gets to "backgrounds/black light.cube" or something like that

[klauss]

If you just svn-upped, you have to reconfigure VS.
(ie: run vssetup and re-set all your settings).

Though I'm not sure it will work with the current windows binary in SVN... if not, you may have to roll back (svn up to revision 12867)

[Psyco Diver 69]

I did the set up already, how do I roll back?

[klauss]

If you're using tortoise SVN, you should have an "update to revision" or "update special" entry somewhere that lets you specify the revision number (use the revision I posted earlier).

See this

[Psyco Diver 69]

Got it thanks, now most of the ships and bases are missing their textures, but I already see theres a post for that

[klauss]

Update the programs folder to head, that will be compatible with the earlier revision and it should fix the missing textures.

(that is, the folder actually named "programs" within vegastrike's data folder)

[Kuoxsr]

This bug appears to have occurred in revision 12869. 12868 is fine, but 12869 crashes right away on the start up screen, and this hasn't been fixed in the latest version.

I may not know anything about shaders, but I do know that as of the 12869 revision, the VegaStrike.config file is referring to files and folders that don't exist, and that leads to program crashes.

Here's the problem area in the latest version:

Code: Select all

<!-- #extremeshader
            <var name="mac_shader_name" value="mac"/>
            <var name="default_full_technique" value="5_ps3.0/default"/>
            <var name="default_simple_technique" value="5_ps3.0/default_simple"/>
            <var name="technique_set" value="6_ps4.0"/>
#end -->
<!-- #highshader -->
			<var name="mac_shader_name" value="mac"/>
			<var name="default_full_technique" value="default"/>
            <var name="default_simple_technique" value="default_simple"/>
            <var name="technique_set" value="5_ps3.0"/>
<!-- #end -->
<!-- #mediumshader
			<var name="mac_shader_name" value="mac"/>
            <var name="default_full_technique" value="5_ps3.0/default"/>
            <var name="default_simple_technique" value="5_ps3.0/default_simple"/>
            <var name="technique_set" value="4_ps2.0"/>
#end -->
<!-- #lowshader
			<var name="mac_shader_name" value="maclite"/>
            <var name="default_full_technique" value="5_ps3.0/default"/>
            <var name="default_simple_technique" value="5_ps3.0/default_simple"/>
            <var name="technique_set" value="3_arbfp"/>
#end -->
<!-- #verylowshader
            <var name="mac_shader_name" value="maclite"/>
            <var name="default_full_technique" value="default"/>
            <var name="default_simple_technique" value="default_simple"/>
            <var name="technique_set" value="2_ps1.4"/>
#end -->
<!-- #onboardshader
            <var name="mac_shader_name" value="maclite"/>
            <var name="default_full_technique" value="default"/>
            <var name="default_simple_technique" value="default_simple"/>
            <var name="technique_set" value="1_ps1.2"/>
#end -->
<!-- #noshader
			<var name="mac_shader_name" value=""/>
            <var name="default_full_technique" value="default"/>
            <var name="default_simple_technique" value="default_simple"/>
            <var name="technique_set" value="0_fixed_gl"/>
#end -->

For the extreme shader, it refers to this folder/file in the defaults: 5_ps3.0/default. Unfortunately, according to process monitor, it is attempting to find this folder within the 6_ps4.0 folder. This value needs to be "../5_ps3.0/default" instead, so that it goes back to the "techniques" folder before starting to look for the sub folder called "5_ps3.0" Any other shader that references a sub folder like this is also broken.

Another problem with the shaders is that the application appears to be looking for a file called "fixed.technique" for every shader definition. When you set it to "onboard shader," for example, process monitor tells me that the application crashes because it cannot find the file "fixed.technique" within the 1_ps1.2 folder. Every shader definition suffers from this flaw. As far as I can tell, the name of the file must come from the application, since it isn't specified anywhere in the config file. Once files of that name exist in the specified folders, the crash goes away, and I can run the very latest version.

I suspect that any developer who isn't having a problem with this might have these files and folders on their hard drive, but they must not be included in the project file, so the rest of us aren't getting them when we check it out. Subversion is kind of funny about that, you have to deliberately add a file to the repository, it doesn't just recognize a new file automatically. It took me a while to get used to that when we made the switch from Source Safe to SVN.

I've actually made a patch of what I changed, if anyone's interested. It's mostly a hack, since I just took a copy of "default.technique" from each folder and renamed it to "fixed.technique." The changes to the VegaStrike.config file are sound, however.

[klauss]

For the extreme shader, it refers to this folder/file in the defaults: 5_ps3.0/default. Unfortunately, according to process monitor, it is attempting to find this folder within the 6_ps4.0 folder. This value needs to be "../5_ps3.0/default" instead, so that it goes back to the "techniques" folder before starting to look for the sub folder called "5_ps3.0" Any other shader that references a sub folder like this is also broken.

Thorough job

You're right, it tries to open 6_ps4.0/5_ps3.0/default, but it fails, and then tries 5_ps3.0/default. It's like so by design. If VS isn't testing 5_ps3.0/default, then it's because it's an older binary.

Another problem with the shaders is that the application appears to be looking for a file called "fixed.technique" for every shader definition. When you set it to "onboard shader," for example, process monitor tells me that the application crashes because it cannot find the file "fixed.technique" within the 1_ps1.2 folder. Every shader definition suffers from this flaw. As far as I can tell, the name of the file must come from the application, since it isn't specified anywhere in the config file. Once files of that name exist in the specified folders, the crash goes away, and I can run the very latest version.

Ya, that's a mystery. Last time it happened to some, it was due to a broken config file.

I suspect that any developer who isn't having a problem with this might have these files and folders on their hard drive, but they must not be included in the project file, so the rest of us aren't getting them when we check it out.

Not so, I did a clean checkout just to try that, and it works.

I've actually made a patch of what I changed, if anyone's interested. It's mostly a hack, since I just took a copy of "default.technique" from each folder and renamed it to "fixed.technique." The changes to the VegaStrike.config file are sound, however.

That's a workaround, but do check your config file.
The best bet is to backup your config file (both in data and your local home) and replace them with a clean version (from svn).

[Kuoxsr]

I think we have a winner:

Code: Select all

initTechnique( "fixed" );

That's in mesh.cpp on line 106.

The initTechnique function that it's calling looks like this:

Code: Select all

void Mesh::initTechnique( const std::string &xmltechnique )
{
    if ( xmltechnique.empty() ) {
        //Load default technique, which depends:
        string effective;
        if ( Decal.size() > 1 || getEnvMap() ) {
            //Use shader-ified technique for multitexture or environment-mapped meshes
#ifdef __APPLE__
            static string shader_technique = vs_config->getVariable( "graphics", "default_full_technique", "mac" );
#else
            static string shader_technique = vs_config->getVariable( "graphics", "default_full_technique", "default" );
#endif
            effective = shader_technique;
        } else {
            static string fixed_technique = vs_config->getVariable( "graphics", "default_simple_technique", "fixed_simple" );
            effective = fixed_technique;
        }
        technique = Technique::getTechnique( effective );
    } else {
        technique = Technique::getTechnique( xmltechnique );
    }
}

For those not well versed in C++ code, that says "if the incoming variable is empty, get the proper file name from the config file, otherwise use the incoming value." (I would have reversed that to reduce nesting, but that's just me.)

Since the incoming value is hard-coded to contain the word "fixed," that's the name of the file it thinks it has to load, hence the runtime error, which can be verified by using process monitor. Keep in mind that this code is in revision 12925. I know this is so, because I just downloaded the head revision of the source code for the first time tonight. Obviously, this problem isn't happening because my config file is "broken."

Now, there must be some secondary calls that actually do reach the config file, because once I worked around the "fixed.technique" problem by adding a file with that name, then it crashed on the bizarre sub folder reference (6_ps4.0/5_ps3.0/default). To work correctly on a Windows system, we need to tell it to go up a folder first, which would require the following in the config file: "../5_ps3.0/default" If that command isn't compatible with Linux, then we'll need to alter the binary to move up a folder before making the request (because it's just silly to deliberately call for a folder that we know will not exist.)

We have two people (in this thread alone) reporting the exact same symptoms, and a message on the "how to check out SVN" wiki page warning everyone that the application won't load after revision 12867 (weird coincidence, I guess)

Hey, I've got an idea, how about we assume that all this evidence points to something wrong with the code, and proceed from there like gentlemen to find out what it is, shall we?

[klauss]

There is a problem with the code: that recent revisions haven't been compiled for windows.

That's it.

If you're using windows, you have to stick to the older revision of the dataset, or do as you're doing and try to patch things. But I'm not sure it will work no matter how much patching, there are places where the fallback lookup (looking without the subfolder) is required.

[Kuoxsr]

I'm not sure it will work no matter how much patching...

Does this mean the Windows version is dead?

[klauss]

No, not at all. It always lags a few weeks (sometimes months) from the latest code, and this time it means it doesn't work with the latest dataset.

But we'll get a new binary rolling eventually, just be patient and stay tuned. I'll probably announce it in the devblog when the new binary is out.

[Kuoxsr]

I'm not here to "be patient and stay tuned." I'm here to roll up my sleeves and get to work. Otherwise, I would have just kept the patch to myself.

Is there a Windows programmer on the team that I can talk to about lending a hand?

[klauss]

Well, shenle did try hard to build the latest windows.

The one that always succeeds in building is hellcatv, but he's usually quite busy in RL and difficult to reach. Last time I asked him, he said the vega-vc7 project in SVN should build fine.

[Kuoxsr]

I can't find a copy of a compiler that old. All roads now lead to Visual Studio 2010, it would seem. That's where every link takes me, even the ones that claim to be for older versions.

I'll keep working on it. Downloading boost at the moment.

[ace123]

I'm planning to spend a "Windows Day" this weekend, so I'll take a crack at getting VS working in VS 2008. Unfortunately I don't have the disk space or time to install 2010 right now since none of my projects need it.

But in general if you're planning to contribute to VS, you'll almost certainly need to get the code compiling, lest yet another backwards-incompatible change should happen.

If you want 2008, it should still be available here: http://www.microsoft.com/express/downlo ... Visual-CPP
They generally go back one version, but yes that means 2005 isn't available any more (it wasn't a very good version anyway).

[Kuoxsr]

Ah, I see the 2008 tab on that page now. Thanks. That's a possibility at least (no need to borrow a copy from work anymore.) Totally agreed on Version 2005.

I still think I'd like to see if I can get it working with VS 2010, though. As long as it's free, I don't see a reason not to stay up to date.

Mind if I PM you with questions about some missing file errors I'm getting? I was able to straighten out a ton of them last night, but there are a few left.

Better yet, when I get home tonight, I'll start a new thread in the "Contributor help" forum. If you're up for it, it might be fun to collaborate out loud this weekend.

[Kuoxsr]

On second thought, that topic sounds more appropriate for the "Compiler problems" forum. I'm going over there.