I have two Android apps for audio that actually do quit entirely if it prompts for an exit. So Yes most apps to behave this way it should be expected that an app terminates completely if you run thru a prompt. not sure if there is a performance impact or not but anything that potentially drains battery should be at least tested. 

{fence textures just show their ugly pink, no cutout. 

Can't save a coop game 

It will in a week or so, haha.

QuakeDroid can actually save co-op games, but the menu is wired like classic Quake to not save multiplayer games.

If you are desperate to save a co-op game, go to console and do "save mygame".

To load a co-op game, first have players connect and go to console and do "load mygame".

*Should* work.

I had to strike that from the initial release todo list due to lack of time.

I plan to make it user-friendly.

Alpha support in the software render is something I want but I have not been able to yet successfully implement (go figure).

I assume the server browser (MultiPlayer->Join Game->Local Games) is working ok for you?

/Nice catch on the underscore being needed in the on-screen keyboard. I went to great effort to try to make sure all the needed keys were there, but I clearly missed an important one! 

Transparent water has wierd lines:
http://www.quaketastic.com/files/screen_shots/Screenshot_20180331-162406.png

Um and screenshots are sideways lol 

I'll look into modifying the transparent water draw algorithm to reduce the likelihood of it looking like that.

It may just be bad luck of the draw with your device's screen resolution, but I'll check it out and see what I can do. 

Gunter pointed out something I think does need changed.

Right side order (NOW):
"Attack"
"Jump"
"Change weapon"

But in order of usuability should be (???)

Right side order (SHOULD BE):
"Change weapon" (the least used of the 3)
"Attack"
"Jump"

?? 

A Doom-like weapon wheel in top right? 

Looks at screenshot of feature. That gives me some different thoughts on some nicer solutions. 

Mt preference is for

Jump
Attack
Change (possibly both directions: < change > Or instead of two buttons, have an area that reads the direction of your swipe -- swipe left or right to change weapons in that direction)

I find it more natural to stretch my thumb upward to hit a jump button. Bending my thumb downward is slightly less easy, so better suited for the less-used buttons.


I notice that if I press a button (like Attack) and slide my thumb to a different button (Jump), it acts as though Attack is still held down and it doesn't trigger a Jump. Prefferd functionality would be:

When finger slides out of Attack button zone, stop attacking, and when finger enters Jump button zone, jump.

OR

Keep attacking even if finger slides out of Attack button zone, AND still Jump when finger enters Jump button zone.

Either of these behaviors would be preferable for the movement keys as well -- you could slide your finger back and forth across the move keys to alter your movement without having to puck your finger up off one button before you can press another.

Actually, with the layout of the move keys, only the first option would work -- the sidestep keys would need to be next to the Forward key instead of the Back key...

Probably a better option is to have a circle onscreen for a virtual joystick, and the movement is determined by your finger position within the circle. If you slide your finger to the top of the circle, you move forward. Bottom of the circle is move back. Left and right edges of the circle are sidestep. And you can move your finger to like the top right position of the circle to be moving forward + sidetep right at the same time, for example. This could just have virtual button triggers at certain points around the circle, or it could actually emulate an analog joystick allowing for movement at varying speeds. If you go outside the circle, then it would just continue your movement unless you lift your finger off the screen.

To enhance the "button" control method (without also having to touch the screen to aim, because you will be using the virtual Fire button), you could have the accelerometer control turning left and right, so you just tilt your device left and right (like holding a steering wheel) to turn left and right. The turning speed would be determined by how far you are tilting. 

Agree with Gunter, sliding finger from one touch zone to another should change button effect...EXCEPT FOR SHOOTING..which should let you continuously aim while shooting otherwise I need two fingers to do that.

Movement needs 4 zkmes added for combinations of wasd keys...wa, wd, as, and ad combos in a 9 square pattern. These could be invisible and only work on slide. 

Stupid phone...zlnes...argh i hat this...zones. 

Hey, that's a good idea: once you put your finger on the Fire button, any sliding you do with that finger should act as aiming, as long as you don't lift your finger (and you still keep shooting).


I've gotten a few crashes with Cache_MakeLRU: active link

I'm trying it out with a little bluetooth keyboard now, on fvf.servequake.com -- where everyone else should be trying it, since it's coop and you can sit around and chat if you want while everyone else kills the monsters ;) 

Probably a better option is to have a circle onscreen for a virtual joystick, and the movement is determined by your finger position within the circle.
I'm not one to stare a solid mobile version of Quake in the mouth (so to speak) but since Gunter has brought it up:

If there was this virtual thumb stick scheme I would play this on my phone often as opposed to just testing this out and playing occasionally. The current style of control is too difficult to get used to to play for long stretches.

I agree that this code should be brought into a repository as well for those who'd like to assist in development. 

