Jump to content
Eternal Lands Official Forums
Grum

Ati(?) click/walking bug

Recommended Posts

Okay, inkydoo did some debugging, and it looks as if the depth value that is returned by the glReadPixels command in get_world_x_y() is off by a factor of 256. At least multiplying it with 256 made him move again. Reading the value as an unsigned integer instead of as a float, and then dividing by 2^bpp gives the same result as directly reading as a float. For the record: on my machine (amd64 laptop with nVidia GF4 MX440 Go) those two numbers are also equal, but they are correct :P Hence it looks like on the offending cards, the drivers and EL/SDL/OpenGL whatever, have different ideas on the range of the depth buffer.

 

Thus, the question is: what could be causing the glReadPixels() to return a value that is exactly 2^8 too low?

Share this post


Link to post
Share on other sites

man glGet

 

Try testing with glGet and GL_DEPTH_* and check the values on the 2 machines. I don't have the time for it right now, but I would guess that's the source of our error as well.

Share this post


Link to post
Share on other sites

Check the values for GL_DEPTH_SCALE and GL_DEPTH_BIAS(using glGet). They should be 1.0 and 0.0 respectively. If they're not, then it probably is a driver problem, since those are the default values. In that case, use PixelTransfer to set them manually.

Edited by mikeman

Share this post


Link to post
Share on other sites

Thanks for the info. Currently waiting for inkydoo to run yet another test :(

Share this post


Link to post
Share on other sites

So, it was a problem with the OpenGL implementation of ATI?

Nvidia also had a problem with that function, on Linux (returned some garbage).

Share this post


Link to post
Share on other sites

Figured I might as well join the conversation directly. I'm more of a unix sysadmin type, so my experience with C is limited to very basic debugging. As such, feel free to laugh hysterically at anything I have to say with regard to programming (at least in C).

 

I inserted the debug code to print the various GL_* variables within init.c at the end of init_stuff(). The values returned appeared to match Grum's. If anyone else wants a look, I'll be happy to post them here as well.

 

I also wanted to point out that I was able to "fix" the problem by making two changes. First, in interface.c, Grum asked me to replace

the get_world_x_y() function with the following:

void get_world_x_y()
{
 float float_mouse_z, mouse_z, z;
Uint32 int_mouse_z;

glReadPixels(mouse_x, window_height-mouse_y, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &float_mouse_z);
glReadPixels(mouse_x, window_height-mouse_y, 1, 1, GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, &int_mouse_z);
mouse_z = ldexp ((float)int_mouse_z, -bpp);

printf ("mouse coords: (%d,%d,%f =? %u/2^%d = %f)\n", mouse_x, mouse_y, float_mouse_z, int_mouse_z, bpp, mouse_z);
unproject_ortho(mouse_x,window_height-hud_y-mouse_y,mouse_z,&scene_mouse_x,&scene_mouse_y,&z);
}

 

Then, in the beginning of the init_video() function, where it tries to establish a value for bpp, it basically looks for 8 or 16 bpp, and then defaults to 32 (line 236 in the 1.47 revision of gl_init.c becomes "else bpp=24;"). If I change that default to 24 and recompile, I can now walk with the normal left-click again. This made me think that maybe if I just added a test for 24bpp righ tafter the test for 16, it might catch it and work. Nope. it goes right past 24 and defaults to 32 as usual.

 

Obviously this isn't a real fix, since I suspect it would totally screw up most people, but maybe it can point someone toward the real source of the problem (or maybe just the place where the problem can be fixed if it turns out the problem is really with the ATI drivers).

Share this post


Link to post
Share on other sites

Good job.

Until a proper fix, we can add a variable in el.ini so those with some ATI cards can turn that on, until ATI fixes their god damn drivers.

Share this post


Link to post
Share on other sites

For what it's worth, and it may not be worth much, but I'm using an ATI card with zero problems. I may have misread this thread, but perhaps the drivers are either A) out there or :P not available for an older card and as such may not ever be officially released for those cards?

Share this post


Link to post
Share on other sites

goliath, is this under linux or windows that your ATI cards work? I've tested on three different Dells with three slightly different ATI cards (one is a laptop even), but all of fairly recent vintage (1-1.5 years old). Under windows, EL works just fine* on all three. Under linux, left click to walk is borked on all three.

 

Also, just for the record, I've tried several different version of the official ATI drivers (inasmuch as ATI has recently been releasing ne Linux drivers relatively often), and the problem exists in all of them. Of course, that doesn't mean it isn't a bug in their drivers, I'm just offering it as a data point.

 

