Just to keep everything together, please post all bugs found with DirectQ 1.9.0 here. If you've already posted on the release comments there's no need to post again; I can pick it up from there. All new bugs should go here.
So far the following have been addressed. If your bug is not on this list it doesn't mean that I'm ignoring it or that I'm refusing to fix it - just that I haven't gotten around to it yet.
Nehahra crash in certain maps
Caused by an assumption in the light code that all static entities would be MDLs. Of course it's possible to have a brush or sprite model as a static entity. Fixed.
Wizard and Knight particle trails display incorrectly
Sigh - I really should have finished that code before releasing it.
oggs can possibly crash/bluescreen and/or play funny
Possibly a codec-related issue; DirectQ just uses whatever codecs are installed on your PC and if you have a codec that's not 100% compatible with DirectSound then Bad Things might happen. As a precaution, music playback is now limited to WAV, MP3 or WMA formats (using the preinstalled codecs). May revisit this.
Buffer read overrun if a map sends a texture with 0 width or height
Nehahra does this. It seemed reasonably benign but it's been fixed anyway.
Some external textures (e.g. mapshots, IQM skins) not loading
External textures off the root gamedir path (i.e. without an explicitly set path) were skipped over by the texture loader because the same condition was used for not bothering to search a directory for BSP textures. Changed condition to something more robust, confirmed fixed (also fixes reported "Saved games no longer display their respective image" bug).
Geometry flickering on quicksave
Can't reproduce this one. Added a safeguard that I think should help prevent it.
Screenshots not working
Can't reproduce this one. Added a safeguard that I think should help prevent it. Removed scr_screenshot_jpeg and scr_screenshot_png cvars as they never worked right, messed things up, and can be handled via scr_screenshotformat anyway.
Tuesday, February 21, 2012
DirectQ 1.9.0 Bugs Clearing House
Subscribe to:
Post Comments (Atom)
32 comments:
I'm not experiencing any problems at all. Though I haven't tried Nehahra or using ogg. For me this release is totally solid...and the light flicker fix is quite nice :D
-KillPixel
Movers can't be seen underwater when looking through transparent water. (r_novis 1)
Using the secret teleporter at the end of e1m3 pushes you too far and off the ledge.
At 1680x1050 resolution, a single line of pixels is visible below the floating HUD.
A number of instances of vis fighting. E1M2 exit door is an example. Also in E1M3, the trap door right behind the gold key door extends back into the secret area and vis fights with the floor.
DirectQ is working fine now that I switched from OGG to MP3's. WAV's work fine also. This made me realize why the music available at quakeone was in OGG format. OGG's only take up about 50mb of space and sound good. uncompressed WAV's take up about 500mbs and MP3's use about 100mbs.
"Movers can't be seen underwater when looking through transparent water. (r_novis 1)"
That's normal behaviour - the map still doesn't contain any vis info for seeing underwater and the server isn't sending the monsters to the client as visible. Use sv_novis 1 to see them.
"Using the secret teleporter at the end of e1m3 pushes you too far and off the ledge."
I'll cross-check with other engines and see if it's normal behaviour.
"At 1680x1050 resolution, a single line of pixels is visible below the floating HUD."
Might be nothing I can do about this as 1050 isn't divisible by 4 - D3D9 really predates "weird" resolutions like this. D3D11 will fix it.
"A number of instances of vis fighting. E1M2 exit door is an example. Also in E1M3, the trap door right behind the gold key door extends back into the secret area and vis fights with the floor."
These are all well-known map bugs.
"DirectQ is working fine now that I switched from OGG to MP3's. WAV's work fine also. This made me realize why the music available at quakeone was in OGG format. OGG's only take up about 50mb of space and sound good. uncompressed WAV's take up about 500mbs and MP3's use about 100mbs."
If I can dynamically link to the ogg libraries I'll add better support, but it may take a few revisions to get there.
I thought all was good after I switched to MP3's but in one of my Quake installs with lots of model and texture replacements and other mods the machine crashed when I tried to change the refresh rate to my desktop value of 85 Hz. In a cleaner install of Quake with not much more than the PAK files, I believe it was alright. I will test again because a show stopping crash of Windows like this sets me back until the machine reboots.
Thanks again for all of your hard work, MH
Seems to be a problem with switching refresh rates in this build that a few people have encountered. I'm going to do some experimenting with this and see if I can get to the bottom of it.
I have a feeling that a really robust refresh rate change may involve a two-step switch - first take it back to a windowed mode from the old refresh rate, then bring it on to the new fullscreen mode.
Further tests: the QRP texture replacement pack is causing a crash and reboot on load on my system. I am using the new Nvidia WHQL drivers just released today. In the past I was able to load this and model replacements in DirectQ. Is there any way to create a crash log? When Windows is rebooting? Has anybody else had any problems loading replacement?
Even without the QRP, DirectQ sometimes crashes to the desktop with an unhandled exception error. The only add ons I had were LIT files in maps and MP3's in sound/cdtracks.
QRP pack working fine for me. Yes, I did test external textures many times over before releasing, and I wouldn't have released with a known crasher in them.
Are you using them in a pk3? pak? Extracted? Anything else (other replacement content)?
I don't think a crash log is going to be of any use - the last few crash bugs I fixed had the cause absolutely nowhere near the crash point, required stepping down the call-stack all the way to the start, setting breakpoints at every step, and monitoring specific variables during the process. I suspect that the majority of crash bugs remaining are of a similar nature.
A crash log just won't give you that info. You get the state captured at the point of the crash, whereas the corruption was happening well before that point.
I am using the QRP Extracted per the guide that used to be on your page. I wish is was still there.
-and LIT files
"A number of instances of vis fighting. E1M2 exit door is an example. Also in E1M3, the trap door right behind the gold key door extends back into the secret area and vis fights with the floor."
These are all well-known map bugs.
I haven't seen them show up with the original executables or other engines. Screenshot here. http://i847.photobucket.com/albums/ab37/durandall/Quake0000.png
"I haven't seen them show up with the original executables or other engines."
Funny that because I just cross-checked the specific e1m2 one you mentioned with FitzQuake and it's there. It's also there with DarkPlaces and FTE but you must disable polygon offset (which is not used in the original GLQuake).
I've also double-checked with the released map sources, and yes - the cause of z-fighting is there too: co-planar polygons on the doors and walls.
The only other engines it doesn't happen in are software engines, but this is a well-known problem with any hardware accelerated rendering. Co-planar polygons cause z-fighting.
Regarding polygon offset - there are plenty of good reasons to not use it, including the fact that the depth buffer is not linear, meaning it gives different results at different depths. In OpenGL it's worse because it's also allowed to be implementation-dependent, meaning it can give different results on different hardware.
See this thread for further discussion: http://quakeone.com/forums/quake-help/quake-clients/8030-ways-eliminate-z-fighting.html.
Are you quite sure about what you're saying here?
I don't have darkplaces on hand at the moment and the download page is giving me trouble. Just picked up proquake again and it doesnt show up in gl, but it does show up in direct x. Of course, my recent playthrough in original software, they don't show up. DirectQ is the first engine I've actually tried that uses direct x (I used gl on the others for playthrough). So thats probably why I didnt pick it up. It just really stood out when I started playing in DirectQ (the closest engine to what I'm looking for so far).
loc binds not working, eg. I'm at %l, shows exactly that -- %l -- instead of current location from id1/locs.
ProQuake is using polygon offset.
Here it is in the original GLQuake 0.97 - freshly downloaded from id, not recompiled.
Again, this is a map bug that has always happened. I've just wasted 3 hours re-confirming what I already know here. My position on this is fully outlined in the QuakeOne.com thread I linked and I'm not continuing this particular discussion any further.
I'll check out the .loc thing.
Sorry I wasted your time, but here are my results from several engines.
DarkPlaces
http://i847.photobucket.com/albums/ab37/durandall/darkplaces.jpg
ProQuake GL
http://i847.photobucket.com/albums/ab37/durandall/glproquake.png
Qrack
http://i847.photobucket.com/albums/ab37/durandall/qrack.jpg
GLQuake
http://i847.photobucket.com/albums/ab37/durandall/glquake.png
Only ones with a problem are DirectQ, other Direct X engines, and for some reason the original GLQuake.
I'm no expert. Just started trying out engines the other day. I just noticed something and pointed it out.
OK, one final comment on this.
All of the engines you've mentioned which it doesn't happen in use polygon offset to correct it.
That fixes the immediate problem of z-fighting, but introduces other problems of it's own. These include cracks around certain models and buttons sinking into walls.
There is no reliable fix for this problem that does not have unwanted consequences. Like I said - it's a map bug.
Z-fighting happens in the D3D8 ProQuake engine because that engine does not use polygon offset - I know because I wrote the D3D8 renderer for it.
Z-fighting happens in DirectQ because DirectQ does not use polygon offset either.
Z-fighting happens in the original GLQuake because the original GLQuake does not use polygon offset.
These 3 engines get z-fighting, but they do not get the other unwanted consequences of using polygon offset.
The engines that do use polygon offset don't get z-fighting but they do get the unwanted consequences.
I have directq in d:\quake
I have a directory d:\music which contains various music formats, including midi. for some reason, some maps start playing midis from this directory. dm6 comes to mind. I searched my entire system for other copies of these files and there are none.
it's bizarre. anyway this is on 1.9.
The Windows crashes I was experiencing were with the latest QRP_map_textures_v.1.00 without the normal map pack installed. I tried some the older, much smaller QRP packs available on their website and I didn't experience any crashes. Again I have an Athlon XP 2500, 1.5gb ram and a 7600 GS 512mb video card.Do you have any clues what would cause the crashes with the larger QRP pack, MH?
"Do you have any clues what would cause the crashes with the larger QRP pack, MH?"
Something bad in the pack. I have the 2007-10-06 version of it but haven't checked out anything later - I'll grab 1.00 and see if I can find out what it is.
"I have directq in d:\quake
I have a directory d:\music which contains various music formats, including midi. for some reason, some maps start playing midis from this directory. dm6 comes to mind. I searched my entire system for other copies of these files and there are none."
Cheers, I'll try to reproduce this and see what happens.
Now I remember the other reason I used OGG for music. Darkplaces only supports WAV and OGG. I have both DirectQ and Darkplaces as my primary Quake clients. As far as I can tell, Darkplaces doesn't support MP3's. At least they don't list it in the readme and they don't play in: /ID1/sound/cdtracks/. Is there any word on the QRP crash?
Cheers!
Hi mh, and thanks for the release.
I'm still having some problems with 1.9.0 just like 1.8.8 as I reported over at func_.
- Sounds for moving things do not play for the entire duration of the move.
- Binds like the one below stop working when the framerate becomes too high; no shot is fired. It works a little better now but not much
bind MWHEELUP "impulse 2; +attack; wait; -attack"
- A new issue I discovered with this new release: I have +jump bound to mouse2. If I don't let go of mouse2 before landing after a jump, sometimes I will jump up again a second time, and sometimes also a third time, before coming to a halt on the ground.
- Unfortunately, the clipping problem remains, for me. As a test I played through id1, then Kinn's marcher. After this I went to play Kinn's bastion. Couldn't even get up the first stairs.
Regards.
"Is there any word on the QRP crash?"
Unfortunately I had a pretty bad hardware failure recently. I'm only just starting to get everything back to normal, so it's gonna take some more time before I can update.
"bind MWHEELUP "impulse 2; +attack; wait; -attack""
Try: bind MWHEELUP "impulse 2; wait; +attack; wait; -attack"
"Sounds for moving things do not play for the entire duration of the move .... and more!"
OK, good to know. More for the list. ;)
It seems I've spoken too soon. I've found a few anomalies: Blood continues to drip from gibbed body parts and ignores geometry and drips through floors. Gibbed parts have some clipping issues and will settle off the sides of steps and ledges causing them to appear to be floating.
I've also noticed a few times, only after saving or alt-tabbing, that flashes of light (like from a rocket explosion) will cause doors to become invisible, the doors visibility seems to be directly related to the brightness of the light, the most intense part of the explosion will cause the door to be almost completely invisible. Restarting the client fixes it.
"Blood continues to drip from gibbed body parts and ignores geometry and drips through floors"
Fixed.
"I've also noticed a few times, only after saving or alt-tabbing, that flashes of light (like from a rocket explosion) will cause doors to become invisible"
Seems to be the same bug as the "geometry flickering on quicksave" one I noted in my original post, or at least have the same source. I'm hoping that the code I've added to help this case will fix that one too.
groovy. It may be an issue with my mp3's (maybe lack of metadata or spaces in track titles?) but regardless of the track selected when recording a demo track2 will always be used.
looking forward to the next release! :D
Update on one crasher.
A corrupt save game can cause a crash on startup. I'll need to work through this to determine the best fix, but if you're crashing on startup try renaming your save game folder and see if it makes any difference.
Just tested the released 1.9.0 with QRP - no crash. The problem is somewhere else, and right now I'm pointing my finger at the weird texture sizes used in QRP. My best guess is that they're not playing nice with your hardware, and because DirectQ allows non-power-of-two textures it's throwing the crash.
It's worth noting that QRP has really really odd texture sizes like 2560x1536 - it was obviously made by people who don't really understand how graphics hardware actually works (every content creator should have a crash course in this). With a 512mb card it's even possible that you're running out of video memory (the fact that the smaller pack works suggests this).
I'm not too sure of where to go from here. Put an absolute limit on texture sizes? Something like 2048x2048? Remove non-power-of-two support and round down external textures? Something else?
Forget it when I said "Gibbed parts have some clipping issues and will settle off the sides of steps and ledges causing them to appear to be floating."
This is due to the maps I'm working on, I forgot I wasn't using vanilla maps when I saw that anomaly.
Bah...that's the second compiler that's giving me issues. I'm now using ids original tools with no problems at all...imagine that.
sorry for the misinformation.
Not a problem.
I'm close to understanding the old clipping issue, by the way. Can anyone who's getting it let me know the kind of FPS they're getting at roundabout the time that the problem happens? This is important and useful info that will give me more to work on here...
Post a Comment