News | Forum | People | FAQ | Links | Search | Register | Log in
Direct3D 8 Porting Project
Baker and mh have been working on Direct3D 8 ports of popular Quake engines. The benefit of this is that people whose video cards have poor-quality OpenGL drivers can take advantage of better Direct3D drivers (many ATI and intel cards are in this boat, apparently.)

Engines ported so far:
* AguirRe's enhanced GLQuake
* Fitzquake
* FuhQuake
* JoeQuake
* TomazQuake
* ZQuake

More info and downloads:
I guess they're not using direct-sound / direct-input. Is there any issues about (not) using them apart from the extra coding. 
No Issues 
More or less, this is an extra level of insulation against bad drivers.

OpenGL driver bad or not installed? Windows 7 OpenGL performance is terrible? Bug X, Y, Z in the driver? No long a killer or source of aggravation.

MH's wrapper version 1 took about 6 hours for me to add to another engine.

The final one requires maybe a good 10 minutes (sounds so hard to believe, yet true), the wrapper is written that well.

Really although I think what MH did is an incredible think for Quake, I think the implications of this really go a bit beyond Quake or at least could.

I am thinking that many non-Quake games that used the OpenGL 1.1 or OpenGL 1.2 API set could be nearly insta-converted to DirectX API (Direct3D).

I mean Quake uses a large set of OpenGL 2D functions and 3D functions. 
it needs support. 
I See He Didn't Do... 
GQ! The best engine evar! >:( 
what would we do without features such as "fish spleening" and "hand" 
Nice work. Certainly makes the game run a hell of a lot faster on my laptop. (ie, I can play quake on my laptop now :)

Unfortunately it seems to cause firstly some strange hue/saturation distortion (this may be my settings, will test), and more importantly, some strange glitching of polys. Looks almost like individual polys are breaking from their verts and 'jumping' slightly. I will do some testing/footage capturing/more informed description when I'm not rushing about.

Still, at least I can run high end maps, so it's an improvement :)

(intel x4500 gma btw) 
I have a ATI 3670 video card, and this D3D8 port is slower than the original openGL. Is this normal? 
It Is 
It isn't as fast as the native OpenGL versions of the engines.

Still, they are fast enough to be playable in single player at a more than playable speed although I have noticed certain things like background flashes can drop the frame rate. 
I might add that DirectQ by MH, if you haven't tried it, is totally native Direct3D and supports FitzQuake 0.85 gigantic maps (and in fact, the FitzQuake 0.85 protocol).

DirectQ is Direct3D 9. 
They can never be as fast as native OpenGL owing to the translation layer they have to go through, but that's not the point of them. The point is to have something that works for people who can't even run the GL engines at all, owing to bad or buggy drivers or whatever.

DirectQ on the other hand *is* fast - very fast. 
What I'd really like would be a
directdraw (software) driver for quake
WinQuake actually uses DD (through the SciTech MGL layer), but completely lacks support for colour depth above 8 bit, which I guess is what you really want. 
Through MGL, yes, but MGL can also use some
direct-to-vidcard modes on win9x, too. Was not
my point though, because MGL doesn't do 64 bit,
also its development is dead, so I need a native
DD driver, at least for win64. Quake2 does have
a native DD code for windows/software renderer,
needs porting to q1/hexen2. 

I've looked at the source several times and I'm thinking it doesn't use MGL. 
Thanks, will look at it. 
Can directquake support command line options? 
Command-line Options 
These are only modifications to the renderer so if the original engine does then so do these. Why? Are you having problems? 
I am talking about running a map with a batch file such as:

glquake -nocdaudio -current -game nsoe -heapsize 120000 -id1 -nomtex -bpp 32

directq doesn't work when I use -bpp 16, for example, it stays at 32 bpp. 
That Sounds Like A Feature. 
Use the menu. It's there under Video Options. And you don't need -heapsize either; DirectQ will never run out of memory. In fact DirectQ doesn't need any command-line parameters at all (unless you really want to use them), everthing can be set while the game is running. 
still have some trouble with this. For example, I changed the game directory to SOE, but when I chose run a map, I still only see the maps from my id1 folder.

Also, is there a way to disable multitexture in directq?

Still think that command line options are easily, perhaps you can consider adding them in in the next version? 
Multitexture And Command-line Options... 
The command-line options actually are still there, and most of them still work the same way as before. The only major difference is that -heapsize is gone, but that's because DirectQ does memory fully dynamically and with no real upper limits. -bpp just doesn't seem to work is all.

No way to disable multitexture; I'm somewhat puzzled as to why you would want to (unless you have a Voodoo 1/RIVA 128/etc).

Also puzzled that you can't see the maps. What happens when you try to run one using the "map" command? 
Why? What? 
768_negke: lightning flash visible through solid geometry in first room.

"Burn in hell 1337 haxors". 
on some maps, it's faster if you disable multitexture, for example beginning of Nightjourney, beginning of Five Rivers land, and sickbase.

If I use the map command in the console it works, the problem is that I set the game directory to something else and it still only shows the maps in my id1 folder.

Maybe you can walk me thorugh again, if I want to load an SOE map from the menu, how would I do it? 
It might not be refreshing the maps list in the menu properly. I'll need to check it out.

Regarding multitexture, rules that apply to other Quake engines don't apply to DirectQ. I've tuned the renderer to be able to handle scenes like that (and even larger and more complex ones) without slowing down. Try it with the cogs in ne_tower as another example, or with ctf1_rq. No need to worry about it. 
Mis-stated The Problem 
After some more testing, the problem for me is actually that the id1 maps show up regardless. If I change the directory to SOE, then I should only see the SOE maps, correct? Instead, I have to browse through all of the id1 maps to get to the SOE maps. But I am not sure if this is a bug or a feature. 
that is technically the correct behaviour.
if you are in a mod folder, you still have access to any maps in id1/maps, so if you are asking the engine what maps you can choose from, it's correct to show you id1/maps along side mod/maps.
maybe a seperate command might be in order (my id1/maps is a long list). 
That makes more sense, yes. Maps and other content from ID1 are always available to mods.

Providing an option to filter the list by mod might be an idea.

There is also tab autocompletion on the "map" command. So type "map a" for example, then press tab, and you can cycle through the maps beginning with a. 
A Few More Suggestions... 
Right now, you have to turn on hypnotic as well as quoth to get the correct status bar, I think just turning on quoth should do it.

It would also be nice to make the save games compatible with aguirre quake. Right now, they have to converted through fitzquake. 
Huh? Save games are fully compatible with ID Quake, no changes there. I don't know if Aguirre Quake has changed the format, but I certainly haven't.

I see the thing with the status bar; I'll fix that. 
Well, Aguirre Quake loads the DOS quake saves fine, but it crashes when I renamed Directq's saves (to s11.sav) and try to load that. 
That's really odd because WinQuake loads DirectQ's saves perfectly fine if you do the same thing. I would assume that the problem is with Aguirre Quake based on the maxim that if it works in WinQuake but doesn't in Engine X, then Engine X is broken.

I'm doing some work with Aguirre Quake at the moment so I'll try to see if I can figure what the cause is. 
If you could put a copy of a save file that's causing you trouble somewhere I can download it, and tell me which map it's from, it would help a lot in diagnosing this.

I've uploaded to the above address, rename to, the map is nesp09, Dawn of Eternity 
Downloaded, cause of problem identified, and fix implemented for the next release. :) 
what was the cause, btw? Was it a bug in aguirre's engine or in directbengt or in directq or what? :) 
Can you also make the +map command work in the command line? It doesn't seem to work currently. 
Not wanting to be rude, but could you describe the problem instead of what you think the solution is? ;)

