User panel stuff on forum
  24 posts on 1 page  1
Client Talk
2016-07-26, 01:40
News Writer
912 posts

Registered:
Jan 2006
Axel Gneiting, who works at idSoftware has ported Quake 1 to run on Vulkan.

What is Vulkan?

Vulkan is a low-overhead, cross-platform 3D graphics and compute API first announced at GDC 2015 by the Khronos Group. The Vulkan API was initially referred to as the "next generation OpenGL initiative" by Khronos, but use of those names were discontinued once the Vulkan name was announced. Vulkan is derived from and built upon components of AMD's Mantle API, which was donated by AMD to Khronos with the intent of giving Khronos a foundation on which to begin developing a low-level API that they could standardize across the industry, much like OpenGL.

Like OpenGL, Vulkan targets high-performance realtime 3D graphics applications such as videogames and interactive media across all platforms, and offers higher performance and lower CPU usage, much like Direct3D 12 and Mantle. In addition to its lower CPU usage, Vulkan is also able to better distribute work amongst multiple CPU cores.


This is the biggest performance issue with QW.... It doesn't work with multiple cores meaning your bottleneck is usually with your CPU and not with your GFX card (Especially if you have an AMD processor).

I am wondering if our modern QW clients like ezQuake would have benefit of having vulkan support with its lower cpu usage and multi cpu support?
2016-07-26, 03:46
Member
245 posts

Registered:
Jan 2006
https://github.com/Novum/vkQuake

Unfortunately i don't have vulkan installed...

Would be nice to see if it gives more fps
2016-07-26, 04:45
News Writer
912 posts

Registered:
Jan 2006
I have a modern (late 2015) gaming laptop and I can run any modern game with high graphics and high fps.... but QW... just sucks. The same when I ran an AMD Desktop... all modern games were great but QW sucked (even with a beefy GFX card).

Perhaps Vulkan is the answer. Would be great if all of a sudden everyone was able to pull much higher FPS.
2016-07-26, 08:15
Member
271 posts

Registered:
Feb 2006
http://triptohell.info/moodles/win32/ftevkqw.exe fte's vulkan renderer

frankly if you want high framerates you're better off with the d3d9 renderer.
there's two reasons for this:
one is that vulkan drivers seem to suck and don't optimise for fullscreen stuff (nvidia seems to do extra screen copies compared to gl) so expect half the framerate when running 1920*1080. hopefully this will be fixed at some point... or someone will tell me what the hell I'm doing wrong...
the other reason is that I took the portable approach and didn't use any of the gl3+ features in the glue between engine and renderer, which allows d3d9 to pull ahead. I don't know of any quake engine that does (my quick hack that I first learned vulkan with does, but its not otherwise interesting). note that you can set 'r_dynamic -1' to batch more aggressively, but its not the same, and will disable a couple of things.
note that these two reasons do not necessarily apply to games with more stuff to draw, where the extra copy becomes insignificant compared to the cpu draw overhead, or where they're already using texture arrays and instancing and stuff.
moo
2016-07-26, 09:11
Administrator
1265 posts

Registered:
Jan 2006
you better download AfterQuake to try that vulkan FTE client.
I also believe you need to update your gfx card driver.
never argue with an idiot. they'll bring you back to their level and then beat you with experience.
2016-07-26, 23:51
News Writer
912 posts

Registered:
Jan 2006
FTE supports everything!
2016-07-27, 07:37
Administrator
647 posts

Registered:
Nov 2008
AMD still having issues with Quake?

I have a mid tier computer, nothing special, but I run EZQ at 1920*1080*144hz and 1155 fps with no lag whatsoever. That's on a NVIDIA card though!
2016-07-27, 12:53
Administrator
384 posts

Registered:
Dec 2006
I'm not an expert on the technical aspect but ATI/AMD has been poor compared to Nvidia for quite some time in QW (OpenGL). For comparison when I switched from a GTX460 to a Radeon 7950 I had to drop maxfps from 1001 to 616. Dynamic lighting seems to hit ATI a lot harder but unfortunately I don't like r_dynamic 0 (seems to reduce powerup visibility e.g. it is much easier to see quad glow from dm3 window).

