Print Page - Generations Arena under Linux ?

Hi there,

has anyone of you been able to run generations arena natively under Linux with ioquake3 ? :doom_?:

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_thumb:

TIA,
D$

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 :P

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).

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.

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.

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 ? :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$

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.

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.

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_thumb:

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.

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 :P), 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 :P 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.

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_?:

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.

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).

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.

From what I can see, it forces a warp at the end of the code segment after setting the mx and my values:

Code:

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

This runs XWarpPointer further down. It also forces the Sys_QueEvent on the next pass since, best I can tell, XWarpPointer is resetting the cursor position to screen center, which sets the condition true for the "if" statement just below the comment about returning from a warp. It looks like it alternates code segments each pass if I'm reading the break statement correctly, running the "if" statement and sending the Sys_QueEvent and breaking out on one pass, then on the next pass running the dx = and dy = and then running XWarpPointer. It's pretty strange logic but that's the only way I can see the mouse data being pumped into the event queue. It may also explain why the mouse in Linux, to me at least, seems choppy compared to Windows. It would have to be updating the x and y positions every other client frame instead of once every frame, otherwise event.xmotion.x - mwx (and y) would be zero every frame. It doesn't make a lot of sense to have it written this way. I'm not sure who wrote this particular code segment but it's not very well implemented.

Let me be absolutely clear: Generations cannot and will not be sold by Wirehead Studios under any circumstances. Wirehead does not own any of the intellectual property involved in Generations - Id Software does. We have only been able to create the mod with Id's explicit permission. LeeMon personally emailed Todd Hollenshead to guarantee before we started that we would not do anything they did not want us to do. There will be no more talk about selling anything.

Now, please bring the conversation back on topic.

Old and OT, but i'd like to chime in on the issues

- Generations' VM code is based on the Q3A SDK, which has a strict EULA that prohibits use on anything but a retail copy of Quake III: Arena. You'd probably have to "cleanroom" it on a new GPL codebase, and that would require lots and lots and lots of time.
- OA doesn't have "same name" equivalents for models used by Generations so dependency on them would render the mod unplayable.
- id intellectual property is used anyway, so for a real "OA Generations" you'd have to redo it all in respect to the other free equivalents, like FreeDoom and OpenQuartz (worse, there's no Free equal for Wolf3D or Quake2 in existence). This would be huge effort for little benefit.
- On top of that, since Generations derives from Q3A content for most things like characters and the menu system, you can't legally play that in OA
- As mentioned already, selling Generations is legally impossible. Suggesting unauthorized commercial exploitation is a nasty idea.

It's kind of a shame anyway since OA has some excellent remakes of Quake DM3 and DM5 based on the released open-sourced GPL map files. Playing them in Generations is one of the reasons why i'm taking them out of the baseoa paks into their own tribute pak as a GPL-licensed addon for both OA and Q3A. :)

Wirehead Studios

Wirehead Modifications => Generations Arena => Topic started by: Darksoul71 on 2011-12-05, 12:44