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: http://quakeone.com/mh/
First | Previous | Next | Last
 
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 QuakeOne.com 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. 
Wut! 
Well that's amazing!

I guess one reason to limit frame rate when recording demos may be file size? 
Yeah... 
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:

http://speeddemosarchive.com/quake/qdq/tools/demtool.html 
 
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. 
Plus... 
I'm not a mapper's engine. I'm a player's engine. 
Clipping 
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! 
MH 
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 ( http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=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? 
Hmm 
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? 
FireBullets 
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. 
Admission 
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. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.