+map just passes to the standard command interpreter, so it's nothing special. Tell me what happens when you try it, tell me the name of the map, do you get any error message in the console (and if so what the error message is) stuff like that.

@metl - a bit of both. DirectQ didn't write "kills" into the savegame comment but Aguirre's engine was depending on it being there. 
C:\Quake\DirectQ.exe +map start works. So +map on the command-line *does* work. So there's something else that's creating a situation in which it *appears* to not work for you.

That's what I meant when I said the above - making +map work is not the solution (it does work), but finding out what that something else is might be a good first step. 
Yeah, I just tested it, it does work. You can disregard the last message. Sorry about that. 
I had an older version version of Directq where if I use it in one of my command lines, it would only load the quoth folder and not the map itself (Fort Driant), but this was an old version and I don't remember which one. 
Has anyone used Dirctq to play Warp? I am using 1.8.3c and I seen some weird grunt/player skins. 
Nevermind, the problem went away when I restarted Directq. 
An update on the problem, if you played the Warp demos before starting up, then the grunt/player skins would be messed up. 
have you tried increasing heapsize? i've had texture and skin corruption problems in the past which went away after allocating more memory. 
DirectQ doesn't use heapsize so it's not that. I suspect it's more likely a texture caching bug which I haven't seen yet - the symptoms certainly match. 
Skin Problems 
OK, I've checked this about 3 or 4 times with Fitz, DP and Aguirres as well as DirectQ and it happens in all of them. It's a content bug rather than an engine bug I'm afraid. 
Sorry About That 
What is it? 
There seems to be a small issue of sometimes not getting the green armor at the beginning of the Map "Return to Dust" with directq. (you have to jump to get it Has anybody else encountered this? 
Extreme Overbright Issue 
I have an animated lavafall texture on a func_illusionary which I had to light quite heavily to make it look right in Glquake (as bright as the regular lava). But now it's totally overbright in DirectQ (and one or two ports from the Proquake pack, for example): screenshot. Even the latest version (1.8.666a) doesn't display it correctly - the first frame of the animation is fuglified like that while the others are fine, so it flickers. What's going on there? 
I Guess... 
... you didn't applied Quake palette to the first frame of the moving texture... Export your image from wad, apply quake palette and then import it back to wad.
It should solve you issue 
It's the engine, not the texture. 
I don't understand why the engine would crap the first texture frame only... hence my answer :P 
Neither do I... hence my question :) 
I'd guess the excessive brightness is because of overbright lighting. The same would happen in software Quake if so, so that's a useful test. (Also FitzQuake and any other engine that supports overbright lighting). gl_overbright 0 will revert DirectQ to GLQuake lighting if necessary.

I don't understand why the first frame would act strange either. Cross-checking with other engines might also be a useful test there. 
I tested it with Winquake, Fitz, and DP (all of which support overbright lighting). The texture looks right in all of them. 
What's the map? I'd like to test this in the debugger to see if I can figure what's going on. 
This One 
Fixed it. Your frame 0 texture was generating the same checksum as the standard lava texture which caused animation cycles to get messed up when both were visible on-screen at the same time. 
Ah, So That Was It 
I thought unique file names were enough. Cheers for fixing it. 
I was comparing checksums though, not filenames. I just added a check for filenames too and it worked. :)

