I remember back in 2000 when i had a Diamond Monster 3D 4MB and had just discovered that Quake would run with it.. so there were mainly two methods to run GLQuake 0.98 exe's.. Direct3D (directx) and OpenGL.. obviously back at the day OpenGL was faster/better..

Today i find myself running a poor OpenGL based EzQuake even though I have a pretty good computer and a HD4850 512MB video card.. simply becouse newer cards are day-by-day getting far away from OpenGL and working on performance improvements on DirectX on and on.. Is it too insane to be able to run EzQuake better than I run any other game such as Quake 3 (wich is OpenGL based as well) ?

I don't really get why my FPS are more consistent at Urban Terror than QW.. simply i get around 700 FPS on timedemo there while QW's timedemo give em some crappy 150 fps.



Would EzQuake developers have to PAY to use DirectX, since its not OpenSource as OpenGL is ?

just to make sure no more time is wasted on this topic, it won't happen :p

Quake3 is arguably less advanced (in some ways) than EzQuake. Additionally I believe that the engine handles open areas much better than QW.
That said, there's something wrong if you're getting 150fps in QW timedemo on a HD4850, unless perhaps you are using a weak cpu and very high settings. I get over 1300fps in demo2.dem using my normal settings (assume you are using that - overkill.qwd clocks in around 800fps).

Have you run a benchmark comparing the old D3DQuake with GLQuake?

Have you installed recent vendor drivers for your GPU? If you simply have the default windows drivers installed.. guess what.. Microsoft gives a %§$ about openGL!

Edit: Hm well if Quake3 runs I guess he has..

I had problems with default nQuake config giving low fps compared to my own cfg, even without any noticeable difference between the way it looked.

Haven't had time to figure out why yet tho :/ - But try another config

my tests were with "FPS.qwd" demo, that one that runs on DM2 with lots of pineapples that DEF had on his "qw distro".


I`ve a Core2Duo E6750 20% overclocked, running at 3.2Ghz + 2GB DDR2 800 (5-5-5-15) ; running the latest drivers for my GPU (that being - Catalyst 9.10) on Windows 7 x64. But i used to get the exactly same result back on Windows XP SP3.

And no matter if I tune all settings on CCC to Performance or Quallity the result is the same. Also running in 800x600 or 1440x900 the average FPS are about the same..

As for temperatures.. I may say they are a bit high.. since my HD4850 is one of Sapphire`s first realease and still has a single slot cooler.. if I run Call of Duty 4 on High settings and play on some FFA server it easily gets to 95˚C .. but i find a bit odd that this would fuck up a timedemo desplay like that or often drop fps on cl_maxfps 300


