No UAC prompts and anti-aliasing is working fine here (HD 5850). Crosshair's also fine. Mouse feels good to me. Played for about ten minutes and nothing jumped out at me as being wrong or broken.
Did some more testing, trying different DQ versions (1.8.8final/1.8.7/1.8.666) and I guess AA never worked (or at least it does not seem to do so now) on all these versions..
I even rolled back to the previous Nvidia driver, but that made no difference..
Anyways.. here is a screenshot (check the stairs area and the crosshair) to see what I mean..
Btw, AA is not a big deal to me really. Sure it would be nice if it worked, but I'm playing 1600x1200 res anyways.. so.. ;)
A custom crosshair - that explains it. The built-in ones don't have this bug. Anyway, found and fixed.
D3D supports AA and it's on my list of things to add, but the big problem is how does application controlled AA interact with driver-set AA? I can't detect during startup if the player has chosen to override application controlled AA via their driver control panel and all drivers are different so there is no one solution for everything. This is another of those D3D vs OpenGL differences and unfortunately hardware vendors make everyone lose by trying to be too cutesy with their settings. What works for one person will always break for another.
I would really like to see an AA option in the engine. I don't force it on everything in my graphics card control panel..
If it's hard to tell if it's forced why not just leave it on off be default? I think this is how it's made in almost all commercial games.
Also could you please add an option to change the display refresh (screen Hz) again? I think you removed it because it was hard to tell what the desktop Hz was set to on some cards. It's a valid reason imo, but could there at least be a command-line for it? No accidents will happen if it's just a commandline..
MH-This has never happened with DirectQ in the years that I have used it. 1.8.8 patch 1:when the game starts to load it crashes and Windows reboots. Athlon XP 2500+ 1.83Ghz 1.5Gb PC 2100 DDR Ram Geforce 7600GS 512 AGP stock speeds. Windows XP SP3 fully updated. 2005, 2008, 2010 Microsoft Visual C++ and security patches. Netframework all the way to 4 and updates. latest DX 9 Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011 2 runs and reboots with mods. 1 run with only PAK0.PAK and PAK1.PAK in the id1 folder still crashes and reboots. If you need dxdiag I can provide if you tell me where to uload. I have gdb in MinGW that I only very basically know how to use. I'm not a programmer. I also have gDEBugger, but I don't know much about using it I have only used the debuggers in Eduke32 SVN build. If there is any thing else I can provide to help with this my email is martyfender AT comcast.net Thanks for all of your hard work.
MH-This has never happened with DirectQ in the years that I have used it. 1.8.8 patch 1:when the game starts to load it crashes and Windows reboots. Athlon XP 2500+ 1.83Ghz 1.5Gb PC 2100 DDR Ram Geforce 7600GS 512 AGP stock speeds. Windows XP SP3 fully updated. 2005, 2008, 2010 Microsoft Visual C++ and security patches. Netframework all the way to 4 and updates. latest DX 9 Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011 2 runs and reboots with mods. 1 run with only PAK0.PAK and PAK1.PAK in the id1 folder still crashes and reboots. If you need dxdiag I can provide if you tell me where to uload. I have gdb in MinGW that I only very basically know how to use. I'm not a programmer. I also have gDEBugger, but I don't know much about using it I have only used the debuggers in Eduke32 SVN build. If there is any thing else I can provide to help with this my email is martyfender AT comcast.net Thanks for all of your hard work.
1.8.8 patch 1 crashes to a reboot in Windows. I have never had this happen with DirectQ ever. Athlon XP 2500+ 1.83 Ghz 1.5 gb PC 2100 DDR RAM Geforce 7600GS 512 AGP Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011 latest DX 9 Win XP SP3 Pro fully updated All C++ redis. to 2010 and patches Netframework to 4 and patches 2 reboots runs with all of my mods 1 reboot w pak0 and pak1 only in id1 folder, still crashes at game startup desktop res 1024x768 60Hz I,m not a programmer but know how to run gdb under MinGW, probably won't help in a reboot crash You can contact me at: martyfender AT comcast.net If I can give you anything else to help with. Regards
It's actually very easy to get the refresh rate, just a call to GetAdapterDisplayMode will tell you what it is.
I removed it because it crashed and I have no monitor with variable refresh rate to test/bugfix on.
The current ruling is that DirectQ will just run at the same refresh rate you have your monitor set to. Set it to 85Hz and DirectQ will run at 85Hz, set it to 30Hz and DirectQ will run at 30Hz.
Refresh rate is completely irrelevant unless you have vsync enabled anyway.
Ah ok. I use 60 Hz on my desktop because some reason like my screen get hot in 120 Hz. Just enable 120 Hz in games. A refresh rate command would be useful imo, but I could live with just setting the desktop refresh rate to 120 I guess.
You mean because the FPS is capped to 72 FPS? You should get a few extra frames that could be displayed compared to 60 Hz at least?
First is your value of host_maxfps, although my new timer code can occasionally cause this to be exceeded (but it will scale back down over a second or two).
Second is your refresh rate (but that's only relevant if you have vsync enabled; if you don't this cap is effectively "infinite"). With vsync enabled the driver will block until the next vertical retrace interval, with no exceptions.
Third is any hard limit I may build into the engine (there are none, but in general terms it can be a source).
Fourth is absolute performance; this is dependent on so many factors such as your hardware, the map you're running, the complexity of the current scene, the engine you're using - it's impossible to quantify.
Your final FPS will always be the lowest of these four because as a wise man once said "you can't put 10 pounds of shit in a 9 pound bag". Any chain is always only going to be as strong as it's weakest link.
Vsync introduces some interesting problems which I guess is one reason why people run without it. If your refresh rate and your framerate are not in an exact ratio you'll get all kinds of weird and interesting latency problems. Specific example: with 60Hz and vsync, if a scene needs to drop below 60 FPS you must wait for two full retrace intervals - and that means that you'll get 30 FPS, not 55 or whatever.
There are also interesting interactions with input device polling rates. Quake's default 72 FPS is actually a really poor choice these days because it syncs badly with the timings of both input devices and monitor refresh rates; decoupling the renderer timing from everything else is one viable solution I've looked at in the past and may yet look at again.
DirectQ 1.8.8 patch 1 crashes soon after launching,
causing windows to reboot.This has never happen with
DirectQ in the past.
Athlon XP 2500+ 1.83 Ghz 1.5 GB RAM Geforce 7600GS 512 AGP MSI Nforce 2 motherboard Win XP Pro SP3 fully patched DX 9 up to date Visual C++ 2005 through 2010 Redist. fully patched Netframework all up to 4.0 and patches
runs: 2 crash-reboots with mods 1 crash-reboots with only pak0 and pak1 in the id1
folder.
I can provide dxdiag and any other info if you tell me
where to upload it. I have gdb debugger in a MinGW that I use to compile
Eduke32.In addition I have gDEBugger, but don't know
enough about gDEBugger to be of use. I do know how to
run gdb though for basic operation. I might add that I
Not sure if I completely understand but I'll write something anyway.
I get that the FPS will not be higher then the weakest link because it's a bottleneck.
I never have v-sync on, the input lag it adds to the mouse movement is horrible. 120 Hz, 120 FPS and v-sync off is nicer. Setting host_maxfps on 120 gives me 120 FPS without problems (3000 FPS is no problem either, but I can see that it's no real use in having 3000 FPS fed to a 120 Hz screen).
Yes 72 FPS seems to be quite poor, when timing between all the things that should be timed, not much else use it. But it at least sends more then 60 (for a 60 Hz monitor) so it cant be that hard to drop those extra 12 FPS?
host_maxfps works really well on 120 in any case, the physics is unaffected as far as I can see.. I guess the commands tells what FPS the server should run at? ezQuake and FTEQW has independent physics as they call it which allow you to run with a higher FPS in the client while the physics is unaffected, thought you had done something similar?
The only thing I really wanted was to be able to change the display refresh inside your engine. :)
MH, I forgot to add this concerning my previous post on DirectQ crashing causing Windows to reboot:
Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011 developer pre-release. This driver has worked fine with all other quake source port I have tried it on and in all other games I have tried also. email: martyfender AT comcast.net
Interesting. The OpenGL stuff isn't much use because DirectQ actually uses D3D. I do have one other person who has a crasher, but in that case it doesn't cause reboots.
One difference is that this release was compiled on Windows 7 whereas previous ones were compiled on XP. I'll backtrack for the next one and we'll see what happens (may also fix the UAC thing).
Vsync: with vsync disabled refresh rate doesn't matter; the engine will run as fast as it can. I guess there may be a quality improvement in terms of less screen tearing, but otherwise there is no difference.
If the refresh rate option didn't cause crashes and/or if I was in a position to actually be able to test it properly, it would be back tomorrow, trust me.
MH, I knew that DirectQ uses D3D, but that is name of the Nvidia developer driver because it also adds support for the newer OpenGL version 4.2, in addition to the D3D that has been in the driver since who knows when. I do not think it is the driver because I have used developer drivers in the past with no problems like this. However I am not ruling out something else on my system that could cause a conflict, but I'm not sure what. All of my other games I have tested with this driver work fine, including older games such as Blood and Redneck Rampage in DOSBOX, to as new as Bioshock 2 and Fallout 3. these two run pretty well consider the age of the system. I built it in about 2004-2005 when it was considered a pretty good system when Athlon XP's were ahead of Pentium 4 in performance. Today it still holds it own against duel cores thanks in part to my optimization. It is getting long in the tooth for any newer games that are starting to make good use of multicores. Thanks for your hard work and dedication.
I never have v-sync on, the input lag it adds to the mouse movement is horrible. 120 Hz, 120 FPS and v-sync off is nicer.
Interesting. At 120 Hz, you should be looking at about 8ms of latency on input updates being reflected on your display (depending on when input is polled). That's a fairly insignificant amount of time, all things considered. Even a typical USB keyboard might end up giving you greater than 8ms of latency between a key press and its registration in some cases.
@mhquake: Yes it tries to max out at 72 FPS by default with v-sync disabled which is a bit from 120 when I have my screen refresh set to 120 Hz. host_maxfps however fixes this.
The difference in 60 Hz and 120 Hz is quite big with v-sync either on or off. In 60 Hz and v-sync on there is a lot of input lag for the mouse movement, with v-sync off there is a lot of tearing. In 120 Hz there is barely any tearing at all and no input lag as far as I can tell in either modes (v-sync).
I'll wait for the future then. :)
@Ron Jones: Those sentences I wrote were weird (maybe these ones will be too!).
I do actually use v-sync in 60 Hz in most casual singelplayer games because the tearing is just too much.
In 120 Hz I don't notice the input lag but I still play with v-sync off because when I use 120 Hz I want the most responsive experience (like when playing online FPS games and Quake singleplayer), and if I know that v-sync adds input lag I would rather have v-sync off.
I never notice the lag for key-presses, just the movement with the mouse is really noticeable and annoying with v-sync on.
Hmmm, D3D has an option for a D3DPRESENT_DONOTWAIT flag on a swap chain, which should in theory give the best of all worlds - you can skip a screen update but still prcess input, client and server events. Unfortunately NVIDIA drivers just ignore it and enforce normal vsync blocking.
Newer versions of D3D and/or drivers assume multicore. On my i7 DirectQ runs on 4 cores by default, without my having done anything in code to enable this. Big single core CPUs with extreme clock speeds are dead at both the hardware level and the OS/driver support level.
Is there any possibility that you might be overclocking? This is one of those "but it works for everything else" situations again, but if you're overclocking, if you stop doing so, and if the problem goes away then it seems pretty cut and dried. See also: http://www.team5150.com/~andrew/carmack/johnc_plan_1998.html#d19980104.
MH, it is hard to tell, but that last response may be directed at me? Tuesday, September 13, 2011 12:21:00 PM GMT+01:00 I have an MSI 6570 motherboard with an Athlon XP 2500+ that I built in ~2004-2005 I have always run it with the peformance settings in the bios where the FSB is 166 and the memory timings are slightly faster, but the multiplier and is at the stock of 11X. I have been using DirectQ since the very first release with only minor problems. Today I set the award bios back to defaults and ran DirectQ with only pak0 and pak1 in the id1 folder and it still crashed with a system reboot. Is there a way to create a log of some type like Eduke32 does for troubleshooting purposes? the bios defaults, by the way would have been 100Mhz FSB. The next thing I will try is to go back the last build this summer and test it to confirm it is this new build and not something screwy that has happened to my system since then.
Marty- MH, I went back and tested with both the last 2 previous builds of DirectQ both with just pak0 and pak1 in the id1 folder, and also in my main Quake directory with the Quake retexturing pack, models and other mods and had absolutely no problems whatsoever with those older builds. I also read that you are on Windows 7 now so you are not testing on XP? Unfortuately some of the hardware on my nforce 2 MB is not supported with drivers in and I would like to build a new system, bu the state of the economy is a major set back in that respect. Thanks again.
I do test on XP on almost a daily basis, but 7 is my primary working system. Most releases are compiled on XP; the recent one had it's final build compiled on 7 purely because I didn't have an XP machine available at the time, no other reason. But all releases get heavily tested on both XP and 7.
DirectQ does have an "unhandled exception filter" (similar to EDuke32) but unfortunately it doesn't give much info (aside from the notorious "something bad happened" message). Implementing the full thing is a LOT of work with poor documentation to follow.
If you have Visual C++ 2008 and the DirectX SDK you could always try compiling a debug build yourself - it should compile clean on almost any PC without any special work needed (I compile it on 4 or 5 different machines with just a basic setup). Running it in the debugger may give you more useful info.
Thanks, MH. Like I believe I mentioned earlier, the only compiling that I have ever done was with MinGW with msys. Ijust download the Eduke32 source, decompress it into a directory, run msys and cd to the directory and run make to compile it. I have never used Visual C++, but have wanted to learn how to do that. Is that all I need is Visual C++ 2008 and the DirectX SDK and run a make file or are there other things that need to be done to set it up? I have briefly been to Inside3D from time to time thought that compiling Quake was much more complicated than that. Also is 2008 still available and can the free Express version do the job? I may have enough space on my external drive to set it up if it will run ok from there. I noticed that with MinGW they wanted you to use your C or primary system drive but for me it works fine from my external USB drive. I have had some interest in learning more about programming but also realize that my talents lie elsewhere but learning how to compile Quake and other source port besides Eduke32 is the type of challenge that I enjoy. Do any of these debuggers provide any useful info when there is a hard system crash and reboot, as in my case? Finally, so one can still get 2008 despite MS only showing the newer version on their site? I haven't researched that as of yet, but will. I enjoy reading your blog because you go into depth about what you are doing where as most sourceport authors do very little of this with the exception of a short line in their SVN that is usually cryptic for anybody but a programmer.
I had thought it was much, much more complicated to compile, because just a quick overview of some of the threads at inside3d showed people having to do alot of edits to compile quake sources etc. Sorry for my naivety in this regard. As I stated earlier I am not a programmer, but want to learn at least how to compile more source ports because in many case author often have newer builds on their SVN, but don't compile binaries very often. A perfect example is Kirk Barnes and his Quake2XP. His last released binaries crashed back in June, but older builds work fine. Thanks again for such a great port of quake of Quake. Marty
MH, this has been in the back of my mind also, so I looked it up. I realize that DirectQ is D3D, but doesn't it read the openGL strings that the card is capable of on initialization? The reason I mention it is that the Nvidia developer driver has support for the new OpenGL 4.2. If this is totally of base, again excuse my ingnorance into the matter. regards, Marty
KMQuake II: 10/13/09 Hotfix time!
It has come to my attention that nVidia's latest 191.x drivers crash nearly all Quake2 engines by having an OpenGL extension string that's longer than Quake2's text ouput buffer. I've whipped up a hotfix to address this crash. I also threw in fixes for a few other minor issues that will be in 0.21:
Fixed round-off error that was limiting the accuracy of the crosshair. Fixed disappearing textures on bmodels with mixed standard and warp faces (e.g. the moving pillar by the laser array in city3). Fixed camera glitch with thirdperson mode and demos.
The fix is in in the downloads section, along with the updated source code. Of course, if you encounter any other issues, let me know. Also, thanks to Kirk Barnes for finding the source of this crash.
I've stumbled upon a curious bug after playing a bit on my new display.
While underwater, with vsync enabled, performance can in some cases become sluggish. The frame counter will read slightly less than my refresh rate of 120 Hz (104, 108 or 112 fps). With vertical sync off, in an identical position and view orientation, my frame rate counter may read in the 1000's, and performance appears fine. This only happens while underwater.
I ran a PIX experiment and, curiously, the issue doesn't manifest while running through PIX. It's possible that just having the PIX overlay visible is somehow causing the issue to not appear, so I can't really generate any kind of worthwhile information out of any experiments for you.
According to Fraps, though, it looks as if it's rendering five frames within 8.3ms, then missing the swap interval for the consecutive frame, so it's pushed out to 16.7ms. Then another five frames at 8.3ms, one at 16.7, and so on and so on. With vsync disabled, there aren't any frame time anomolies in the Fraps benchmark I ran. Where I was situated for the benchmark, every frame completed within 1.05ms, with exceedly little variability.
MH, thanks for your great programming skill with DirectQ and your confidence in it that eventually lead me to go back and troublshoot my system to solve the problem. In June I had reinstalled Windows XP and that included the Visual c++ redist. 2010 and the latest June DX 9.
Over the course of the last few months I had installed 3 or 4 relatively new games and one of which, I don't remember the name, I remember installing Direct X 9 and the Visual C++ redist. 2008 wih out checking or even giving me the option to back out because I already had the very latest versions. That must have been the cause of the problem of DirectQ crashing the system. I re-downloaded the latest Direct X 9 and installed it and now DirectQ's latest version runs perfectly. It really pisses me off when a game install can't check to see if I have the lastest version and even more so when they don't even ask if I want the option or not to Install the Direct X and Visual C++ redist. I know it can be done because I have seen several game installers that do ask that question. Is it just pure lazieness on the game developers part to put that option in, or are they using some Micrsoft prescripted installer which doesn't check or ask you if you want install the items or not? I do understand that there are no computer savy people who do need to have DX and VS C++ installed automatically for them, but it still should check and only install if you have and older or no install of those Items. What are your thoughts on this matter? For me it is very irritating and irresponsible of the developers.
Sorry for the time and trouble and I am also looking forward to RMQ and the Remake Quake to be released. I haven't checked their page in about a month for any new of an impending release date or new beta.
".....For me it is very irritating and irresponsible of the developers."
There are too many people out there who think "my program is the most important program in the world and damned if I'm going to make any effort to coexist peacefully with anything else".
You're right; it's highly irresponsible. I don't claim to be perfect in this regard but at least I do try (my time as a network admin managing over 1000 PCs taught me a lot of relevant lessons here).
The most important thing for me though is - it works for you now.
Everything we went through in troubleshooting this was all useful stuff; I now have something definite to suggest to other people if they get a crash too. If it fixes even one other crash for someone else it will have been a very good thing indeed.
"I've stumbled upon a curious bug after playing a bit on my new display......."
That's one of the issues with vsync. If you miss a swap interval even by 0.00000000000000001 millliseconds it will block all the way to the next swap interval. Because the entire program itself is blocked this can result in jerky input, sound stuttering and extra latency. If it happens quite frequently things can become really uneven.
In terms of trade offs, I think some screen-tearing from having vsync off is a relatively minor cost by comparison; you can tune your host_maxfps to minimize this of course.
I've long suspected that Quake's default 72FPS was chosen for no reason other than that it matched the most common refresh rate on monitors of the time. Nowadays with 60Hz being more common it's havoc.
Whenyou're underwater DirectQ uses render-to-texture, which will cause some performance overhead and which is probably why this is happening to you. You can quickly confirm this by setting r_waterwarp 0 (disabled) or 2 (uses an alternate method, lower quality but higher performance). You can also set r_waterwarp 666 to have it turned on all the time, even when above water (I included this hidden mode for benchmarking/testing purposes such as this).
That's one of the issues with vsync. If you miss a swap interval even by 0.00000000000000001 millliseconds it will block all the way to the next swap interval.
Of course, but what would cause a frame which would ordinarily complete within 1ms to take >8.3ms when vsync is enabled? And why would it not manifest while it's running through PIX?
Are there any other profiling options, that you know of, that I can use to try and pin this thing down besides PIX?
(The D3DPRESENT_DONOTWAIT flag mentioned here is the one that some drivers just ignore, so there's no point using it.)
I've seen odd things happen in PIX before that don't happen outside of PIX. It's just placing an extra later between your program and the driver and doing some work of it's own, so it's not really a useful indicator of this kind of thing. Wonderful for general troubleshooting though.
Thanks for the link. I did some screwing around earlier this morning and found that the issue can be traced back to certain multisampling and supersampling modes on my AMD card. Interestingly, the only anti-aliasing modes I can use without issue are 2xSSAA and 8xSSAA — so I'd say it's fairly safe to pin this one on an AMD driver bug. There may still be some sort of oddity within DirectQ itself, but I suspect that isn't the case.
Running at 8xSSAA definitely kicks my GPU into overdrive, but it still kicks out 120 frames a second without skipping a beat and there are no apparent issues otherwise.
That gives me an interesting clue. I know that there are interactions between AA/multisampling and Render To Texture that I haven't fully explored yet (and the underwater warp uses RTT) - OpenGL hides all this from the programmer, D3D exposes it in all it's ugliness (with OpenGL you don't need to worry, with D3D you get more control).
It's one of the reasons I've been keeping away from implementing AA (another reason is that I know my video startup code is nasty and needs rewriting, and adding AA to the mix is something I'd prefer to do post-rewrite).
36 comments:
Cheers! Trying it out right away :D
Ok, some feedback after a quick test:
Windows UAC kicks in again every time I start this one...
Crosshair images appear to be borked (no alpha).
Anti-aliasing is not working (I know it was never officially supported, but my driver settings used to work on previous releases).
No more mouse-lag :D
Host_maxfps works nicely as described :D
Curious what host_speeds is all about ;)
I'll report back if I notice anything else worth mentioning..
No UAC prompts and anti-aliasing is working fine here (HD 5850). Crosshair's also fine. Mouse feels good to me. Played for about ten minutes and nothing jumped out at me as being wrong or broken.
I'm puzzled cos I saw neither the crosshair nor the UAC probs (didn't test AA).
Did some more testing, trying different DQ versions (1.8.8final/1.8.7/1.8.666) and I guess AA never worked (or at least it does not seem to do so now) on all these versions..
I even rolled back to the previous Nvidia driver, but that made no difference..
Anyways.. here is a screenshot (check the stairs area and the crosshair) to see what I mean..
Btw, AA is not a big deal to me really. Sure it would be nice if it worked, but I'm playing 1600x1200 res anyways.. so.. ;)
The crosshair I can not do without though!
A custom crosshair - that explains it. The built-in ones don't have this bug. Anyway, found and fixed.
D3D supports AA and it's on my list of things to add, but the big problem is how does application controlled AA interact with driver-set AA? I can't detect during startup if the player has chosen to override application controlled AA via their driver control panel and all drivers are different so there is no one solution for everything. This is another of those D3D vs OpenGL differences and unfortunately hardware vendors make everyone lose by trying to be too cutesy with their settings. What works for one person will always break for another.
I would really like to see an AA option in the engine. I don't force it on everything in my graphics card control panel..
If it's hard to tell if it's forced why not just leave it on off be default? I think this is how it's made in almost all commercial games.
Also could you please add an option to change the display refresh (screen Hz) again? I think you removed it because it was hard to tell what the desktop Hz was set to on some cards. It's a valid reason imo, but could there at least be a command-line for it? No accidents will happen if it's just a commandline..
MH-This has never happened with DirectQ in the years that I have used it.
1.8.8 patch 1:when the game starts to load it crashes and Windows reboots.
Athlon XP 2500+ 1.83Ghz
1.5Gb PC 2100 DDR Ram
Geforce 7600GS 512 AGP stock speeds.
Windows XP SP3 fully updated.
2005, 2008, 2010 Microsoft Visual C++ and security patches.
Netframework all the way to 4 and updates.
latest DX 9
Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011
2 runs and reboots with mods.
1 run with only PAK0.PAK and PAK1.PAK in the id1 folder still crashes and reboots.
If you need dxdiag I can provide if you tell me where to uload.
I have gdb in MinGW that I only very basically know how to use. I'm not a programmer. I also have gDEBugger, but I don't know much about using it I have only used the debuggers in Eduke32 SVN build.
If there is any thing else I can provide to help with this my email is martyfender AT comcast.net
Thanks for all of your hard work.
MH-This has never happened with DirectQ in the years that I have used it.
1.8.8 patch 1:when the game starts to load it crashes and Windows reboots.
Athlon XP 2500+ 1.83Ghz
1.5Gb PC 2100 DDR Ram
Geforce 7600GS 512 AGP stock speeds.
Windows XP SP3 fully updated.
2005, 2008, 2010 Microsoft Visual C++ and security patches.
Netframework all the way to 4 and updates.
latest DX 9
Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011
2 runs and reboots with mods.
1 run with only PAK0.PAK and PAK1.PAK in the id1 folder still crashes and reboots.
If you need dxdiag I can provide if you tell me where to uload.
I have gdb in MinGW that I only very basically know how to use. I'm not a programmer. I also have gDEBugger, but I don't know much about using it I have only used the debuggers in Eduke32 SVN build.
If there is any thing else I can provide to help with this my email is martyfender AT comcast.net
Thanks for all of your hard work.
1.8.8 patch 1 crashes to a reboot in Windows. I have never had this happen with DirectQ ever.
Athlon XP 2500+ 1.83 Ghz
1.5 gb PC 2100 DDR RAM
Geforce 7600GS 512 AGP
Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011
latest DX 9
Win XP SP3 Pro fully updated
All C++ redis. to 2010 and patches
Netframework to 4 and patches
2 reboots runs with all of my mods
1 reboot w pak0 and pak1 only in id1 folder, still crashes at game startup
desktop res 1024x768 60Hz
I,m not a programmer but know how to run gdb under MinGW, probably won't help in a reboot crash
You can contact me at:
martyfender AT comcast.net
If I can give you anything else to help with. Regards
It's actually very easy to get the refresh rate, just a call to GetAdapterDisplayMode will tell you what it is.
I removed it because it crashed and I have no monitor with variable refresh rate to test/bugfix on.
The current ruling is that DirectQ will just run at the same refresh rate you have your monitor set to. Set it to 85Hz and DirectQ will run at 85Hz, set it to 30Hz and DirectQ will run at 30Hz.
Refresh rate is completely irrelevant unless you have vsync enabled anyway.
Ah ok. I use 60 Hz on my desktop because some reason like my screen get hot in 120 Hz. Just enable 120 Hz in games. A refresh rate command would be useful imo, but I could live with just setting the desktop refresh rate to 120 I guess.
You mean because the FPS is capped to 72 FPS? You should get a few extra frames that could be displayed compared to 60 Hz at least?
Well there are 4 possible sources of any FPS cap.
First is your value of host_maxfps, although my new timer code can occasionally cause this to be exceeded (but it will scale back down over a second or two).
Second is your refresh rate (but that's only relevant if you have vsync enabled; if you don't this cap is effectively "infinite"). With vsync enabled the driver will block until the next vertical retrace interval, with no exceptions.
Third is any hard limit I may build into the engine (there are none, but in general terms it can be a source).
Fourth is absolute performance; this is dependent on so many factors such as your hardware, the map you're running, the complexity of the current scene, the engine you're using - it's impossible to quantify.
Your final FPS will always be the lowest of these four because as a wise man once said "you can't put 10 pounds of shit in a 9 pound bag". Any chain is always only going to be as strong as it's weakest link.
Vsync introduces some interesting problems which I guess is one reason why people run without it. If your refresh rate and your framerate are not in an exact ratio you'll get all kinds of weird and interesting latency problems. Specific example: with 60Hz and vsync, if a scene needs to drop below 60 FPS you must wait for two full retrace intervals - and that means that you'll get 30 FPS, not 55 or whatever.
There are also interesting interactions with input device polling rates. Quake's default 72 FPS is actually a really poor choice these days because it syncs badly with the timings of both input devices and monitor refresh rates; decoupling the renderer timing from everything else is one viable solution I've looked at in the past and may yet look at again.
DirectQ 1.8.8 patch 1 crashes soon after launching,
causing windows to reboot.This has never happen with
DirectQ in the past.
Athlon XP 2500+ 1.83 Ghz
1.5 GB RAM
Geforce 7600GS 512 AGP
MSI Nforce 2 motherboard
Win XP Pro SP3 fully patched
DX 9 up to date
Visual C++ 2005 through 2010 Redist. fully patched
Netframework all up to 4.0 and patches
runs:
2 crash-reboots with mods
1 crash-reboots with only pak0 and pak1 in the id1
folder.
I can provide dxdiag and any other info if you tell me
where to upload it.
I have gdb debugger in a MinGW that I use to compile
Eduke32.In addition I have gDEBugger, but don't know
enough about gDEBugger to be of use. I do know how to
run gdb though for basic operation. I might add that I
am not a programmer. Thanks, MH
Not sure if I completely understand but I'll write something anyway.
I get that the FPS will not be higher then the weakest link because it's a bottleneck.
I never have v-sync on, the input lag it adds to the mouse movement is horrible. 120 Hz, 120 FPS and v-sync off is nicer.
Setting host_maxfps on 120 gives me 120 FPS without problems (3000 FPS is no problem either, but I can see that it's no real use in having 3000 FPS fed to a 120 Hz screen).
Yes 72 FPS seems to be quite poor, when timing between all the things that should be timed, not much else use it. But it at least sends more then 60 (for a 60 Hz monitor) so it cant be that hard to drop those extra 12 FPS?
host_maxfps works really well on 120 in any case, the physics is unaffected as far as I can see.. I guess the commands tells what FPS the server should run at? ezQuake and FTEQW has independent physics as they call it which allow you to run with a higher FPS in the client while the physics is unaffected, thought you had done something similar?
The only thing I really wanted was to be able to change the display refresh inside your engine. :)
MH, I forgot to add this concerning my previous post on DirectQ crashing causing Windows to reboot:
Geforce 280.36 OpenGL 4.2 Driver - 08-25-2011 developer pre-release. This driver has worked fine with all other quake source port I have tried it on and in all other games I have tried also. email:
martyfender AT comcast.net
Regards
Interesting. The OpenGL stuff isn't much use because DirectQ actually uses D3D. I do have one other person who has a crasher, but in that case it doesn't cause reboots.
One difference is that this release was compiled on Windows 7 whereas previous ones were compiled on XP. I'll backtrack for the next one and we'll see what happens (may also fix the UAC thing).
Vsync: with vsync disabled refresh rate doesn't matter; the engine will run as fast as it can. I guess there may be a quality improvement in terms of less screen tearing, but otherwise there is no difference.
If the refresh rate option didn't cause crashes and/or if I was in a position to actually be able to test it properly, it would be back tomorrow, trust me.
MH, I knew that DirectQ uses D3D, but that is name of the Nvidia developer driver because it also adds support for the newer OpenGL version 4.2, in addition to the D3D that has been in the driver since who knows when. I do not think it is the driver because I have used developer drivers in the past with no problems like this. However I am not ruling out something else on my system that could cause a conflict, but I'm not sure what. All of my other games I have tested with this driver work fine, including older games such as Blood and Redneck Rampage in DOSBOX, to as new as Bioshock 2 and Fallout 3. these two run pretty well consider the age of the system. I built it in about 2004-2005 when it was considered a pretty good system when Athlon XP's were ahead of Pentium 4 in performance. Today it still holds it own against duel cores thanks in part to my optimization. It is getting long in the tooth for any newer games that are starting to make good use of multicores. Thanks for your hard work and dedication.
I never have v-sync on, the input lag it adds to the mouse movement is horrible. 120 Hz, 120 FPS and v-sync off is nicer.
Interesting. At 120 Hz, you should be looking at about 8ms of latency on input updates being reflected on your display (depending on when input is polled). That's a fairly insignificant amount of time, all things considered. Even a typical USB keyboard might end up giving you greater than 8ms of latency between a key press and its registration in some cases.
@mhquake:
Yes it tries to max out at 72 FPS by default with v-sync disabled which is a bit from 120 when I have my screen refresh set to 120 Hz. host_maxfps however fixes this.
The difference in 60 Hz and 120 Hz is quite big with v-sync either on or off. In 60 Hz and v-sync on there is a lot of input lag for the mouse movement, with v-sync off there is a lot of tearing.
In 120 Hz there is barely any tearing at all and no input lag as far as I can tell in either modes (v-sync).
I'll wait for the future then. :)
@Ron Jones:
Those sentences I wrote were weird (maybe these ones will be too!).
I do actually use v-sync in 60 Hz in most casual singelplayer games because the tearing is just too much.
In 120 Hz I don't notice the input lag but I still play with v-sync off because when I use 120 Hz I want the most responsive experience (like when playing online FPS games and Quake singleplayer), and if I know that v-sync adds input lag I would rather have v-sync off.
I never notice the lag for key-presses, just the movement with the mouse is really noticeable and annoying with v-sync on.
Hmmm, D3D has an option for a D3DPRESENT_DONOTWAIT flag on a swap chain, which should in theory give the best of all worlds - you can skip a screen update but still prcess input, client and server events. Unfortunately NVIDIA drivers just ignore it and enforce normal vsync blocking.
Newer versions of D3D and/or drivers assume multicore. On my i7 DirectQ runs on 4 cores by default, without my having done anything in code to enable this. Big single core CPUs with extreme clock speeds are dead at both the hardware level and the OS/driver support level.
Is there any possibility that you might be overclocking? This is one of those "but it works for everything else" situations again, but if you're overclocking, if you stop doing so, and if the problem goes away then it seems pretty cut and dried. See also: http://www.team5150.com/~andrew/carmack/johnc_plan_1998.html#d19980104.
MH, it is hard to tell, but that last response may be directed at me? Tuesday, September 13, 2011 12:21:00 PM GMT+01:00 I have an MSI 6570 motherboard with an Athlon XP 2500+ that I built in ~2004-2005 I have always run it with the peformance settings in the bios where the FSB is 166 and the memory timings are slightly faster, but the multiplier and is at the stock of 11X. I have been using DirectQ since the very first release with only minor problems. Today I set the award bios back to defaults and ran DirectQ with only pak0 and pak1 in the id1 folder and it still crashed with a system reboot. Is there a way to create a log of some type like Eduke32 does for troubleshooting purposes? the bios defaults, by the way would have been 100Mhz FSB. The next thing I will try is to go back the last build this summer and test it to confirm it is this new build and not something screwy that has happened to my system since then.
mfender
Thanks,
Marty- MH, I went back and tested with both the last 2 previous builds of DirectQ both with just pak0 and pak1 in the id1 folder, and also in my main Quake directory with the Quake retexturing pack, models and other mods and had absolutely no problems whatsoever with those older builds. I also read that you are on Windows 7 now so you are not testing on XP? Unfortuately some of the hardware on my nforce 2 MB is not supported with drivers in and I would like to build a new system, bu the state of the economy is a major set back in that respect. Thanks again.
Mfender
"in Windows 7" left out
I do test on XP on almost a daily basis, but 7 is my primary working system. Most releases are compiled on XP; the recent one had it's final build compiled on 7 purely because I didn't have an XP machine available at the time, no other reason. But all releases get heavily tested on both XP and 7.
DirectQ does have an "unhandled exception filter" (similar to EDuke32) but unfortunately it doesn't give much info (aside from the notorious "something bad happened" message). Implementing the full thing is a LOT of work with poor documentation to follow.
If you have Visual C++ 2008 and the DirectX SDK you could always try compiling a debug build yourself - it should compile clean on almost any PC without any special work needed (I compile it on 4 or 5 different machines with just a basic setup). Running it in the debugger may give you more useful info.
Thanks, MH. Like I believe I mentioned earlier, the only compiling that I have ever done was with MinGW with msys. Ijust download the Eduke32 source, decompress it into a directory, run msys and cd to the directory and run make to compile it. I have never used Visual C++, but have wanted to learn how to do that. Is that all I need is Visual C++ 2008 and the DirectX SDK and run a make file or are there other things that need to be done to set it up?
I have briefly been to Inside3D from time to time thought that compiling Quake was much more complicated than that. Also is 2008 still available and can the free Express version do the job? I may have enough space on my external drive to set it up if it will run ok from there. I noticed that with MinGW they wanted you to use your C or primary system drive but for me it works fine from my external USB drive. I have had some interest in learning more about programming but also realize that my talents lie elsewhere but learning how to compile Quake and other source port besides Eduke32 is the type of challenge that I enjoy. Do any of these debuggers provide any useful info when there is a hard system crash and reboot, as in my case? Finally, so one can still get 2008 despite MS only showing the newer version on their site? I haven't researched that as of yet, but will. I enjoy reading your blog because you go into depth about what you are doing where as most sourceport authors do very little of this with the exception of a short line in their SVN that is usually cryptic for anybody but a programmer.
Thanks Again,
Marty
I had thought it was much, much more complicated to compile, because just a quick overview of some of the threads at inside3d showed people having to do alot of edits to compile quake sources etc. Sorry for my naivety in this regard. As I stated earlier I am not a programmer, but want to learn at least how to compile more source ports because in many case author often have newer builds on their SVN, but don't compile binaries very often. A perfect example is Kirk Barnes and his Quake2XP. His last released binaries crashed back in June, but older builds work fine.
Thanks again for such a great port of quake of Quake.
Marty
MH, this has been in the back of my mind also, so I looked it up. I realize that DirectQ is D3D, but doesn't it read the openGL strings that the card is capable of on initialization? The reason I mention it is that the Nvidia developer driver has support for the new OpenGL 4.2. If this is totally of base, again excuse my ingnorance into the matter.
regards,
Marty
KMQuake II: 10/13/09 Hotfix time!
It has come to my attention that nVidia's latest 191.x drivers crash nearly all Quake2 engines by having an OpenGL extension string that's longer than Quake2's text ouput buffer. I've whipped up a hotfix to address this crash. I also threw in fixes for a few other minor issues that will be in 0.21:
Fixed round-off error that was limiting the accuracy of the crosshair.
Fixed disappearing textures on bmodels with mixed standard and warp faces (e.g. the moving pillar by the laser array in city3).
Fixed camera glitch with thirdperson mode and demos.
The fix is in in the downloads section, along with the updated source code. Of course, if you encounter any other issues, let me know. Also, thanks to Kirk Barnes for finding the source of this crash.
Nope, D3D doesn't need to read those strings, it has a completely different way of figuring that stuff out (that's not prone to the same problem).
I've stumbled upon a curious bug after playing a bit on my new display.
While underwater, with vsync enabled, performance can in some cases become sluggish. The frame counter will read slightly less than my refresh rate of 120 Hz (104, 108 or 112 fps). With vertical sync off, in an identical position and view orientation, my frame rate counter may read in the 1000's, and performance appears fine. This only happens while underwater.
I ran a PIX experiment and, curiously, the issue doesn't manifest while running through PIX. It's possible that just having the PIX overlay visible is somehow causing the issue to not appear, so I can't really generate any kind of worthwhile information out of any experiments for you.
According to Fraps, though, it looks as if it's rendering five frames within 8.3ms, then missing the swap interval for the consecutive frame, so it's pushed out to 16.7ms. Then another five frames at 8.3ms, one at 16.7, and so on and so on. With vsync disabled, there aren't any frame time anomolies in the Fraps benchmark I ran. Where I was situated for the benchmark, every frame completed within 1.05ms, with exceedly little variability.
MH,
thanks for your great programming skill with DirectQ and your confidence in it that eventually lead me to go back and troublshoot my system to solve the problem. In June I had reinstalled Windows XP and that included the Visual c++ redist. 2010 and the latest June DX 9.
Over the course of the last few months I had installed 3 or 4 relatively new games and one of which, I don't remember the name, I remember installing Direct X 9 and the Visual C++ redist. 2008 wih out checking or even giving me the option to back out because I already had the very latest versions. That must have been the cause of the problem of DirectQ crashing the system. I re-downloaded the latest Direct X 9 and installed it and now DirectQ's latest version runs perfectly. It really pisses me off when a game install can't check to see if I have the lastest version and even more so when they don't even ask if I want the option or not to Install the Direct X and Visual C++ redist. I know it can be done because I have seen several game installers that do ask that question. Is it just pure lazieness on the game developers part to put that option in, or are they using some Micrsoft prescripted installer which doesn't check or ask you if you want install the items or not? I do understand that there are no computer savy people who do need to have DX and VS C++ installed automatically for them, but it still should check and only install if you have and older or no install of those Items. What are your thoughts on this matter?
For me it is very irritating and irresponsible of the developers.
Sorry for the time and trouble and I am also looking forward to RMQ and the Remake Quake to be released. I haven't checked their page in about a month for any new of an impending release date or new beta.
Thanks again for your great support MH
Marty
".....For me it is very irritating and irresponsible of the developers."
There are too many people out there who think "my program is the most important program in the world and damned if I'm going to make any effort to coexist peacefully with anything else".
You're right; it's highly irresponsible. I don't claim to be perfect in this regard but at least I do try (my time as a network admin managing over 1000 PCs taught me a lot of relevant lessons here).
The most important thing for me though is - it works for you now.
Everything we went through in troubleshooting this was all useful stuff; I now have something definite to suggest to other people if they get a crash too. If it fixes even one other crash for someone else it will have been a very good thing indeed.
"I've stumbled upon a curious bug after playing a bit on my new display......."
That's one of the issues with vsync. If you miss a swap interval even by 0.00000000000000001 millliseconds it will block all the way to the next swap interval. Because the entire program itself is blocked this can result in jerky input, sound stuttering and extra latency. If it happens quite frequently things can become really uneven.
In terms of trade offs, I think some screen-tearing from having vsync off is a relatively minor cost by comparison; you can tune your host_maxfps to minimize this of course.
I've long suspected that Quake's default 72FPS was chosen for no reason other than that it matched the most common refresh rate on monitors of the time. Nowadays with 60Hz being more common it's havoc.
Whenyou're underwater DirectQ uses render-to-texture, which will cause some performance overhead and which is probably why this is happening to you. You can quickly confirm this by setting r_waterwarp 0 (disabled) or 2 (uses an alternate method, lower quality but higher performance). You can also set r_waterwarp 666 to have it turned on all the time, even when above water (I included this hidden mode for benchmarking/testing purposes such as this).
That's one of the issues with vsync. If you miss a swap interval even by 0.00000000000000001 millliseconds it will block all the way to the next swap interval.
Of course, but what would cause a frame which would ordinarily complete within 1ms to take >8.3ms when vsync is enabled? And why would it not manifest while it's running through PIX?
Are there any other profiling options, that you know of, that I can use to try and pin this thing down besides PIX?
Have a read of this; it explains it better than I can: http://tomsdxfaq.blogspot.com/2006_04_01_archive.html#114482869432550076.
(The D3DPRESENT_DONOTWAIT flag mentioned here is the one that some drivers just ignore, so there's no point using it.)
I've seen odd things happen in PIX before that don't happen outside of PIX. It's just placing an extra later between your program and the driver and doing some work of it's own, so it's not really a useful indicator of this kind of thing. Wonderful for general troubleshooting though.
Thanks for the link. I did some screwing around earlier this morning and found that the issue can be traced back to certain multisampling and supersampling modes on my AMD card. Interestingly, the only anti-aliasing modes I can use without issue are 2xSSAA and 8xSSAA — so I'd say it's fairly safe to pin this one on an AMD driver bug. There may still be some sort of oddity within DirectQ itself, but I suspect that isn't the case.
Running at 8xSSAA definitely kicks my GPU into overdrive, but it still kicks out 120 frames a second without skipping a beat and there are no apparent issues otherwise.
That gives me an interesting clue. I know that there are interactions between AA/multisampling and Render To Texture that I haven't fully explored yet (and the underwater warp uses RTT) - OpenGL hides all this from the programmer, D3D exposes it in all it's ugliness (with OpenGL you don't need to worry, with D3D you get more control).
It's one of the reasons I've been keeping away from implementing AA (another reason is that I know my video startup code is nasty and needs rewriting, and adding AA to the mix is something I'd prefer to do post-rewrite).
Post a Comment