Strange Mouse behavior in latest trunk builds

[Verminus]

Hi, I'm getting some strange mouse/pointer behavior with the latest svn trunk builds, all the menus are fine, but once I get into the game, (skirmish or campaign), when ever i try to move the mouse over ANY part of the GUI (build/manufacture/research/intel/commander/design menus, power bar, anything!) the mouse pointer IMMEDIATELY jumps to what looks like wherever it was when the map loaded (usually around the middle of the screen, but not always)

I was thinking about submitting this to the bug tracker, but I don't know what to put, other than HELP! my mouse is messed up!. So I was wondering if anyone else is having this problem? or knows if it is something on my end and not a WZ problem. my spstem spec/setup is below:

CPU: AMD Athlon 64 X2 Dual Core 3800+
Motherboard: Asus A8N-SLI SE
RAM: 4x 512MB PC3200 400MHz DDR-SDRAM
GRAPHICS: Geforce 7600 GT
SOUND: Creative SoundBlaster Audigy2 Platinum eX
MOUSE: Logitech Mx518
Keyboard: Logitech "Access"
OS: Ubuntu 7.10 "Gutsy Gibbon" (amd64)
KERNEL: Linux 2.6.22-14-generic
DESKTOP: GNOME 2.20.1
NVIDIA DRIVER VERSION:100.14.19

[Buginator]

Hi, I'm getting some strange mouse/pointer behavior with the latest svn trunk builds, all the menus are fine, but once I get into the game, (skirmish or campaign), when ever i try to move the mouse over ANY part of the GUI (build/manufacture/research/intel/commander/design menus, power bar, anything!) the mouse pointer IMMEDIATELY jumps to what looks like wherever it was when the map loaded (usually around the middle of the screen, but not always)

I was thinking about submitting this to the bug tracker, but I don't know what to put, other than HELP! my mouse is messed up!. So I was wondering if anyone else is having this problem? or knows if it is something on my end and not a WZ problem. my spstem spec/setup is below:

CPU: AMD Athlon 64 X2 Dual Core 3800+
Motherboard: Asus A8N-SLI SE
RAM: 4x 512MB PC3200 400MHz DDR-SDRAM
GRAPHICS: Geforce 7600 GT
SOUND: Creative SoundBlaster Audigy2 Platinum eX
MOUSE: Logitech Mx518
Keyboard: Logitech "Access"
OS: Ubuntu 7.10 "Gutsy Gibbon" (amd64)
KERNEL: Linux 2.6.22-14-generic
DESKTOP: GNOME 2.20.1
NVIDIA DRIVER VERSION:100.14.19

You mean it snaps back to the center of the screen?
If so, then this is the first time I heard of this.  Have no idea what could cause it to do that.
You play window or fs?

[Kamaze]

Do a barrel roll. That should fix it.




Joking apart, do you have any logfile or can you crash the game with this?

[Verminus]

Joking apart, do you have any logfile or can you crash the game with this?

No the game won't crash so no gdmp file. Ran 'warzone2100 --debug=all --debugfile=/tmp/warzone-debug.log' to get a log file, (attached) loaded warzone, started skirmish on sk-rush, one AI, tried to move the mouse over a Gui element 6 or 7 times, then quit. (the menu brought up by pressing Escape is the only part of the GUI i can put the mouse over.)
Don't know if there anything useful in there though.

You mean it snaps back to the center of the screen?
If so, then this is the first time I heard of this.  Have no idea what could cause it to do that.
You play window or fs?

Not quite the center of the screen, sometimes its on one of the edges of the screen (causing the view to scroll), its not the same place for every game, but it is the same place every time for that game (if that make sense)

I play in Fullscreen. Tried changing the resolution from 1280x1024 down to 640x480 and it made no difference.
However, running in a window stopped the problem form occurring.

[Giel]

This is a known issue and it only appears when using the coloured mouse cursor.

You can disable the coloured mouse cursor by setting "ColouredCursor=0" in ~/.warzone2100/config (this is now the default).

[Verminus]

Cool, thanx.

Wasn't sure if this was just specific to my machine or not as I couldn't find anything remotely similar either here or on the bugtracker. Good that it has such a simple workaround.

Shame though, the coloured cursors look really good.
Pity i cant use them fully yet.

[Buginator]

