Thanks for the tip. The gamma part does indeed look really clean. I might give it a go in the future.

Out of curiosity: What do you use TCL for?

the tcl i used was for haudraud's weapon script (its some where here on the forum or blogs)

So, whats up? 3.1 coming ? LINK!

Luckily there's a version that doesn't require TCL Working on getting some builds up and running as soon as possible (hopefully new nightly builds later on).

Is it possible to build it on Mac OS X?

I've been using the 3.0 R666 build for quite a while now.

Commands to change refresh rate are broken for me. Whether I use the command line option (-freq) or attempt to change the variable in game, the refresh rate remains at the Windows default. So the only way to get the desired refresh rate when playing on a CRT is to lower the Windows resolution to match one's Quake resolution, which is not very pleasant at 800*600!

I really like the other features in 3.0 though, and appreciate that people are still improving the client, so I'll continue using it regardless.

Here's one of the later builds dimman gave me, it has displayfreq fixed, at leasth the cvar http://upload.foppa.dk/files/ezquake.exe

Of course! And it is even documented.. somehow..

https://github.com/ezQuake/ezquake-source/blob/master/COMPILING_ON_OSX.txt

Cool. Do anyone know how I setup the client to look in subdirs outside the ezQuake.app ? Have my QW dir the Windows way, and works fine with the official released Mac build

Don't think so. ezQuake follows the design pattern to have everything inside its app. But I think you should be able the skip the .app step and run ezquake executable from any directory where it looks for "id1", "qw" etc directories.. no?

If I take out the ezquake-darwin-x86_64 and run it from the Terminal, it works. I can't change resolution tho.

I used to hold down a button before running the app to get to some kind of launcher where it was possible to change resolution and cmdline

The launcher is long gone and so is most of the old OSX code to be honest. The current code and state of the client is miles ahead of the old one and actually usable Right now it uses Tunas code for mouse input so you shouldn't even get any mouse acceleration.

Anyway, to your resolution problem: The application is now started by default using desktop resolution and settings. You can set vid_width and vid_height manually to override (or use the menu), but do note that you must set vid_usedesktopres 0 for it to listen to your custom settings (I have removed the vid_height 0 or vid_width 0 behaviour and now its toggled with the mentioned cvar instead). vid_displayfrequency works too if you have multiple options.

Some other thing is that fov calculation has changed, find more info about it earlier in this thread.

Yep, changing vid_usedesktopres fixed all my issues. Really enjoying the improvements in this release. The improved QTV support is great.

Cool cool

Now some other questions:

1. When doing vid_restart the screen darkens a lot, but is fixed by for example changing gl_gamma to something new and back again. Are there a variable to fix that?

2. How to get another keyboard layout ?

3. Are there a simple scripting way to run the executable with a doubleclick on some file in Mac OS X ?

1) Hmm, seem like gamma is buggy on your platform. I am looking into solving gamma with OpenGL shaders instead but the current implementation I tested cost way too much performance for it to be acceptable. I'm investingating other solutions, proposals/patches accepted!

2) It currently doesn't work but it seems like more ppl are asking for it so I'll probably bring it back and make it work again.

3) Ask DyB|Tuna, I'm no OSX expert

OS X supports bash shell scripting.. so it would be similar to the Linux way. However you have to figure that out that one by yourself if you refuse to use the app bundle ;-p

Just want to point out two issues I've come across.

1. sys_disablewinkeys doesn't always work. I'm not sure what triggers the malfunction. It always works fine when the client has been freshly started, but after some amount of alt-tab'ing throughout the play session it breaks, and the windows key resumes alt-tabbing again despite setting sys_disablewinkeys to 1.

2. Sometimes, but not always, alt-tabbing causes the windows desktop to take on the resolution and refresh rate of the qw client. For example, I'll be in 1600 x 1200 in Windows, start qw in 800*600, and then alt-tab to find my desktop has switched to 800*600. The only solution is to change the desktop resolution every time you alt-tab. But again, this only happens sometimes, so I'm not sure what triggers it.

If you don't mind please create two Issues @ github for this: here. Thanks :-)

It's been a while and I wanted to try out the latest changes, but compilation failed because it couldn't find a package named jansson (see this commit). So, a new package installation needs to be added to my initial post:


Next I ran into this problem:


Looking up this function, it appears that it's only available since SDL 2.0.2, whereas my version (since I wrote the instructions) is 2.0.1. I'll have to update my dependencies and try again later.

[Edit] I cleaned up the first post a bit and updated all packages to the latest versions. Now ezquake 3 compiles again!

Have you made any changes to the build666 you once posted?

I personally cannot use any other version of ezQuake now that aspect ratio is properly fixed in that version and I am using 16:9....

I haven't ever made any changes since the 2 minor ones (support new player model, and weapon switching issue that was linked on previous page) over a year ago, but Dimman has. There is some new QTV functionality for one, and you can browse through the changes since last year to see more.

I can post a link to the latest build if Dimman is ok with it, but I do need to figure out why all of my builds end up being version 666 instead of a proper version number with a git commit hash. I see that version.sh sets the version number and revision number, but in my environment the part that gets run is:

I'll look into it at some point and make a new build with the proper version number.

I liked the build 666

@dimman: ezquake-3 finally works for me.

Seems that ion3 / notion window managers doesn't work with it. Tried it in windowmaker and it just worked as you said..

[edit]
@dimman: Is it possible to make ezquake-linux-i386 to change to a specific vidmode when alt-tabbing?, eg lets say x runs in 1280x1024 and ezquake is 640x480. It would be a nice feature..

and btw.. gamma doesn't work (xgamma -gamma 2) is ok though

The SDL2 version you're using produces an error with winapifamily.h.



This file fixes it: https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h



Also, this happens when you try to compile ezQuake:



I had to copy "windres.exe" to "mingw32-windres.exe" in C:\MinGW\bin to fix that.

Otherwise, following this guide 1-1 will get ezQuake to compile in Windows. Great stuff

Mistakes in my guide? I have been shamed

But seriously thanks for the corrections, I'm pretty sure I tried everything from scratch as described and didn't have issues but I guess not.

There is one thing that isn't perfect, it's that the build number always ends up being 666. Should be easy to fix, IIRC last I looked the number is set through some shell script that may have other dependencies (and defaults to 666 if it fails to generate a build number).

Build number works for me.



Maybe you haven't installed git on your machine?

Build number is set by these two lines in version.sh:



Also, writing "strip ezquake.exe" after compiling will remove useless debugging stuff, reducing the binary size by about 50%.

Alot of really interesting code talk going on here. I´m reading it carefully to find flaws and possible errors with my vast knowledge of .cfg editing. I have yet to find something that seems out of order.

Is the ezQ 3.0 client currently allowing for the new player.mdl, and if not, is it possible to add? It´s faithful, gives no noticable advantages, smooth and modern. I can´t see a reason why it shouldn´t support it.

Thanks for all the hard work you´re putting in guys!

It does support it and it should work just fine.

I have the same TCL-error from Haudraufs weapon script.
What´s the status on this issue? Feels sad that such a minor thing would prevent me from testing the new client.

Hehe, read the quote? Just grab the regular config-version instead of the tcl-script, it should behave the same just a bit more code.