Func_Msgboard: Direct3D 8 Porting Project

News | Forum | People | FAQ | Links | Register | Log in

|  | Direct3D 8 Porting Project

Posted by metlslime [98.248.107.212] on 2009/12/21 02:20:25

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/

Huge
#1 posted by stevenaaus [110.20.46.193] on 2009/12/21 21:08:55
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
#2 posted by Baker [99.54.146.62] on 2009/12/21 22:07:26
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.
Mingw
#3 posted by megaman [188.109.39.50] on 2009/12/22 03:54:11
it needs support.
I See He Didn't Do...
#4 posted by Gleeb [212.159.124.139] on 2009/12/22 18:20:50
GQ! The best engine evar! >:(
Yeah...
#5 posted by metlslime [173.11.92.50] on 2009/12/22 21:53:24
what would we do without features such as "fish spleening" and "hand"
#6 posted by meTch [69.183.58.210] on 2009/12/23 01:45:05
...what?
Bees
#7 posted by ijed [190.20.109.172] on 2009/12/23 03:37:30
Hmm
#8 posted by nonentity [86.138.32.7] on 2009/12/23 09:24:15
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)
This post was flagged as spam.
#9 posted by a spammer [196.207.198.211] on 2010/02/10 16:46:45
ATI
#10 posted by yhe1 [140.144.129.4] on 2010/02/25 03:43:15
I have a ATI 3670 video card, and this D3D8 port is slower than the original openGL. Is this normal?
It Is
#11 posted by Baker [99.54.146.62] on 2010/02/25 04:57:29
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.
DirectQ
#12 posted by Baker [99.54.146.62] on 2010/02/25 04:59:14
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).
http://mhquake.blogspot.com/
DirectQ is Direct3D 9.
#13 posted by mh [78.152.224.247] on 2010/02/28 14:55:50
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.
#14 posted by O.S. [60.240.198.243] on 2010/03/01 11:54:17
What I'd really like would be a
directdraw (software) driver for quake
#15 posted by mh [109.79.187.237] on 2010/03/01 20:19:44
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.
DD
#16 posted by O.S. [88.234.209.208] on 2010/03/01 23:42:01
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.
MGL
#17 posted by Baker [99.54.146.62] on 2010/03/02 03:14:20
FTEQW?
I've looked at the source several times and I'm thinking it doesn't use MGL.
DD, FTEQW
#18 posted by O.S. [88.234.211.94] on 2010/03/02 08:06:22
Thanks, will look at it.
#19 posted by yhe1 [71.109.88.59] on 2010/04/04 03:31:20
Can directquake support command line options?
Command-line Options
#20 posted by mh [109.79.144.12] on 2010/04/04 16:54:36
These are only modifications to the renderer so if the original engine does then so do these. Why? Are you having problems?
#21 posted by yhe1 [71.109.88.59] on 2010/04/05 04:04:52
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.
#22 posted by Spirit [213.39.186.16] on 2010/04/05 10:06:23
#23 posted by mh [109.79.243.245] on 2010/04/05 17:04:01
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.
#24 posted by Yhe1 [71.109.88.59] on 2010/04/06 08:19:43
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...
#25 posted by mh [109.79.255.220] on 2010/04/06 18:53:11
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?
#26 posted by negke [88.70.79.41] on 2010/04/06 19:06:37
768_negke: lightning flash visible through solid geometry in first room.
"Burn in hell 1337 haxors".
#27 posted by Yhe1 [140.144.129.4] on 2010/04/06 20:08:14
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?
#28 posted by mh [109.79.255.220] on 2010/04/06 22:51:21
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
#29 posted by yhe1 [71.109.88.59] on 2010/04/07 05:34:22
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.
#30 posted by necros [99.227.131.204] on 2010/04/07 07:17:56
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).
#31 posted by mh [137.191.242.106] on 2010/04/07 11:09:14
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...
#32 posted by yhe1 [71.109.88.59] on 2010/04/11 08:34:39
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.
#33 posted by mh [109.79.196.18] on 2010/04/11 12:42:22
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.
#34 posted by yhe1 [71.109.88.59] on 2010/04/11 20:24:35
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.
#35 posted by mh [137.191.242.106] on 2010/04/12 15:17:16
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.
Incidentally...
#36 posted by mh [137.191.242.106] on 2010/04/12 15:24:02
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.
#37 posted by yhe1 [71.109.88.59] on 2010/04/13 07:49:20
http://www.quaketastic.com/upload/...
I've uploaded to the above address, rename to s11.save, the map is nesp09, Dawn of Eternity
#38 posted by mh [109.79.157.130] on 2010/04/13 23:47:49
Downloaded, cause of problem identified, and fix implemented for the next release. :)
Mh:
#39 posted by metlslime [173.11.92.50] on 2010/04/14 00:46:26
what was the cause, btw? Was it a bug in aguirre's engine or in directbengt or in directq or what? :)
#40 posted by yhe1 [71.109.88.59] on 2010/04/14 01:02:06
Can you also make the +map command work in the command line? It doesn't seem to work currently.
#41 posted by mh [137.191.242.106] on 2010/04/14 11:27:08
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.
Incidentally...
#42 posted by mh [109.79.181.131] on 2010/04/14 17:57:50
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.
Oops
#43 posted by yhe1 [71.109.88.59] on 2010/04/14 19:15:19
Yeah, I just tested it, it does work. You can disregard the last message. Sorry about that.
#44 posted by yhe1 [71.109.88.59] on 2010/04/14 19:22:23
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.
#45 posted by yhe1 [71.109.66.153] on 2010/05/16 10:56:04
Has anyone used Dirctq to play Warp? I am using 1.8.3c and I seen some weird grunt/player skins.
#46 posted by yhe1 [71.109.66.153] on 2010/05/16 11:01:30
Nevermind, the problem went away when I restarted Directq.
#47 posted by yhe1 [71.109.66.153] on 2010/05/16 22:33:32
An update on the problem, if you played the Warp demos before starting up, then the grunt/player skins would be messed up.
#48 posted by necros [99.227.131.204] on 2010/05/16 23:04:03
have you tried increasing heapsize? i've had texture and skin corruption problems in the past which went away after allocating more memory.
#49 posted by mh [78.152.224.156] on 2010/05/17 01:41:18
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
#50 posted by mh [109.79.229.188] on 2010/05/19 20:28:10
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
#51 posted by ijed [190.20.66.140] on 2010/05/25 02:55:44
What is it?
#52 posted by [71.109.69.235] on 2010/07/26 05:47:00
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
#53 posted by negke [88.70.253.129] on 2010/08/11 20:59:31
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...
#54 posted by JPL [82.227.228.57] on 2010/08/12 08:31:15
... 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
Blah
#55 posted by negke [88.70.59.135] on 2010/08/12 10:36:39
It's the engine, not the texture.
Negke
#56 posted by JPL [82.227.228.57] on 2010/08/12 13:43:50
I don't understand why the engine would crap the first texture frame only... hence my answer :P
JPL
#57 posted by negke [88.70.59.135] on 2010/08/12 13:59:39
Neither do I... hence my question :)
#58 posted by mh [109.79.174.206] on 2010/08/14 16:50:48
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.
#59 posted by negke [88.70.236.214] on 2010/08/14 17:07:06
I tested it with Winquake, Fitz, and DP (all of which support overbright lighting). The texture looks right in all of them.
#60 posted by mh [109.79.174.206] on 2010/08/14 18:42:57
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
#61 posted by negke [88.70.92.243] on 2010/08/14 22:43:04
http://negke.quaddicted.com/files/...
#62 posted by mh [109.79.197.175] on 2010/08/15 15:01:22
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
#63 posted by negke [88.70.243.170] on 2010/08/17 21:30:04
I thought unique file names were enough. Cheers for fixing it.
#64 posted by mh [137.191.242.106] on 2010/08/18 12:36:15
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.
Fog
#65 posted by yhe1 [108.23.26.193] on 2011/01/12 19:20:17
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
#66 posted by jt_ [24.11.39.160] on 2011/01/12 20:10:02
#67 posted by yhe1 [108.23.26.193] on 2011/01/12 22:15:52
then's what with the "getting fog back in 1.9"?
#68 posted by mh [78.152.229.91] on 2011/01/12 23:08:17
I lied. :)
I actually restored fog a few versions ago; it only works with shaders (OpenGL vs D3D differences here) but it's there.
#69 posted by Yhe1 [108.23.26.193] on 2011/01/18 00:01:58
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?
#70 posted by mh [109.79.214.239] on 2011/01/18 19:49:05
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... http://mhquake.blogspot.com/2010/1...
#71 posted by Yhe1 [108.23.26.193] on 2011/01/18 23:25:05
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?
#72 posted by mh [109.79.214.239] on 2011/01/19 00:20:21
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. :(
#73 posted by yhe1 [108.23.26.193] on 2011/01/19 05:21:26
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.
#74 posted by necros [99.227.131.204] on 2011/01/19 08:17:13
well, i suppose you could put those settings in a cfg file and just run that all the time.
#75 posted by mh [109.79.141.236] on 2011/01/19 09:27:34
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.
Neh2m5...
#76 posted by rj [82.13.31.251] on 2011/01/19 19:09:22
...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...
#77 posted by mh [78.152.242.241] on 2011/01/19 19:39:34
> ...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.
Bug
#78 posted by Yhe1 [108.23.26.193] on 2011/01/24 04:33:13
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
#79 posted by mh [109.79.222.145] on 2011/01/24 19:06:33
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?)
#80 posted by mh [109.79.222.145] on 2011/01/24 19:10:30
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.
Bug
#81 posted by Yhe1 [108.23.26.193] on 2011/02/10 06:29:03
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.
#82 posted by mh [137.191.242.106] on 2011/02/10 13:35:13
Known bug, will be fixed in the next one.
#83 posted by Yhe1 [108.23.26.193] on 2011/02/21 01:01:11
Is the next version going to support Neh fog also?
#84 posted by mh [137.191.242.106] on 2011/02/21 16:01:44
> 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.
#85 posted by Yhe1 [108.23.26.193] on 2011/02/21 21:14:14
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
#86 posted by Yhe1 [108.23.26.193] on 2011/02/25 22:15:20
When I ran directq 1.8.7, it looked like this:
http://www.quaketastic.com/upload/...
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
#87 posted by Yhe1 [108.23.26.193] on 2011/02/25 22:35:21
http://www.quaketastic.com/upload/...
#88 posted by mh [109.79.9.155] on 2011/02/26 00:24:53
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
#89 posted by Yhe1 [108.23.26.193] on 2011/02/26 20:13:27
When you start a map, you're not facing straight fowards. Seems to happen with any map.
#90 posted by mh [109.79.54.208] on 2011/02/26 22:38:18
Doesn't happen with any of the ID1 maps. Can you be more specific?
Screenshot
#91 posted by Yhe1 [108.23.26.193] on 2011/02/26 23:42:30
http://www.quaketastic.com/upload/...
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
#92 posted by Yhe1 [108.23.26.193] on 2011/02/26 23:45:43
Also affects Nehahra too
#93 posted by Yhe1 [108.23.26.193] on 2011/02/26 23:57:43
It also happens in 1.8.7 beta 1, so it is the changes between 1.866b and 1.8.7 beta 1
#94 posted by mh [109.79.78.12] on 2011/02/27 00:19:43
Got it, thanks.
#95 posted by 5 rivers bug [108.23.26.193] on 2011/02/28 06:19:23
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.
#96 posted by mh [137.191.242.106] on 2011/02/28 11:22:41
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.
Bug
#97 posted by Yhe1 [108.23.26.193] on 2011/03/03 00:35:12
Beta 3 can no longer play the Warp demos. Thx
#98 posted by mh [109.79.161.203] on 2011/03/03 02:01:25
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
#99 posted by Yhe1 [108.23.26.193] on 2011/03/03 02:40:20
There now seems to be no fog in Quoth maps, I've tested APSP2 and Ruined Nation.
#100 posted by Yhe1 [108.23.26.193] on 2011/03/03 02:48:09
It seems that only nehahra fog works now, I've also tested elements, and there was no fog there either.
1.866b worked fine.
#101 posted by mh [78.152.246.135] on 2011/03/03 11:23:42
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.
#102 posted by Yhe1 [108.23.26.193] on 2011/03/03 18:01:59
In 1.8.7 rc1, the fog in elements works now, but still no fog in Ruined Nations.
#103 posted by Yhe1 [108.23.26.193] on 2011/03/03 18:03:59
APSP2 also has fog now.
#104 posted by mh [109.79.208.221] on 2011/03/03 19:11:40
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.
#105 posted by mh [109.79.208.221] on 2011/03/03 19:18:47
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.
#106 posted by Yhe1 [108.23.26.193] on 2011/03/11 21:49:37
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?
#107 posted by Yhe1 [108.23.26.193] on 2011/03/12 03:26:03
Normally, the FPS is 71, but these stuttering cause it to go down to 30-40.
#108 posted by mh [109.79.174.169] on 2011/03/12 13:52:26
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.
#109 posted by mh [109.79.132.88] on 2011/03/13 19:16:57
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.
#110 posted by Yhe1 [108.23.26.193] on 2011/03/13 19:31:58
I have windows 7, but no texture pack, my specs are in post 86.
#111 posted by Yhe1 [108.23.26.193] on 2011/03/13 19:58:50
Is there a logging function in directq? maybe I can produce a log and sent it to you
#112 posted by mh [109.79.132.88] on 2011/03/13 21:08:04
-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.
#113 posted by necros [99.227.131.204] on 2011/03/13 21:18:31
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
#114 posted by mh [109.79.132.88] on 2011/03/13 22:38:00
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.
#115 posted by necros [99.227.131.204] on 2011/03/14 23:31:42
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.
#116 posted by mh [89.19.72.168] on 2011/03/15 00:26:24
15-19ms
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.
#117 posted by mh [89.19.72.168] on 2011/03/15 00:36:05
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.
#118 posted by necros [99.227.131.204] on 2011/03/15 03:15:26
it's unfortunate performance takes such a huge hit, but thanks for clearing that up for me.
#119 posted by mh [78.152.233.110] on 2011/03/15 03:57:39
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.
#120 posted by mh [109.79.170.151] on 2011/03/16 19:59:58
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.
#121 posted by Yhe1 [108.23.26.193] on 2011/03/19 05:19:19
It seems that RC3 no longer has this issue. Your changes must have fixed it.
#122 posted by mh [78.152.211.222] on 2011/03/20 00:10:16
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.
Bug
#123 posted by Yhe1 [108.23.26.193] on 2011/03/20 07:31:29
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.
#124 posted by Yhe1 [108.23.26.193] on 2011/03/20 19:48:48
Also, in Tronyn's new map sludge, when you pick up the amulet of deflection, the particles do not move around.
#125 posted by mh [109.79.234.235] on 2011/03/20 20:54:48
RC3 cannot run Ricky's Slave and Starkmon. It could run the hand tho.
Fixed.
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.
Fixed.
#126 posted by Yhe1 [71.246.41.128] on 2011/03/30 09:04:49
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
#127 posted by Yhe1 [71.246.41.128] on 2011/03/30 22:39:02
Directq crashes when running rpgsp1.
#128 posted by mh [78.152.236.90] on 2011/03/30 23:07:57
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.
#129 posted by Yhe1 [71.246.41.128] on 2011/03/30 23:31:04
Directq crashes when I load rpgsp1.
commandline: directq -nocdaudio -current -game id1 +map rpgsp1 -id1 -bpp 32
Great Idea!
#130 posted by rj [86.0.166.158] on 2011/03/31 00:19:19
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
#131 posted by Yhe1 [71.246.41.128] on 2011/03/31 01:10:51
A save game uploaded of the nehahra issue:
http://www.quaketastic.com/upload/...
#132 posted by Yhe1 [71.246.41.128] on 2011/03/31 01:14:19
and here the screenshot of the bug happening:
http://www.quaketastic.com/upload/...
#133 posted by Yhe1 [71.246.41.128] on 2011/03/31 01:17:55
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.
#134 posted by mh [78.152.236.90] on 2011/03/31 01:33:38
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.
#135 posted by mh [137.191.242.106] on 2011/03/31 13:12:37
RC3 cannot run Ricky's Slave and Starkmon. It could run the hand tho.
Directq crashes when I load rpgsp1.
same bug, same fix.
Mh
#136 posted by megaman [217.229.129.3] on 2011/03/31 20:34:45
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?
#137 posted by mh [109.79.201.235] on 2011/04/01 00:47:05
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...
#138 posted by mh [109.79.201.235] on 2011/04/01 00:51:36
...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.
#139 posted by mh [109.79.201.235] on 2011/04/01 01:07:11
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.
Fixed.
Silly me; there I was thinking it might have been a server message. It's Nehahra, so of course it was a stuffcmd.
Hmm
#140 posted by negke [88.70.53.237] on 2011/04/02 11:04:13
And I thought MH stood for Maximum Hate...
#141 posted by Yhe1 [71.246.41.128] on 2011/04/07 05:08:18
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.
#142 posted by mh [109.79.213.168] on 2011/04/07 22:14:14
Already been fixed.
#143 posted by Yhe1 [71.246.41.128] on 2011/04/08 04:40:32
RC3 also cannot run Lower Forecourt.
#144 posted by Yhe1 [71.246.41.128] on 2011/04/08 05:11:49
Also cannot run fr3nrun2
Heh
#145 posted by negke [188.96.130.136] on 2011/04/08 09:56:15
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, ...).
#146 posted by mh [109.79.211.228] on 2011/04/08 10:01:33
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.
#147 posted by Yhe1 [71.246.41.128] on 2011/04/09 02:03:47
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.
#148 posted by mh [109.79.141.33] on 2011/04/09 03:56:21
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.
#149 posted by Yhe1 [71.246.41.128] on 2011/04/09 04:06:13
Started a new game and nocliped to the said area.
#150 posted by mh [78.152.231.120] on 2011/04/09 18:03:10
And "said area" being here, right?
http://i56.tinypic.com/2uzfep3.jpg
#151 posted by Yhe1 [71.246.41.128] on 2011/04/09 20:08:44
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
#152 posted by mh [78.152.231.120] on 2011/04/09 23:39:52
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.
#153 posted by Yhe1 [71.246.41.128] on 2011/04/10 01:50:37
I know, it's just laziness from using Aguirre's and Fitzquake
#154 posted by mh [109.79.255.142] on 2011/04/10 16:06:41
...and it also lets you swap out exe names without changing the params... ;)
More info: http://forums.inside3d.com/viewtop...
#155 posted by negke [188.96.130.190] on 2011/04/15 12:10:34
What happened to host_framerate? How can I speed or slow down demo playback now?
#156 posted by negke [188.96.130.190] on 2011/04/15 12:31:19
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)...
#157 posted by Yhe1 [71.246.41.128] on 2011/04/17 20:07:03
Please check if there is something wrong with Directq saving games, because I am only able to save one game.
#158 posted by mh [109.79.201.0] on 2011/04/18 16:10:23
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!!!
#159 posted by negke [88.70.88.149] on 2011/04/18 16:21:58
I meant non-DirectQ demos actually. And, alas, unsurprisingly they don't work.
On Automap
#160 posted by megaman [88.64.179.109] on 2011/05/06 14:12:26
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
#161 posted by megaman [88.64.179.109] on 2011/05/06 14:14:24
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.
#162 posted by necros [99.227.131.204] on 2011/05/06 22:23:33
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. ¬_¬
#163 posted by Yhe1 [71.246.41.128] on 2011/05/11 22:58:10
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.
#164 posted by mh [137.191.242.106] on 2011/05/12 14:46:02
Checked it out, it's OK in the current version of the code.
#165 posted by negke [89.204.153.129] on 2011/05/20 10:53:26
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.
#166 posted by mh [109.79.203.38] on 2011/05/20 12:43:33
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.
#167 posted by mh [109.79.203.38] on 2011/05/20 13:10:22
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)
#168 posted by negke [89.204.153.172] on 2011/06/19 13:50:19
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
#169 posted by Mandel [80.217.95.105] on 2012/01/08 17:41:52
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
#170 posted by mh [89.19.74.101] on 2012/01/09 21:09:11
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.
Savegames
#171 posted by Mandel [80.217.95.105] on 2012/01/10 19:43:06
Here are two savegames, which when loaded now unfortunately no longer display the problem: http://mandelmassa.net/temp/masque...
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!
#172 posted by mh [109.79.198.196] on 2012/01/10 21:00:44
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
#173 posted by Mandel [80.217.95.105] on 2012/01/15 15:22:15
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!
#174 posted by mh [109.79.241.65] on 2012/01/15 17:12:58
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.
#175 posted by mh [109.79.241.65] on 2012/01/15 18:48:18
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
#176 posted by mh [109.79.241.65] on 2012/01/16 00:47:05
OK, I've been beating on the input code some, and this problem should be gone in the next one.
Wut!
#177 posted by Mandel [80.217.95.105] on 2012/01/16 19:11:37
Well that's amazing!
I guess one reason to limit frame rate when recording demos may be file size?
Yeah...
#178 posted by metlslime [67.188.81.46] on 2012/01/16 19:58:30
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...
#179 posted by mh [109.79.171.13] on 2012/01/16 20:17:41
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.
#180 posted by Mandel [80.217.95.105] on 2012/01/16 20:38:30
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...
#181 posted by negke [31.18.178.13] on 2012/01/18 10:42:53
When is r_showtris going to come back?
I Never Had R_showtris
#182 posted by mh [109.79.188.46] on 2012/01/18 13:10:50
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...
#183 posted by mh [109.79.188.46] on 2012/01/18 13:14:55
I'm not a mapper's engine. I'm a player's engine.
Clipping
#184 posted by Mandel [80.217.95.105] on 2012/02/12 13:06:43
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
#185 posted by negke [31.18.172.250] on 2013/01/19 12:43:35
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
#186 posted by szo [88.238.192.102] on 2013/01/19 22:52:09
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.... ) 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.
#187 posted by mh [213.233.148.2] on 2013/01/20 00:39:53
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).
#188 posted by mh [213.233.148.2] on 2013/01/20 00:55:24
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
#189 posted by negke [31.18.172.250] on 2013/01/20 11:38:42
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?
#190 posted by negke [31.18.172.250] on 2013/01/20 11:53:52
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
#191 posted by Preach [77.98.165.95] on 2013/01/20 14:23:37
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...
#192 posted by negke [31.18.172.250] on 2013/01/20 20:28:40
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.
#193 posted by mh [78.152.240.60] on 2013/01/21 02:04:25
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.
#194 posted by negke [31.18.172.250] on 2013/01/21 20:24:50
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
#195 posted by Preach [77.98.165.95] on 2013/01/22 01:21:14
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
#196 posted by negke [31.18.172.250] on 2013/02/23 18:38:07
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.

Post A Reply:

Name: |
Title: |
Body: |

Website copyright © 2002-2013 John Fitzgibbons. All posts are copyright their respective authors.