Would be interesting to see some benchmarks on different hardware for comparison.
2016-07-27, 13:04
Administrator
1265 posts

Registered:
Jan 2006
those with ATI cards are better served with a client which renders in d3d

FTE has a d3d binary
never argue with an idiot. they'll bring you back to their level and then beat you with experience.
2016-07-27, 21:10
Member
8 posts

Registered:
Apr 2015
Anyone know how to compile vulkan binaries for FTE?

Might be useful for those of us who use Mac OS X or Linux.
2016-07-27, 23:49
Member
271 posts

Registered:
Feb 2006
kelliegator wrote:
Anyone know how to compile vulkan binaries for FTE?

Might be useful for those of us who use Mac OS X or Linux.

Regarding linux, there's a couple of bugs with updating the swap chain when the window is resized (which results in some glitching), which isn't too bad considering that I wrote all that code from windows without even trying it in linux. Using windowed mode (-window on the commandline) should work fine, so long as you don't resize it.

Here's a pre-compiled binary http://triptohell.info/moodles/linux_amd64/fteqw_vk64 (from a debian jessie box, so it has silly glibc issues on earlier distros that I really need to work around, but its probably not a serious issue because getting the vulkan loader working on earlier distros is similarly problematic (albeit still possible with a load of hackage)).
Its a game so it doesn't do too much that's likely to break on other distros, so long as their libc is up to date and have jpeg+png+ogg libraries.
That said, ubuntu may need -noxim on the commandline. I don't provide the vulkan loader, so you'll need to depend on your distro/drivers/lunarg/source for that, fte will print out a friendly message if that's the case, with distinctly different wording from no gpu drivers. Also, don't forget chmod!

If you want to compile yourself, this should download, compile, and run:
svn checkout svn://svn.code.sf.net/p/fteqw/code/trunk fteqw-code && make -C fteqw-code/engine vk-rel -j4 && fteqw-code/engine/release/fteqw_vk -window -noxim -basedir ~/quake
And if it doesn't, then I'm sure you can figure it out - I really don't remember which dev packages you'll need so it'll be annoying but shouldn't be too hard with eg apt-cache search.

Regarding Max OS X, Vulkan binaries are totally irrelevant on a mac as Apple have declined to support it (*insert rant here*).
FTE-on-mac needs to use SDL2 and the gl renderer, eg: make gl-rel FTE_TARGET=SDL2
However, I'm told that there are some crashes due to negative joystick/controller device ids, these may be fixed now, or they may still be an issue - I don't have a mac, nor any joysticks/controllers.
moo
2016-07-28, 02:26
Member
1 post

Registered:
Jul 2016
I have made a package for Debian Jessie / SteamOS. Details are below. As mentioned, this is still in early testing.

https://www.reddit.com/r/SteamOS/comments/4uo8g8/early_testing_vkquake_quakspasm_with_vulkan_api/
2016-07-28, 15:47
Member
8 posts

Registered:
Apr 2015
Spike wrote:

Regarding Max OS X, Vulkan binaries are totally irrelevant on a mac as Apple have declined to support it (*insert rant here*).
FTE-on-mac needs to use SDL2 and the gl renderer, eg: make gl-rel FTE_TARGET=SDL2
However, I'm told that there are some crashes due to negative joystick/controller device ids, these may be fixed now, or they may still be an issue - I don't have a mac, nor any joysticks/controllers.

You're sure? 'cause I found this online and it seems legit, although I can't know for sure unless I try to compile a vulkan version for Mac:

https://moltengl.com/moltenvk/

Also,when I compile via make gl-rel FTE_TARGET=SDL2 and run the app I just get a black screen and a cursor. >w>
2016-07-30, 17:11
Member
245 posts

Registered:
Jan 2006
kelliegator wrote:

https://moltengl.com/moltenvk/

Also,when I compile via make gl-rel FTE_TARGET=SDL2 and run the app I just get a black screen and a cursor. >w>


What if you start with +vid_fullscreen 0?
2016-07-30, 20:18
Member
8 posts

Registered:
Apr 2015
raket wrote:

What if you start with +vid_fullscreen 0?

