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. 

It's been a while but IIRC getting rid of the cache system for sound is a little more work than for MDLs. Probably the least intrusive way is to just replace it with a malloc, but if you want runtime game changing that's not going to play nice. Look at Quake II's sound loading code as well; it's instructive to try port that to stock WinQuake as it has better implementations of a lot of this stuff, but yet is not too wildly different. That should then set you up nicely for implementing similar in your own engine. 

It's been a while but IIRC getting rid of the cache system for sound is a little more work than for MDLs. Probably the least intrusive way is to just replace it with a malloc, but if you want runtime game changing that's not going to play nice. Look at Quake II's sound loading code as well; it's instructive to try port that to stock WinQuake as it has better implementations of a lot of this stuff, but yet is not too wildly different. That should then set you up nicely for implementing similar in your own engine. 

It's been a while but IIRC getting rid of the cache system for sound is a little more work than for MDLs. Probably the least intrusive way is to just replace it with a malloc, but if you want runtime game changing that's not going to play nice. Look at Quake II's sound loading code as well; it's instructive to try port that to stock WinQuake as it has better implementations of a lot of this stuff, but yet is not too wildly different. That should then set you up nicely for implementing similar in your own engine. 

Download: QuakeDroid GL - skybox/fog/etc

1) Gamma slider now available (gunter)
2) Tap during demo brings up menu (mh, qmaster)
3) Possibly exit hang fixed (qmaster)

In the future, I'm going to rewrite the cache system to work around gunter post #242.

The gamma system is texture gamma, so if after releasing the slider it takes a moment for it to apply the gamma -- that is expected. It waits 0.35 seconds after you stop adjusting to apply it.

In the future, may put "Applying gamma ..." in the middle of the screen when it is doing that. 

Hm, in the Preferences you can change the aim assist to "Off" or "Quake Default." How about "Always On," meaning that Quake's traditional keyboard vertical aim assist would function regardless of if the server has disabled it....

Servers disable it because mouse aimers hate it. It actually makes it harder to aim accurately. But keyboarders could still really use it...

And yeah, I know, having it be client-side like that starts to sound like an aim bot, but I re-iterate I'm only talking about Quake's standard sv_aim feature for keyboarders, which, for the most part, just messes you up in deathmatch, but can really help keyboarders in online coop (I have been testing Quakedroid with keyboard only; aiming up and down is difficult!). 

I don't think it's going to be easy to move sv_aim to client-side - have you actually looked at how it's used, so that you can understand what you're asking for?

The sv_aim cvar is actually only used by QC; to be more specific, the QC "aim" function, which calls into the C code. There is no other entrypoint for use of sv_aim.

Rather than making it client-side, a more useful approach might be to have each player use their own version of sv_aim, so that rather than one sv_aim cvar there are 16 of them. That might work. 

Then I suppose it would have be basically a client-side aimbot that only mimicked sv_aim behavior... which is probably beyond the scope of what Baker would want to do for QuakeDroid....

Of course, touch-aiming allows easy vertical aiming, but currently touch-aiming is disabled when the keyboard is being used. 

Who the hell plays with only a keyboard? Quake is the grandfather or mouse look games. I'd like Baker to spend his time on meaningful code. 

I should add, I am aware we're talking about QuakeDroid. But the number of ppl who will play this I general is small. The subset of ppl who will play with a controller is smaller. The number of ppl who will play with keyboard only has to be nearly non-existent. 

ignoring keyboards, autoaim is still fairly important for gamepads too.
at its most basic, all it'd need to do is to reduce non-mouse sensitivity while the crosshair is over entities flagged with U_NOLERP (aka: U_STEP), or something (the other option is to network an additional takedamage==AIM flag).

Regarding keyboard users, the view already auto-pitches according to whatever slope the player is standing on (assuming mlook is off). Pitching it towards enemies too might not be too unreasonable as sv_aim basically does exactly this already.
Note that this could actually be done fully serverside inside SV_SetIdealPitch. Keyboard users would then auto-pitch while mouse users wouldn't even notice, both would be catered to without adding any new settings - but what kind of weirdo still favours keyboard-only?!?

The other option is to add some extra userinfo setting(like name/colours) to control sv_aim on a per-client basis, but personally I'd rather the actual viewangles changed instead of just the weapons. 

