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. 

Well, all kinds of problems today.

Upon first starting, it did not detect my bluetooth gamepad which I had just connected. I looked to see if I could manually set "joystick 1" but that is not a valid command.

Rebooting QuakeDroid fixed that issue.

I started experiencing the lookspring issue right away, and kept playing around to see if I could narrow down the circumstances when it works or not, but I just can't get it to work or not work reliably, and it seems kind of random. mlook seems to have nothing to do with it though. It does seem like stepping on various surfaces can get it to snap back on (stairs or teleporter pads), but not reliably.... Sometimes it just seems like bumping into a wall makes it kick on.

And then very coincidentally, while I was messing around with it, another player on the server mentioned that Mark V's centerview wasn't working correctly for him.... He said sometimes it works and sometimes it doesn't, and it seems to behave differently depending on where he's standing, like on stairs..... So it's not a QuakeDropid problem, it's a Mark V code problem. I just never used keyboard alone with Mark V, or I probably would have ran into it sooner. Anyway, I told him about force_centerview, and he said that worked for him.

Next, I was going to try and copy my console to clipboard so I could pate his report here, but the "copy" command crashed the heck out of QuakeDroid, possibly because my console was too long for it to handle (but it wasn't really that long though). Upon rebooting and trying "copy" right away, it seemed to work. But after connecting to the server and trying it again with not a lot of text, it crashed again.

And finally, this happened to me last night as well but I thought it was a fluke... I got disconnected from the server, and any attempt to reconnect just comes up with "could not resolve fvf.servequake.com host_error:connect failed." And that happens very quickly, like it's not even trying to connect. This persists even after closing and restarting QuakeDroid.

Hm, ok, after sitting here for a few minutes typing this message and trying again, it does connect. This may have to do with my old connection still being attached to the server or something, and it thinks I'm trying to spam connect.... Not sure. I don't think I have the server set to be super strict about connections. 

And oh yeah, I'm not running the fvf mod on QuakeDroid, and I always get:

couldn't load sound/fvf/nuke.wav
HTTP downloading: sound/fvf/nuke.wav
(bigfoot.servequake.com)
httpdownload failed (5):
"sound/fvf/nuke.wav"

(and other custom sounds I use) 

1) Copy command ... yeah, I need to disable that in QuakeDroid or make it work (not sure it can be done for Android). I already have disabled most impossible commands like "imagedump". I haven't messed with the clipboard on Android at all. But it sounds like it does work sometimes already (???).

2) Downloads for your fvf precache sounds ... options ...

Either contact Polarite (?) or whoever can add files on bigfoot.servequake.com and maybe ask them to add a sound folder in the same folder as maps, then make an FvF folder inside the sound folder and put your sounds there. Then they will download. OR do pq_download_http 0 or whatever the cvar name and it won't try and you'll just have missing sounds. If you contact whoever can upload files to bigfoot, you might try to get the FvF maps on there. Around the time quakeone.com had forum issues, the previous download depot (that had FvF maps and sounds and stuff) went away and bigfoot.servequake.com has replaced it as the depot. 

The code in the engine for force_centerview is simple ...

It is literally this ...

void Input_Force_CenterView_f (lparse_t *unnused) { cl.viewangles[PITCH] = 0; }

Now mouse input will override force_centerview, hence you need "-mlook; force_centerview; +mlook" to get the same effect (in any Quake engine).

Stair smoothing in engines that do that (most modern ones) will mess with force_centerview.

You can turn stair smoothing off in QuakeDroid/Mark V via "v_smoothstairs 0" and get the classic jerky stairs.

Anyway +1 for noticing that force_centerview + stair smoothing while on stairs don't mix in engines. Almost all engines are using stair smoothing, no one ever noticed that before.

/The engine has nothing to do with network like "Can't resolve xxx" or getting disconnected -- as far as I know. Then again, in many ways you are pioneering online play with Android, hehe. 

There definitely is a clipboard in android. I can copy the console when I first start up, and then paste it elsewhere in android. QuakeDroid just chokes to death if the console is very large. (Side note: I use an app called ClipSync for android, and its server program that runs in windows, which lets me copy/paste to/from android/windows across my network, basically sharing the clipboard contents between android/windows.)

I'm not sure stair smoothing has anything to do with the lookspring/centerview issue. I tried disabling it as you noted, but centerview was still not working (force_centerview always works). 

I wasn't aware that there was both "centerview" and "force_centerview" until just now.

I've never used "centerview" and didn't know it was a command.

We may have been talking about different things entirely.

When would someone want "centerview" over "force_centerview"? 

I don't know.... And I don't really know what the difference is, since they should both do the same thing? But centerview does work when lookspring is correctly functioning. But when lookspring stops working correctly (for unknown reasons), then centerview no longer works either, but force_centerview does.

