2024-03-28, 20:13 *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
Pages: [1] 2
  Print  
Author Topic: Generations Arena under Linux ?  (Read 36881 times)
0 Members and 1 Guest are viewing this topic.
Darksoul71
 
Dopefish
*
Posts: 5

« on: 2011-12-05, 12:44 »

Hi there,

has anyone of you been able to run generations arena natively under Linux with ioquake3 ?  Doom - Huh?

Under Linux ioquake3 is currently the best option to run Q3A plus mission pack and several mods. I have use E+ successfully for a long time.

Unfortunately generations arena bombs out after displaying the intro screen with a few error messages about missing files.

I am not that much in knowledge about modding in Q3A but at least under Quake most mods run fine under Linux as well as under Windows. The only issues I had here where when mod devs used Window-specific path to content of their mod (e.g. graphics, sound files).

Could this be a possible problem source for the error messages ?
I am willing to help in regard to Linux support with ioquake3. Be it beta-testing or what else.  Doom - Thumbs Up!

TIA,
D$
Logged
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #1 on: 2011-12-05, 16:08 »

Hmmm, I thought it would be a quick check to confirm it works for me, but you're right.  ioq3 doesn't seem to like generations now.  I've used linux to run servers for it, but the issue is in the UI system.  I think generations uses TA menu stuff (don't quote me on that, since I'm very rusty on all that), so maybe that's a clue.

Runs fine with q3 1.32b linux.
Logged
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #2 on: 2011-12-05, 16:19 »

Did some quick digging for you.  I know urban terror uses a similar menu system and searched around for that.  The issue is actually an ioq3 issue that I don't believe has been addressed (as it only happens on 64bit linux).

It should work fine for you if you use the ioq3 32bit linux binary.

Edit: I should say it's not so much an ioq3 issue as it is an issue with a piece of q3 code that was never designed for 64bit compiling.  I assume anyway... I haven't actually looked at the code yet Slipgate - Tongue
« Last Edit: 2011-12-05, 16:23 by fourier » Logged
Darksoul71
 
Dopefish
*
Posts: 5

« Reply #3 on: 2011-12-05, 16:32 »

Thanks for your reply and the hint !  Slipgate - Thumbs up!

I will crosscheck with ioquake32 this evening and report back.

As for the original Q3A Linux port I always tried to use ioquake mainly because I thought that ioq is more advanced in technical terms.

Another (dumb) option would be running Q3A as Windows version inside WINE.
Logged
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #4 on: 2011-12-05, 17:19 »

I just installed q3 in linux on this install (I did a fresh install of ubuntu a few months ago), since I wanted to say hi to someone in quake.  My obsessive mind noticed the mouse acceleration in q3 even though I had x disable acceleration (xset m 0 0 && xinput set-prop <devid> 'Device Accel Profile' -1 && xinput set-prop <devid> 'Device Accel Velocity Scaling' 1).  I then tried in_mouse 2 which supposedly uses x's mouse, but it still had acceleration and seemed to operate completely independent of whatever x settings I used (changing x sensitivity had no affect in q3).  In addition, I had noticed some issues with the side buttons on the mouse and a bizarre problem where if I hit ENTER (such as while typing a message) and I was windowed, it would fullscreen.  Finally, I decided to install ioq3 and see if it worked there, and it did -- no more mouse accel.  So I can see why ioq3 would be the better choice in this case.

I would say you should use the native linux binary before wine (not sure what point there would be to running the windows version under wine).
Logged
Phoenix
Bird of Fire
 

Team Member
Elite (7.5k+)
*********
Posts: 8805

WWW
« Reply #5 on: 2011-12-05, 19:46 »

I can confirm for you that Gen uses the TA menu system.  It's necessary for the HUD system to work.

Looking at the Linux code in Q3, this line seems to grab the accel info from the OS.  In linux_glimp.c:


