Opened 12 years ago

Closed 10 years ago

Last modified 8 months ago

#3151 closed defect (fixed)

GUI: Minor glitches with modern theme on IRIX64

Reported by: joostp Owned by: lordhoto
Priority: low Component: GUI
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)

gui-glitch1.png (22.1 KB) - added by joostp 12 years ago.
Screenshot 1
gui-glitch2.png (25.4 KB) - added by joostp 12 years ago.
Screenshot 2
gui-glitch3.png (105.6 KB) - added by joostp 12 years ago.
Screenshot 3
gsoc2008-gui-1.png (26.6 KB) - added by joostp 11 years ago.
gsoc2008-gui launcher
gsoc2008-gui-2.png (29.0 KB) - added by joostp 11 years ago.
gsoc2008-gui debugger

Download all attachments as: .zip

Change History (34)

Changed 12 years ago by joostp

Attachment: gui-glitch1.png added

Screenshot 1

comment:1 Changed 12 years ago by joostp

File Added: gui-glitch1.png

Changed 12 years ago by joostp

Attachment: gui-glitch2.png added

Screenshot 2

comment:2 Changed 12 years ago by joostp

File Added: gui-glitch2.png

Changed 12 years ago by joostp

Attachment: gui-glitch3.png added

Screenshot 3

comment:3 Changed 12 years ago by joostp

File Added: gui-glitch3.png

comment:4 Changed 12 years ago by fingolfin

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 Changed 12 years ago by fingolfin

Owner: set to lordhoto

comment:6 Changed 12 years ago by lordhoto

An '64bit issue' just happening on BE machines though, on my Linux/amd64 machine there're no problems.

comment:7 Changed 12 years ago by fingolfin

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 Changed 12 years ago by lordhoto

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:9 Changed 12 years ago by sev-

What is the status of this item?

comment:10 Changed 12 years ago by lordhoto

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 Changed 12 years ago by fingolfin

Status: newpending

comment:12 Changed 12 years ago by fingolfin

What is the status of this item? Does the issue still occur with latest SVN? Does it occur with 0.10.0?

comment:13 Changed 12 years ago by joostp

Status: pendingnew

comment:14 Changed 12 years ago by joostp

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:15 Changed 12 years ago by fingolfin

This bug is annoying, but mostly harmless, so lowering priority.

comment:16 Changed 12 years ago by fingolfin

Priority: normallow

comment:17 Changed 11 years ago by fingolfin

Two questions:

1) Does this bug still occur with latest SVN?

2) Does this bug occur in Tanoku's GUI branch?

comment:18 Changed 11 years ago by joostp

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).

Changed 11 years ago by joostp

Attachment: gsoc2008-gui-1.png added

gsoc2008-gui launcher

comment:19 Changed 11 years ago by joostp

File Added: gsoc2008-gui-1.png

Changed 11 years ago by joostp

Attachment: gsoc2008-gui-2.png added

gsoc2008-gui debugger

comment:20 Changed 11 years ago by joostp

File Added: gsoc2008-gui-2.png

comment:21 Changed 11 years ago by joostp

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 Changed 11 years ago by joostp

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 Changed 11 years ago by lordhoto

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 Changed 11 years ago by fingolfin

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 Changed 11 years ago by lordhoto

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:26 Changed 11 years ago by sev-

Does it still apply with new theme code?

comment:27 Changed 10 years ago by joostp

Resolution: fixed
Status: newclosed

comment:28 Changed 10 years ago by joostp

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 Changed 8 months ago by digitall

Component: GUI
Note: See TracTickets for help on using tickets.