This has the potential to be actual gaming news, anything else than a public repository would be an embarrassment if it hits the headlines.

Well, you see my source code isn't refined or cleaned up. I expended all my time and energy getting the features to work and writing documentation to make it mapper friendly.

I agree with your sentiment about this being "Actual Gaming News" level -- thanks!

I was going for that level of quality. 

Plays flawlessly on my Motorola XT1575 Moto X Style (a.k.a. Moto X Plus in US).


2 issues: it "flips" to the opposite orientation when entering into landscape mode so I need to turn my phone "upside down" compared to other apps.

also upon Quit > Yes the app does not close on my phone either 

I can't believe there's a chance that in the near future, I could be playing Quake 1 and all its awesome custom maps on my iPod Touch!

Frankly, that would be an amazing jaw dropping experience!

Baker, you're the guy that is making this possible? You're a real life hero! 

"Quitting doesn't actually shut down the app - it resets the game and minimizes the window."

That sounds like standard Android behavior. When you "quit" an app, it still appears in the "recent apps" list, and that app will run again if you tap it in that list. Apps in that list are sometimes "paused" in the background, but other times they are only there because you recently ran them.

If you truly want to SERIOUSLY QUIT an app, you can swipe it out of the "recent apps" list, and then you won't see it any more. 

@dumptruck - "flips to wrong landscape". Well at least it is rendering correctly. I'll have to meditate on that one. I thought that should not happen with the configuration I used.

+extra example of device where "Quit" doesn't close the app.

@barnak - The iPhone version is buildable in the source code, but only tested on one device (hasn't been tested on Retina, nor an iPhone X, nor IOS 10 let alone IOS 11) but the main issue is mapper friendliness -- loading maps and such isn't easy at all like an Android USB connection -- it is very hard and awkward. I'll think about over the coming weeks and we will go from there. 

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?