Just tested a timedemo on demo2 and i`ve got some 200fps.. but the weirdest thing happen.. everytime i run it again like, over and over the FPS would drop a bit.. i managed to get to 73 fps and then just got bored of doing it.

The weirdest thing is that i previously had a GeFoce GT8600 xXx (that was about 1 year ago) and it would give me solid 770 FPS. When I switched to HD4850 I noticed the FPS drop and tried to do everything to keep using cl_maxfps 770 as before, but it was just impossible.. had to go all the way down to cl_maxfps 300 to get it solid.. and even so eventually i get some fps drop!

Other games were flawlessly faster on HD4850 than on old 8600GT, including Urban Terror wich is a Q3 (openGL based) mod.

The problem is not OpenGL per se. The problem is that Quakeworld graphics are made in a way that's simply not done anymore. Hence those paths are not optimized in newer drivers, which will result in poor performance. Dynamic lighting seems to be the biggest killer of FPS on ATI hardware as far as I can see. Try disabling it and see what kind of performance you get (r_dynamic 0). Have you tried DirectQ by any chance? I know it's Netquake, but I'd like to hear what kind of performance you get on it anyway.

The problem with disabling dynamic lighting is that you can't see the quad coming. OpenGL support is at its peak in version 6.12 of the ATI catalyst drivers if you want to consider rolling back.

By modern standards, Quake3 fails because it has to push the entire scene to the gpu, reusing only textures.
By modern standards, EzQuake fails because it has to push the entire scene to the gpu on a per-vertex basis, and if there are dynamic lights, it has to rebuild and push those too.

By modern standards, the BSP format in either engine is outdated at best, and its this that requires Quake3's batching or QuakeWorld's lack of batching (I realise that my logic seems flawed by saying that, but QuakeWorld cannot batch because the surfaces are not linear, they have hidden/obscured surfaces causing gaps. Generally they are large enough that batching is not so much of an issue, as the card will be busy drawing a single poly while the cpu is somewhat idle, while Quake3 needs to copy *everything* in order to close those gaps, resulting in higher cpu usage, but stalls the card less).

Quake3 at least has larger batches. Quake3 thus gets better fps.
(Plus, drivers tend to be better optimised for Quake3, considering that it was quake3 that was the more recent benchmarking engine, and its derivatives being almost the sole reason that ATI even support opengl).

Additionally, Quake3 tends to limit the maximum number of dynamic lights to a much lower value. It also doesn't ever modify lightmaps. r_dynamic is essentually always 0. Unlike Quake, which has to potentially animate and upload every lightmap in the map each frame.
If you want competative play, r_dynamic 0 is almost a must. You can use gl_flashblend to reenable some quad lights, but its not quite as effective, as it doesn't show through walls.

Imho.

One way to accelerate QuakeWorld with r_dynamic on could be to update dynamic lights on a separate thread, and to use 'vertex' buffer objects to provide quick-switch texture uploads, so the GPU is not stalled at any point to upload lightmap updates (also doesn't have to happen every single frame - quake2 updates dynamic lightmaps at most 10 times a second, or something, which really limits the fps loss).
Another way is to actually batch stuff.
A third way is to not use textures for dynamic lights.

***

Is a Core2Duo an AMD chip? If so, try finding + downloading the AMD dual core optimizer - my fps in QW would drop over the course of an hour or two to become unplayable before I ran the app. I guess there's some fundamental error in the way AMD dual cores work out of the box.

Darff : Core2Duo is Intel I don't notice much difference using that optimizer btw.

I have a AMD Athlon 64 x2 5000+ and a ATI Radeon 4670 512mb and can get 308 fps stable, but that's with QW looking pretty much default.. it's definitely the newer drivers that do it. Watching QTV or similar messes my fps up though, down to 100-200 at times :/ Basically, Nvidia is great for qw and ATI sucks oh and ATI's drivers are worse too.. certainly getting a GeForce next time!

porting ezQuake is a huge effort for the devs, also it wouldn't work in any other plattform than windows

GLQuake had a Direct3d port back then?

I never saw one until recently at this guy's blog: http://mhquake.blogspot.com/

there have been multiple d3d ports in the past.
heck, just FTE is currently on its 4th d3d rewrite.

most d3d ports of quake are done just for the sake of doing it. To work around drivers, or whatever. Tbh, mh's is the first serious attempt at a full d3d quake engine.
(side note: halflife is based on the quake engine, and it has a d3d port! it also retained its gl port. use that if you want fair comparisons, but also bear in mind that the original halflife is dated now, so its only fair if you want to compare d3d from many years ago, which is not entirely relevent, so mneh).

Someone could easily make a Direct3D FuhQuake using MH's wrapper at www.quakeone.com/mh. It is 2 files (gl_fakegl.c and fakegl.h) add to a project and 2 small changes (vid_wgl.c would need SwapBuffers changed to FakeSwapBuffers) and commenting out the extension check, and an addition to gl_local.h.

There is already a DirectJoe engine released, using JoeQuake. JoeQuake is almost an entirely straight port of the graphics in FuhQuake to NQ. So it's already compatible.

Much of it could be incorporated in ezQuake just disabling the non-supported features (i.e. #IFNDEF DX8BUILD ... then no gl_smokeylava availability or whatever)

MH's OpenGL to Direct3D wrapper can be used in most Quake engines almost plug and play.

The performance is very good in most circumstances, although as a whole probably not quite as smooth as a great OpenGL setup with because it doesn't have 10 years of engine optimization, but it is sure better than not being able to use a graphically enhanced build if the ezquake GL isn't working at all.

Spike, about the r_dynamic 0 story, does this also apply to software or just GL ???

its a gl command.

I dunno if there's a software equivalent, as it seems to be always on.

DirectX8 FuhQuake + source code (requires the usual libraries to compile)

DirectTonik - the DirectX8 version of ZQuake.

Version Direct3D8 ezquake 2.0
http://zachem.org/qw/ezquake-gl-d3d.exe

Taken from there:
http://www.quakeworld.nu/forum/viewtopic.php?pid=53307#p53307

One of the benefits of OpenGL is that the porting from win to mac/unix is pretty easy, which makes the clients on all platform pretty similar and easy to keep updated =)