#3151 closed defect (fixed)
GUI: Minor glitches with modern theme on IRIX64
| Reported by: | joostp | Owned by: | lordhoto |
|---|---|---|---|
| Priority: | low | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
There are 2 minor issues with the modern theme GUI when running ScummVM ("latest" SVN, dated April 19th) on my Octane.
1) Mouse-over buttons look wrong - see first screenshot.
2) There are some weird pixels near the border of GUI components on the overlay (maybe it attempts to do blending?) - as seen in the second screenshot.
I've attached a 3rd screenshot which shows both problems at once.
The machine in question is an SGI Octane (64-bit, big-endian) running IRIX. Not sure which version, 6.5.27 I think, but it shouldn't matter.
Ticket imported from: #1704753. Ticket imported from: bugs/3151.
Attachments (5)
Change History (34)
by , 17 years ago
| Attachment: | gui-glitch1.png added |
|---|
comment:4 by , 17 years ago
This is a 64bit issue, probably in the code responsible for gradient computations in gui/ThemeModern.cpp (calcGradient etc.). I recently saw very similar glitches when I tried to optimize the code a bit. There is some very subtle overflow issue there or something alike.
comment:5 by , 17 years ago
| Owner: | set to |
|---|
comment:6 by , 17 years ago
An '64bit issue' just happening on BE machines though, on my Linux/amd64 machine there're no problems.
comment:7 by , 17 years ago
Wouldn't be the first case of this I've seen...
Anyway, the code as it is relies on the RGB data occuring in that order in the OverlayColor. If the bits for one color are not in a row (e.g. when you deal with LE graphics data on a BE system, or vice versa), it'll break down. Maybe this is the case. But I am just throwing ideas into the court, I can't debug this *shrug*.
comment:8 by , 17 years ago
I wonder where the LE data should come from...
I don't have any 64bit BE machine to check/debug this, but I'll see what I can do about it.
comment:10 by , 17 years ago
Nothing new yet, as I'm not able to reproduce it on any platform I have access to, which are 32bit/LE 64bit/LE and 32bit/BE.
comment:11 by , 17 years ago
| Status: | new → pending |
|---|
comment:12 by , 17 years ago
What is the status of this item? Does the issue still occur with latest SVN? Does it occur with 0.10.0?
comment:13 by , 17 years ago
| Status: | pending → new |
|---|
comment:14 by , 17 years ago
I don't have access to my Octane at the moment, but the problem still existed in an SVN trunk checkout of 19th June 2007.
comment:16 by , 16 years ago
| Priority: | normal → low |
|---|
comment:17 by , 16 years ago
Two questions:
1) Does this bug still occur with latest SVN?
2) Does this bug occur in Tanoku's GUI branch?
comment:18 by , 16 years ago
1) Yes, the bug still occurs with latest SVN.
2) Yes, the whole general GUI looks a lot worse (see gsoc2008-gui-1.png) and while the weird pixels on the border of the debugger are now gone, the rest of the window is "wrong" in that the window has no opacity and the font is illegible (see gsoc2008-gui-2.png).
I should add that I'm using gcc 3.4.0, and not mipspro (which I don't have access to).
comment:21 by , 16 years ago
Interestingly enough, if I force InitScalers(555) in backends/sdl/graphics.cpp instead of letting the system choose between 555 and 565, then the glitches with the current gui code go away.
comment:22 by , 16 years ago
The code in question:
// Distinguish 555 and 565 mode if (_hwscreen->format->Rmask == 0x7C00) InitScalers(555); else InitScalers(565);
However, on my machine: Rmask = 0x1F, Gmask = 0x3E0 and Bmask = 0x7C00 - so it seems like BGR rather than RGB. If I change:
if (_hwscreen->format->Rmask == 0x7C00)
to:
if (_hwscreen->format->Rmask == 0x7C00 || _hwscreen->format->Bmask == 0x7C00)
then it uses 555 and everything looks ok.
However, I have no idea if this is the correct fix...
comment:23 by , 16 years ago
Tanoku's code currently has problems with BGR modes, since our ColorMask code only supports RGB 555 and not BGR 555 and he relies on that for color creation/assembling. Thus all colors will be R/B swapped.
Of course that's more of a problem with our support API for that. So we would need to extend the ColorMask and related helper API. How we do that has to be planned though :-).
comment:24 by , 16 years ago
Thanks for the update!
I think we need to get rid of ColorMask & gBitFormat. And introduce OSystem::getScreenPixelFormat() and OSystem::getOverlayPixelFormat() methods. And a PixelFormat struct similar (or even identical?) to that of SDL. That should solve this problem once and for all. And I don't think the peformance penalty would be that bad, we could still have code optimized for e.g. 555 and 565 mode, but now we'd let the middleware decide about that, instead of the backend.
I read in the logs that the GUI code was a lot smaller. Guess we should try to optimize it then :). I will try to use a profiler on it, but my machine is too fast to notice speed hogs. Maybe I can find an old 400 Mhz machine somewhere, that certainly would help doing tests :).
comment:25 by , 16 years ago
Actually I think we can/should keep ColorMask templates to allow easy templated specialization code. But I agree that we need some PixelFormat struct like SDL has to allow generic color support.
Introducing it might also ease adding 16bit support for the backend. Just thought of it since you talked about a possible OSystem::getScreenPixelFormat :-).
comment:27 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:28 by , 15 years ago
This was fixed by the PixelFormat stuff that was introduced some time ago. Guess I forgot to close this bug. :)
To answer Eugene's question; no, the new GUI rewrite didn't fix this (in fact, IIRC it made it worse than it was before).
comment:29 by , 5 years ago
| Component: | → GUI |
|---|
Screenshot 1