User panel stuff on forum
  17 posts on 1 page  1
Client Talk
2011-01-03, 18:36
Member
3 posts

Registered:
Jan 2011
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:
git clone git://brechpunkt.de/qw.git

You need to check out the brechpunkt branch:
git checkout -b brechpunkt origin/brechpunkt

Required libraries (with the corresponding dev packages installed):
- glew
- alure
- OpenAL
- glew
- libPNG
- libJPG
- zlib
- OpenGL
- libXi

compile by typing
make

Afterwards, copy/symlink the qw binary into your quake folder and copy/symlink the shader directory into the ezquake subfolder in your quake folder.
2011-01-03, 19:23
Member
347 posts

Registered:
Feb 2006
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.
2011-01-03, 20:22
Administrator
887 posts

Registered:
Jan 2006
I already love this guy!
Join us on discord.quake.world
2011-01-03, 20:27
Member
171 posts

Registered:
Jan 2006
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.
2011-01-03, 20:52
Member
405 posts

Registered:
Jan 2006
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.
<3
2011-01-03, 21:19
Member
3 posts

Registered:
Jan 2011
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.
2011-01-03, 21:33
Member
1435 posts

Registered:
Jan 2006
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 )
2011-01-03, 21:59
Member
27 posts

Registered:
Oct 2010
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.
2011-01-03, 21:59
Member
405 posts

Registered:
Jan 2006
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.
<3
2011-01-10, 17:08
Member
132 posts

Registered:
Mar 2006
Quote:
[ aas@HAL9001 ~/projects/ezquakelinux (git::brechpunkt) ]$ git log --author="Christoph Schied" | grep -c remove
68

Impressive!
Mine do no spaek engrish!
2011-01-10, 20:52
Member
364 posts

Registered:
Oct 2006
Sounds fantastic, keep it going
2011-01-11, 17:12
Member
1102 posts

Registered:
Jan 2006
Awesome!

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


Getting

Quote:
[LD] qw
/usr/bin/ld: cannot find -ltcl

I do have /usr/lib/libtcl8.5.so
2011-01-11, 17:59
Member
3 posts

Registered:
Jan 2011
remove the -DWITH_TCL line in the Makefile and -ltcl from the LIBS variable
2011-01-12, 22:49
Member
27 posts

Registered:
Oct 2010
Spirit wrote:
Getting

Quote:
[LD] qw
/usr/bin/ld: cannot find -ltcl

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

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...
2011-07-24, 00:37
Member
1011 posts

Registered:
Feb 2006
Did anything ever happen with merging these changes back into ezQuake?
2011-07-24, 10:11
Member
1435 posts

Registered:
Jan 2006
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.
2012-12-03, 16:01
Administrator
1025 posts

Registered:
Apr 2006
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.
  17 posts on 1 page  1