This is a known issue and it only appears when using the coloured mouse cursor.

You can disable the coloured mouse cursor by setting "ColouredCursor=0" in ~/.warzone2100/config (this is now the default).

It looks like it has something to do with the trap cursor settings.  Turn that off, and use colored cursor.

It seems the the mouse motion events are not being updated when that is on.

Maybe a SDL bug.  Dunno.

[Verminus]

yea...
coloured cursor + fullscreen = bad,
no coloured cursor + fullscreen = good,
coloured cursor + window + trap cursor = bad,
coloured cursor + window + no trap cursor = good,

I guess this maybe why the PSX version had coloured cursors, and the PC didn't (except on 3dfx cards), maybe we should get someone to test on an old 3dfx card, if it works properly then we will have our answer ::)

[Buginator]

yea...
coloured cursor + fullscreen = bad,
no coloured cursor + fullscreen = good,
coloured cursor + window + trap cursor = bad,
coloured cursor + window + no trap cursor = good,

I guess this maybe why the PSX version had coloured cursors, and the PC didn't (except on 3dfx cards), maybe we should get someone to test on an old 3dfx card, if it works properly then we will have our answer ::)

Well, it seems to be a SDL issue.
This would NOT be a issue on windows, since it does support color hardware cursors.
SDL only supports monochrome hardware cursors for whatever reason.

[Chojun]

I guess this maybe why the PSX version had coloured cursors, and the PC didn't (except on 3dfx cards), maybe we should get someone to test on an old 3dfx card, if it works properly then we will have our answer ::)

Well, it seems to be a SDL issue.
This would NOT be a issue on windows, since it does support color hardware cursors.
SDL only supports monochrome hardware cursors for whatever reason.

Colored cursors work fine on our end.  I don't know about SDL but it the functionality is NOT limited to 3dfx as previously suggested.  I don't know what you guys have changed or how you re-implemented it but in the original source the colored cursors are rendered via the game's software pipeline.  In other words, they are neither hardware, nor controlled via Windows.

The only time this is an issue is when the framerate drops fairly low.

[Buginator]

Colored cursors work fine on our end.  I don't know about SDL but it the functionality is NOT limited to 3dfx as previously suggested.  I don't know what you guys have changed or how you re-implemented it but in the original source the colored cursors are rendered via the game's software pipeline.  In other words, they are neither hardware, nor controlled via Windows.

The only time this is an issue is when the framerate drops fairly low.

Let me clarify a bit, I meant to say that it would be better if it was hardware cursors, instead of software.

Yes, the original used software blits, and it is basically the exact same code as the original.
The input handler isn't the same, since it now uses SDL to handle that on all platforms.

The reason it 'skips' is that for some reason, it isn't getting the updated coordinates/events when a certain SDL call is used to trap the mouse pointer.
Unsure why.

[Buginator]

Another slight update.

We are talking about 2 different issues

1) full screen issue

2) trapping issue in window.

They now appear to be both SDL bugs.

I didn't get a chance to check out what exactly SDL is doing, but here is my thoughts on these.

If you disable (and by that I mean comment out the lines) SDL_ShowCursor() in pie_SetMouse(), and pie_DrawMouse(), and in pie_DrawMouse() disable the check to see if it is colored or not (yes, it will always draw it now, under the hardware cursor), you will find that we don't have any issues.  Both are being drawn/updated fine.
It looks like in fullscreen mode, it saves the mouse state/position when you SDL_ShowCursor(SDL_DISABLE); and when you turn it on again, it resets the old mouse state/position, which is why the cursor goes back to the center(ish).
Here is a snippet of info:
init called x= 640 y=512
...
--SDL_DISABLE
motionEvent->x = 559 & y= 989 
SDL X= 559 Y= 989
blit X= 559 Y= 989
--SDL_ENABLE x = 641 & y= 516
...

Looks like a bug too me.

For the trapping in window mode, well, I already talked about it, but looks like another bug.

and now ... zzzzzzzzzzzzzzz

[Buginator]

OK, I did a workaround for it, since I didn't feel like digging through the SDL code.

Whenever they submit the patch, both cases should be fixed.

[Buginator]

OK, It is now in trunk.

If you can svn up, and test it, and report back if it is OK now, it would be appreciated.

[Verminus]

Yea it works fine now. Thanks