Opened 8 years ago

Closed 8 years ago

Last modified 8 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 Changed 8 years ago by fabio

Milestone: BacklogAlpha 5

comment:2 Changed 8 years ago by Philip Taylor

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?

comment:3 in reply to:  2 Changed 8 years ago by fabio

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 Changed 8 years ago by fabio

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 Changed 8 years ago by Kieran P

Priority: Should HaveRelease Blocker

comment:6 Changed 8 years ago by Philip Taylor

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 Changed 8 years ago by fabio

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 Changed 8 years ago by Kieran P

Milestone: Alpha 6Backlog

comment:9 Changed 8 years ago by fabio

Description: modified (diff)

comment:10 Changed 8 years ago by fabio

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 Changed 8 years ago by Philip Taylor

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 Changed 8 years ago by fabio

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 Changed 8 years ago by Kieran P

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 Changed 8 years ago by Philip Taylor

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.

comment:15 in reply to:  14 Changed 8 years ago by fabio

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.