I'm glad compiling went easy. I try to make things easy to compile :) I did a reinstall clean compile, but hadn't tested fresh on a different machine.

I actually don't use Android Studio (it must be installed for the toolchain).

I go to the Android folder where there are several .bat files I made ...
1) (Done just once) make_symlink.bat (hooks up SDL2 folder)

2) gradle_assembleDebug.bat (compiles)
3) adb_install.bat (installs apk to phone)
4) (optional) adb_debug.bat (open a window with live log prints as it runs)

Because the Android compile process is rather slow ... I typically make sure Visual Studio will compile the Windows version of the engine (in 3 seconds Visual Studio will tell me if I am missing a semicolon, the Android process will take 2 minutes to tell me such a thing). I also have a "Fake Android" configuration in Visual Studio with the right preprocessor defines for Android so I can easily work with the code.

/And as time moves on, I want to see if I can speed up the Android compile. Sadly the gradle build system documentation for use with the Android NDK (native C/C++ dev kit) is basically non-existent. 

Well, I played for a little while on FvF and got the same crash as my old device:

Cache_MakeLRU: active link


Also, I feel like the "Invert Mouse" setting should also invert the look axis on the gamepad (right joystick).

Other than that, gamepad control feels really good. Perhaps the "Dead Zone" (the amount you can move the joystick before it counts as moving the joystick) for looking up and down should be a little larger as compared to the dead zone for looking left and right. Most of the time you don't want to look up and down but it's not too hard to accidentally let the joystick drift up or down a bit when you're looking left and right.

When hiding the onscreen controls (from keyboard use), there's no need to disable touchscreen aim. 

Check this out for a picture of my awesome Quake rig running QuakeDroid: http://www.fvfonline.com/forum/viewtopic.php?f=4&t=3810 

I've been focused on getting the OpenGL build up and running, so I haven't had the time yet to hit the everything on the todo list (especially a lot of qmaster items). But they'll happen ...

For the "active link" I either have to acquire the Quakespasm SDL sound mixing code that they acquired from ioQuake3 or read mh's cache system redesign tutorials and redesign the sound cache system.

For deadzone and company, the following cvars are available and they all save to config.

joy_deadzone
joy_deadzone_trigger
joy_sensitivity_yaw
joy_sensitivity_pitch
joy_invert
joy_exponent
joy_exponent_move
joy_swapmovelook
joy_enable

Since I use adapted ericw/Quakespasm controller support, I would prefer to leave the default values unchanged. 

And you know what?, it is working perfectly here.
Great thank you Baker, this is nothing short of awesome!

My smile starts to hurt already.

Thx again. 

Just a few things I noticed while messing around with it this morning:

In Options when Autoscale is set above "Auto Small" setting (medium and large) the white test descriptions do not match the currently selected item. So the Crosshair description reads: "Screenblend underwater, powerup..."

My screen resolution is defaulted to 2392x1440 BTW.

Another thing I noticed in Video Options changing Pixelation settings has no effects. It remains set to default GL smoothed regardless of what the selection reads.

While I was typing this I had QD looping through the demos so I could type the right settings for you. While on one of the demos the app gave error:

Chache_UnlinkLRU: Null link

When I touched okay the app crashed to home screen. 

should read: Cache_UnlinkLRU: Null link  

@mfx - Thanks!

@dumptruck - another fine catch! Shall be addressed. The LRU link active deal will be fixed either tomorrow (if time permits) or late Sunday.

The next release will have a QuakeDroid (GL version) and a QuakeDroid WinQuake and I'll have to reorg the QuakeDroid page some to reflect the new changes. 

"Button names LTHUMB, RTHUMB, LSHOULDER, RSHOULDER, ABUTTON, BBUTTON, XBUTTON, YBUTTON, LTRIGGER, RTRIGGER. The DPad acts as arrow keys (and also supports diagonal movement)"

I was playing a bit and wanted to configure my joystick buttons but I couldn't figure out the button names and had to come back and scan over this thread to see the key names to bind...

