New Bugs, Rev 5879+

[Argh]

1. Whenever I alt-tab, the farther textures of the map get covered with the TextureAtlas stuff. Anything lower than the highest mip, I suspect. S3Os aren't effected.

Moreover, I think that something bad is happening with texture handling- if I /give all in P.U.R.E., then fire a weapon that has a textured S3O, the same thing happens as the alt-tab bug. I suspect it's related, given that this has all been changed recently.

2. How do I set (i.e., what TDF, etc.) CompressTextures to 1? I'd like to compare quality and test stuff out, such as turning that off and using all-dds pre-compressed bitmaps for TextureAtlas objects, now that it supports mipmapping again, among other things. It won't attempt to re-mipmap DDS, right?

3. Lastly, Trepan's commit 5881 broke Auswaschbar's commit 5872 (use of gadget:GameStartPlaying(), etc.) which was tested and working. I think it's because Trepan forgot to edit the Gadget side, I only saw edits on the Widget side when he renamed stuff. Probably easily fixed.

[EDIT] No. 3 has been fixed. Thanks, Trepan, I was a bit worried there for a minute. [/EDIT]

[Argh]

This isn't really a bug, per se, but while that new caustic water shader is amazingly cool and runs nicely, I think it needs one additional parameter- I'd like a parameter to adjust to what depth / % of depth it renders the caustic effects.

On the World Builder demo map, the steep slope creates a distinct "band" effect where there are caustics being rendered, which looks a bit artificial. If you need a screen to see what I'm talking about, I'll make one later, when I'm done figuring out how to make it look like rain's hitting the water's surface

Basically, though, I would very much like a parameter that would allow me to make that area larger or smaller, I don't like how the automated version is working. I know that's nitpicking, but meh, it's almost perfect and blows everything else away.

[det]

Mantis is much better suited to these issues than the Spring forums.

[ZellSF]

is there a place to get automatic Windows builds now?

edit: woah, buildbot is fully back up?

[Argh]

Um, I did a bunch more tests, to try and pin down the graphics bug, which is seriously annoying.

This error occurs when a S3O model is being loaded. It doesn't seem to happen in a predictable fashion- I'll build a factory and build 5 different things, then it'll start acting seriously buggy, or 8 things, or 3. It always happens on a "give all". And when it happens, there's a huge pause- something must be looping a lot. Then the map turns black, with speckles of color, like this:



So, whatever this is, it's gotta be related to loading the textures. See the weird, half-colored triangles / quads, too? What's up with that? Why are we rendering the map's triangles multiple times? I thought all that was being done was a shaded rendering pass, and a shadowmap pass... it doesn't make any sense.

[jK]

1. Whenever I alt-tab, the farther textures of the map get covered with the TextureAtlas stuff. Anything lower than the highest mip, I suspect. S3Os aren't effected.

As far as I can see it only affects the ground texture? If so could you deactivate the usage of PixelBufferObjects -> set UsePBO=0 in your registry (HKEY_CURRENT_USER\Software\SJ\spring).

2. How do I set (i.e., what TDF, etc.) CompressTextures to 1? I'd like to compare quality and test stuff out, such as turning that off and using all-dds pre-compressed bitmaps for TextureAtlas objects, now that it supports mipmapping again, among other things. It won't attempt to re-mipmap DDS, right?

It is a user option. You can set it in your registry/.springrc, and it will be soon added to SpringSettings++. Also it doesn't compress the 3do textureatlas, but it compress all non-dds s3o textures and the particle atlas.

[AF]

The compress textures is not a mod option its a game option, the same kind that sets the screen resolution...

[Argh]

I just tested UsePBO = 0 and CompressTextures = 1 in the Registry. That resulted in severely crippled performance- the game was unplayable

I'll try turning CompressTextures off, see what happens.

[Argh]

Just tested UsePBO = 0, and performance is still crippled to the point of unplayability.