That seems to work so it's clearly a problem with running the game fullscreen that I'm having. Odd.

Also worth noting is that if I generate the config.h with "sh makeconfig.sh" I get a bunch of weird errors that I don't fully understand because I'm generally not a programming guy. Here's a file for the curious.

https://www.dropbox.com/s/20fqyk99f5qy9ng/fteqw9.txt?dl=0

Something about undeclared identifiers, it seems.

(And sorry if I'm derailing the thread here, just asking for help while also trying to figure out if it's possible to make vulkan binaries for Mac or not)

EDIT:
I also tried to compile it in vulkan but I do get a linker error and since I'm not really a programmer I don't know how to fix it. Anyone care to look at this and help me out?

https://www.dropbox.com/s/y8mtyd41gxlw9di/fteqw10.txt?dl=0
2016-07-31, 01:20
Member
271 posts

Registered:
Feb 2006
the config.h was some 'wouldn't it be nice if...' thing that has too many possible combinations to have any real confidence in it. it certainly doesn't get enough testing.
tbh its easier to just delete that config.h file you made and direclty modify bothdefs.h instead, then you know you're starting from a good base.

vulkan is not supported on the mac. the *only* way would could possibly get it working on the mac is via the moltenvk wrapper library, which apparently has its own framework for handling the windowing system things (referred to as WSI in the vulkan docs, for Windowing System Integration) (also, frameworks are almost universally bad for porting - even if you do use SDL you still need to add system-specific hacks just to get rid of mouse acceleration on osx, and that's just a library. real frameworks are much worse).
SDL does *NOT* support vulkan - some people have used some hacks to create a vulkan surface from an SDL-owned window, but all such hacks are fundamentally system-specific, with system-specific WSI extensions, which pretty much defeats the point of SDL. Plus FTE doesn't use any such assumption that it would be safe to completely stomp over SDL's window buffers, and even if it did it wouldn't have any mac support, because there is no standard WSI extension for mac, because apple do not support vulkan (nor have khronos defined any such extension in their sted).
basically what I'm trying to say is that 'make vk-dbg FTE_TARGET=SDL2' cannot work out of the box. Not on windows, not on linux, and especially not on the mac. If you want to put in the grunt-work to figure out how to use moltenvk's framework stuff instead of SDL then feel free, however I cannot, noone else has done so, and even if they did it would likely violate the GPL.
In theory all you'd need to do would be to add some 'rendererinfo_t vkrendererinfo' struct in some file, initialise it like the xlib or win32 versions of the code do, provide your own VKVID_ or whatever functions (the other ones are generic and can just be reused as-is). The vk_win32.c file's VID_AttachVulkan shows fairly nicely exactly what you need to do to initialise FTE's vulkan renderer stuff, you just give it the WSI extension name and a callback for it to call to obtain a vulkan surface using that WSI. All that really remains is creating a window, changing screen resolutions, gamma ramps, passing mouse/keyboard/joystick/etc input over to in_generic.c and other system specific stuff like that. Easy, right?...
But yeah, its a shame about the whole GPL thing.
Anyway, that's the way I see it. Either way you won't get it working with vulkan on the mac without someone writing lots of code to do that, the current code has no way of doing it.
moo
2016-07-31, 12:33
Member
8 posts

Registered:
Apr 2015
Spike wrote:
the config.h was some 'wouldn't it be nice if...' thing that has too many possible combinations to have any real confidence in it. it certainly doesn't get enough testing.
tbh its easier to just delete that config.h file you made and direclty modify bothdefs.h instead, then you know you're starting from a good base.

Thanks. I'm a total newb at this though so how exactly do I modify bothdefs.h? Which parts do I edit?
2016-07-31, 12:48
Member
271 posts

Registered:
Feb 2006
there's a whole load of defines somewhere in that file. just comment out the defines that you want to disable.
the very first part tries to make sense of the system and makes guesses at the libraries that are available.
the next part contains the lists of #defines for the various build types (non-compat, minimal, and regular).
the bottom half attempts to enable/disable other things to try to keep the thing making sense (ie: quake2 gamecode without quake2 bsp is pointless).
moo
2016-07-31, 14:55
Member
8 posts

Registered:
Apr 2015
Spike wrote:
there's a whole load of defines somewhere in that file. just comment out the defines that you want to disable.
the very first part tries to make sense of the system and makes guesses at the libraries that are available.
the next part contains the lists of #defines for the various build types (non-compat, minimal, and regular).
the bottom half attempts to enable/disable other things to try to keep the thing making sense (ie: quake2 gamecode without quake2 bsp is pointless).

Thanks! That seems to take care of it.

I have no idea why I can't run FTE in fullscreen, though. I just get a black screen and a cursor. o_O
2016-08-01, 18:53
Member
245 posts

Registered:
Jan 2006
kelliegator wrote:
Spike wrote:
there's a whole load of defines somewhere in that file. just comment out the defines that you want to disable.
the very first part tries to make sense of the system and makes guesses at the libraries that are available.
the next part contains the lists of #defines for the various build types (non-compat, minimal, and regular).
the bottom half attempts to enable/disable other things to try to keep the thing making sense (ie: quake2 gamecode without quake2 bsp is pointless).

Thanks! That seems to take care of it.

I have no idea why I can't run FTE in fullscreen, though. I just get a black screen and a cursor. o_O


Does it work with ezquake?
2016-08-02, 10:38
Member
8 posts

Registered:
Apr 2015
raket wrote:
kelliegator wrote:
Spike wrote:
there's a whole load of defines somewhere in that file. just comment out the defines that you want to disable.
the very first part tries to make sense of the system and makes guesses at the libraries that are available.
the next part contains the lists of #defines for the various build types (non-compat, minimal, and regular).
the bottom half attempts to enable/disable other things to try to keep the thing making sense (ie: quake2 gamecode without quake2 bsp is pointless).

Thanks! That seems to take care of it.

I have no idea why I can't run FTE in fullscreen, though. I just get a black screen and a cursor. o_O


Does it work with ezquake?

Yes, I've been using ezquake for quite a while.

I've also tried to compile by typing "make gl-rel -j4" like the readme says, only to get "ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)"
2016-08-02, 13:58
Member
245 posts

Registered:
Jan 2006
kelliegator wrote:
raket wrote:
kelliegator wrote:
Spike wrote:
there's a whole load of defines somewhere in that file. just comment out the defines that you want to disable.
the very first part tries to make sense of the system and makes guesses at the libraries that are available.
the next part contains the lists of #defines for the various build types (non-compat, minimal, and regular).
the bottom half attempts to enable/disable other things to try to keep the thing making sense (ie: quake2 gamecode without quake2 bsp is pointless).

Thanks! That seems to take care of it.

I have no idea why I can't run FTE in fullscreen, though. I just get a black screen and a cursor. o_O


Does it work with ezquake?

Yes, I've been using ezquake for quite a while.

I've also tried to compile by typing "make gl-rel -j4" like the readme says, only to get "ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)"


So ezquake 3 works in fullscreen with sdl2?
2016-08-02, 14:17
Member
8 posts

Registered:
Apr 2015
raket wrote:
kelliegator wrote:
raket wrote:
kelliegator wrote:
Spike wrote:
there's a whole load of defines somewhere in that file. just comment out the defines that you want to disable.
the very first part tries to make sense of the system and makes guesses at the libraries that are available.
the next part contains the lists of #defines for the various build types (non-compat, minimal, and regular).
the bottom half attempts to enable/disable other things to try to keep the thing making sense (ie: quake2 gamecode without quake2 bsp is pointless).

Thanks! That seems to take care of it.

I have no idea why I can't run FTE in fullscreen, though. I just get a black screen and a cursor. o_O


Does it work with ezquake?

Yes, I've been using ezquake for quite a while.

I've also tried to compile by typing "make gl-rel -j4" like the readme says, only to get "ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)"


So ezquake 3 works in fullscreen with sdl2?

Yes.
2016-08-03, 15:41
Member
11 posts

Registered:
Jul 2014
Ftevkqw.exe works in Windows 10 x64, Amd 7970 3GB GHz edition, i7 4770k, display 144hz?
Only sounds i heard. And the message "no signal input" appears.
The latest driver version is installed.
  24 posts on 1 page  1