Darkplaces Error Reporting Thread

[LeXa2]

Strange and very significant FPS drops when playing on AMD APU C-50/E-350 equipped systems (i.e., slow CPU + AMD GPU)

-Description of the bug
Playing DP on systems equipped with C-50 and/or E-350 APUs is nearly impossible due to strange and sudden FPS drops occurring at some places. I believe this to be DP bug as other GLQuake engines seem to have no problems and FPS drops at that places.

-How to replicate (even if obvious)
Very basic setup is needed to replicate the problem:
a) Standard id1 base + vispatch.
b) Any DP engine from last two years (I had tested with 2009/07/09 and 2011/06/28; as both are affected I assume that any version in-between also is).
c) System with C-50 or E-350 APU. In general I think that any entry-level AMD GPU will do but hadn't checked it for sure.
d) Start up the game, configure it to use minimal settings (no rt-lights, no deluxemapping/glsl, quake-level effects, e.t.c).
e) On C-50 system with 1280x720 32bpp resoluton FPS would be good enough to play - at around 45-60. Start up a new game and then enter into any of the difficulty selecting teleporters.
f) There are two places to notice severe FPS drop here at start.bsp. First one is when you just enter the hallway towards the episode 2 slipgate and watch into the direction the slipgate is (there would be a room with pulsing lights and a closed doors beneath slipgata chamber). Second one is when you're near the "water pool" leading into the fourth episode slipgate room. Most noticeable it would be in case you walk upstairs towards this "pool", turn around and watch into the direction where the first episode slipgate is looking slightly downwards then the "centerview" is.
g) FPS drop level is severe, down to around 10-15 FPS from usual 45-50.

-Other notes
I suspect this to be ATI/AMD OpenGL implementation "feature" DP runs into as switching the game into using vid_dx9 fixes the problem. Setting gl_nopartialtextureupdates = 1 also partially "fixes" the problem: FPS drop remains in place but becomes more slight - FPS goes down to 20-30 from the usual level of 45-50. Switching on/off vid_gl20/vid_gl13/deluxemapping/offsetmapping does not change the behavior. FPS drop remains in place, just the general FPS level changes slightly. Turning on glsl perpixel world shading also doesn't fix the problem. Having gl_nopartialtextureupdates affect the severity of the drop and noticing that there are pulsing lights on start.bsp at the places where bug occurs I suspect that the problematic code might be somewhere at the texture downloading/updating part of the DP.

[LeXa2]

Darkplaces non-rtworld rendering path renders water wrong in case deluxemapping is enabled and dlit is available for the played map

-Description of the bug
Well, SUBJ pretty much describes it. Water (slime, portals, e.t.c) surfaces are being rendered all black in case r_shadow_realtime_world=0, r_glsl_deluxemapping=1, r_wateralpha=1 and dlit file is available for current map. Binary build bisect shows that this bug was introduced between 20091213beta1 and 20091219beta1.

-How to replicate (even if obvious)
* Use any DP build freshen or equal to 20091219beta1, install into fresh Q1 folder.
* Install "deluxemaps for id1", make sure your maps inside pak0.pak are patched for water vis (or simply revis them using hmap2).
* Launch the DP binary, go to console, issue following commands:
r_shadow_realtime_world 0
r_glsl_deluxemapping 1
r_wateralpha 1
* Start up the new game, observe totally black portals selecting the game difficulty, black water surface under the platform in the "Easy" hallway, black water on the way to the fourth episode slipgate, e.t.c.

-Other notes
I believe this bug to be related with changes introduced into GLSL shader between 20091213beta1 and 20091219beta1 releases. All builds from 20091219* and till 20100221beta1 seem to have r_glsl_dump functionality broken, but I had been able to extract default.gsls from the gl_rtmain.c code of the 20091219beta1 release. Looks like shader code had been a bit refactored and the code size from the more recent release seems to be about 1k bigger. Unfortunately it's a bit hard for a person who is unfamiliar with the DP codebase to quickly catch-in into this shader code, but I'm pretty sure the bug should be there, at this changes. Hope to hear good news about fixing this bug soon, thx in advance.

P.S. Just confirmed this bug to happen on both nVIDIA and AMD videocards.

[Patrol1985]

Hip2m3 (The Catacombs) - Vores don't spawn and prevent further progress

- Bug description: When I entered the room with a horn of conjuring (the one which summons a Death Knight) I killed a shambler... and didn't know what else to do. I checked every corner of the level and finally decided to watch a walkthrough. In the video, the player enters the room where a shambler appears along with two vores. After killing everyone a message "sequence complete" appears and some doors open leading to stairs and further part of the level. When I played, the vores never spawned thus preventing my progress.

- recreating the bug: Just play the above mentioned level on nightmare skill (possibly other skill levels as well). I did nothing special other than just playing the game. The vores won't appear.

- notes: of course I can progress through the level using the rocket jump, but when trying to do it the "proper way", I end up in a dead end.

EDIT: I did some tests. Easy and Medium skills work fine. In the first instance, two knights spawn normally. On the normal skill setting four scrags spawn - also no problem. It is the hard and the nightmare skills that cause problems, as the vores don't appear. Also, I know the thread concerns Darkplaces, but maybe this info will help: the same bug happens in Fitzquake, but the good, old GLquake v.097 works fine.

[NightFright]

