Hi,

I forked the ezQuake engine with the general intention to increase the Linux gaming experience because ezQuake doesn't play nicely along in a multimonitor setup, has sound issues, etc. I began by removing large amounts of code I do not need/like/want. Windows support and Software rendering, the particle stuff, etc fell into that category. I did this to make the project more manageable for me. I plan to contribute changes back to ezQuake when i feel the code works sufficiently well and the ezQuake team actually wants to have it

So far, I implemented the following:
- Fixing the gamma correction mess. ezQuake (and many other games) change gamma by altering the Xserver gamma curves. This is done by rendering everything by very simple shaders and applying the gamma curve in the shader. This is important if you wan't to play in window mode, or use multiple displays (in this case, you need to use the window mode and set the resolution accordingly). This change brings negligible costs in performance but allows for much larger flexibility. Two examples for what is possible now (the first one not being very useful...): pic1 pic2
- Proper mouse Input. The client uses exclusively XInput2 as input system. This allows for raw input, so no acceleration is applied to the input. ezQuake currently offers three different mouse input methods that all have different problems: The XLib input code is a horrible mess with hacks around bugs and strange timeout stuff; simply unusable. DGA input works, but DGA is deprecated for quite some time and therefore doesn't work on all systems. Evdev input opens /dev/input/eventX files. This is problematic though, as users normally don't have read permissions for those files. This is for a very good reason as users would be able to read other users input. To change the permissions you need to have root access which is not always the case. Furthermore you need to configure the deviceid which changes when you plug in additional mice, remove a keyboard, etc.
- Replacing the ezQuake sound engine by OpenAL. This reduces the code complexity, fixes the aliasing problems that exist in the current resampling code and thus increases the sound quality, reduces the sound latency and most important: PulseAudio support and ALSA support which doesn't exclusively access the sound device. Finally you can listen to some music while playing quake, yay!

Further goals:
- cleaning up the rendering code and make it use OpenGL in a more modern way. This should hopefully result in some performance improvements (VBOs for example)
- Figure out why ezQuake doesn't run with 21897391723fps on a Radeon 5770 and fix it. Drawing ~10000 triangles shouldn't be that hard
- Port the code to the Maemo/Meego platform
- Rewrite the particle system. The VX particle engine stuff is currently gone and needs to be replaced.
- more to come...

I don't consider the code to be ready, it is more like a prove of concept that works pretty well. I played quite some time using my XI2 and shader code and didn't have bigger issues. The OpenAL source still has a few minor issues which I'll fix eventually.

The code can be found here:
You need to check out the brechpunkt branch:
Required libraries (with the corresponding dev packages installed):
- glew
- alure
- OpenAL
- glew
- libPNG
- libJPG
- zlib
- OpenGL
- libXi

compile by typing
Afterwards, copy/symlink the qw binary into your quake folder and copy/symlink the shader directory into the ezquake subfolder in your quake folder.

You should come by #fodquake on QuakeNet (duh). Fodquake is a fork of fuhQuake with many of the same goals as you list. Many of them are also implemented already, non-sucky ALSA and PulseAudio support being some of the most recent (directly though, not through OpenAL). #fodquake and #fte are also nice places to hang out to keep you updated on qw-dev beside ezQuake and MVDSV/KTX. Bigfoot (fodquake), jogi (fodquake/camquake), Spike (FTEQW, QTV, FTEQCC), Taniwha (everything QuakeForge) and LordHavoc (DarkPlaces) hang out there.

I already love this guy!

Great news!

It took a while to figure out how to permanently set permissions on the evdev mouse (the only one that seems to support all my buttons).

The sound is also very shaky, I have to quit all programs using sound before starting ezQuake in order for it to work.

I don't really see point in that fork, since fork is most of the time is lastresort, and ezqauake is somehow active project, most likely you can get write access to it etc. I see only one reason - if you want to mess with the quake sources without bothering of breaking anything, well, supporting one OS is probably a reason too.

But all this one-man-projects end up as unmantained/abandoned in few years/moths. Not to mention it brings more problems in compatibilities between all this cliens/servers.

But wish you good luck, anyway.

Well, I don't think you would be happy if I deleted ~100k LOC from the ezquake repo, right? I don't have the intention to create a widely used standard quake client, I see it as a playground for my ideas.

It is generally a good thing™ to have multiple clients because that prevents single projects from repeatedly changing protocols, creating bugs which get the new standard, etc. Having only one client doesn't fit the opensource model and the qw community (at least i think and hope so) as well.
This fork won't create new incompatibilities as long as everybody obeys the protocols, and since it's derived from ezQuake, everything should be alright, no?

Forking isn't a big thing in the times of git, so I cannot agree on the statement "[...] since fork is most of the time is lastresort, […]"

You should not see this fork as an insult, it is just the way to work I prefer.

Well that depends on whether your perceive "open source" either as
a) many forks of single thing, or
b) many people working on single thing
Also the issues you describe (protocol changes, bugs as standards) belong more into the server department, in clients there's not too much space for that.

Anyway, great effort, keep it up! (And check your PM )

About the mouse input:
there was a client out there couple of years ago, which used svga-lib based mouse for the GL client. it was perfect, I could say.
The client called surmoclient. if you are interested and dont find it, maybe I can dig up some source code from one of my CD archives, just let me know.

Yeah, I feel from your first post that this project is playground for you and not treat it as insult.

About open source and freedom, well, I have my own opinion and experience about it.

Impressive!

Sounds fantastic, keep it going

Awesome!

Sound has never been an issue for me after I switched to OSSv4.


Getting


I do have /usr/lib/libtcl8.5.so

remove the -DWITH_TCL line in the Makefile and -ltcl from the LIBS variable

If I remember properly, you need to have lib???.so or lib???.so.0 symlink for the linker, but it was a long time ago when I played around such thing...

Did anything ever happen with merging these changes back into ezQuake?

Nope. We had some internal discussions but that's it. Anyway, all the changes are publicly available on that git, so anybody can review them and pick which are suitable for ezQuake code base and do the merging work. So it doesn't have to necessarily be xewie or somebody from ezQuake.

We need more devs! I've ported/rewritten some of the stuff xewie started on, but people with especially OpenGL skills is needed! So if you'r reading this and feel you want to help out, PM me.