Just waiting to see if I can fix one more thing and I'll release a patched version for this. 
I have a question regarding Directq, when I use 1.866b, I can see the fog fine, but I thought Directq didn't support fog since 1.8.3? 
You Thought Wrong 
then's what with the "getting fog back in 1.9"? 
I lied. :)

I actually restored fog a few versions ago; it only works with shaders (OpenGL vs D3D differences here) but it's there. 
I noticed although fog works, it is not loaded automatic in some maps, such as neh2m5, I have to manually set the fog value in the console. Why does it load for some maps and not others? 
For the same reason as it behaves this way in Fitz. It only loads automatically if the mapper has set a worldspawn key, and is cleared between maps (and the reason for that is because apparently that's the way mappers prefer it).

I did write about this back in October... 
I am not a mapper so the technical stuff is beyond me, but basically what you're saying is that the mapper didn't intend for that nehahra map to have fog by not setting a worldspawn key? 
More or less, yeah. Another possibility is that the map was made before fog via worldspawn in engines was common, but we can discount that in the case of Nehahra. It is a problem with older maps though, and unfortunately I can't see a solution that would make everyone happy. :( 
for the users that do want the fog, is there a quick way to enable it? Right now, I have to load it up in Aguirre, get the fog values, and manually input them. 
well, i suppose you could put those settings in a cfg file and just run that all the time. 
Really, this is something that players and mappers would need to trash out between themselves. I don't want to be stuck in the middle of this argument. Whatever the accepted solution is, I'll do, but until such a time as there is an accepted solution I'm preferring to keep my head down and leave things as they are.

The only exception is if we come up with something for RMQ that handles this situation; that has a higher probability of also being done in DirectQ. 
...should have fog in it i'm sure; kind of an orangey yellow colour. nehahra handled fog differently though - i think it was via an info_start entity rather than a worldspawn value so that might be why certain third party engines aren't picking it up? i may have misinterpreted parts of what mh has said above...

i'll admit i like adding fog (and skyboxes) to maps that don't have any. i don't mind it resetting when a new map loads but i do kind of wish it would remember the settings when you die & reload; i'm not sure how possible that is engine-side... 
> ...should have fog in it i'm sure; kind of an orangey yellow colour. nehahra handled fog differently though - i think it was via an info_start entity rather than a worldspawn value so that might be why certain third party engines aren't picking it up? i may have misinterpreted parts of what mh has said above...

Right, that would make sense. If it expects to use the old gl_fogenable/etc cvars there may be cases where sometimes it gives results that look like they're working and sometimes it doesn't. I'll need to test fully, but it's definitely a viable-sounding theory.

In my specific case I went for FitzQuake fog, the reasoning being that it's the current standard and is used by more recent maps and mods. Not sure if it's even possible to make this compatible with the old method.

> i'll admit i like adding fog (and skyboxes) to maps that don't have any. i don't mind it resetting when a new map loads but i do kind of wish it would remember the settings when you die & reload; i'm not sure how possible that is engine-side...

Perfectly possible. One solution I have (don't think it's in a released version yet though) is to not wipe the fog if the map name hasn't changed. The same could be done for skyboxes. 
There is a bug with directq regarding the map rc1 by fat controller. I can't move at the beginning of the map. RC1 works fine in Fitzquake085. Thanks 
Hmmm - every engine I've tried this map with - including GLQuake - sticks at the start, with the exception of the latest Darkplaces. This includes a freshly downloaded Fitz0.85 - sticks at the start.

ProQuake (Win and GL), EngineX, Fitz, RMQ, DirectQ, ID Quake, older Darkplaces, all stick at the start.

I'm finding it difficult to accept it as a DirectQ bug. More likely a config setting, a QuakeC bug or a map bug (bad clipping hulls perhaps?) 
More info; I've just read the readme for this map, and it's clearly stated in there that it's a beta map. Unless there is an obvious engine-related bug that's common to everything except the latest DP this one is going in the "won't fix" bin. 
There is a bug with the first two ammo boxes in the map sm28 for Directq, when viewed from certain angles the sides of the ammo boxes are missing. This does not happen in Aguirre Quake, Fitzquake 0.85 or RMQ engine. 
Known bug, will be fixed in the next one. 
Is the next version going to support Neh fog also? 
> Is the next version going to support Neh fog also?

No. Neh fog is a completely different implementation of fog that's incompatible with the way DirectQ does fog, and will never, and can never be supported. DirectQ's fog is based on FitzQuake, which is an established, clean and sane standard for mappers, whereas Nehahra is a bunch of dirty hacks (technically impressive for the time, but still a bunch of dirty hacks).

It's just not possible to support both as there is no way of differentiating between them when reading fog values from worldspawn. Given the choice between supporting one standard that was only ever really used for one mod, versus supporting a second that is in widespread use, is what mappers expect, and which will continue to have content released that uses it, it seems obvious which to pick. 
Oh, does this mean the Fitzquake can't support Neh fog? (Aguirre's can support both, but that engine, like Nitin said, isn't widescreen friendly) 
Directq Bug 
When I ran directq 1.8.7, it looked like this:

I have the June 10 version of Directx, My system is a Dell XPS 1640, 4gb ram, p8400, ATI 3670 with 10.6 drivers.

Directq 1.866b works perfectly. Thanks. 
Another Screenshot 
Thankfully it's a beta release...

A few people have got this bug and it seems confined to ATI users. I've a good idea what causes it and will have a fix coming in Beta 2. 
Bug In Beta 2 
When you start a map, you're not facing straight fowards. Seems to happen with any map. 
Doesn't happen with any of the ID1 maps. Can you be more specific? 

This is how I start at Menk. I've tested Fort Driant, and ijed's Maelstrom. All like that.

This bug does not happen if you load the map from the cosole, only via a batch file.

My batch file for load Menk:

directq -nocdaudio -current -game id1 +map Menkstart -id1 -bpp 32

This bug did not exist in 1.866b. Thanks 
Also affects Nehahra too 
It also happens in 1.8.7 beta 1, so it is the changes between 1.866b and 1.8.7 beta 1 
Got it, thanks. 
Directq 1.8.7 beta 2 crashes when I run Five Rivers Land by JPL

this is my commandline:

Directq -nocdaudio -current -hipnotic -game quoth -heapsize 48000 +map 5rivers_e1 -bpp 32

said something about Directq being toast.

Directq 1.866b worked fine. 
5 rivers has corrupted TGAs for it's skybox which D3D's TGA loader doesn't like. A fix I had before was bypasssed by some of the new code. 
Beta 3 can no longer play the Warp demos. Thx 
Beta 3 can no longer play the Warp demos. Thx

I thought I wrote about this a while back but I obviously didn't. I've removed support for the protocols used by these demos; it was getting silly having 7 different protocols in the engine, so they went. Playing the Warpspasm demos is honestly not high on the priority list.

Ask me nicely enough and I might add support back in on the client-side only, and for the purposes of demo playback only. 
Bug Report 
There now seems to be no fog in Quoth maps, I've tested APSP2 and Ruined Nation. 
It seems that only nehahra fog works now, I've also tested elements, and there was no fog there either.

1.866b worked fine. 
Well I did say that compatibility between Nehahra fog and regular fog was a difficulty. I'll check it out, but if it's not resolvable then Nehahra fog is going to go. 
In 1.8.7 rc1, the fog in elements works now, but still no fog in Ruined Nations. 
APSP2 also has fog now. 
In 1.8.7 rc1, the fog in elements works now, but still no fog in Ruined Nations.

There actually is, but Ruined Nation sends it's fog colours on a 0-255 scale whereas everything else sends them on a 0-1 scale. So fog colour is coming through as fully white, and you might not be noticing it properly. 
It also uses a VERY low density value - 0.02 - whereas the norm for most maps is in the 0.05 to 0.1 range. 
Hi mh, I noticed that since 1.8.7, directq some times have slight stuttering at certain parts of maps. (It only happen when you enter an area for the first time) It is kind of hard to replicate, because sometimes it happens, and sometimes it does not. For example, it happened with e1m1rmx by czg and vondur. I didn't notice anything like this in 1.866b. I haven't been able to pin down a pattern of where or when it does this, but maybe you can test the performance of 1.866b vs. 1.8.7? 
Normally, the FPS is 71, but these stuttering cause it to go down to 30-40. 
Entering an area for the first time? Sounds like textures or lightmaps that haven't been seen before are being downloaded to your video RAM. Odd, and interesting. 
OK, I'm going to put on my psychic hat here and guess that you're using a texture pack. Most likely Rygel's but possibly QRP. (This would have been useful info in your original post, by the way.)

If I'm right then the cause of this is that certain textures are being seen for the first time and as a result need to be pulled into video memory (my psychic hat tells me that you also have either Vista or 7 - also would have been useful info). The sheer size of some of these textures makes this a slow operation.

The reason why this happens now but didn't before is on account of a workaround for a bug fix elsewhere.

So - assuming that I'm right in my guesses - I can fix it; but I really need to know if I'm right before I proceed. 
I have windows 7, but no texture pack, my specs are in post 86. 
Is there a logging function in directq? maybe I can produce a log and sent it to you 
-condebug should work but I don't think it's going to be of any benefit. You've clearly got a bug that hasn't shown up during my own testing and that nobody else has reported (I've got other ATI users saying that it's smoother and faster than ever before, and my own benchmarks show it a consistent 1.5 times faster than the last 1.8.666) so it's definitely caused by something in your own setup or on your own machine.

So I need help from you to isolate the cause of this one, because everything on my side and everything on everybody else's side is pointing towards this being something that shouldn't even be happening.

Are you using any particular settings in your Catalyst Control Center? Anything to do with texture optimization or quality?

Have you any other programs running?

Are you overclocking?

Have you tried going back to a clean, default Quake configuration and seeing if it happens with that?

That's the kind of info that's needed now. 
just tested this out of curiosity and it is insanely slow. is there something i need to do to get it running properly? i seem to be getting about 10 or less fps in an area with 11k wpoly and about 6k epoly, no dynamic lights or particles effects.
this is on an nvidia gts250 and launched with the command line:
-heapsize 192000 -particles 20000 -nocdaudio -width 1600 -height 1200 +gl_clear 1 +scr_conspeed 32768 -bpp 32 
If you're finding it that slow then something is wrong with your machine or your setup, or else you've got a contrived scene or situation. I've a GT230 and I manage over 50 FPS with 17k wpoly and 30k epoly. With dynamic lights and particle effects. In an unoptimized debug build. And r_novis 1.

If this is an in-development map I'd be interested in knowing more as I'd like to figure out why it's slow. Because it most definitely shouldn't be. 
oh well, actually, it's slow like that for all maps.
arbitrarily picked e4m3:

noclipped out of the map, about 2.3k wpoly.
directFQ is about 15-19ms r_speeds
quakespasm is 1-3ms.

it has to be something to do with my machine though, i mean, i know the engine isn't *actually* that slow. i was hoping to figure out what does it though.

if it helps, this is on a dual-core cpu, w7 64bit system. 

Ahh, betcha vsync is enabled. Vsync behaves very differently between OpenGL and D3D, and D3D doesn't respect your video card's control panel settings. Or something; I'm not sure how it works in D3D8 which directFQ uses. 
OK, I get 16 or so ms with DirectFitz as well so it's not your machine, it's the code. Bearing in mind that the purpose of that port was stability on Intel cards rather than performance, it's OK.

DirectQ itself does 3-4ms noclip out, r_novis 1, sv_novis 1, 2846 wpoly and 27234 epoly. 
it's unfortunate performance takes such a huge hit, but thanks for clearing that up for me. 
Well I could probably do a lot to improve it, but it's not a live codebase anymore and I don't want to go hacking and slashing at the original Fitz code either; one of the objectives in those ports was to preserve the original code as much as possible. 
Hi mh, I noticed that since 1.8.7, directq some times have slight stuttering at certain parts of maps.

Another possible reason for this is that you may have CPU affinity set. DirectQ actually likes multiple CPUs and/or cores, and will prefer to use them if they're present. Setting CPU affinity screws this up and can cause exactly this kind of behaviour. 
It seems that RC3 no longer has this issue. Your changes must have fixed it. 
It seems that RC3 no longer has this issue. Your changes must have fixed it.

Good to know. I wonder what it was though. Did you ever check the CPU affinity? One of the changes I made was removing a sort on an extra thread, and another person had problems with that on a single core machine. 
RC3 cannot run Ricky's Slave and Starkmon. It could run the hand tho.

I don't have CPU affinity set, I suspect the issue is the slight jerkiness of the timer altho I am not sure. 
Also, in Tronyn's new map sludge, when you pick up the amulet of deflection, the particles do not move around. 
RC3 cannot run Ricky's Slave and Starkmon. It could run the hand tho.


I don't have CPU affinity set, I suspect the issue is the slight jerkiness of the timer altho I am not sure.

Doubtful; this problem didn't happen for anyone else.

Also, in Tronyn's new map sludge, when you pick up the amulet of deflection, the particles do not move around.

Hi mh, I think there might be a problem with fog in the nehahra map Invein. On some of the windows, the green fogs shows on Directq but not Aguirre quake. Would be cool if you looked into it. Thx 
Directq crashes when running rpgsp1. 
Directq crashes when running rpgsp1.

Anything else I need to know? Does it crash when you try to load it? Does it crash at any specific point in the map? When you're doing something? Going somewhere?

Regarding the Nehahra stuff: the status of Nehahra support is always going to be "experimental". The mod dates back to 2001 and contains many incompatibilities with newer concepts, and even has some breaking changes made to the original Quake engine.

I'm still finding out stuff about what's needed for supporting it. It's only recently I found out about how it handles fog and skyboxes. Instead of some nice clean worldspawn keys or server messages the engine must instead call a function in QC which then stuffcmd's all the settings. It's that nasty.

I'm not saying "I won't do it". What I am saying is that it's a lot more complex than just pressing a button marked "make Nehahra work". And that sometimes when you turn over stones you find nasty things crawling out from under them, and then go have to deal with those nasty things before you can do what you originally wanted to do. 
Directq crashes when I load rpgsp1.

commandline: directq -nocdaudio -current -game id1 +map rpgsp1 -id1 -bpp 32 
Great Idea! 
What I am saying is that it's a lot more complex than just pressing a button marked "make Nehahra work".

if you do come up with such a button then please add it to rmqengine, kthx 
and here the screenshot of the bug happening: 
A little more info:

This issue happens if you drop into the bottom area of invein, with the heavy green fog, then use the teleporter to get back up. You will then see the heavy green fog outside of the windows like in the picture. 
Ah, there must be a server message or a stuffcmd I'm missing then. That's useful info, I can debug it now.

rpgsp1 doesn't crash in the new code (due for release tomorrow or Friday), by the way. So much new stuff that I'm not certain what the cause was; I'll need to download a copy of the old and run it in a debugger just to confirm that I've caught it correctly. 
RC3 cannot run Ricky's Slave and Starkmon. It could run the hand tho.

Directq crashes when I load rpgsp1.

same bug, same fix. 
I'm amazed how fast you seem to find all those bugs. How do you do it? What tools do you use, what's your method? 
Microsoft Visual C++.

Set a debug configuration, Ctrl-Shift-B to build it, F5 to debug it. It's got the out-and-out best debugger you can get. 
...And I Also Think... 
...that Yhe1 is actually a great help here. If I sometimes come across as a little annoyed, it's more the case that I'm thinking "Christ! Another one!", but I do have to admit that without his own apparent determination to run every map ever made in DirectQ and let me know what doesn't work, I would never have even known about half of them. So major credit and muchas gracias is definitely due there. 
This issue happens if you drop into the bottom area of invein, with the heavy green fog, then use the teleporter to get back up. You will then see the heavy green fog outside of the windows like in the picture.


Silly me; there I was thinking it might have been a server message. It's Nehahra, so of course it was a stuffcmd. 
And I thought MH stood for Maximum Hate... 
The lift in the middle of the lava pit in Hrim_sp1 doesn't work in RC3, it doesn't come up when the button is pressed. 
Already been fixed. 
RC3 also cannot run Lower Forecourt. 
Also cannot run fr3nrun2 
In fact, you broke pretty much all of my maps. Something RC3 doesn't like about some of the hacks involving brush entities (self-removing func_wall, custom func_door, ...). 
There is a bug in it relating to brush model bounding boxes and I'm suspecting that is the cause behind all of this stuff. It's already been fixed and the fix will be included in the next release. 
The Hrim_sp1 lava platform is still broken under the new release. I can see the platform if I dived into lava using God mode, but it just doesn't come up when I press the button. 
Funny that because I just tried it earlier on today and it worked then. You're not running off a savegame made under the previous version are you? That might have messed up something in the entity if so. 
Started a new game and nocliped to the said area. 
And "said area" being here, right? 
Yes, I nocliped to the area, pressed the button, and the platform didn't come up. I then did the same thing with Aguirre's and the platform worked.

Dunno why that platform is not working for me in directq.

My commandline is:

directq -nocdaudio -width 1366 -height 768 -conwidth 640 -conheight 384 -game Hrim +map hrim_sp1 -heapsize 54000 -id1 -bpp 32 -fullscreen 
It doesn't come up when you load the map from the command line. It does when you load it from the console. The very same happens with any engine that has rotating brush model support in the server code; so far I've traced it to one specific function in the world interaction; disabling the check for rotation fixes it.

I think this needs to go on I3D as it seems to be a bug in the rotation code that affects anybody who's using it.

Don't bother with -heapsize by the way, it does nothing. 
I know, it's just laziness from using Aguirre's and Fitzquake 
...and it also lets you swap out exe names without changing the params... ;)

