Jump to content
The Dark Mod Forums

Search the Community

Showing results for 'black screen' in content posted in TDM Tech Support.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. I tried it but it didn't work, TDM tried to use it but failed. I ended up removing and cleaning then installed the 2019 Win 11 driver. Could we just supply a small black specularmap texture for the driver to use since that seems to get around the problem in the first place?
  2. This is an AMD card, so more than likely it's a performance hack or AMD doing something stupid with OpenGL. Is there a reason that we couldn't just provide a simple small black dds specular texture on startup for any shader missing it?
  3. Better, don't get the full squares around windows, but the windows in black mage flicker blue still
  4. @stgatilov EDIT: It's still doing it in Flakebridge, just not as badly and the colour doesn't stick around. But, the black mage flickering windows are worse. Before, I just had the blue color in the window texture itself, now it's a big box.
  5. How can you explain that the problematic spots stick forever? You can disable bloom and it disappears, but then you enable it back and have exactly the same black/red/whatever spots, even though you look in the opposite direction already. Where is this magic memory?
  6. It's possible, but it sounds unlikely to me. I would expect any sensible driver to not actually sample the existing framebuffer if its blendweight is zero. Could be wrong, of course, wouldn't be the first time My personal hypothesis is that we may have negative values in the input color framebuffer. This has actually happened in another place where I already put a workaround for the resulting issues in place, so this isn't too far-fetched, even though I don't fully understand the cause. Now, if there is a negative value in the input to bloom, it would probably get smeared across the bloom stages and then added to the final image, which, if the negative value is high enough, would explain why it ends up as black. This is potentially simpler to test and workaround; all we'd need is a check in the bloom_downsample.frag.glsl brightpass function that returns 0 if the brightness is negative.
  7. I'm noting other problems which I'll post issues for once we're up and running again. One of those is related to this one: textures for some non-frobable objects (worldspawn and func_statics) aren't being painted. The same textures will be missing through several dmaps, then suddenly they appear again, and different textures go away. It's as if a) the texture can't be found (though other surfaces with the same texture are fine) or b) the surface is behaving as if no light--not even ambient--is touching it, so it's painted black. In favor of the "texture not being found" thought is that on one load the loading screen was black, as if it couldn't be found. There are no missing texture warnings. Will file an issue with examples when we're back online.
  8. I took a moment to look at the source. My very brief search has me suspect it has something to do with ID_CONSOLE_LOCK. There's a comment "draw the console full screen - this should only ever happen in developer builds". It could be that the Linux release build has the ID_CONSOLE_LOCK variable set incorrectly. Dhewm3: https://github.com/dhewm/dhewm3/blob/ae63021d0060a61374657e507a43fcd12a0d0606/neo/framework/Session.cpp#L2556 TDM: framework/Session.cpp#L2676 Also, there's a comment "If the console's not already down, and we have it turned off, check for ctrl+alt". Dhewm3: https://github.com/dhewm/dhewm3/blob/ae63021d0060a61374657e507a43fcd12a0d0606/neo/framework/Console.cpp#L809 TDM: framework/Console.cpp#L774
  9. Please set: con_noPrint 0 and getViewPos in the console and capture a screen-shot for the location of the lock picks. In my playthrough, this mission was driven by doors with keys that are specific to them but I did locate lock-picks : ( not in a chest ).
  10. Maybe stupid question, but are you running Windows 7 32 bit or 64 bit version? I thought it made sense that if you are running a 32 bit version, you would need to run the 32 bit version of TDM. That is not an indication at all. If I remember correctly, in the new driver selection screen you can select a manual location, here you select the unzipped folder (from the dowloaded intel driver) with the inf file (the graphics folder, I think).
  11. Massive fps drop in the caves. I posted in the black mage fan mission topic my specs.
  12. @GadavreUntil you get this new variable you could use this customised particle file to make the most common fog particles invisible. z_nofog.prt You have to be logged in to download it. (edit: should be renamed to a_nofog.prt) To use it, close TDM and create a folder called "particles" in your "darkmod" folder and put this file inside it. Result: darkmod/particles/z_nofog.prt. Some FMs like The Black Mage have custom versions of fog particles, which means this file might not work 100%. So you can create a folder called "particles" in the fm's folder and put a copy of the file inside it. Result: darkmod/fms/black_mage/particles/z_nofog.prt.
  13. Sorry for going somewhat off topic but I've seen this problem before in fhdoom and it can be a clue for TDM has well. When using a custom post process glsl shader, a small window at the lower left corner of the main window shows up, the effect works in the small window and the rest of the screen gets like you said. I know almost nothing about shader coding, but it could be connected to the way id tech 4 renders the screen first to 640x480 then converts it to the users screen size after. Here is one of the shaders with problems, for those that want to see it. Btw this code was not written totally by me (just made changes to try blindly convert it to fhdoom), this is a modification of a shader from Total Chaos a free game (gzDoom engine), nice game btw and credit for it should be giving to them. Btw how do you hide text in the forum? (so the reply doesn't get so big) hope this helps. Global.inc #version 330 #extension GL_ARB_shading_language_420pack: enable uniform mat4 rpModelMatrix; uniform mat4 rpViewMatrix; uniform mat4 rpModelViewMatrix; uniform mat4 rpProjectionMatrix; uniform vec4 rpLocalLightOrigin; uniform vec4 rpLocalViewOrigin; uniform vec4 rpLightProjectionS; uniform vec4 rpLightProjectionT; uniform vec4 rpLightProjectionQ; uniform vec4 rpLightFallOff; uniform vec4 rpBumpMatrixS; uniform vec4 rpBumpMatrixT; uniform vec4 rpDiffuseMatrixS; uniform vec4 rpDiffuseMatrixT; uniform vec4 rpSpecularMatrixS; uniform vec4 rpSpecularMatrixT; uniform vec4 rpColorModulate; uniform vec4 rpColorAdd; uniform vec4 rpDiffuseColor; uniform vec4 rpSpecularColor; uniform vec4 shaderParm0; //this shaderParm's seem to be connected to the ARB program.local[0], etc uniform vec4 shaderParm1; uniform vec4 shaderParm2; uniform vec4 shaderParm3; uniform mat4 textureMatrix0; uniform int rpAlphaTestEnabled; uniform float rpAlphaTestThreshold; uniform vec4 rpCurrentRenderSize; uniform vec2 rpClipRange; uniform int rpDepthBlendMode; uniform float rpDepthBlendRange; uniform float rpPomMaxHeight; uniform int rpShading; uniform float rpSpecularExp; uniform int rpShadowMappingMode; uniform mat4 rpSpotlightProjection; uniform mat4 rpPointlightProjection[6]; uniform vec4 rpGlobalLightOrigin; uniform vec4 rpShadowParams; //x=minBias, y=maxbias, z=fuzzyness, w=samples uniform vec4 rpShadowCoords[6]; uniform vec4 rpShadowMapSize[6]; //xy = width/height of far plane, zw = near/far clip distance //TODO(johl): is width/height correctly set for non-parallel lights? uniform float rpCascadeDistances[5]; uniform mat4 rpInverseLightRotation; Vertex shader #include "global.inc" layout(location = 0) in vec3 vertex_position; layout(location = 1) in vec2 vertex_texcoord; out vs_output { vec2 texcoord; } result; void main(void) { gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0); vec4 vertex_texcoord4 = vec4(vertex_texcoord, 1.0, 1.0); result.texcoord.x = dot(rpBumpMatrixS, vertex_texcoord4); result.texcoord.y = dot(rpBumpMatrixT, vertex_texcoord4); } Pixel shader/frag program #include "global.inc" layout(binding = 0) uniform sampler2D currentRender; in vs_output { vec2 texcoord; } vert; out vec4 fragColor; vec2 fixScreenTexCoord(vec2 st) { float x = rpCurrentRenderSize.z / rpCurrentRenderSize.x; float y = rpCurrentRenderSize.w / rpCurrentRenderSize.y; return st * vec2(x, y); } void main() { float samples = shaderParm0.x; float amount = shaderParm0.y; float dist = shaderParm0.z; float threshold = shaderParm0.w; vec2 texSize = textureSize(currentRender, 0); vec2 uv = vert.texcoord; uv *= 1.0 - uv.yx; vec4 src = texture(currentRender, vert.texcoord); vec4 c = vec4(src.rgb, 1.0); vec4 fsrc = texture(currentRender, vert.texcoord); vec4 fc = vec4(src.rgb, 1.0); vec2 tc = vert.texcoord; float size = 0.5; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 0.35; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 0.8; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 1.0; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 0.98; for(int i = 0; i < samples; i ++) { size += dist*2; vec2 tc = vert.texcoord; tc.x *= size; tc.y *= size; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } fc = fc /(samples*3); fc = fc - threshold; fc = clamp(fc,0.0,1000000.0); fragColor = vec4(c + (fc * vec4(0.8, 0.8, 1.0, 1.0))*amount); }
  14. As the refactoring in 5323, there would be option to skip success screen completely. Although it probably won't work for campaigns. Also there would be option to replace music/background for success screen. The music along can already be overriden, although the approach cited by @Dragofer is not the best one. Better find this text in mainmenu_custom_defs.gui, uncomment it and set the sound shader you want: // Uncomment this to override the default mission success sound //#undef MM_MISSION_SUCCESS_SOUND_CMD //#define MM_MISSION_SUCCESS_SOUND_CMD "music mission_complete;"
  15. Strange ... After trying to capture in-game screenshots for comparison between 2.06 and SVN, and taking Windows screen captures for comparison, the problem has morphed to: SVN is darker than 2.06, but the "nearly-all-black screen" condition that I saw has changed to a "noticeably darker, but not all-black" condition. Since I invoked SVN by accident while working with my WIP in 2.06, I'm willing to let this go until we get into 2.07 beta and see how other existing missions behave. Perhaps it was some unexplained momentary glitch on my end.
  16. @duzenko So I managed to compile the svn version (2.10 #9675, supposedly), but the issue still appears to be present with black mirrors mirrors (screenshot: far right) and visual glitches on the silverware (screenshot: middle and left) in version 0.9 of my FM:
  17. Well, we all get older and our eyes can't read the fine prints anymore... But 3 is still twice as large as what i would call small at 2160p on a 32" screen. So it probably is three to four times greater than small for the majority plaing at 1080p. So while the restriction is okay, it also has no reason to exist since 2010. And even the most conservative standard should go for at most 4 (also since 2010).
  18. I think I fixed black mirrors in svn but I'm not sure how problematic the silverware is now I'd think it hasn't changed much for a while
  19. The black mirror happens to me as well in svn. Will look into it.
  20. In this case, isn't it the primary issue that the mirror itself is black?
  21. I just tried deleting all the entities with shading issues in the room being discussed on version dev16390-9648 (map version 0.9 - link above) and this seems to have no effect on the mirror. The mirror texture was still black weather the serving platters were present in the sealed room or not.
  22. Hello, I just tested my mission using the most recent development build and in this case the problem is not present, but the reflective mirror texture that I am using is also entirely gone/missing (all mirrors appear completely black). I'm not sure what conclusion to draw from this... Does the "textures/common/mirror" texture behave differently in 2.10 or should I perhaps use an entirely different texture to be 2.10 compatible?
  23. @Dragofer Thanks for your feedback. I thought I should also mention that there is one other instance where this also seems to be to be the case. In this example, I have a door frame with a glass awning on top (model name "models/darkmod/architecture/modules/interior_mansion01/mansion01_door02.lwo"): I managed to solve this in my mission by inserting a black texture just behind the glass part, so for me this is not an issue - but perhaps others might stumble into this same problem.
  24. Which issue? Are you sure you paid attention to color of the flickering objects? Or you only checked whether you see these large spots sticking over the whole screen? Did you reset your config after every checkout? Did you rebuild engine from source code? Bisecting with tdm_installer is not prone to such things, that's why I usually start by suggest it. Also, our trunk is not 100% reliable, sometimes it gets broken temporarily.
  25. My interpretation of what I saw, combined with the discussion in this thread, is that Bloom is amplifying a particular problem, spreading invalid colours across the screen in large boxes, but Bloom itself is not the cause of the original invalid values. The invalid colours disappeared when I switched color depth from 64 to 16. Assuming that "64 bit" means "double float" and "16 bit" means "integer", this would be consistent with the appearance of NaNs in some part of the rendering backend. Integer arithmetic does not have NaNs, which would explain why the problem went away.
×
×
  • Create New...