The SDL2 library controller support is for the gamepads that were designed to support Android out-of-the-box.

I guess it is natural that some users with existing PS4/XBox/Steam Controllers are going to try to use those with their phone/tablet, but those aren't the "Works With Android" controllers that the SDL2 library supports.

They may work or not, may require Google Play button remapping apps or what not. The mileage on that is going to vary.

The best I can probably do with that if someone like yourself gets it to work with, say, a PS4 controller, is to make note of your post and perhaps eventually throw a link on QuakeDroid page. 

Obviously, I do hope you get it to work. 

And if you do, I'll accomodate the info on a "using PC/console info" page or similar on the QuakeDroid page. 

“B” mode works with Android devices running Android OS 3.1 (Honeycomb) or higher.

According to this link, you may need to switch your MOGO to "B" mode.

https://support.mogaanywhere.com/hc/en-us/articles/201290560-Which-Android-devices-does-the-MOGA-HERO-POWER-work-with- 

2 things. I was really only attempting it because I read that you can use PS4 controllers on Android and thought "what the heck." But as with everything it's a rabbit hole, time-suck thing to get working.

Even Sony's Android specific streaming solution is limited to specific phones OR you need to root the phone (and *then* you sign into your PSN account --- fuck that noise.)

The other reason I'm trying this is to just add to the knowledge base here on the thread. So, please don't research too much on my account!! I asked earlier as I was hoping against hope there was somethin I was missing.

After work I'll hit Fry's and see what they have for Android controllers. I had a Steel Series for iPad and I do think their products are excellent overall.

Thx! 

Confirming that everything starts up clean now.

An interesting observation is that the texture filtering options don't work either. My guess is that there's a bug with glTexParameter calls on this device, and that your code is otherwise fine. 

When I was trying to get it to run, if I recall correctly OpenGLES 1.1 doesn't support the texture filtering options docs.

In head, I was planning OpenGLES 1.1 first and then convert to OpenGLES 2.0 using RMQ engine GLSL as a guide.

But getting OpenGLES 1.1 to work was more time consuming than anticipated. Also I was met with challenges like non-supported draws like GL_POLYGON (easy --> GL_TRIANGLE_FAN) but more complex ones (GL_QUAD_STRIP) slowed me down a bit.

Plus limitations like the typical mobile NPOT extension GL_APPLE_texture_2D_limited_npot (despite the name Android uses this commonly) can't be used with clamp to edge textures (if I recall).

So more can definitely be done on the rendering side of things over time. 

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.