More info: 
What happened to host_framerate? How can I speed or slow down demo playback now? 
Does DirectQ by any chance support the playback of demos that were recorded with a level change?

I wish someone could modify BJP's convdem tool to support protocol 666 as well. And if it's just for joining demos (to fix the post-level change recording)... 
Please check if there is something wrong with Directq saving games, because I am only able to save one game. 
host_framerate had to go I'm afraid as it was interfering too much with other (normal) operation. I'll probably look into another way of providing functionality for demo speed up/slow down.

Haven't tested with demos recorded with a level change in some time, but unless I broke something recently they should work.

I've normally been saving from the console myself, but will test and fix if required. 
You Feature Scrapper!!! 
I meant non-DirectQ demos actually. And, alas, unsurprisingly they don't work. 
On Automap 
I loved the 3d wireframe descent automap, and it was a great tool once you got the hang of it. Just that descent's geometry complexity was a lot lower than quake's , I guess. The actual level geometry served well as a "bounding hull" that was visible in the automap.

Maybe you can figure out an algorithm that somehow makes large bounding boxes around level geometry while retaining the feeling of space, etc. you get from the base geometry itself. Then a 3d automap will be truly useful. 
Another Thing 
i think it's metroid prime where they show bounding boxes for rooms and then the actual geometry for the room you're currently looking at. Controls work much worse than descent's first person flycam though. 
i'd like to see an engine coder try to just do a rudimentary one with the bsp wireframe and just not display lines that are part of the coplanar face and restricted to the current PVS. (or the engine could do some expensive but one shot calculations to determine visibility with raytracing).
i don't know the math involved with that kind of thing though. maybe it's very complicated and weird or something... math usually is. ���_� 
Hi mh, can you check the map neh2m5, there seems to be a fish stuck in the ground where the four jaggers are in the beginning. This fish didn't seem to be there in Aguirre's. 
Checked it out, it's OK in the current version of the code. 
What's the command to turn off the colored muzzleflash again? All I found was r_colored which disables all colored lighting altogether.
I guess it should be in the advanced visuals menu, too. (colored lighting: full, only world, off).