Code:
XGetPointerControl(dpy, &mouse_accel_numerator, &mouse_accel_denominator,
                     &mouse_threshold);

That's the only reference I can find right now.  I'd have to dig through the code when I have more time to see if there's any kind of explicit acceleration references beyond the read request.  There's another possibility.  If you're running with vsync disabled it may affect the polling on the mouse, or mouse smoothing, which interpolates between two input reads, could be affecting it.  Try experimenting with combinations of r_swapinterval 0 and 1 (requires a vid_restart), and m_filter 0 and 1.  Tinker with com_maxfps as well... if set too high and frame rate varies a lot it could cause screwy input processing.  See if any combination of those settings have an effect.
Logged


I fly into the night, on wings of fire burning bright...
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #6 on: 2011-12-05, 20:37 »

It's working fine in ioq3, so I won't bother.  I appreciate the input, and don't worry about digging through it.  It's an issue that is difficult to make sense of.  For instance, some people under the same version under the same distro report that in_mouse 2 works with x, and other say it doesn't.  Obviously something is happening somewhere, but finding causes to this is more difficult than it's worth.  I've spent too many hours battling the issue in the past (mostly trying to overcome windows xp in particular -- the closest solution I found was MarkC's registry fix, the cpl one just plain doesn't work).  It also heavily depends on the mouse.
Logged
Darksoul71
 
Dopefish
*
Posts: 5

« Reply #7 on: 2011-12-05, 21:01 »

Hi there,

ok, I can confirm that Generations Arena works fine under Linux with ioquake3 32 bit  Doom - Love

I am unsure whether I should submit a bug to the ioquake folks here. Makes this sense ?  Banging Head against Wall

@fourier:
>(not sure what point there would be to running the windows version under wine).
The point here is that often (unfortunately) Windows versions of certain games work better under Linux as their Linux pendants. Be it because of external dependencies or whatsever.

UT2k4 as I have from Unreal Anthology requires little work when being installed under WINE while it is a major PITA if you try to install it under Linux natively.

Thanks again.....now Generations Arena is running under Linux. I am happy with the result.

Later,
D$



Logged
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #8 on: 2011-12-05, 21:29 »

Gotcha.  Id has a good history with making games compatible with linux (at least in the past).  The linux version of q3 is pretty compatible.  You'd have more issues with video drivers in linux than you would with q3 and linux.  I don't know about Epic's history with linux and how well their linux implementations are. 
Logged
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #9 on: 2011-12-12, 00:55 »

Update for you Phoenix.  Last night I ended up getting involved in trying to figure the Q3 issues with mouse accel (again, ioq3 works fine).  I blindly followed the XGetPointerControl, noticing that regardless of what settings you use in X it ignores them and always has an acceleration on it.  Well if you look more closely at what that is doing, you'll see it's grabbing the current values of mouse_accel_numerator, denominator, and threshold, then forcing them to 1, 1, 0 respectively with XChangePointerControl(which should disable accel on the pointer).  When you close down the game, and the system shuts down the input with uninstall_grabs(), you'll see it restores the values it saved when it started.