Ent, if you want me to test the patches to CVS that would allow such an entry in el.ini, let me know.

 

Thanks to everyone, especially Grum, for taking the time to guide me through this troubleshooting.

 

* Actually, on the laptop (under windows or linux), every so often, the graphics get totally screwed up, flickering wildly in the EL window and causing a static type look on everything outside the EL window. So far, I've found two solutions to this. The easiest is to reboot the machine, but sometimes I've been able to fix it by moving the EL window around the screen repeatedly until it stops (though it can take a lot of moving to do this). Different bug though, and I recognize that laptop video is a nasty beast, so unless someone reeally wants to talk to me about this, I'll drop it now.

Edited by inkydoo

Share this post


Link to post
Share on other sites

inkydoo, i checked in a patch that arbitrarily multiplies the depth value by 256 if #ati_click_workaround is set to 1 in el.ini. If you could try it, that'd be great.

 

Meanwhile, we need to find something that detects this situation.

Share this post


Link to post
Share on other sites

I got the latest CVS, with your recent changes. I ran it once before changing my el.ini as needed, and got a segfault. Reverted multiplayer.c to 1.100 (since that doesn't appear to be related to the ati issue). That made the seg fault go away, and...

 

Once I add the #ati_click_workaround = 1 to my el.ini, it works. As you say, this is just a workaround, but at least it's a working workaround.

Share this post


Link to post
Share on other sites

Cool.

 

Of course now I'm worried about the segfault, and I can't find any change in multiplayer.c that would cause a segfault from 100->101, unless you compiled with -DMULTI_CHANNEL. (Even then, it shouldn;t crash, but this change needs server support to function properly).

Share this post


Link to post
Share on other sites

It segfaults whether I add the -DMULTI_CHANNEL or not.

 

Here's the ouput of running the current CVS version (compiled without the -DMULTI_CHANNEL) through gdb (run with no options):

(gdb) run
Starting program: /home/shanew/EL-test3/elc/el.x86.linux.bin 
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 17897)]
I/O warning : failed to load external entity "languages/en/strings/titles.xml"
I/O warning : failed to load external entity "languages/en/strings/titles.xml"
[New Thread 32769 (LWP 17900)]
[New Thread 16386 (LWP 17901)]
[New Thread 32771 (LWP 17902)]
[New Thread 49156 (LWP 17903)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17897)]
0x4046ac35 in mallopt () from /lib/libc.so.6

 

And here's the last few lines of an strace (run with no options):

recv(15, "\0t\1\220Hi, and welcome to Eternal L"..., 8192, 0) = 374
open("/home/shanew/.elc/chat_log.txt", O_WRONLY|O_APPEND|O_CREAT, 0666) = 16
fstat64(16, {st_mode=S_IFREG|0644, st_size=13972, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
x4b20e000
fstat64(16, {st_mode=S_IFREG|0644, st_size=13972, ...}) = 0
_llseek(16, 13972, [13972], SEEK_SET)   = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

 

The only change I made was removing the "-Wdeclaration-after-statement" from Makefile.linux

Share this post


Link to post
Share on other sites

At least this one was only indirectly introduced by me :P

 

Please update CVS and try again. I think it should be fixed.

Share this post


Link to post
Share on other sites

Just for information really.

 

I run Suse Linux 9.3 and have moved from the ATI 8.12 driver to the ATI 8.14 drivers. Looks like they have fixed the problem that required '#ati_click_workaround = 1'.

 

In fact having the workaround enabled under 8.14 reintroduces the left click movement problem.

Share this post


Link to post
Share on other sites

Yes, if they finally fixed the bug, than the workaround will cause trouble. Only try it when normal walking doesn't work.

Share this post


Link to post
Share on other sites

just to chime in - it is if you use the ati drivers in linux, then you have the problems. if you use drivers from kernel then it will be fine.

 

i am running ati driver 8.12 now with via-agp modules loaded and i must use ctrl+right to walk. im not going to update to 8.14, but will wait for a new release of the el client for the fix. i'd rather not deal with cvs and cutting edge drivers for my ati card atm. but i'm glad to hear it is working for people. =)

 

EDIT: ok, i caved and am loading the 8.14.13 drivers! :(

 

EDIT2: client 1.0.1 works with the ati 8.14.13 drivers. regular left clicking is functional just like Murlock says! ;)

Edited by Carpathius

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×