Some time ago I had some trouble getting (a cfgless) DirectQ to run on Win7 without additional effort, because it was always using 1600*900 as default video mode which out-of-range'd my monitor. However, today it started in 800*600, so no idea.

I wanted to watch the latest SDA demos with DirectQ for easier file selection, but the engine crashed each time a demo ended. 
What's the command to turn off the colored muzzleflash again? All I found was r_colored which disables all colored lighting altogether.

Hmm, think that one got lost some time ago. Must add it back.

I wanted to watch the latest SDA demos with DirectQ for easier file selection, but the engine crashed each time a demo ended.

Something in the demo file it doesn't like is the most likely explanation. I'll download some of them and check it out. 
disconnect does't actually clear the intermission screen state in Quake. That's a new one.

So if you're doing anything with cl.worldmodel during an intermission you should set cl.intermission = 0 in your CL_Disconnect_f. Probably not a bad idea to do it anyway. 
1.8.8.test2 (and Earlier) 
The sound looping on moving func entities seems broken. It plays the sound once and then often just stops. I recall a similar issue in DP once. 
Some Directq Bugs 
I've been playing around with directq lately and I'm impressed with it. A convenient engine that seems to have (almost) everything I need nowadays, and that's also being actively maintained.

Is this the place to report bugs?

I finally played "masque of the red death" and I experienced an annoying problem. Entering a room in the middle of the map, it suddenly seemed like the floor started to behave badly. I couldn't ascend even the most moderate of stairs without sliding down and taking fall damage. Got stuck in architecture at one time. Seems like the "clipping" had shifted up or down or something, compared to the actual map architecture.