Beyond this, I can see that the game itself isn't applying any accel for me in CL_MouseMove(), so it's either getting input from X already accelerated (from who knows where, since it's disabled), or it has something to do with HandleEvents switch MotionNotify.  Both in_dgamouse 1 and 0 have an interesting "if abs(delta) > 1, motion += delta * 2; else motion += delta".  It's here where I cannot find where these mx and my values are even parsed, since I don't see a Sys_QueEvent for them; I have to assume it's happening somewhere, though, since this is the only area where mouse movement is processed from the system events.

You mind taking a look at linux_glimp.c HandleEvents() and see if I'm just missing something on that * 2 (maybe there's a logical reason it has to be * 2, but I didn't see one).  That would explain the issue, since that would essentially lock in a 2/1 accel ratio with a threshold of 1 (so anything but the tiniest movements would be accelerated).

I cannot debug anything since q3 hates being compiled on 64bit (I spent several hours altering the make file, cons, and construct scripts to get it to compile far enough where ld joins them but fails to find addresses of some tr and sound functions).  I'll just install a virtual 32bit distro sometime so I can actually debug this further.

Edit:
P.S. I miss quakesrc, lol.
Logged
Phoenix
Bird of Fire
 

Team Member
Elite (7.5k+)
*********
Posts: 8805

WWW
« Reply #10 on: 2011-12-14, 11:24 »

The SysQueEvent is right there under case MotionNotify: statement.  At the top of the file, mx and my are defined as static integers and set to zero, so they're calculated before the SysQueEvent in the logic.  It looks like they're derived from event.xmotion.x_root and event.xmotion.y_root, dumped into SysQueEvent, and then cleared.  SysQueEvent is throwing it into the game logic.

Best I can tell the y_root and x_root values are grabbed during XNextEvent, and it does look like the *2 forces a hard-coded accel into the mouse movement.  In the Windows stuff under win_input.c, the mouse code simply pulls in the X and Y values and dumps them into SysQueEvent, so the raw values go straight into the game logic.

Now why they put that 2x multiple in the Linux stuff I have no idea, but that looks like that's the most likely candidate for a forced acceleration problem.  It's a glaring mathematical difference between the Linux and Windows mouse code.  When I get a chance... assuming the old system still works... I'll see about booting up my Linux install and looking over the in-game behavior and testing this out.
Logged


I fly into the night, on wings of fire burning bright...
Phoenix
Bird of Fire
 

Team Member
Elite (7.5k+)
*********
Posts: 8805

WWW
« Reply #11 on: 2011-12-14, 14:29 »

I just nosed around the ioquake3 source, and linux_glimp.c isn't even used.  They changed a lot of stuff so the code segment that is present in the Q3 1.32b source isn't present in ioquake3, which would explain why it does not have the mouse issue present with the Id provided source.
Logged


I fly into the night, on wings of fire burning bright...
Phoenix
Bird of Fire
 

Team Member
Elite (7.5k+)
*********
Posts: 8805

WWW
« Reply #12 on: 2011-12-14, 15:46 »

My Linux install still works, though it took me a bit to remember how to compile on it.  Linux was definitely producing acceleration in Q3.  After some tinkering with sensitivity I was set it to move my view through a 90 degree arc at slow speed from one extreme of my controller's position to another, but moving the controller faster moved the view through 180 degrees through the same controller movement distance, so it seemed like we were on the right track with the 2x multiple being the culprit.  I made the following changes to this section of linux_glimp.c and recompiled:

Code:
    case MotionNotify:
t = Sys_XTimeToSysTime(event.xkey.time);
      if (mouse_active)
      {
        if (in_dgamouse->value)
        {
// Pho removed          if (abs(event.xmotion.x_root) > 1)
// Pho removed            mx += event.xmotion.x_root * 2;
// Pho removed          else
            mx += event.xmotion.x_root;
// Pho removed          if (abs(event.xmotion.y_root) > 1)
// Pho removed            my += event.xmotion.y_root * 2;
// Pho removed          else
            my += event.xmotion.y_root;
          if (t - mouseResetTime > MOUSE_RESET_DELAY )
          {
            Sys_QueEvent( t, SE_MOUSE, mx, my, 0, NULL );
          }
          mx = my = 0;
        } else
        {
          // If it's a center motion, we've just returned from our warp
          if (event.xmotion.x == glConfig.vidWidth/2 &&
              event.xmotion.y == glConfig.vidHeight/2)
          {
            mwx = glConfig.vidWidth/2;
            mwy = glConfig.vidHeight/2;
            if (t - mouseResetTime > MOUSE_RESET_DELAY )
            {
              Sys_QueEvent( t, SE_MOUSE, mx, my, 0, NULL );
            }
            mx = my = 0;
            break;
          }

          dx = ((int)event.xmotion.x - mwx);
          dy = ((int)event.xmotion.y - mwy);
// Pho removed          if (abs(dx) > 1)
// Pho removed            mx += dx * 2;
// Pho removed          else
            mx += dx;
// Pho removed          if (abs(dy) > 1)
// Pho removed            my += dy * 2;
// Pho removed          else
            my += dy;

          mwx = event.xmotion.x;
          mwy = event.xmotion.y;
          dowarp = qtrue;
        }
      }
      break;

This eliminated the speed doubling on the mouse inputs.   Doom - Thumbs Up!

If you want the binary to play with I'll need to rebuild a release build as the current build is debug, and I'll need to reroute some network cable to get this particular machine back on the net before I can upload a copy.  Let me know if you want a binary and I can probably get this all done sometime tomorrow.
Logged


I fly into the night, on wings of fire burning bright...
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #13 on: 2011-12-14, 18:20 »

I'm mostly looking at in_dgamouse 0, so I still don't see an area where Sys_QueEvent is called, but I really haven't examined it thoroughly, as it's not important how just that I know it is happening somewhere somehow.

Yeah, ioq3 completely changed how the structure and rendering, input, etc are handled (for the better in most cases).

I'd use ioq3 if I could, it's just for PB servers, so a recompile won't work.  I don't really know how to write a hook into statically linked stuff (I guess I could find some bot writers Slipgate - Tongue), but I think I can probably hook XNextEvent, since that's Xlib; if it's a mouse event, and if the dx/dy is > 1, I could divide by 2 (but this will create a 1/2 deceleration spot for anything between 1 and 2.  I'll think about this in detail when I have time.

A big thanks for testing this for me.  I tried installing ubuntu 32bit in virtualbox a couple days ago, and it just was a mess (locks up, a bunch of dmesg errors), so I kind of forgot about this Slipgate - Tongue  I know I've had centos in there before, though.  Actually, it might be easier to just compile this with mingw in my virtual windows OS.

As for why I asked for a second set of eyes, it just seemed too stupid for it to be that simple -- it's such a glaring bug (that's the only way I can refer to it) to hard code 2/1 acceleration into linux only...  I couldn't believe it would be that.  Also, I have found no one in any of the linux forums ever mention this as the cause for the acceleration problems has ever mentioned this, and now it's pretty obvious this is the cause.  It's so easy to see, and linux people are far more common to look at code and figure things out than windows users, it just surprises me this has not been talked about before.
Logged
Darksoul71
 
Dopefish
*
Posts: 5

« Reply #14 on: 2011-12-14, 21:16 »

Just a sidenote:
I have found another option to run Generations Arena natively under Linux:
Open Arena

This means being able to run Generations Arena without requiring the original Q3A files.

I found the hint here:
http://openarena.wikia.com/wiki/ModCompat/Generations_Arena

The only step required for enabling OA compatibility is copying a pak file into the Generations Arena directory which seems to match the Q3A players to the OA ones.

Have you ever considered building a standalone version of Generations Arena like this ?  Doom - Huh?

Logged
J3E125
 

Spider Mastermind
********
Posts: 407

In cunning 480p!

« Reply #15 on: 2011-12-15, 04:55 »

If I understand your question, you will still need the main models (Doom, Ranger, Sarge, Grunt.... eh Visor). I don't think its legal to put them in a standalone version, unless you make and animate new models, which if that were the case, generations wouldve been dead long ago and not very nostalgic.

(P.S. I use Open Arena to run on Windows XP and Android O.S.  Slipgate - Thumbs up!)
Logged

Darksoul71
 
Dopefish
*
Posts: 5

« Reply #16 on: 2011-12-15, 07:32 »

Quote
If I understand your question, you will still need the main models (Doom, Ranger, Sarge, Grunt.... eh Visor). I don't think its legal to put them in a standalone version, unless you make and animate new models, which if that were the case, generations wouldve been dead long ago and not very nostalgic.
Oops, it seems I did not explain things clear enough:
The pak file I was refering to is "remaping" the default Q3A bots to those available in Open Arena. Since Open Arena is fully free, a Generations Arena standalone based on it would also be free.

Many old Q3A mods have been change into standalone versions.
Logged
Phoenix
Bird of Fire
 

Team Member
Elite (7.5k+)
*********
Posts: 8805

WWW
« Reply #17 on: 2011-12-15, 12:30 »

There's some problems with OpenArena.  Generations 1.0 is going to use its own executable.  In addition, we've been making animation changes to the player models so that they hold and operate their weapons correctly from third-person point of view.  The executable could probably work with Open Arena, but the animation2.cfg files would have to be remapped so that they're not calling non-existant animations, or the Open Arena models would have to be modified in the same way we're doing with the torso models of the normal Q3 player models.

Legally, I do not think we could release a fully stand-alone project due to how the licensing is structured on the program code.  We'd have to completely move our code into the GPL, which means having to remove every line of code and manually put it into the GPL source from the 1.32 point source.  In addition, we'd run into intellectual property issues.  We have Id's explicit permission to do this for Q3A, and since it's using their intellectual property - Doom, Quake, etc - we could end up going outside the bounds of that permission.  So it's fine for a user to tweak Gen to work under OA, but for us to do it as a completely stand-alone project is not a good idea.

Fourier:  in_dgamouse calls it right above the break statement, but it's not necessary.  The read operation is occuring in XNextEvent.  Look at the "Pho Removed" comments.  See where it's setting dx and dy equal to the event.xmotion.x and even.xmotion.y calculations?  That's where the input is coming from.  SysQueEvent is only happening during a warp (teleport).
Logged


I fly into the night, on wings of fire burning bright...
Phoenix
Bird of Fire
 

Team Member
Elite (7.5k+)
*********
Posts: 8805

WWW
« Reply #18 on: 2011-12-15, 13:57 »

Here's the Linux binary with the changes I implemented.

http://www.wireheadstudios.org/phoenix/misc/linux_test/linuxquake3.zip
Logged


I fly into the night, on wings of fire burning bright...
fourier
 
Hans Grosse
*******
Posts: 267

« Reply #19 on: 2011-12-15, 15:41 »

Right, I understand where it's reading the input from (the XEvent), but I don't see where mx/my are populated into cl.mouseDx/cl.mouseDy.  It comes from X input, processed in linux_glimp.c, then how does it get into the q3 event queue?  Like I said, I haven't really looked at it, and it's not that important.  We're probably just talking about different things; I think you're referencing how the binary gets input from X, and I'm talking about how that input makes it to the mouseDx and mouseDy variables for CL_MouseMove().

To be more specific, client/cl_input.c CL_MouseMove needs mouseDx and mouseDy; mouseDx and mouseDy are populated in client/cl_input.c CL_MouseEvent; CL_MouseEvent is run from qcommon/common.c Com_EventLoop which pulls the event with Com_GetEvent, which pulls from Com_GetRealEvent which pulls from Sys_GetEvent.  So what I meant was, I don't see where the mx and my values get into eventQue[] so they process all the way through to CL_MouseMove and actually get into cl.viewangles.  Obviously they are, and I'm sure I just need to sit down and see where it's happening -- but not a big deal, though, since we know it's happening.

You didn't have to bother with the binary, but I'll check it just to confirm the problem is solved and try to figure out how I can fix it without modifying the binary.  That guy from quakesrc, luigi aerim---something-or-other used to make patch files somehow for the binary that didn't break PB; or maybe they would have for the client, since they were server patches.  The preload technique is workable but would have the deceleration thing I mentioned. 
Logged
Pages: [1] 2
  Print  
 
Jump to: