#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 )
The circular minimaps are broken here since a while. Example on current build from svn on Linux with Death Canion:
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 , 13 years ago
Milestone: | Backlog → Alpha 5 |
---|
follow-up: 3 comment:2 by , 13 years ago
comment:3 by , 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 , 13 years ago
comment:5 by , 13 years ago
Priority: | Should Have → Release Blocker |
---|
comment:6 by , 13 years ago
Milestone: | Alpha 5 → Alpha 6 |
---|---|
Priority: | Release Blocker → Nice 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 , 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 , 13 years ago
Milestone: | Alpha 6 → Backlog |
---|
comment:9 by , 13 years ago
Description: | modified (diff) |
---|
comment:10 by , 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 , 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 , 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 , 12 years ago
Milestone: | Backlog → Alpha 9 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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.
follow-up: 15 comment:14 by , 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.
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?