Yeah, I never knew force_centerview was a command until you mentioned it several posts back (and apparently the keyboarding guy on my server didn't know about it either until I told him). I guess you may need to re-read my posts with that difference in mind, heh. When I mentioned "centerview" I specifically meant "centerview" and not "force_centerview." 

Ok, this is some info from a Quake wiki:


"centerview - realigns the view of the player to the center of the screen. Does not work with mouselook, instead force_centerview must be used."


Hm, I would assume that when mlook was active, lookspring would not function... so maybe mlook is getting set on somehow. Though I've tried +mlook and -mlook when I was having the lookspring problem, and it didn't seem to make any difference. 

This occurs when using QuakeDroid and the joystick together exclusively or does the lookspring issue happen in other combinations (QuakeDroid with joystick only, QuakeDroid without joystick)? (For you only, in your personal experience).

Also: I need to know ... does this occur ONLY when playing FVF connected to a server or also when playing vanilla singleplayer Quake offline (First only, second only, both)?

There are a number of places that touch that code an some of it can be triggered by QuakeC.

So in order for me replicate this or speculate it, I need to be able to pin it down (or hopefully experience it myself). 

Well, I've only been playing FvF online when I experience the issue, so I'm not sure if it would occur in other situations.

It has happened both when using the joysticks and when using the keyboard only.

I've just been playing for a hour or so and lookspring/centerview were working perfectly, heh, so I couldn't do any testing.... This is difficult for me to pin down, but I'll keep watching for it.

And like I mentioned, the other player on FvF (who I think uses Mark V on linux) mentioned the same problem, I think.

I do note that if I set +klook it behaves in the same way as the issue I am experiencing (no lookspring when moving with joystick, centerview doesn't work, but force_centerview still works), with the difference that my keyboard movement keys then look up and down, of course. Setting +mlook, on the other hand, does not replicate the behavior.

I'm sure I'm not normally setting +klook when I have the issue, but next time I experience it, I will try forcing -klook to see what happens. 

Record a demo while you are playing. When/if it happens, press TAB to see the level time and write it down.

Then upload the demo somewhere and tell me where in the demo. I might be able to develop a theory based on what is going on when it happens. 

Not sure a demo would reveal anything.... I hadn't been experiencing the issue the last few times I played, but then it struck again tonight, so I started playing around to see if I could narrow anything down.

Well, first I hypothesized that the joysticks could be detecting a tiny amount of drift from the center position -- not enough to trigger movement, but enough so that it thinks I am in the process looking up/down so it prevents centerview from working....

But then I turned off the bluetooth gamepad (while the game was still running) and used the keyboard only, and the issue didn't go away.

What I noticed is that tapping a "centerview" key does work, but with a delay. Generally between 10-30 second after I tap the key (while standing completely still) my view will be centered.

Just running around (which would normally trigger lookspring) does not work, even after a delay. But running around after tapping the key does work after a delay.

And I see a difference between centerview and force_centerview -- the former method "animates" the view so that the screen *moves* back into the centered position whereas force_centerview just snaps it to center instantly (which I don't like in terms of gameplay experience).


Then when I exited the level and started the next map, my lookspring and centerview were functioning correctly. Hm, again noting that my gamepad was disconnected at this point.

And I was playing on the FvF server when this all occurred.


Hmmm, testing my hypothesis above, I can kind of replicate the issue by barely holding my joystick off center, upward. It's not enough to move my view (that I can tell) but it does prevent centerview from working.....

But again, I'm pretty sure I've experienced the issue before when only using the keyboard (gamepad never having been connected -- I'll try playing this way more to be certain)....

Yet that "joystick drift" thing would also account for the "delay" in centerview working. A drifting joystick analog value would tend to, over time, drift around slightly between say 0 to 0.9. When it drifted back to 0, the (I guess buffered?) centerview command would then activate....

Hm, but no, when I replicate the issue by holding the joystick off-center, then tap the centerview key, it does not then center my view when I release the joystick (unless I tap centerview again)... so it seems that joystick drift can't be the same issue....

This is a tricky one.



Additionally, here's another error that's been crashing me:

Assertion failure at SDL_GL_SwapWindow_REAL (C:/Dropbox/quakedroid_source_go/Android/app/jni/SDL2/src/video/SDL_video.c3506), triggered 1 time: 'window && window->magic==&_this->window_magic'

At least I think that's the same error I've gotten a few times before -- I never screenshotted it previously, but it looks the same. I wasn't doing any window switching or anything when it happened. Though I do have apps running in the background, and one that displays network traffic in an overlay near the android softkeys. 

Download: QuakeDroid GL - skybox/fog/etc | QuakeDroid WinQuake

0) In addition to supporting native "Works with Android" controllers, also supports at a minimum the wireless Xbox One Controller S (white standard Xbox controller).

1) Big Sepulcher support (polarite/qmaster)
2) Brassbite Kindle issue resolved (brassbite)
3) Multiplayer save/load in menu (qmaster)
4) Texture mode works (mh, dumptruck_ds)
5) Forced disconnect console input (qmaster)
6) Cache_LRU issue solved (gunter, dumptruck_ds)
7) Optional "joy_" prefix for controller keys (gunter)
8) Uses more conventional landscape (dumptruck_ds, amongst others)
9) Bluetooth keyboard connect/disconnect no longer restarts QuakeDroid
10) More optimized builds = faster.
11) Many quality control enhancements for OpenGL build.

Thanks to everyone who provided feedback to help get QuakeDroid more refined!

QuakeDroid will continue to evolve ...