Wierd lines on construction on ATI Radeon Express 1250

[hughperkins]

When something starts constructing, there are white lines at integral multiples of 45 degrees; or maybe intersecting with corners of the screen; that flash on and off.

Running with an ATI Radeon Express 1250.

Is there maybe some option I could set to work around this problem?

edited to change title from "nanoing" to "constructing"

[Neddie]

HUGH! Where have you been?

I think you may be able to override those graphics using some lua contained in Complete Annihilation, but I'm not sure if the problem is local or general. I'm on Nvidia only, so we will need to wait for more ATI input.

[AF]

This is not confined to the 1250 express.

I have integrated 1150 express on my laptop, and when drawing construction wireframes or command lines when holding shift random lines show up everywhere. Its looking as if glEnd and glBegin arent being handled properly as you can see where the last vertex of the mex being built has a line coming off it heading towards the first vertex of another unit and the various funky colours inbetween, sometimes itll go off to a map quad and the whole thing screams buggy drivers. After a few minutes the whole map and the GUI dissapears and all the units, the ground is a cyan blue block or w/e colour the background colour is on the infinite, and the minimap is visible but you cant use it and it just shows the map and no units or sfx.

This appears to be an example of how crap ATI drivers are rather than how buggy spring is. This behaviour shows only on ATI Catalyst drivers for Vista, usually on integrated graphics.

[rcdraco]

I've had this before, over a certain number of units in a game, and on certain maps it will occur. The problem looks like it's from the nano's to the geos and stretched out and it cuts up trees. SmallDivide is a big culprit. Any map with geos, and forests, seems to cause it. I can probably say it's an OpenGL issue with ATI's, the easiest fix is get an nvidia card, or if you're on a laptop, lower the settings on particles.

[hughperkins]

Great :-/

[hughperkins]

Seems to be something to do with the wireframe stuff? I thought it was the nanoing, because you get it when something starts and finishes being build, but I think it's actually something to do with wireframe stuff?

[hughperkins]

I guess I could build from source, and modify any stuff that uses GL_LINES to use GL_TRIANGLES? (and add the first point as a third point each time).

[hughperkins]

Ok, found the line that offends ATI. It looks like these ATI drivers dont like glpolygonmode "GL_LINE". Commented out the following lines in CUnit::DrawBeingBuilt, and the issue has (for now) gone away; albeit with pretty hideous construction animations in its place.

Code: Select all

	//glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
	DrawModel();
	//glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);

Edit:

To get somewhat acceptable visuals on an ATI, did also:
- commented out also "UnitDrawingTexturesOff
- removed the "* 3" in the clip plane 0 4th coordinate calculation

[hughperkins]

Update: it's an interaction between:
- glPolygonMode( GL_LINE )
- the clip-planes

If you leave glpolygonmode gl_line in, and move the glEnable( clippanes ) to just after the glpolygonmode gl_fill has been reactivated, the problem also goes away.

=> It looks like glpolygonmode gl_line on ATI doesnt like clipping very much.

[LordMatt]

Once you get it figured out, you should submit a patch to mantis.

[hughperkins]

Yeah, unfortunately it's looking increasingly likely that there is no obvious clean, generic solution.

Basically, any clipping of wireframes fails with the ATI.

There are therefore two possible hack solutions:
- detect that it's an ATI, and dont clip the wireframe
- have an option in the settings to not clip wireframes

Neither are satisfactory for lots of reasons.

We could also simply generically not clip the wireframes. It's not that ugly, but it means that 97% of people (maybe more) sacrifice some visual quality for the good of the 3% of people with bad drivers.

Unless someone pushes for some specific solution, I'm just going to publish my own code tweak here, and so if someone has the same problem in the solution he can do the same thing.

Some background on the DrawBeingBuilt function:

There are three parts to the DrawBeingBuilt function:

- a wireframe version of the unit
- a blue filled-polygon version of the unit
- the full-color version of the unit

Each of these starts off totally clipped, then its upper clip-plane comes up from the ground, gradually revealing the unit. In parallel, the lower clipplane will itself move up from the ground at some point, ultimately re-hiding the unit, except for the full-color version, which stays revealed, becoming the final constructed unit.

The timings are as follows, as fractions of total build time:
- wireframe:
upper clip: rises from bottom at 0 time to top at 0.333
lower clip: rises from bottom at 0.9 time to top at 1.000
- blue filled-polygon:
upper clip: rises from bottom at 0.333 to top at 0.666
lower clip: rises from bottom at 0.666 to top at 1.000
- full-color version:
upper clip: rises from bottom at 0.666 to top at 1.0 time

My current fix that I'm running with:
- dont bother clipping the wireframe part at all, so it is visible for the entire build period
- the fix works for both factories being built, and units being built
- it looks ok
- it's not a generic fix

Specifically, in the Unit.cpp file, in the function DrawBeingBuilt, we displace the "glEnable( GL_CLIP_PLANEx)" lines to after the "glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);", and rebuild.

[hughperkins]

Ok, a reasonable solution could be to make the updated binary available?

It's here:

http://manageddreams.com/files/spring.exe

Seems not really worth patching the cvs etc itself, since by the time the cvs becomes a release, hopefully ATI will have fixed their drivers... ?

(Edit: this is a patch of the 0.76b1 release)

[imbaczek]

could you please base your patch on top of the next release? see the 'next' branch of

http://gitorious.org/projects/spring-sv ... s/mainline

[hughperkins]

Well, I'm not patching cvs, because it's not a generic patch; however anyone who wants to run the current release on an ati card, can use the exe linked above.

Hopefully, ati will patch their own drivers and we wont need to actually change our own cvs.

When is next release?

[imbaczek]

I wouldn't count on ATI fixing things. We should have a setting like 'ATI fixes' with proper disclaimers attached to it.

I have no idea when the next release will happen, I've got virtually no time in the next 2-3 weeks; experimental exes are available for testing. Need a buildbot so they could be generated automatically, since it's tedious to do by hand. IOW ask Tobi.

[hughperkins]

Ok. Do you have an example / doc of adding things to settings dialog, and reading things from settings dialog?

[imbaczek]

Unfortunately, no idea. I think koshi is maintaining springsettings, need to ask him. Visit #springlobby on freenet or in the lobby to find him.

[hughperkins]

Ok, so, in the program it looks like we need:

Code: Select all

#include "Platform/ConfigHandler.h"

if( configHandler.GetInt("AtiHacks",0) == 1 )
{
  ...

... then the question is just how to get AtiHacks into the settings dialog box.

[hughperkins]

Committed, revision 5937.