I'm aware of the gold key door issue in HIP1M1, and was working on it for an entire day recently, no luck though, I did find the revision of the code where the bug began but could not deduce the cause and effect there, experimented at length with the current code but couldn't get it to detect the door touch, will need to experiment more...

For what it's worth, if you move to the left side of the door and slide slowly to the right while pushing into the door, you'll get it to open.

As a reminder to myself, this patch was the beginning of the problem: [twilight] Revision 8070

Would like to add that the blue key door in HIP3M4 seems to suffer from the same problem. Solution is similar, slide from left to right until it eventually opens.

[czevak]

DP + Teamfortress Classic

I tried DP in combination with TF 2.8.

One issue that arose is the engineer unable to build anything because of "not enough room to build here".

This can be mended by putting "sv_gameplayfix_findradiusdistancetobox" "0" in the autoexec.cfg of fortress. (Thanks a lot LordHavoc!).

There is the other issue that the "changeclass" and all class aliases ("sniper", "scout", etc.) to change player character classes are not working. The alias is accepted by the console, but it does not do anything.

Additionally (minor problem): The viewsize always resets to 120, which hides the beautiful transparent HUD Seven made. It does not matter if I put it into config.cfg or autoexec.cfg first, as soon as I get ingame, the HUD is gone and I have to get it back by either pressing "-" or consoling "set viewsize 100".

So if anyone has suggestions for these problems, I am all ears.

[NightFright]

Interesting. Well, as long as it only happens at that specific location, I guess it's not so bad. If need be, I will noclip through it if your tip shouldn't work.

[LordHavoc]

I'm aware of the gold key door issue in HIP1M1, and was working on it for an entire day recently, no luck though, I did find the revision of the code where the bug began but could not deduce the cause and effect there, experimented at length with the current code but couldn't get it to detect the door touch, will need to experiment more...

For what it's worth, if you move to the left side of the door and slide slowly to the right while pushing into the door, you'll get it to open.

As a reminder to myself, this patch was the beginning of the problem: http://svn.icculus.org/twilight?view=rev&revision=8070

[NightFright]

I noticed something with Darkplaces June 28 autobuild. In the first map of MP1 (HIP1M1), I was unable to pass the golden keycard door even though I had collected the card. I also didn't get any error message before when I didn't have the card and tried to pass it. This way, I couldn't finish the level.

[jakub1]

bug found/bug killed (lost chapters)

hi fellow quakers,
-
i tested great pack "the lost chapters" yesterday and i found strange darkplaces bug. however, don't be sad, this time i've came with solution too. so... here we are:
-
inside the lost chapters pack there is a map chapter_kell. i started this map, jumped down to a "well" through a hole in the middle of a start area, continued to the right of the gold-key-door and entered small room with a lift. there was no button and the lift didn't go up automatically when i stepped on it. something was wrong. as far as i remembered, there should have been a gun on the lift platform. the gun itself should have acted as a triger - pick up the gun and the lift goes up. but the gun was gone...

fig 1.


i searched it and i found it. there was a small water pit under the lift platform with a teleport to the secret area on the bottom and it was there where the gun ended. at first, i thought that the gun somehow slipped through the lift brush to the water...

fig 2.


i started to experiment with a sv_freezenonclients cvar to see what happened when the map was loaded. result was quite interesting. i entered the map, set sv_freezenonclients 1 and restarted the level. sv_freezenonclients command remained active so after the restart everything was dead frozen. i continued to the problematic lift and saw something weird. the gun was there floating in the midair, but the lift itself wasn't there.

fig 3.


i set sv_freezenonclients back to 0, unfroze the game again and the lift appeared out of the thin air under the gun. i happened so fast that the gun didn't make it to the water and the gun stayed on the lift. problem solved...

fig 4.


i don't know much about the principles of dp engine or about the order in which map entities are being loaded, but it seems to me that darkplaces loads the gun sooner than the lift platform and the gun falls down to the water. setting sv_freezenonclients 0 freeze all movement within the map at the start up and it prevents the gun from falling down. or maybe it's something else. anyway... it works for me. and maybe the same procedure can fix other maps with items falling through floors/lifts.
-
jakub

[DaniOcampo1992]

With the sdl Version i don't have this issue but when i Alt/Tab out of the game and use (for example) firefox the mouse buttons work but the mouse cursor itself is not movable. When i get back into the game mouselook still works. So it's "bad" exactly into the other direction.

The same thing happens to me..

[grave_digga]

With the sdl Version i don't have this issue but when i Alt/Tab out of the game and use (for example) firefox the mouse buttons work but the mouse cursor itself is not movable. When i get back into the game mouselook still works. So it's "bad" exactly into the other direction.

[LordHavoc]

Please try darkplaces-sdl.exe then and let me know if the problem also occurs there?

darkplaces.exe is an evolved version of the original Quake windows code and gets less testing on my part because I run Linux.

darkplaces-sdl.exe is using the SDL.dll portability library instead, which gets more testing than my Windows code (and has no overhead), but the functionality is slightly different (for example turning on/off vsync requires restarting the video mode).

[DaniOcampo1992]

For me the Darkplaces.exe too..

[grave_digga]

For me it's darkplaces.exe . I really don't know the difference between those two versions...

[LordHavoc]

Autobuild happens every 6 hours, so technically it's not a nightly build

The alt-tab issue you describe, does it affect darkplaces.exe or darkplaces-sdl.exe? They have entirely different event code so I'm curious which one.