#2022 posted by ericw on 2016/05/25 22:29:48
Latest windows dev build has the fix for ^ getting inserted in the console on German keyboard layouts:
http://quakespasm.ericwa.com/job/quakespasm-sdl2/
@ericW
#2023 posted by Icaro on 2016/05/25 23:10:23
could you please fix also the OSX version?
Icaro
#2024 posted by ericw on 2016/05/25 23:32:08
I haven't seen this bug on OS X.
IIRC, I tested the latest stable build, 0.91.0, SDL2 version. OSX 10.11. German keyboard layout.
What configuration is it happening with for you?
EricW ... You Are Right!
#2025 posted by Icaro on 2016/05/26 00:07:10
I�ve just added --> bind "^" "toggle console" in the config.cfg and it works .. sorry for that!
EricW
I'm adding some functionality to Quakespasm for qexpo, I have some questions regarding the engine. Is your email in the your profile here correct? Can I hit you up with some questions there?
Yep, Sure
#2027 posted by ericw on 2016/05/26 19:50:25
Mousewheel Weapon Switching Bug?
For some reason I can only switch forward, but not back -- i.e. rolling the mousewheel forward will e.g. switch from shotgun to super shotgun, but rolling it backwards does nothing.
Oddly, this does not happen when playing Arcane Dimensions. In AD, I can switch in both directions. In id1, though, I can only switch in one direction.
I'm on Linux, running QS 0.91.0.
#2029 posted by metlslime on 2016/05/27 01:50:58
This is a mod issue, some mods do not support the impulse that cycles backwards through the weapons. It's not actually an engine feature!
#2030 posted by dwere on 2016/05/27 02:12:54
This shouldn't happen with clean and up to date id1 though.
Err, how do I know if my id1 is up to date?
Thanks for the responses, by the way.
metlslime, I'm not sure if I understand your reply correctly, but I didn't mean that it was an issue I was encountering when playing with mods (unless one counts id1 as a mod). I just added the bit about AD because I thought it might be relevant that it does work under AD.
I was under the impression that cycling through weapons in both directions should be possible when playing in standard id1 (as dwere's response seems to imply as well).
But now I'm a little confused...
#2033 posted by ericw on 2016/05/27 04:07:59
total_newbie, I think either you don't have quake patched to 1.06, or the mousewheel down isn't bound in your id1/config.cfg.
Under id1, try "impulse 12" in the console, then close the console. If it doesn't switch to the previous weapon, then you must be missing the 1.06 patch.
The patch is here but it's DOS-only unfortunately:
https://www.quaddicted.com/files/idgames/idstuff/quake/q101-106.zip
Thanks for the response, ericw.
Turns out I am using an out-of-date set of pak files, but I can't get the linked patch to work.
Would it not suffice to download an up-to-date pak0.pak (i.e. the shareware pak) and replace mine with it? The readme from the patch you linked to suggests that it's just the pak0.pak that gets updated anyway:
Step 2: Run the file 'patch.exe' from your Quake directory, which will alter
your quakeid1pak0.pak file.
Or does it do something to the pak1.pak too?
That Last Sentence Wasn't Supposed To Be A Quote.
Yep
#2036 posted by ericw on 2016/05/27 04:55:26
try updating pak0.pak. Is there a zip on quaddicted? I guess this should be covered on:
https://www.quaddicted.com/quake/installation which currently doesn't say anything about patching.
(hmm, weird my pak0.pak - from Steam, I think - doesn't match the md5 sum listed there. the pak1.pak does though.)
Found it here via a google search: http://community.pcgamingwiki.com/files/file/411-quake-shareware-pak/
Haven't checked to see if Quaddicted has it too.
Anyway, that seems to have worked. :) Here's hoping I haven't inadvertently broken something.
Just checked and both my pak files have md5sums matching the ones on Quaddicted. So I seem to be up to date -- finally. :)
Thanks for all your help.
Optimization On Raspberry Pi
#2039 posted by SpecialBomb on 2016/06/02 04:58:10
The quakespasm engine does not seem to work nicely on the raspberry pi. It has slow framerates and broken geometry. Oddly, the more demanding darkplaces engine works smoothly. Any clue why this is happening?
#2040 posted by ericw on 2016/06/02 05:27:57
QS needs desktop OpenGL, whereas DP is able to use OpenGL ES.
It sounds like desktop OpenGL has been software emulated only until recently, see: https://www.raspberrypi.org/blog/another-new-raspbian-release/
Do you have a Pi2? Try enabling the experimental hw-accelereated OpenGL option.
Already Did That
#2041 posted by SpecialBomb on 2016/06/02 05:36:09
The experimental drivers do help with qs, but effects like dynamic lights slow it down, and some other factors I haven't pinpointed yet. Would it be hard to allow OpenGL ES with qs?
Ok, Interesting
#2042 posted by ericw on 2016/06/02 08:22:55
adding full GLES support is possible, but relatively a lot of work.
there may be some simple tweaks to the lightmap format that would fix slowdowns with dynamic lights.. but we need some developer with a RPi to do it.
#2043 posted by mh on 2016/06/02 12:23:16
Would it be hard to allow OpenGL ES with qs?
It would need a rewrite of much of the renderer because it still uses a lot of glBegin/glEnd calls which don't even exist in ES. BSPs and MDLs IIRC use vertex arrays/VBOs but they're the easy ones to port.
#2044 posted by Spirit on 2016/06/02 13:30:48
It would probably be worth it on the long run but sacrifice compatibility for some ancient hardware maybe?
#2045 posted by Izhido on 2016/06/02 15:58:34
The network drivers for vanilla have this class-like structure with function pointers that are filled with the proper functions for a specific net driver. I don't currently see a reason why we couldn't use such a mechanism to incorporate multiple rendering engines. (id Tech 2, the engine for Quake II, actually uses that).
Also, if you're interested, I had to implement ES on the iOS VR target of my port... might guve you some useful pointers :)
#2046 posted by Spike on 2016/06/02 19:35:26
GLES1 pretty much just requires using vertex arrays instead of glBegin. The rest is basically just omissions. It should be easy enough to update quakespasm to use this, but you'll probably want to handle batching properly to compensate for the batch-merging work desktop drivers do with small glbegin batches.
GLES2 requires glsl too, which is a little bit more messy, but also offers significant speedups.
GLES3 is a strict superset of GLES2, thankfully.
FTE's gl renderer dates back to when glsl was still new (and slower). as a result it still copes just fine with glsl on some times and not others (also, yay q3 shaders).
tbh the only significant difference is whether glsl is available or not. There's a few extra limitations from using GLES, but tbh those things should probably be avoided even on desktop GL, so its not a huge problem really.
Of course, this is assuming you're willing to have gl1.1 as a minimum requirement - this may mean you need to use a quake3 minidriver instead of an older one, so I don't personally see this as a serious issue, even for those old cards.
|