For reference, in QuakeWorld if the server had autoaim set, you could opt out of that by setting "noaim 1" in your client. 

Yeah, so thanks for fixing that. 

Tried it on a Pixel 2 just now. No joy so far...

On launching I get this message: http://www.eclecticmenagerie.com/jl/temp/msg1.png

Which then leads to: http://www.eclecticmenagerie.com/jl/temp/msg1.png

I tried rebooting the phone, didn't help.

Then I tried manually creating and populating the Quake directory.

Made the directory here: http://www.eclecticmenagerie.com/jl/temp/storage.png

Put pak files in it like so: http://www.eclecticmenagerie.com/jl/temp/quakedir.png

Same result when trying to run the app.

Was just curious, so I'm not raging at the sky here, but if there's anything you want me to do to help debug this let me know. 

Ah duh, it needs an id1 subfolder. For some reason I thought I saw that this app was doing that differently. 

@brassbite: Awesome, thanks for the confirmation!

@johnny: Did you get it to work? I'm thinking you did. I'm not sure why it would work differently on that phone vs. all the other phones the various others have tried, but yeah, I care of course! 

Yup works now. Didn't auto-download pak0.pak, but worked when I put the paks in. 

Yeah ... mh and Spike's comments.

I don't want to add "bot-like" behavior and cannot control what a server uses for settings or QuakeC. 

Ok, here is a demo that shows the weird centerview behavior near the end. I don't know how long the whole demo is, but it starts out in e4m7, when I reconnected with the software version because the hardware version had just crashed with that cache error. Centerview kept working fine, until we got to e1m3 at about 18 minutes in, right as we were about to exit. But around 25 minutes into e1m3 there are some good examples of me testing it and saying when I was pressing the button, then I'd wait, and then my view would be centered like 15 seconds later without me touching anything. I'm not positive I was tapping the correct button a few times before that when it didn't seem to be working at all (small android keyboard) but the other guy on the server experienced the same issue at the same time I did.

http://fvfonline.com/centerview_demo.zip 

Oh yeah, additionally, I find that gl_overbright 0 causes things like doors and ammo boxes to... uh... get extremely blurry to the point where it looks like they are textureless. 

Demo acquired.

saying when I was pressing the button

Excellent!

This one has my curiosity. I don't know how long it will take to develop some sort of plan, but an interesting bug and what should be enough evidence to trap it, is kind of like a 4D Rubik's cube. 

With pq_moveup 1 set, if you go in the water (I was in waist-deep) and tap jump, you just keep furiously bobbing even after you release jump. It only stops if you actually tap a +moveup key.


In android, r_bloom 1 causes a huge black square to appear and take up almost half my screen. Yeah, I know: experimental feature in development?


gl_flashblend 1 is causing many things to appear with a blue lightball instead of orange.... Watch the start demo and see the ogres and scrags glowing blue.


Tapping the power button on android (normally this would cause the screen to go to sleep) kills QuakeDroid and HARD NUKES all configs. It even erased my name, colors, and social security number. All default controls were set to ??? (nothing), and I had to delete the config.cfg file to even get those back.


I should start holding all my bug reports for ransom.... "Deliver OGG support to the dumpster outside of the Slipgate Complex, or you'll never see your precious bugs again!!" >:D 

:F

...

Uhhh, In the Mark V thread, Baker said:

Gunter, I just want to point out that it is impossible to play ogg on Android or an iPhone (without unacceptably chewing up metric shit tons of CPU -- hence the frames per second would be absolute trash --- because it is an obscure format and hence does not have hardware decoding in the processor)

Soooo, I just happened to be browsing the File Explorer on my Android device, and in the "Recent" section, imagine my surprise when I found (because I had been adjusting my alert sound): "hangouts_message.ogg"

I tap that and it opens right up in a Google Play Music popup right there on my screen....

So... yeah... it seems Android is FULLY CAPABLE OF PLAYING OGG FORMAT, and at least one Google app includes sound effects in OGG format....

...

Just Saying....


I guess it remains to be seen if it would actually affect the frame rate, but it seems that QuakeDroid does not yet include any music support anyway -- at least I can't get it to play the MP3s.

Though with Google having OGG support built in and used in some of its major apps on Android... I'd suspect it would not be a CPU-killing format on Android... otherwise... why did Google chose to use such an "obscure" format?