I flew around in noclip and made some save games. Restarted directq and the problem was gone. Also the save games don't display the problem anymore unfortunately.

My computer has an Athlon II X4 640 CPU, 8 GB of some RAM, and a GeForce GTS 450. Nothing is clocked above nominal rating. Using DirectQ 1.8.8 Patch 2. 
Ah, The Dreaded Clipnodes Bug 
I'd thought that one should be fixed, but obviously not. I'll need to pass over the code before the next release then.

It's useful to know some circumstances it does and doesn't happen in; that'll help a lot with troubleshooting. 
Here are two savegames, which when loaded now unfortunately no longer display the problem:

I entered that room, and bam - stuff got weird. As far as I remember, anyway.

The second save displays an interesting bullet hole decal floating in mid air, though I don't know if it's strictly related to the clipnodes problem! 
OK, thanks for the saves.

I ran through it with the current revision of the code and it seems to be handled right now. If you're on or Inside3D I'll happily drop you a test build so that you can cross-check and confirm. 
Cross Checking 
I'm not sure if I'm on either of those sites, however, I can't reproduce even with the current engine so it must have been something completely random. Thanks for the offer anyway.

Here are some other problems I'm having:

- When I use the menu to change game directory, the start map that loads will be mostly black. Reloading or loading a new map fixes the problem.

