Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#803 closed defect (fixed)

Minimap broken

Reported by: fabio Owned by:
Priority: Nice to Have Milestone: Alpha 9
Component: Core engine Keywords:
Cc: Patch:

Description (last modified by fabio)

The circular minimaps are broken here since a while. Example on current build from svn on Linux with Death Canion:

http://img194.imageshack.us/img194/3881/0adbrokenminimap.png

EDIT: this is a mesa (Linux) driver problem: see this bug for more info: https://bugs.freedesktop.org/show_bug.cgi?id=36762

Change History (15)

comment:1 by fabio, 13 years ago

Milestone: BacklogAlpha 5

comment:2 by Philip Taylor, 13 years ago

I guess "a while" may have been r9139. This looks like a z-ordering problem, but it works fine for me and I don't see why it'd be different for you :-(

What drivers are these? Is it the same regardless of renderpath/shadows/fancywater, and regardless of any scrolling on the map?

in reply to:  2 comment:3 by fabio, 13 years ago

Replying to Philip:

I guess "a while" may have been r9139. This looks like a z-ordering problem, but it works fine for me and I don't see why it'd be different for you :-(

What drivers are these? Is it the same regardless of renderpath/shadows/fancywater, and regardless of any scrolling on the map?

Broken with r300g (git master and git 7.9 branch) and every combination of renderpath/shadows/fancywater.

Works fine with old r300 and llvmpipe.

comment:4 by fabio, 13 years ago

I reverted r9139 and indeed the minimap worked again. However, if you think the current 0ad code is fine, and indeed it only breaks gallium r300, maybe it's better to leave this as is. In this case I'll open a bug report against the r300 gallium driver.

comment:5 by Kieran P, 13 years ago

Priority: Should HaveRelease Blocker

comment:6 by Philip Taylor, 13 years ago

Milestone: Alpha 5Alpha 6
Priority: Release BlockerNice to Have

I don't see anything obviously wrong or particularly unusual with the current minimap code, and haven't seen problems in any other drivers, so I guess it's most likely that it is a driver bug.

(Only about 0.5% of users seem to be on r300g so I don't think this is critical for the release. But it's probably good to keep the ticket open for a while to track any driver bug reports, and maybe add workarounds to our code depending on what the bug is.)

comment:7 by fabio, 13 years ago

OK, I reported the bug here: https://bugs.freedesktop.org/show_bug.cgi?id=36762

Please avoid adding the workaround until the r300g driver is fixed, so that mesa developers can have a test case for it.

comment:8 by Kieran P, 13 years ago

Milestone: Alpha 6Backlog

comment:9 by fabio, 13 years ago

Description: modified (diff)

comment:10 by fabio, 13 years ago

Since there are users complaining about this in the forum maybe the old behavior should be made the default on mesa r300g, adding also a command line option -mesabug36762 to force the bugged mode (to have a test case for fixing r300g).

comment:11 by Philip Taylor, 12 years ago

I seem to get the same incorrect appearance with Intel HD Graphics 3000 on Win7. Will try to debug some time, since I'd like to know what we're doing wrong.

comment:12 by fabio, 12 years ago

This problem no longer appears in current SVN version of 0ad (but it is still reproducible with alpha 8, just to confirm it wasn't fixed in the graphic driver). Do you have an idea on what's happened? Eventually this bug (and the related mesa one) can be closed.

comment:13 by Kieran P, 12 years ago

Milestone: BacklogAlpha 9
Resolution: fixed
Status: newclosed

Excellent. Philip made a lot of changes recently to try and support mobile platforms like Android. Most of his changes were cross-platform, i.e. also affected the desktop version. This and a few other rendering bugs may be fixed now :-) So I'm going to close this issue as resolved.

comment:14 by Philip Taylor, 12 years ago

I think the relevant change was r11041 - the problem was probably basically just z-fighting, where it would fail on certain drivers due to minor variations in the depth calculations.

in reply to:  14 comment:15 by fabio, 12 years ago

Replying to Philip:

I think the relevant change was r11041 - the problem was probably basically just z-fighting, where it would fail on certain drivers due to minor variations in the depth calculations.

I tried reverting it but I still get the correct behaviour. Something else fixed it.

Note: See TracTickets for help on using tickets.