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. 

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.