- Like Negke mentions above, sounds for moving things do not play for the entire duration of the move. I am using the quake sound resampling project sounds and -44khz command line, but the problem is still there with original sounds.

- With cl_maxfps set to 72, the game is unplayably unsmooth. Setting it to 60 or 6000 fixes it. However, when recording a demo, the unsmoothness comes back.

- Sky disappears when under water, an example would be in the start area of e1m2.

- Binds like the one below stop working when the framerate becomes too high; no shot is fired. Other buttons are fine, seems to be mwheel related.

bind MWHEELUP "impulse 2; +attack; wait; -attack"

None of these are show stoppers for me though! 
When I use the menu to change game directory, the start map that loads will be mostly black. Reloading or loading a new map fixes the problem.

Already fixed and will be coming in the next release.

Like Negke mentions above, sounds for moving things do not play for the entire duration of the move. I am using the quake sound resampling project sounds and -44khz command line, but the problem is still there with original sounds.

That's down to some "sounds move with entities" code that's not working out. I'll revert.

Sky disappears when under water, an example would be in the start area of e1m2.

That's actually some underwater fog affecting the sky - set gl_underwaterfog 0.

With cl_maxfps set to 72, the game is unplayably unsmooth. Setting it to 60 or 6000 fixes it. However, when recording a demo, the unsmoothness comes back.

72 is a bad value if your refresh rate is 60; pick a multiple of your refresh rate instead. I'll check out the demos.

Not certain about the binds; I'd suggest a wait after ime impulse to see what happens. I can test that more tomorrow. 
I'll Check Out The Demos. 
I had throttled framerates back to 72fps when recording a demo; with hindsight there's no need for that any more (those who care about this kind of thing will be just using JoeQuake anyway) so I'll remove it for the next version. 
Input Roughness 
OK, I've been beating on the input code some, and this problem should be gone in the next one. 
Well that's amazing!

I guess one reason to limit frame rate when recording demos may be file size? 
I guess one reason to limit frame rate when recording demos may be file size?