I suggest adding joy_ to the beginning of each of these key names, so that if I do something like "find joy" or "help joy" it would show me the key names.

And the directional pad on the joystick doesn't need to replicate keyboard arrow keys -- they could be their own separate thing, like joy_left, joy_right, etc. 

Those are the names that Quakespasm uses for the buttons.

If I were to change the names then I would be throwing a wrench into consistency ... 

(This doesn't mean that something couldn't be done to make discovering the button names easier ... I concur about that ...

I'll think about how the names could be easier to discover.) 

I use 8bitdo Bluetooth controller. found your project before u added controller support and thought it was the only drawback. but now, this is now probably the nicest Quake port to android that I've seen. works well w/ controller. Props! 

Yeah - joy_abutton, joy_ltrigger, ... would probably have been better choices for key names.. it's one of those annoying things that's hard to change without breaking anyone's configs. I was expecting people to use the "customize controls" menu for binding controller buttons so didn't expect knowing the key names to be an issue.

And the directional pad on the joystick doesn't need to replicate keyboard arrow keys -- they could be their own separate thing, like joy_left, joy_right, etc.

Same goes for the "back" and "start" buttons (the two small buttons on the front of an Xbox controller), I hardcoded them to emit Tab and Escape keyboard keys. In hindsight it might have been better to introduce new key names in the engine. This still might break some configs but seems like it'd be an improvement. 

It probably wouldn't be much of an issue if it's not compatible with Quakespasm configs, especially since this is the Android port.... Though I would also hope the joystick code gets put into Mark V at some point as well.

But would it be possible (in Quakespasm too) to add in the better names like joy_abutton, etc, and still keep the old names for backward compatibility? So both joy_abutton and abutton would refer to the same button.

Though that might not work as well for the joystick buttons that were hard-coded to emulate keyboard buttons.... I guess in that case, people would just have to update their configs.

Or, you put in a console variable like "joy_keyboard_keys 1" that causes the previously hard-coded joystick buttons to act as a keyboard keypress (which would be Quakespasm's "default" setting), but then you could toggle it off with joy_keyboard_keys 0 to make those buttons work independently as joystick buttons, joy_start, etc. (this should be QuakeDroid's default, since it's not much of an issue at this point to carve a new path, since we're still in pretty early testing mode). 

Thanks for the feedback! I'm glad it is working well with your controller.

The goal is to do mobile in a more comprehensive and more versatile way than has been done before.

And I think it is off to a great start, including the number of different users providing feedback to help mold it into shape.

@gunter - I'll think about all of that more as this progresses. 

there's no reason that name->keycode->name needs to result in the same name. just add multiple key names and it'll favour the first found when it writes out the config, and the bind command will accept either.

regarding back->tab, if the new joy_back's keybind is still null then just lookup tab's keybind instead of printing a warning about it being null/unset.
I had a similar issue when I split left and right shift/ctrl/alt keys in FTE. This stuff is entirely feasable, its just messy enough that you'd do it ONLY for compat.
With all the various different default.cfg files around the place, it can be nice for those various keys to actually do something by default. So whether the compat is short-term or permanent is up to you... 

that doesn't sound so bad. DP has "X360_*" and FTE has "GP_*" prefixes for the Xinput key names, so if QuakeDroid and/or Quakespasm migrate their controller key names it would make sense to match one of those. 

Quake had all the cvars begin with "joy_" and all the buttons were "joy1", "joy2", "joy3" since 1996.

Plus the associated cvars in Quakespasm begin with "joy_".

/One thought 

joy1, joy2, joy3, etc., would most certainly be the better option for button names, since not every gamepad is going to have its buttons labelled a, b, x, y....

Plus you can then allow for an infinite number of buttons, like joy18, joy19, joy20... What? I might want to play Quake with my Vagina Hero controller!

https://web.archive.org/web/20110427183508/http://www.ripten.com:80/2008/07/03/vagina-hero-exclusive-first-look/ 

Sure, but joy1 ... joyNN conveys no information about what button it is.

Although there are a lot of controllers, since Xbox/PS/Nintendo use the same layout (and have for over a decade) including Android/iPhone controllers ... it has become a rather reliable norm like keyboard layouts.

And if the norm somehow changes (the future is always full of surprises), there is always Menu->Customize Controls.

A "joy_" prefix as an additional alternate name should suffice and permit easy discovery via auto-complete.

Nice that Spike reminded there isn't a 1:1 names to keys ratio. 

Well, not PS controllers -- they use the X, O, Triangle, Square buttons. But it does seem that most all bluetooth gamepads go with the A B X Y buttons.

Also, I believe R1, R2 are the standard names for right shoulder and right trigger, though I suppose they may be a bit less informative.

But yeah, alternate JoyNN (or joy_NN) names would be like the Windows control panel joystick test page, where the buttons are only numbered 1, 2, 3, etc., to allow for all the different types of joysticks that may not be labelled the same, and may have more buttons that other gamepads.


I note that using "Customize Controls" currently does not function correctly. When trying to set joystick functions there:

My A button is detected as ENTER (though functions correctly in game when bound with ABUTTON).

B button seems to act as ESCAPE.

Both joysticks are detected as arrow keys. But the right joystick still causes me to look around in the game (while the menu is open).


I am guessing this has to do with setting the gamepad stuff to act as menu navigation keys when the menu is open.


Another question: my tablet keyboard does not have F1, F2, etc., keys. It has multimedia keys (volume, play, brightness, etc). Actually, my bluetooth gamepad has some multimedia keys as well.... Is it possible for QuakeDroid to capture those keys and bind them? That may not be possible, since they hook right into OS functions.... though I know that, for example, the "back" softkey button in Android can be overridden by whatever app is running. 

For my first attempt on the QS joystick code, I only supported SDL2's Game Controller api, which on Windows, corresponds to only supporting Xinput. Xinput gives your program button/axis events labelled based on Xbox controllers. This makes the dev's life easy, and player's lives easy if they have Xinput-compatible joysticks.

Support for support for arbitrary joysticks that don't conform to Xinput is doable, this would be like the original Quake joystick code where the buttons produce joy1, joy2,... and you have to figure out what that different axes do yourself.

@Baker
I would be fine with the joy_ prefix for the buttons, as well as adding:
joy_dpadup, joy_dpaddown, joy_dpadleft, joy_dpadright,
joy_back, joy_start, joy_guide
to cover the remaining Xinput/SDL2 game controller buttons that I initially set up to emit keyboard keys. 

Weirdly, when I started up QuakeDroid tonight, some of my keys had been unbound. LSHOULDER, RSHOULDER, Tab, XBUTTON, YBUTTON (which I had left at the default assignments). And I think uparrow, downarrow were not how I left them (+attack, +jump). I have no idea what caused this. They all functioned correctly after I rebound them in the console. They are all keys that are either gamepad only, or duplicated on the gamepad though....

I've still been intermittently having the issue where lookspring and centerview stop functioning, but force_centerview does work when that occurs (no -/+mlook necessary).

I know these aren't very helpful reports....


Also, I remember with Mark V, I asked about the text size for the scr_showfps not being scaled up with the other text, and you said this was by design. On android that scr_showfps is TINY. Could there be some other variable to scale that up? 

Centerview ... bind "-mlook; force_centerview; +mlook". Will be 100% reliable, right?

QuakeDroid (and Mark V and Quakespasm) all unbind all your keys when it runs config.cfg. This is so things you don't want bound from default.cfg don't linger that you don't want, I don't know if that could somehow be a factor. That being said, I'll look around and see how they save and make sure that I didn't exclude the new keys.

I hear you on the fps thing. I guess I will need to address that. Never considered that the fps could go microsize. 

Yes, force_centerview always seems to work, even when centerview (and lookspring) stop working.

Adding those mlook settings in there seems to be unnecessary, and could potentially cause problems...?

Hm, next time lookspring stops working I will try messing with mlook alone and see if that makes any difference.