DRD Team

Well the title says it all, basically. Except that this is LINUX related.

EDIT: What I mean is, the mouse cursor 'sticks' to the center of the screen. When moving the mouse, the cursor also moves, but snaps back towards the center. So when in game, the cursor 'jumps around' your crosshair.
This behaviour is present ingame and in the menus. The mouse is 'released' in the same instant you press 'y' when quitting. I can then move it away from the center, just before the window/gameview gets destroyed and gzdoom exits.

I'm new to the forums, and yes I did read the 'posting bugs'-guideline

This is happening on a 64bit-linux build. I know this kind of thing can have a lot of different causes, that don't necessarily lie within gzdoom.
But:
Zdoom doesn't have this, neither has GZdoom's software renderer.
So this definitely contained in the GL renderer.
I also don't get this with any other openGL(+sdl) apps.
EDIT: Only in fullscreen mode. Windowed works fine.

I'm using Gentoo Linux, everything X11 related is pretty new.
I'm also using the opensource drivers for my ati 9800(r300), current kernel etc.

So, are any other linux users out there who have experienced this problem?
Or maybe other problems?
I was pretty pleased after checking out svn a couple of days ago. I could build with (nearly) no hassle. And basically everything works(stability is another issue...).
Considering that not too long ago (G)Zdoom was a no-go for linux people, I'm really impressed

I have not experienced this problem with Slackware 12.0, running Skulltag in GL mode (natively). However, I've never had a successful GZDoom build on my version of Linux.

What was giving you problems when building?
I myself had a slight problem due to it not finding the fmod-libraries. I found a thread on the zdoom forums, and a workaround for it.
To build (both zdoom and gzdoom) I followed the compile guide on zdoom wiki. All I needed to to was adjust the compile command slightly: Keep in mind that this only works if you have specified version of fmod installed!

I sometimes have this problem, but bringing up a menu and closing it usually fixes it. If that doesn't do it, try disabling/reenabling the mouse under the menu. See if that works.

try disabling/reenabling the mouse under the menu.

You're a genius

On disabling the mouse, I can move it away, off the screen. Then re-enabling it, it stays off screen, and I can play without the cursor bugging me.

Might be handy to have a keybinding, then.should work.

Thanks for that, its been getting really annoying doing this by hand every time gzdoom starts up, especially due to it not being very stable in general, thus crashing often.

I somehow missed your post, or I would have replied earlier...

EDIT: It now only requires two toggles on->off->on to make the mouse cursor disappear.
No more moving it off screen, once it gets 'released' when use_mouse is set to false, via the menu.

EDIT: This seems to maybe originating from zdoom's base:
http://forum.zdoom.org/viewtopic.php?f=2&t=16409
Something up with the SDL-initializing??

This makes the key perform the action twice, so you don't have to.

As far as the origin of the problem, I have no idea, mainly because I haven't used Linux in a while now.

This makes the key perform the action twice, so you don't have to.

That doesn't seem to work. The double toggle does, but the mouse cursor does not 'disattach' itself form the gl-screen.
Probably it needs to actually 'be false' for a moment for it to work, the double toggle doing it instantly

Oh, this is now 296,299,300.

Hey, cool that works
But I was thinking couldn't this just be autoexec'ed at startup somehow?

I've never tried wait commands at autoexec, but my guess is, they don't work. Graf can correct me if I'm wrong, though.

This is actually a bug which only affects linux,
when i sent in a (small) patch to make it compile in linux about a year ago, gzdoom seemed to want to initialise its renderer twice.
When i inserted a check to not "refresh" when the old res is the same as the new one the issue stopped, but since this wasn't a real fix, i inclined graf not to use it.
I said i was going after that bug, but have seemed to stop looking for it about a couple days afterwards, and haven't started to check again.

so TL;DR, it's a bug that occurs after i sent in a patch, haven't (or graf) been able to fix it yet .

edit: damn it seems i've bumped it quite a bit now when i look at the dates, but i'm glad i finally got it off of my chest

graf, could you check to see if this code actually still works on windows?
all i've done is add "setmodeneeded = false;" to v_init2(), because it did a complete "init" there.

I don't see any reason to do another init, and this fixes the linux "in-mouse" problem, hence i'm posting it here.

I'm posting a patch which is to be applied to a clean r351 though.

There's also a bug where the save game doesn't get written to ${HOME}/.gzdoom, but a folder called ~.gzdoom in the current directory.
Do you want me to fix it or is it already done? (i thought that a bug this "serious" ought to be noticed imm.)

r401 is still affected by this bug, seems really like an SDL initialization problem.