Yeah... i played at 20fps (i think?) to record the rubicon2 demos, so they wouldn't be so big. Of course it isn't fun to play a whole level like that, when you're playing for your own entertainment. So it would be nice if there was a good tool for capping the framerate of demos. It would have to collect all the temp effects/stuffcmds/etc. from any frame that is dropped, and move it into a previous non-dropped frame, so you don't miss anything. I wonder if it would be better as an engine feature, cl_maxdemofps or something... 
File size was one potential reason (although I run the server at 72fps irrespective of the client speed, so it's not such an issue), the other was compliance with SDA rules (although, like I said, they're just gonna be using JoeQuake anyway so it doesn't really matter).

Recording at 20fps though is a good idea, if a mite unpleasant for the person doing the recording. 
I wouldn't worry too much about SDA rules these days, unfortunately.

metlslime: qdq has a utility called demtool which has a framerate capping function, -f. I guess it's fairly intelligent but I'm not sure, and also it's ancient so you may need dosbox to run it: 
When is r_showtris going to come back? 
I Never Had R_showtris 
I do have r_wireframe though, but that totally replaces the normal render rather than drawing tris on top of it.

r_showtris is useless for mappers in DirectQ anyway as triangle counts are very much irrelevant to performance. Number of draw calls and vertex cache efficiency are much much more important.

r_speeds 1 will get you the former, and GPU vendors won't let you get the latter. 
I'm not a mapper's engine. I'm a player's engine. 
I for one am looking forward to the next release. I was playing fmb maps today and got the clipping bug again on fmb8.

This time though I think it happened gradually. First the world started feeling just a little bit less solid. Then, I started getting stuck on corners and stairs. Last thing happening was getting stuck totally in a staircase. I noclipped out, made a savegame, restarted, and it was all back to normal solidness again! 
Not sure you received my PM, so post it here just to be sure.

I came across an issue in DirectQ where using the player lightning hack described here causes the engine to freeze. It must have been introduced in version 1.8.8 patch 2, as it works in earlier versions (including patch 1). Possibly some stricter handling of certain things.

The freeze can be reproduced in mappi.bsp by activating the lightning traps on the balconies in the boss/exit area on skill 2.

There's a similar issue in Quakespasm which, however, works in that particular map (but not in my current WIP map, it drops to the console with "Host_error: NAN in Traceline"). 
RE: Freeze 
Looking at the diff between MH's 1.8.8-p1 and -p2 shows that he inherited the 64 bit compatibility code for progs strings. To compare: QuakeSpasm earlier than 0.85.1, i.e. unreleased code, svn rev.37 and older w/o that, also haven't been hitting a NaN in Traceline, but svn rev.38 ( ) reveals that issue. It is _probably_ a QC issue. QS, errors only in "developer 1" mode: with developer 0, it silently sets the NaNs to 0 and carries on. 
I got the message but haven't had a chance to look at this problem till now. It appears to be resolved in my current sources but I'll need to backtrack to an earlier version to determine the change that fixed it; my guess is either string handling or something in SV_TouchLinks (where I've tightened up handling of the touched edicts list a little). 
This is almost definitely QC. I backtracked through 2.0.0, a (slightly patched) 1.9.0, the released 1.9.0 and the ancient 1.8.0 and am unable to reproduce it in either test case (mappi and your WIP). This is using a standard unmodified id1 progs.dat - are you using a different progs? 
I just checked again (in sm133_negke, because it's the quickest testing case). And indeed, the lightning works in DirectQ 1.9.0 and QS on progs 1.0 as well as a few others. It does freeze DQ and abort QS with Travail and Quoth (v.2+) - shame on Preach? :) I was sure it also occured on Hipnotic, but I must have confused it as it works there. However, the issues remain in my WIP map, even if using unmodified ID1 progs. Try the lower and upper seals; the middle one works for some reason. I can't see an error in the .map setup, so I'm clueless as to why this still happens.

Good to know QS can deal with it if developer mode is off, though (I didn't notice since I have it set on in the autoexec.cfg). 
Da Lol? 
Ok, something to make it weirder: I just grouped all lightning entities together at the top of the WIP's .map list, and now they work on "normal" progs in both engines. Before, only the first one (which happened to be the middle one) would. What the hell? 
The issue is actually with FireBullets, not W_FireLightning, What makes this harder to diagnose is that the code is line-for-line identical in Quoth and the Quake source.

In particular the offending line is:

traceline (src, src + direction*2048, FALSE, self);

Since this is called by a use function, direction happens to be equal to '0 0 0', so presumably the hang is due to a zero length traceline causing an infinite loop.

The larger mystery is why this code is getting called in Quoth but not in Quake, because it's inside the

while(framecount > 0)

loop. framecount is one of the function parameters, which should default to zero because it's called as a use function (admittedly this is sort of undefined behaviour that the hack is depending on, but it's a de facto standard now). In stock Quake it's coming out as exactly 0 (according to debugging code). In Quoth it's coming out as 0.00000, so presumably it's ever so slightly larger than zero. Hence we enter the loop once and hang. 
It Never Gets Boring... 
Thanks for looking into it!
At least we've now identified another potential issue. If anything, it would be nice if DQ could drop to the console with an error message like QS does instead of freezing altogether. 
Yeah, I could detect a zero-length traceline and drop if so, but I'd prefer a more robust solution; one that gives the result as if the trace had stopped at the start point.

I appreciate that the one approach may be better for mappers or content creators, but where I'm coming from here is that dropping to the console is a rather rude thing to do on the player if an error condition is in any way recoverable. 
Of course that would be a more favorable solution. Ideally, it would just force the value to 0 like QS does in non-dev mode - if there are no serious ramifications to such an approach. 
My instincts were wrong, DQ is not doing anything incorrect with paramters on a function call. In fact in Quoth, FireBullets fires one shot in fitzquake as well, so the traceline is the problem. But why different behaviour from two functions with identical code?(I even went and checked the assembly output..)

Quick lesson on calling. Quake has 8 global variables PARM0...PARM7 for function parameters (which is why QC functions can't have more than 8 parameters). To pass parameters at a function call the following sequence of events happens:

� In the calling function, at the QC level, the parameter values are stored into the global variables.

� The QC calls the function with an OPCODE which indicates how many parameters there were. The different OPCODEs only matter when calling string functions with variable arguments like dprint.

� The engine steps in here to copy the values in PARM0...PARMn into the local variables the "called function" expects them to occupy.

� Now the called function starts running.

OK, so what happens when you call a function with the wrong number of parameters? Remember it's hard to do because it's an error at compile time - but if we're setting a value in the .use field, that can't be checked statically. Well, setting the globals is the responsibility of the QC, so if you trick it like this then nobody sets the globals. This means you get stuck with whatever was put in there last time.

I suspect this is the problem with Quoth, Travail etc. In stock Quake you get very lucky: between touching the trigger and firing the use function of its target, PARM0 gets set to something that safely gets counted as 0, and no shot fires. In Quoth, some extra function, (maybe related to the extra code supporting targetname2 etc) sets PARM0 to something different, so shotcount comes out as non-zero. This causes problems, but it could be much worse: eg junk in a parameter interpreted as an entity could easily segfault the program or corrupt memory.

Before investigating I honestly believed there was some bit of code scrubbing the PARMx values, but I can't find it. So I don't believe anything does, but corrections welcomed! My suggested fix is to no longer use FireBullets in this hack, W_FireAxe is a better substitute because it takes no parameters. W_Attack should work as well. Which one is more likely to be resilient to a mod that changes the weapons? Your guess is as good as mine... 
More Issues 
1. It seems DQ handles brush models vs visblocking differently? In MCE there's a case of disappearing func_walls in the basement that doesn't occur in other engines.

2. After changing the gamedir, one can't change it back to ID1. For instance, switching to Quoth, one can change to Hipnotic and other mods, but when trying to change to ID1, it switches back to Quoth. 
1 post not shown on this page because it was spam
Post A Reply:
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.