Bug 48

Summary:	Cannot click to move or interact with objects on Linux with Radeon X1950 Pro card
Product:	Salem	Reporter:	Karsten Bock <KarstenBock>
Component:	Client	Assignee:	loftar <fredrik>
Status:	RESOLVED DUPLICATE
Severity:	critical
Priority:	Normal
Version:	unspecified
Hardware:	PC
OS:	Linux
Attachments:	The clickimage for windows. The clickimage for for linux.

Description Karsten Bock 2012-08-30 19:16:08 CEST

This bug is similar, but not completely, to this: http://www.seatribe.se/bt/show_bug.cgi?id=12

I cannot interact with the 3D environment at all, the 2D-UI works. It works on windows with the same hardware.

Through my own investigation and the patch in the above mentioned ticket I have found the following:

1. It fails on the first check (MapMesh hit = rl.get(g, c) - in MapView)
2. Somehow the color values of the rendered image on linux are wrong. E.g. instead of red 208 it is red 207. I will attach the images, one from windows and one from linux. They are both made in the new game area.

Technical Information:

The Distribution is Ubuntu Precise.
I am using an Radeon X1950 Pro graphics card.
Since there are no official drivers for my card that work with the current kernel version I am using the r300g (Gallium) drivers from Mesa for accelerated 3D graphics.

Comment 1 Karsten Bock 2012-08-30 19:17:00 CEST

Created attachment 7 [details]
The clickimage for windows.

Comment 2 Karsten Bock 2012-08-30 19:18:07 CEST

Created attachment 8 [details]
The clickimage for for linux.

Comment 3 loftar 2012-08-30 19:40:40 CEST

I see; that's interesting.

My initial analysis is that it seems like a driver bug, though, and that it's a different issue from #12. In this case, the color is just slightly off, as if it were a floating-point rounding error, while in #12 it's completely off the scale altogether.

I can't immediately think of any workaround, though.

Comment 4 loftar 2012-08-30 19:45:09 CEST

Hmm, actually. Since you're patching the code anyway, can you try changing the c2fa() function in src/haven/Utils.java so that it reads 256 instead of 255 in all four places?

Comment 5 Karsten Bock 2012-08-30 20:51:22 CEST

(In reply to comment #4)
I will try that when I boot Linux next time, which is probably not before tomorrow.

Comment 6 Karsten Bock 2012-08-30 21:02:44 CEST

(In reply to comment #4)
Changing that will lead to the same problem on windows though.

Also, I would suspect a driver bug too, but as far as I know there is no other/better driver I could use. And a new graphics card is out of the question too.

Comment 7 loftar 2012-08-30 21:04:00 CEST

(In reply to comment #6)
> (In reply to comment #4)
> Changing that will lead to the same problem on windows though.

Certainly. I'd just like to know whether it makes it work. It might lead to some possible workaround.

Comment 8 Karsten Bock 2012-08-30 21:20:39 CEST

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > Changing that will lead to the same problem on windows though.
> 
> Certainly. I'd just like to know whether it makes it work. It might lead to
> some possible workaround.

OK, I just checked it and changing the values to 256 does not make it work. The colours values are one more less then. If I change them to 254 though it works.

Comment 9 Karsten Bock 2012-08-31 09:32:37 CEST

Ok, I've been testing it some more and while clicking to move now works most of the time interacting with objects only works rarely. This may or may not be a different bug though as it passes that check that failed before.

Comment 10 loftar 2014-03-14 08:20:52 CET

Made a new, more descriptive report for the general case of this particular problem.

*** This bug has been marked as a duplicate of bug 211 ***