Hrm. Trying the latest version on my new Android 6 tablet, the screen does not auto-rotate (flip). That's a problem because my keyboard case connects to one side of the tablet, which means UP is a certain direction, but QuakeDroid does not agree that this direction should be the UP!

But my bluetooth gamepads work flawlessly with no problem. I use an iPega 9023 v2 (suitable for tablets 7" and larger) and an iPega 9055 (suitable for smaller phone-size devices). These controllers actually hold the device, basically converting your phone or tablet into a portable game console. 

Is it upside down from what you need?

I could add a setting possibly in video options to flip it.

dumptruck also said for his phone it was "upside down".

/Awesome your gamepad works flawlessly. 

All the phones I tested QuakeDroid on are "flipped" like this. They are all Motorola phones from the past few years.

Moto X Pure (aka Style)
Moto Mini
Moto X (1st Gen)
Motorola RAZR 

That second one should read Droid Mini - but it's still a Motorola. 

Download: GL QuakeDroid Alternate Landscape

I'll end up making this a setting in video options later. 

I can't speak with certainty for whatever tools you are using to build this, but with Android development stuff, auto-rotate should be a simple switch somewhere, along with limiting it to either portrait or landscape modes. I mean, it's basically built-in functions in Android to detect which direction is UP and rotate the screen accordingly; you just have to set the game to allow it when developing. Of course, I have played games where it is locked to one position... so it may not be something that is easily set in all development tools. I just know that when I made my little android games ( www.tinyvast.com ), it was a very simple setting to allow auto-rotate in landscape modes only.

If that's not an option, then I guess a menu setting would suffice! 

I think I'll default the landscape to the "gunter/dumptruck" preferred kind. Looks like that should be normal. And then I'll put an option in video options to flip it. 

The alternate landscape build should solve you issues for now. Let me know. 

I guess it's cold out today! :) 

Btw, Baker I did get it to build in Android Studio with no issues - nice!

Double checked the joystick initialization code and SDL is just returning the accelerometer and no joysticks for my setup. I think my tablet may just lack the Xbox driver, as it's a running a customized android, so I probably can't help test at the moment. 

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.