Win build issues (r12931 or head)

[pheonixstorm]

Now that the latest win32 is running I have come across another problem.. Testing the new build I get a problem with the vertex shaders as well as not being able to load units.csv (still). This happens both under XP and 7. Error logs included.. the shader issue looks like this

Vertex info
-----------
Internal error: assembly compile error for vertex shader at offset 18050:
-- error message --
line 337, column 1: error: binding in multiple relative-addressedarrays

This was listed in the stderr.txt using nice shaders. If I run the config with any shader support I get a white ship at startup at the hanger and a white fuzz around the planet if I launch into orbit. With no shader there is no problem with either.

On the other side of things, I still get the issue with the game claiming not able to load units.csv and complaining that it can't find Llama.begin in stdout.txt

Error: Cannot Open Unit Llama.begin from save file New_Game.

At least I get this though!

using NV_CUBE_MAP
Initializing optimizer
Compilation of technique fixed successful
Compilation of technique default successful
Compilation of technique default_simple successful

[pheonixstorm]

Ok, change the ReadFull() code slightly to spit out the size it thinks units.csv is... so, I now have

Attempt to call ReadFull on a bad file units.csv -1

Odd... anyone have any ideas why it barfs on that file??

[pheonixstorm]

Ok, added another item to the stderr output for ReadFull. Line now reads

Attempt to call ReadFull on a bad file units.csv -1 E:\Games\Vegastrike\data/units/units.csv

Correct path.. file still reads -1.... May try to ifndef _WIN32 the call for the size and see what happens.

On the shader front I have found out why they aren't working for me. It seems that the latest nvidia drivers are a bit buggy on the shader side of things. The following page has the info and a possible workaround. http://www.mail-archive.com/osg-users@l ... 43406.html

Thats it for now.... I will fly around and see if there are any other odd glitches waiting to be found.

[charlieg]

So the differing file separators don't make a difference?

[pheonixstorm]

I don't think it does. As far as I can tell it reads in the whole file, gets the size, and runs a few other checks before passing off to an assortment of other functions. The VSFileSystem.h/cpp are a mess and its hard to tell whats what. I'm not even sure it really matters what the file name is for that matter. It reads the directory and starts grabbing at files to load or so it looks. I didn't get a lot of time to tear into it last night.

As far as the windows/unix path slashes I had the faintest hope that could be the cause, but explorer doesn't barf.. Just had a thought to try in console though. Then again, units.csv is the only file the err files point to as not being loaded. Maybe the next line

'import site' failed; use -v for traceback

will shed a little more light. I'm not hopeful though...

[pheonixstorm]

Havent looked into the units.csv issue tonight.. My attention has been focused on the irritating problem of texture glitches in the release build but not a single issue under the debug binary.

Release - First scene at Atlantis shows the LLama, top half white, the bottom half looks fine
Mining base - Outer buildings white while the asteroid textures have green spots were it looks as if the textures are gone or not properly placed.

Debug - No graphics issues at all!! (other than the nvidia shader malfunction...)

[breese]

I don't think it does. As far as I can tell it reads in the whole file, gets the size, and runs a few other checks before passing off to an assortment of other functions. The VSFileSystem.h/cpp are a mess and its hard to tell whats what. I'm not even sure it really matters what the file name is for that matter. It reads the directory and starts grabbing at files to load or so it looks. I didn't get a lot of time to tear into it last night.

I can think of two possible causes:

• units.csv does not contain carriage-return characters. Maybe that causes fgets() on win32 to read all the lines as a single line.
• The global boolean variable "use_volumes" in vsfilesystem.cpp is not initialized. If its uninitialized value happens to correspond to "false" then the vs file functions will ignore the file.

Talking about vsfilesystem, it really needs to be rewritten.

First of all, we should use boost::filesystem, which provides a platform-independent interface to the filesystem.

I do not think that volumes are supported anymore in SVN (but it is difficult to decipher from the sourcecode), and if it isn't then we should remove it.

The only thing left in vsfilesystem that has to survive, is how to find the various data files.

[pheonixstorm]

I can think of two possible causes:

• units.csv does not contain carriage-return characters. Maybe that causes fgets() on win32 to read all the lines as a single line.
• The global boolean variable "use_volumes" in vsfilesystem.cpp is not initialized. If its uninitialized value happens to correspond to "false" then the vs file functions will ignore the file.

Talking about vsfilesystem, it really needs to be rewritten.

First of all, we should use boost::filesystem, which provides a platform-independent interface to the filesystem.

I do not think that volumes are supported anymore in SVN (but it is difficult to decipher from the sourcecode), and if it isn't then we should remove it.

The only thing left in vsfilesystem that has to survive, is how to find the various data files.

A lot of things need a rewrite.. Right now i'm more concerned about the graphics issue. vegastrikeD takes longer to load and runs a bit slower than the release exe, but it at least doesn't have the graphics glitches.

[Dolphin]

Pheonixstorm,

I wanted to thank you for committing the windows binaries in rev 12933. Other than the issue with the nVidia shaders, which I also experience, I've been able to use this build successfully. It's the first time I've been able to upgrade past 0.50 without having some bug that is a show stopper. Planetary rings now look good, yeah!

Things still look good with shader=simplest, so that's what I'm using for now. 0.50 is finally history for me!

Anyway, I thought I'd also post to user help in case people are watching there for improvements to the SVN binary situation for windows. I know there are probably others that have been waiting for this too.

http://vegastrike.sourceforge.net/forum ... =1&t=15695

Thanks again to both you and the larger Vega Strike developer community!

[klauss]

Bugs that disappear on debug mode are almost always uninitialized variables.

Which is odd, since linux builds don't exhibit that. But still... it's almost always the same explanation: if debug builds run but release don't, look for uninitialized variables.

There could also be pointer misalignment issues, but I doubt that's the case... I can't think of a single structure alignment situation that would result in your described bugs.

[klauss]

On the shader front I have found out why they aren't working for me. It seems that the latest nvidia drivers are a bit buggy on the shader side of things. The following page has the info and a possible workaround. http://www.mail-archive.com/osg-users@l ... 43406.html

Thats it for now.... I will fly around and see if there are any other odd glitches waiting to be found.

That makes little sense, our shaders don't iterate over lights, and they're already unrolled.