Framerate reads nominal, and higher than with CompressTextures = 1 (which makes no sense, if it's doing what it should be)- there's a massive spike of CPU activity whenever the camera moves.

In short, Spring's currently unplayable for me. I'll try CompressTextures =1 and UsePBO = 1 now...

[AF]

In all your tests compressTextures=1, what about =0? And why do two of you tests have identical values for PBO's and compresstextures?

[Argh]

Here, let me straighten that out. Instead of just commenting... you could, y'know, try my experiments out yourself, you have a copy of P.U.R.E. so it'll be a real test.

Tests run:

UsePBO = 1, CompressTextures = 0 (default settings) results in some sort of texture corruption, seems to be related to mips and is triggered by loading of a S3O, and may involve the LODBias changes (which, btw, everything I've read over here says are a big no-no- we want to use anisotropic filtering, not mess with the bias settings).

UsePBO = 0, CompressTextures = 1 ... unplayable game. Framerate reads nominal, but CPU usage occurring when camera moves is so large that it desyncs.

UsePBO = 1, CompressTextures = 1 ... game is playable, framerates are near usual rates. I need to reset all of my graphics card settings to my normal rig to do benchmarking, but I suspect it'll be nearly nominal again.

[jK]

Here, let me straighten that out. Instead of just commenting... you could, y'know, try my experiments out yourself, you have a copy of P.U.R.E. so it'll be a real test.

Tests run:

UsePBO = 1, CompressTextures = 0 (default settings) results in some sort of texture corruption, seems to be related to mips and is triggered by loading of a S3O, and may involve the LODBias changes (which, btw, everything I've read over here says are a big no-no- we want to use anisotropic filtering, not mess with the bias settings).

UsePBO = 0, CompressTextures = 1 ... unplayable game. Framerate reads nominal, but CPU usage occurring when camera moves is so large that it desyncs.

UsePBO = 1, CompressTextures = 0 ... same thing.

UsePBO = 1, CompressTextures = 1 ... game is playable, framerates are near usual rates. I need to reset all of my graphics card settings to my normal rig to do benchmarking, but I suspect it'll be nearly nominal again.

1. no, those problems can't be tested by anyone else, they are system related.

2. the LODBias is only set if you set it. Also afaik anisotrophic filtering is only enabled for terrain. And s3o mipmap is fixed by this:
*fixed dds mipmapping filter setting. (yeah, smoth was always right, there was something wrong with s3o textures ;)
So nobody should really need LODBias now ..

3. it is very strange that UsePBO=0 cause lags, cos it is the old mechanism so you should got those lags already in 76b1.

Btw what gfx do you have?

[Argh]

GeForce 7800GTS (AGP)

Latest nVidia driver, using nHancer to alter profile to benchmark with.

1. no, those problems can;t be tested by anyone else they are system related.

That may be so, but repeating the experiment will tell us something about the frequency of the problems. If this is going to affect most users of Spring, then it should be removed until it's been tested more. I'm really not kidding about the whole "unplayable" issue- CPU usage is so high when the camera moves that there's a multiple-second wait, if you try panning the camera rapidly, using the settings in experiments 2 and 3

2. the LODBias is only set if you set it. Also afaik anisotrophic filtering is only enabled for terrain.

What should be done is to enable anisotropic filtering as a global option, imo. I force it to run through nHancer, it results in markedly superior graphical quality at little cost for 4X. Should be adjustable by users, since there are people trying to run Spring with Geforce 3's still

3. it is very strange that UsePBO=0 cause lags, cos it is the old mechanism so you should got those lags already in 76b1.

I agree, it's very strange, but meh, I'm just reporting the test results. It's almost like with UsePBO off, Spring's having to load all of the map textures for a given sector whenever you move the POV, or something equally awful, though.

Meh, all I know at this point is that this could not have happened at a worse time for me personally- I wanted to begin beta-testing P.U.R.E., as it appears to be stable in alpha tests and most of the bugs reported by users have been addressed, but I can't really do that until this gets resolved

[Argh]

I tested SVN build 5893 on my folks' computer tonight- Athlon 2700+, ATi Radeon 9600.

Like my computer at home, this is using XP Pro, is all up-to-date and stuff, it's just ancient hardware. I've always been able to use and test Spring on this box... right now, I can't



Test results, using the World Builder map:

1. Default settings (UsePBO 1, CompressTextures 0) Spring starts, and renders, and is unplayable after that. Rendering a single frame took so long it was practically frozen.

2. UsePBO 1, CompressTextures 1. Spring starts, loads initial assets, renders loadscreen correctly, But Spring crashes before finishing loading sequence. The infolog's last entry is "Loading detail textures". Maybe that's what's wrong? But meh, it's not like it's a new detail texture, and it sure as heck worked before.

3. UsePBO 0, CompressTextures 0. Same results as test 1- it starts and renders, but is completely unplayable.

4. UsePBO 0, CompressTextures 1. Same results as test 2.


Now, get this- I had slightly different results with Tabula V2. I checked that out after the whole incident with the "detail texture".

Each time, the game actually started. And I got about 55FPS, with UsePBO and CompressTextures both 0, until I actually started the game- then it dropped to less than 1FPS, my UI elements didn't draw correctly, and eventually Spring crashed. Oh, and it was using 211MB of RAM, with nothing going on.

All three other settings resulted in similar results. Just rendering the map, it was Ok... game started, and everything went to hell in a handbasket.

I know you guys are probably trying to get this fixed, just wanted to report this round of testing.

[Argh]

Well, I finally have some good news!

After testing a lot, I've found that, at least with the GeForce 7800, turning Anti-Aliasing to "application control" seems to resolve the major problems!

Anisotropic filter overrides don't seem to be causing the problem, and I didn't see a return of the bad map-rendering reported earlier, with UsePBO = 1 and CompressTextures = 0.

[Guessmyname]

Gah! I just got hit by this as well. I dunno exactly what Argh did or what tags were involved, but PURE is now massively unplayable.

EDIT: Just tried it again using the same install but a different mod (just copied from the current released version of Spring). These are the results:

Ingame, things look normal, and the frame rate is sound├óÔé¼┬ª until you notice some weird errors such as below




Then, when a unit is selected, the framerate just keels over and dies, only to recover when the unit is unselected:


(selected. Note the FPS counter in the corner)


screen022.jpg (unselected. Again, note the FPS in the corner)

[Otherside]

i need to test svn in windowed mode to not get this horrible alt tab bug

[zerver]

Anyone else had problems with certain big units refusing to fire at enemy?

I usually "give all" a couple of times and then give half of the units to Gaia. When I order my turret to attack, it walks toward the enemy but never fires.

[imbaczek]

I had problems with units not shooting, too. Not even trying to aim.

[AF]

In pre-Vista windows, the graphics memory address space is shared by every program and so when you alt tab all that texture space used by spring could be overwritten by textures used for displaying things in windows or other programs, hence the classic image of spring with window titles in the trees and a giant start menu button in the sky.

Im not sure about the latest linux, but in Vista the whole video ram is hoisted into virtual graphics memory so this issue with texture overwritting between programs is eradicated. It was a necessary change otherwise the aero sfx would have spring trees in the title bars and spring trees would look like aero windows.