New Bugs, Rev 5879+

[Kloot]

I examined the give-all bug once, you can reproduce it in XTA (9.44)
with:

Code: Select all

/cheat
/give arm_luacommander
/give arm_luacommander

Anything given or built before or after the second arm_luacommander
spawns will lock up, as do factories and builders (which refuse to build
from that point). Some gadget intercepting commands perhaps?

[Argh]

I examined the give-all bug once, you can reproduce it in XTA (9.44)

Hmm... if you can reproduce the corruption bug with XTA, that's interesting. That means it's very unlikely to have anything to do with running out of texture memory, which was one idea lurking at the back of my mind...

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.

Instead of giving them to Gaia, give them to team 1.

@GMN: Hmm. That's a whole different set of weird bugs!

[Argh]

I've found an "aha", in terms of performance issues.

Hitting F5 to hide the UI resulted in acceptable performance and stability on the ATi 9600.

I disabled all display Widgets / Gadgets in P.U.R.E., and it sped up framerate (maybe 5FPS, instead of 1FPS) but was not really functional, even with Spring's default LuaUI.

I am also seeing the corrupted textures, like GMN reported, if CompressTextures == 0. Setting it to 1 results in the correct textures being displayed.

Soooo... the issue seems to have to do with drawing the interface. My gameplay Gadgets, and my modified Unit Damage display Gadget works just fine, with no significant slowdowns. Text displays on the screen without a major problem, too. It's pretty clear that whatever's supposed to happen with CompressTextures 0 doesn't work right, on the ATi card, and turning UsePBO on still results in a crash.

[Noruas]

Boats seem to drift over the location where it was suppose to stop, and then start dancing to try to go back to that destination.

[imbaczek]

that's because braking speed has been decoupled from acceleration. increase deceleration for boats.

a proper fix should make the boats (units in general, since e.g. BA jeffies had this problem too) start braking before they reach destination... dunno how hard would this be.

[Argh]

As of rev 5915, more bugs have shown up:

1. Groundflashes no longer draw, period. Neither do Flares(CBitmapMuzzleFlame). Neither do any CEG-spawns.

2. Units exploding will not show the CEGs they've generated after they've been destroyed. It's almost like seeing the CEGs they generated is predicated on their existence. Maybe the changes in LOS? Weird.

3. Graphical corruption of the UI elements (overlaid with TextureAtlas stuff) occurs after a /give all. The big bug of complete corruption of the map seems to be gone, after testing the possible combos of UsePBO / CompressTextures, but meh, I may not have tested thoroughly enough yet.

4. The very first time I tested 5915, LuaRules didn't function normally. I tested changing to LuaGaia, then back again, now it works. Very weird. In addition, Water 4 wouldn't turn on. Again, all of this magically worked again, after some futzing about.

5. The new engine contrails I put into P.U.R.E. no longer draw right- it appears that the texture's not showing up at all, at lower mip levels. Zoom in, and there the trails are- zoom out, and they're hardly being seen.

6. I tested TextureLODBias. It should be removed, imo. Setting it higher than 0 results in unbelievably ugly textures that are obviously at lower mip levels than they should be.

Setting it lower than 0 results in greatly improved sharpness- back to the previous levels I associated with Spring.

It also magically corrected issue 5. Tobi, I think that this "fix" isn't quite adjusted to the distance of the POV correctly, I see fuzzed-out textures with it at 0. I'm guessing it's showing us the mipmap it should be showing at level 1 (second level down) when it should be showing us level 0 (largest size) instead. This might explain why certain CEGs aren't drawing at all now, too. Moreover, this is happening with CompressTextures = 0... my tests with this indicated that whether this is on or off, Spring's using mipmaps for S3O textures and others, such as trees. I can make a screenie showing the effects of changing the LOD Bias if you want to see what I'm talking about.

However, setting it to < -1 results in a lot of CEGs not drawing right.

7. Certain CEGs are no longer loading their textures correctly. This is a weird one. I'm using a generic "smokecloud" texture in a lot of places in P.U.R.E., and it won't load for one of the primary uses (smoketrails behind moving vehicles) until I've used another CEG, which also uses the texture. This is totally bizarre.

8. World Builder CEGs expect certain textures to be loaded by the main mod / game file, because I'd previously found that you cannot have two Resources.tdf files without conflicts. Now, none of them load their textures at all.

[Argh]

Omg! I found a really weird thing.

If certain textures are visible... others are then visible, including ground-flashes!

Maybe there's a problem with names and the assigned texture coordinate space? Maybe it can't handle the same texture being referred to more than once?

<checks more stuff>

<comes back from testing>

Hmm. Had one missing texture, and one reference to a texture that no longer exists (not terribly surprising, and previously didn't cause problems), but fixing both didn't change anything. Lemme go look at the CEG that magically causes the other ones to start drawing... maybe there's a solution there...

[Argh]

Ok, I know what's causing the bugs with CEGs. Basically, most of them aren't drawing correctly, unless a Unit is being built and shows a wireframe.

This is the most likely culprit:

enabled polygon offset for all units begin built (fixs a clipping issue)

[jK]

1. first no one says you have to use TextureLODBias and it is strange you play a lot with it, but request to remove it o_O

2. TextureLODBias=1 is a lot. and yeah, it doesn't work with the particle atlas (the atlas generates mipmaps but don't use them as long as TextureLODBias isn't set)

3. all cegs work fine here. the polygon offset for units being built, isn't any culprit. that offset is only active as long as the unit is being rendered, also it would prove the opposite (the offset would fix wrong particle clipping, not causing it).

4. i can't say what exactly, but something is wrong with your computer (all those texture overwrites aren't spring related)
perhaps it would help to increase the agp aperture size (current P.U.R.E. use many textures, which need space), but i don't know

