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 ... 

 

More from the "Gunter tries weird things that nobody would ever do" department: If I run the Win version then go to Preferences and try to alter the Autoscale value which says "GL ONLY" (it doesn't change, obviously), then I close it and run the GL version, Autoscale will be set to "Forced Off" (so all the text will be tiny).

I see that Win has a Gamma adjustment in addition to Contrast, but the GL only has a Contrast adjustment.... I don't like using Contrast because, even though it makes the world look nice and bright and vivid, it washes out fullbright textures and they lose their subtle colors (like the blue streaks in lightning bolts totally disappear, and torches look bad). I know this is an issue I've reported for Mark V in the past (with screenshots). Is there no other way to adjust brightness in the GL version?


I know control tweaking will be worked on later, but ANY input from a physical keyboard should disable the onscreen control overlay, not just toggling the console with the `/~ key on the keyboard. Like when I use the keyboard to go through the menus and start a new game, I get the touch overlays. Additionally, I have bound ALT to toggleconsole, and using that does not remove the overlays.
And any touching of the screen should restore the onscreen controls.... 

@qmaster - QuakeDroid GL updated has been updated and should resolve the bug you reported. Must be some sort of bug in the SDL2 library.

@gunter - I'll add a brightness slider bar. Was on my list initially. I agree, I just kind of ran out of steam trying to package so much in a single update.

Should have the brightness slider bar added later today. 

I'm glad the FPS text (etc.) can be scaled now, but since it it essentially part of the HUD, it should be linked to scr_sbarscale rather than scr_conscale (i.e., it should be the same size as the clock digits in the status bar). 

It's on the same row as messages like "You got the silver key!"

(LEFT Console print) (scr_showfps counter)

I think it would look strange if print on the same row were of different size. The status bar is far, far from either of the above.

But yeah, possibility of microtext gone! Yay!

/Anyway, those were my thoughts. 

Looks more like its 2.5 lines down from where messages appear:

(Also activated scr_showpos for the screenshot)
https://imgur.com/kCl8x3n

Which is a good place for it to be... But I still say it should be the size of the clock in the status bar rather than matching the size of the message text (it's too large).

Would making it smaller look more strange than this already does? I think it would end up looking less jumbled because you would automatically mentally differentiate the text of a different size as not being part of the game messages. 

You are asking me to fine-tune based on the appearance a very specific resolution and console size.

The reality is that scr_showpos is going to occasionally bump heads with something when the font is large and the screen real estate is small.

On the plus side, scr_showpos is nice to have available (do you play with it on? It's just developer tool. Is there a reason to with it on? I'm curious.) 

Also, I'm curious why you don't use the centered deathmatch statusbar feature? Yeah, I know your screenshot is original, original Quake status bar and I get having a preference for that.

/Regretable 2x post instead of including that above :( 

Actually this is not the case of a very specific resolution and console size -- it's the built-in "Autoscale Medium" option, which will probably appear identical in every resolution(?). At least it looks virtually identical on my XP Netbook as it does in the Android screenshot (see first image):

https://imgur.com/a/yB6j1YT

The first image also demonstrates why I use the Quake Default status bar position -- it allows player names to be displayed to the right of the status bar. Having the status bar in the center (single-player style) does not allow this (which is, of course, unnecessary in single-player), so you lose some information when playing online.
Honestly, this is one of those little niggles I have where you changed a Quake Default which causes a slight determent to functionality (the conveyance of some information). I even mentioned this on the old Mark V page, in #1110, hah: "Why did the HUD move to the center (single-player style) instead of moving to the left edge (deathmatch/proquake style) like it used to, so you can also display some player names in the extra space...."

At least in this case there is a clear menu option to return to the Quake Default value (so I haven't chosen to complain loudly about this "feature" ;). But I do feel the Quake Default should be the Default for Mark V as well -- the engine should start users out at the defaults, and allow them to tweak from that starting point, according to their taste. You've changed the default based on your own tastes....

Though on my Android device, the screen space doesn't automatically allow room for the player names at the "Auto Medium" setting, so I will have to tweak the scale manually to make room (the names don't appear if there isn't room based on resolution, so they weren't in my Android screenshot).


Back to the FPS text. As the 2nd screenshot shows, it used to be teeny-tiny, which was acceptable on a laptop screen. But you can see it's not an issue having text on the same rows of different size. However, both "too small" and "too large" are not good. Currently it's "too large." I accept that it will sometimes bump heads with other screen text, but that problem can be mitigated by making the text a bit smaller in this case.

I originally thought just linking the FPS (and POS) text scale to the status bar scale would be better (the clock text is a reasonable size -- and I wanted to be able to scale FPS separately from the other screen text), but you mentioning that the showpos text was "developer info" gives me another thought...

You should have a separate scr_ something scale variable for the FPS, POS, and Texture Pointer text (Texture Pointer text also suffers from being teeny tiny in Android). I'm not sure if there are any other onscreen texts that fit into this "information" category. But this would allow us to set a reasonable size for all this on-screen info text, no matter what resolution, without messing with the scale of other game elements. This would be ideal, I think. scr_infoscale? scr_infotextscale?


And yeah, I do normally run (when I play in Mark V) with scr_showpos ON (along with showfps). Why? I like having access to lots of information (like those deathmatch player names). Always being able to see the FPS helps me determine what things greatly affect my FPS, which allows me to tweak my settings to strike a balance between "looking nice" and "performance." "Performance" may not be an issue for people with powerful computers, but I'm still using my XP Netbook (and now Android) so it's important to be able to squeeze out better performance. For example, seeing my FPS lets me see how badly Mirrors harm my FPS! (by the way, Mirrors should be Defaulted OFF, as in standard GL Quake, since it's an optional visual enhancement that greatly affects performance ;) and there's not even an easy menu option to return to Default in this case...).

As to why I keep scr_showpos activated, that's another case of "Gunter doing unusual things in FvF that most people would never think of...." In FvF, you get more bonus points at the end of a level if you have killed 100% of the monsters. So the players usually scour the levels to find every last one. I have an admin command that will locate all the remaining monsters and print their coordinates on screen (sometimes they get stuck in walls or we just can't find the last few monsters on a large map). Before Mark V had the showpos ability, I programmed in a way for players to check their own location coordinates when using the info [ key built into FvF. Knowing your location and the monster location helps you find your way to those last few hiding monsters. But now I just tell people to use "Quake GPS" with the scr_showpos feature, which is much better than having to press an info key repeatedly. So yeah, I know for a fact that me and other FvF players have used your scr_showfps feature as a part of our actual gameplay, to enhance our game :D 

... I meant, "I know for a fact that me and other FvF players have used your scr_showPOS feature as a part of our actual gameplay, to enhance our game"

Made it all the way to the end of that long post and typoed the final thought!

Now that's regrettable ;) 

4) Texture mode works (mh, dumptruck_ds)

Confirmed; everything looks nice and crunchy now.

With the menus up, the square "touch" regions overlap the menu graphics. This is normally not noticeable, but is very much so in e.g. the Options menu. This is a visual glitch rather than a functional issue, but if you're going for the extra layer of polish, IMO you should be fixing it.

When running a demo, touching the screen anywhere should bring up the menu. This removes one barrier to entry for new players, and is also consistent with stock Quake's "during demo playback, most keys bring up the main menu": https://github.com/id-Software/Quake/blob/master/WinQuake/keys.c#L685 

The any touch while start demos = console slipped through the cracks. I'll be addressing that hopefully today.

I hear you and agree about the options occasionally overlapping with the other UI controls.

I've been focusing a bit on function over form at the moment to try to thin my todo list way down. 

Using GL 1.98, still crashing with: Cache_MakeLRU: active link.

Though my player seems to disconnect right away when this happens, when before he would stick on the server as a disconnected player for a while.... 

Lest we forget, Quake's cache memory exists because it needed to run on a P60 with 8MB of RAM running an OS with no virtual memory.

That's why it got a caching system that kept stuff in memory between map changes (for faster reuse), but was able to evict stuff from memory at any point in time too (in case memory ran out), as well as on-demand load previously-evicted stuff (in case it was needed again).

That's also why as soon as ID moved away from those constraints they got rid of the caching system. 

@mh - Yeah, I have been looking around your cache system code within the last several minutes.

I suspect SDL2 on Android is hostile towards the Quake sound system or at least feature incomplete compared to SDL2 on Windows.