Oh yeah, forgot was I was going to say about bluetooth controls: when you detect input from a bluetooth keyboard (or gamepad - do those work? I'll find out later), you should remove the onscreen control overlay, because it's not being used.... If someone touches the screen, then you draw it again until you detect bluetooth input.

... and you really need to disable the android Sleep mode, heh... While I wtas typing this, my table fell asleep, and Quake go bye bye. 

Is there any way to add original soundtrack? 

If I use 3 fingers on the left like I do on a keyboard, it's actully not bad. I still can't steer and shoot at the same time though. 

https://forums.libsdl.org/viewtopic.php?p=52442
https://stackoverflow.com/questions/6361966/exit-android-app-kill-all-processes

Android apps are not automatically unloaded even after the onDestroyed() callback, e.g. when they are in the destroyed lifecycle state. They will only be removed from memory if more recently started apps would require memory themselfes.

You cannot completely "exit" an Activity on Android (like on Windows or other OSes where exit() resp. return from main unloads the program from memory). Android will decide for itself whether and when to remove an Activity from memory.

Now I understand why I end up with an accumulation of several apps in the "Multitasking Screen" pic after I closed them.

The reason behind this design is the fast restart of applications (caching). 

@dudeq - Not yet, but it'll be coming.

@gunter - I have seen that happen on rare, I also know how to fix it.

As far as detecting a Bluetooth Keyboard, I don't know that SDL2 provides a method for that, but I think what would work just as well is that ...

1) opening the menu with the keyboard causes the in-game controls to hide

2) opening the menu by touch would unhide the game controls

After all is quite possible to not want to use the keyboard for playing, just entering console commands.

This scheme would satisfy all preferences and not require a setting, so it would be real convenient. 

What about using quaddicted? 

(UNSUPPORTED - BUILTIN QUADDICTED/QUAKE INJECTOR)

(Requires registered Quake and QuakeDroid doesn't check to see if registered vs. shareware)

In the console

1) type "install rapture"
2) type "game rapture"
3) Do Single Player->New Game

I have installed 6-7 mods with it -- things like (kinn_marcher, nihilore, rapture), but would prefer to test it more and think more about the structure on Android. Also johnny law provided me an example or 2 were unexpected file structure in a map jam confused the unpack a bit.

So "Should work, unsupported, use at own risk" because I want to exhaustively review it. 

Yeah that isn't a problem on iPhone, but you can't really mess with your own Quake folder on a iPhone, like put map from your hard drive on it. 

I guess the only solution for mappers for iphone would be to design with a controller in mind and release as normal. 

The controls leave something to be desired. As was said, it'd be nice if jump/attach were switched so attack is in a more naturally reachable position, maybe the ability to manually place the buttons.

Also the icons are a little faint, and the movement buttons are not very easy to use.

Any chance of a Quake-Touch type radius where on the left side is like a trackpad (like the aiming?)

As crappy as Q-touch is the controls are actually very natural and it's pretty easy to move around, whereas with this setup the individual buttons and binary movement make phone play much less enjoyable 

Here are my current thoughts on control options:

So you have possibly an onscreen graphic of a circle on both the left and right side of the screen. Left circle is movement, and right is aiming. Each circle would necessarily have a dead zone in the center, but as you move your finger around in the circle you would just measure the distance from the center and the direction of the line. These pretty much emulate analog joysticks. If you move your finger outside the circle it just reads as the maximum value which is the same as touching the edge of the circle, since you are noting the line from center to your finger position.

Ok, so left circle is move forward, back, left, right. Right circle behaves the same way for aim up, down, left, right. But if you double tap the right circle, you start firing and you keep firing as long as you don't lift your finger, and you can still aim using that circle while firing.


Just above the left movement circle there is a virtual Jump button, so that if you slide your finger up to it (outside the move circle) you keep moving forward and you jump.... These should probably also still be a virtual jump button above the right circle for tapping, because "jump while aiming up would not work well, but it could still be tappable if you aren't aiming.


Now you could get fancy, and not draw set cirle areas, but within a fairly large area on the left and right of the screen, you just detect the first place a touch occurs, and set that as the center of the circle (and then possibly draw it once a touch occurs). The movement controls would work the same as I described, just by measuring the distance and direction of the finger starting at that first touch point. When someone lifts their finger, you just forget the last touch start point and make a new one when they touch the screen again.

You may need a permanent jump tap button somewhere on the right to go with this scheme, but that button could also be dynamically relocated to just above the wherever the touch occurs and the circle is positioned when that happens.

The move circle could optionally respond to a double tap to toggle to walk mode, or to trigger a jump, or something else.


I also do think the weapons in the status bar do need to be touchable to select a gun (actually, to trigger impulse 1-9), abut if you swipe left or right along the weapon area, it will cycle weapons left or right. Touching the player face could activate messagemode.