[Argh]

Look, no offense... but before you submitted your patch, none of this stuff was broken. This is all new.

I, and others in this thread, have reported various things are seriously wrong since you submitted your patch. I have reported that I've tested it on multiple platforms, and that it was broken on multiple platforms.

At this point, I'd have to vote that we revert to the last SVN that worked correctly.

If you're not going to fix it, you're going to cause a disaster at release, jK. There are a lot of us out there using older hardware and Windows XP, and if the tests with the Radeon are reflective of what's going to happen... we're truly, totally hosed.

[Argh]

Users with the following hardware setup report graphical corruption of the UI elements (in this case, the button textures), but otherwise ran well:

OS : windows XP
RAM : 4 gb
GFX Cards : 8800 GT 1024 mb OCd's SLI *2
CPU : Quadcore 6600 Ocd to 3.6 ghz

[Argh]

I dunno whether this will help resolve these issues, but nVidia wrote the following whitepaper about use of PBO:

Link

I've just skimmed it, and I don't pretend to understand all of it, but I was struck by how many warnings are in the text, about how to avoid certain problems, uniformity of texture types is a problem, and certain things must be done in a very specific order.

So. Maybe these problems are being caused by DevIL's translation of various image formats? Or it's happening because of lazy-loading issues?

We already know that this causes various odd problems, but before PBO was implemented, it was all reasonably stable, so long as certain things were avoided.

Meh, it would be so much better if we eliminated TextureAtlas entirely, and just mandated DDS for anything used in CEG, imo. Then we wouldn't have to screw around with this so much, and it'd probably run faster as well.

[smoth]

8. World Builder CEGs expect certain textures to be loaded by the main mod / game file, because I'd previously found that you cannot have two Resources.tdf files without conflicts. Now, none of them load their textures at all.

if they need to be held with the map then trepan added this:
- Added 'gamedata/resources_map.tdf' for gaia unit projectile textures.

in the version prior to this one.

[Argh]

It's not the map, it's an add-on module. Basically a fancy "mutator". Also, it magically draws just fine, when I have a Unit being built, anywhere in the gameworld...

[Argh]

Ok, I have at least one piece of testing information that may be pertinent: Spring's loading speed of JPG is much, much, much slower than its loading speed of TIF, and the performance of the engine is a lot better when using TIF for larger bitmaps.

TIF is a filetype I've been experimenting with, because it's almost completely raw pixel data. PNG isn't working a lot better than JPG. And I tried TGA for interface elements, and it fails to draw- I don't know what that means.

I'm going to eliminate all use of compressed image formats, other than DDS, and we'll see what happens.

[jK]

I know that PBOs can be slower than the regular way, that's why there is UsePBO. And I know how to use PBOs, fact is that ATI has problems with non 32bit data blocks and NVidia has problems which not matching data formats, but both doesn't matter 'cos the PBO is used here to upload compressed textures (32bit bit blocks + not switchable s3 data format).
As far as I know nothing is wrong with it, nothing of you said/wrote proved me the opposite (in the case of PBOs).
Also I didn't changed the base code at all, so you have to get the same or more frames with UsePBO=0. And as long as you are the only one with that problem, the probability is very high that it is a problem with your system(s) and instead of comparing totaly in independent options like UsePBO, CompressTextures and TextureLODBias ...
you should test all testbuilds and find a build where it runs fine or try to adjust your AGP aperture size, try older versions of P.U.R.E. or other mods with less textures, ...

PS: using different fileformats for textures doesn't have any impact on runtime performance, it can only affect the loading speed (what could be made async. with PBOs, then you could load the texture before you want to use it, so loading and first usage aren't in the same frame anymore, but that's future).

[Argh]

Multiple people have reported similar bugs. Read the thread.

I have tested on multiple computers, with different rendering hardware.

What part of this suggests that my computer is broken?

Quit sticking your head in the sand. You wrote a giant patch, it doesn't seem to confer any benefits, and it's broken Spring very badly. Either fix it, or revert it.

[lurker]

First, realize that this is only a part of the patch and give jK a thumbs up for everything that works for you.
Second, I just want to make sure you tested the exact revision before jK's stuff started going in?

Edit: I understand that you're upset, but you have to realize that it's going to be quite a while until .77 is released.
And I'll see if it works for me on my kickass Intel integrated graphics later today.

[Argh]

Look, the new water shader is wonderful. No argument. I love it, and plan to show it off.

What concerns me is that my report, specifically about the Radeon 9600, which can't even render Spring's UI without running at crippling speeds, is being ignored.

Let alone the crashes, the CEGs not even drawing unless something's being built, etc. Spring's a mess right now, and I've never seen this many rendering errors.

And yes. I've tested before and after. Do you want pictorial proof? I can do that, but if I do it, and nothing gets done, I'm going to have to go on one of my infamous tirades. You guys have no idea how frustrating it is for me right now, to see my game pretty much completely ruined by this.

[lurker]

It's not being ignored, so calm down.
And I know you tested before, but did you test right before? Do you know the exact revision this started? It would help a lot.