Planning for 0.77 Release

[imbaczek]

jK: UsePBO=0 makes no difference.

this screenshot highlights broken stuff:

- tree leaves are bogus
- grass LOD doesn't quite work
- chicken window texture completely wrong
- also, trails left by units are turned into a single-color stripe:

edit: not to mention that running spring twice makes it crash... ATI + opengl = fail, but somehow other opengl games work. Since I've got an ATI now, could anybody point to some resources about its bugs and workarounds?

[jK]

Argh had the same issue with the grass, he said it was solved after a driver upgrade (/downgrade?).

So either ATi's "glGenerateMipmapEXT" support is broken (nvidia isn't better in that case ) or it is glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE).

PS: It would be nice if you could test, if it is glGenerateMipmapEXT() (just edit myGL.cpp::glBuildMipmaps).

[imbaczek]

yup, that's it. doesn't help the chicken window, so mods have to work around ATI by themselves.

can't commit now, patch submitted to http://spring.clan-sy.com/mantis/view.php?id=999 - make sure to set AtiHacks to 1 in the registery; request adding this option to settings.exe or pointing me to it if it exists.

[koshi]

http://filebin.springlobby.info/springs ... cluded.exe

not quite sure if it is what you want tho. i have only the exe lying around, seems i "misplaced" whatever branch i built that from...

[Kloot]

Not a good idea to stick each new hack under the same umbrella
if its behavior (working / broken) varies across driver versions and
hardware, ex. a driver might break A (with the hack for A disabled)
but not B and enabling it could then kill B unnecessarily if A and B
simply shared an override code. PS. "AtiHacks" would also become
something of a misnomer if it started covering nvidia workarounds
too, IMO having a separate var per hack beats the one-size-fits-all
approach.

[jK]

yup, that's it. doesn't help the chicken window, so mods have to work around ATI by themselves.

very strange

1. Lua textures (alias NamedTextures) aren't using glGenerateMipmapEXT
2. only the chicken gui texture seems broken

The only special at the chicken texture is that it uses nearest filtering, which uses gluBuildMipmaps if GLEW_ARB_texture_non_power_of_two isn't supported. So if your cards supports npots then nearest filtering is broken for ATi+npots (would be nice if you could check this ^^).

PS: There is no need for a special rule, I will remove glGenerateMipmapEXT completely (from glBuildMipmaps), because it is even broken for NVidias (Orge did the same).

[Argh]

So, that might finally resolve the graphics corruption bugs? That'd be nice, the performance issues all seem to have been resolved quite nicely at this point...

[imbaczek]

chicken thingie pretty much amazes me, it looks like texture memory corruption - parts of the noise pattern vary with builds and/or spring restarts.

[KDR_11k]

"is that texture not a power of two" was the first thing I thought of, I remember feeding Half-Life an NPO2 texture back in the day, same effect in hardware rendering (showed fine in software).

[imbaczek]

tga is 300x210, lemme see...

edit: yup, some mad image resize skillz result in:

512x256 - ergo, a mod bug (haven't changed any lua code here.)

[jK]

The only special at the chicken texture is that it uses nearest filtering, which uses gluBuildMipmaps if GLEW_ARB_texture_non_power_of_two isn't supported. So if your cards supports npots then nearest filtering is broken for ATi+npots (would be nice if you could check this ^^).

-> please, check if your card supports ARB_texture_non_power_of_two.

PS: it isn't a mod bug, the engine rescales the textures to the next PO2 if the cards doesn't support NPOTs.

[imbaczek]

jk: it exists in ext.txt (pastebinned).

[Tobi]

Some cards/drivers advertise they support NPOT textures but actually switch to software rendering or just break when you try to use it. There's some condition for this already in Bitmap.cpp.

[jK]

The problem isn't that easy.

1. fact NPOTs are a core feature of OpenGL2.0 and most of ATi's OGL2.0 cards don't support it!

2. very often ATis fallback into software mode when using NPOTs

So now some ATi cards support NPOTs, mostly with restrictions in filtering,mipmaping,clamping,...
And the newest series even support NPOTs w/o any restrictions.
Also some of their drivers export the extension and some don't (even if the card supports it!). ATi says it is a core feature of OpenGL2.0 and so it doesn't need to be exported! (where is the logic here???????)

Yeah and now, it even seems that nearest filtering+NPOTs is broken for their newest series/drivers.

I am just waiting for det's repsonse (he has an ati too). When I asked him before he said he has "sometimes" the issue with the chicken gui texture, what doesn't make any sense to me o_O

[Argh]

So... if NPOT fails... resize the texture with a linear filter, maybe? Better that it functions, but looks terrible, than does not function period, imo. When it's then displayed at the required size, it'll probably be ... ok-ish. Dunno.

Also... can we expect to be able to test an Installer with the UnitSync / Settings issues resolved fairly soonish?

Sorry to bug about this, but it's one of the more major things left, besides the NPOT thing, before this is a release candidate, imo.

[jK]

That's what it does already.

The problem is to find out _when_ it is needed to do so.

[Argh]

Ah... that explains a few things, then. I was wondering why UI elements seemed to be getting filtered.

That's bad.

So... how's about a switch- "NPOT Good"... and a test that users can do, from Settings, to determine whether they should turn that switch on / off? All it needs to do is a simple OpenGL program showing a NPOT texture, and if the user reports it's not displaying properly, there ya go... I wouldn't bother trying to automate it, though, too much hassle and future maintenance issues.

[rattle]

So for compatiblity reasons you'd need it as 512x256? Hmm I remember that a lot of games used to map their UI graphics from a single texture using a configuration file which specified the top left and bottom right coords.

[Argh]

Well, we could do it that way, too- just rebuild all of our UI elements as POT, or use texture coordinate systems in a single large texture (although right away we're running up against the 1024 size limit on older hardware, but meh, if they're running hardware that old, the game is barely playable anyhow).

I've been considering re-formatting the UI graphics in PURE to meet that standard, after hearing about this issue. I could just do stuff like the main bar as 2048 actual, but 1600 that's not masked, so that it's at the largest resolution width most monitors can display...

[EDIT]Done. Thank goodness for batch operations.[/EDIT]

[koshi]

I've changed SpringSettings to remove the need for that annoying hack with the unitsync location panel. Also you should be able to select water 4 now (no options for that to set yet)

http://springlobby.info/windows/springs ... ttings.exe
changelog