Search the Community
Showing results for 'black screen' in content posted in TDM Tech Support.
-
My new FM is in beta test, and some testers are using 2.12. They have discovered a hang/crash that only happens in 2.12 (crash doesn't happen in 2.11). I am able to recreate it in 2.12 now. I run TDM in the Visual Studio debugger (using dev16829-10455). After starting the mission, I just wait a minute or so and the screen freezes. Then, I wait another couple of minutes, and the debugger reports a failed assertion. The assertion is: WARNING:ASSERTION FAILED! E:\games\darkmod_source212\idlib\containers\List.h(394): 'newsize >= 0' The callstack is: TheDarkModx64_debug.exe!AssertFailed(const char * file, int line, const char * expression) Line 75 C++ > TheDarkModx64_debug.exe!idList<idPlane>::Resize(int newsize) Line 394 C++ TheDarkModx64_debug.exe!idList<idPlane>::AddGrow(idPlane obj) Line 765 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 351 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FlowLightThroughPortals(idRenderLightLocal * light, idFlexList<int,128> * areaIds, lightPortalFlow_t * portalFlow) Line 495 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::AddLightToAreas(idRenderLightLocal * def) Line 2038 C++ TheDarkModx64_debug.exe!R_CreateLightRefs(idRenderLightLocal * light) Line 738 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::UpdateLightDef(int lightHandle, const renderLight_s * rlight) Line 423 C++ TheDarkModx64_debug.exe!idLight::PresentLightDefChange() Line 1076 C++ TheDarkModx64_debug.exe!idLight::Present() Line 1132 C++ TheDarkModx64_debug.exe!idEntity::Think() Line 2318 C++ TheDarkModx64_debug.exe!idLight::Think() Line 1274 C++ TheDarkModx64_debug.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds, int timestepMs, bool minorTic) Line 3366 C++ TheDarkModx64_debug.exe!idSessionLocal::RunGameTic(int timestepMs, bool minorTic) Line 3063 C++ TheDarkModx64_debug.exe!idSessionLocal::RunGameTics() Line 3109 C++ TheDarkModx64_debug.exe!idSessionLocal::FrontendThreadFunction() Line 3159 C++ TheDarkModx64_debug.exe!idSessionLocal::StartFrontendThread::__l2::<lambda>(void * x) Line 3235 C++ TheDarkModx64_debug.exe!unsigned int <lambda>(void *)::<lambda_invoker_cdecl>(void * x) Line 3236 C++ [External Code] The code in question: ID_INLINE int idList<type>::AddGrow( type obj ) { if ( num == size ) { int newsize; if ( granularity == 0 ) { // this is a hack to fix our memset classes granularity = 16; } newsize = (size * 3) >> 1; // + 50% size newsize += granularity; // round up to granularity newsize -= newsize % granularity; // Resize( newsize ); } list[ num ] = obj; num++; return num - 1; } size = 968651120, so newsize is calculated as -694506944, which causes the assertion. Obviously something is running away and the code ends up trying to resize the list to a size that is so big that it wraps around to negative. Is my mod doing something wrong that is leads to this? How do I track this down? I can supply the FM package if that will help. Or, I can set some breakpoints if there's something I can look at here. Thanks. Edit: Here's the FM: https://www.dropbox.com/scl/fi/3fg2x3w4owmku1l4gifi7/altham_crash.pk4?rlkey=z0q1gaflz5b7mifeuayoqmlug&dl=1 To reproduce the problem, start the mission (Easy difficulty), then just stand there. The guard will walk close to you but he shouldn't see you (you can always set the "notarget" console command to ensure he doesn't see you). After a few minutes, the game freezes. A few minutes after that, it crashes. Sometimes it happens in just a minute or two; other times it takes several minutes. But so far, it always happens eventually.
-
I think first mission one and two were A pawn in the game and The art of revenge. Then the campaign was introduced (which is still 3 seperate missions), which includes the prequel The angel's tear and the original missions got renamed. But I think this isn't correctly updated in the mission database. So here is a screenshot of vfat1 in the mission downloader: And here is vfat2 listed in the mission selection screen (after downloaded): Clearly this is the same mission. In the mission listing the darkmod.txt is used, in the mission downloader something else is used. But you're right that vfat1 is "The angel's tear".
-
2.10 Crashes - May be bow \ frontend acceleration related
Araneidae replied to wesp5's topic in TDM Tech Support
Don't know if it's helpful, but with the latest dev build (dev16818-10434) I had two or three crashes when head-shotting zombies while playing In The Black (forgotten the mission, will try and work it out). I was going to report it, because it seemed quite repeatable, all the crashes were in exactly the same location ... but then it went away. -
"ongoing" objectives don't get checkmarked at end of mission
thebigh replied to Skaruts's topic in TDM Tech Support
What I'd like to see is being able to review the objectives when the mission is over, as extra pages on the Mission Statistics screen. -
I am not sure but I believe that ReShade offers a temporal or morphological AA solution which might be much cheaper than using in-game MSAA. Given your high screen resolution, I am surprised that 8x MSAA isn't sufficient. One thing that MSAA doesn't cover is shader aliasing and transparency so cranking up to 16x won't help there. If ReShade doesn't have the needed options, you can also try forcing AA in your Nvidia driver settings. People complain about the blurry nature of FXAA but with really high pixel DPI it should have minimal degradation to image clarity. Try setting MSAA to 4x and forcing FXAA for transparency coverage and see if the results are acceptable. Depending on your aptitude with ReShade settings you might prefer it's SSAO and lighting mods... but I will humbly submit that you can improve the sense of scene depth with my own Fresnel Mod: https://www.moddb.com/mods/the-dark-mod/addons/fresnel-mod-211-unofficial Also you can achieve something similar to the ReShade HDR by modifying the r_postprocess cvars : https://wiki.thedarkmod.com/index.php?title=Advanced_TDM_Visuals_Tweaking Setting r_postprocess_colorCurveBias to something like 0.2 or 0.25 should make the game look more like your ReShade screens but obviously ReShade has many more customization options for color behavior so you have more control there ( with some additional expense due to increased shader parameters ). Note: Some options from that article are gone in favor of a newer bloom implementation controlled by r_bloom settings.
-
so I just downloaded the game but every time i boot it up it doesn't work my device is the ASUS x550c it only shows a grey screen i have the intel(R) Core I3 Inside and the Intel (R) HD Graphics 4000
-
Bug 1: In "The Accountant 2: New in Town": "Grab your gear" objective will not complete when using auto-frob. Individual clicking on each item completes the objective. To replicate: [spoiler] Exit starting room and head inside the room to your far right, next to a window. Pull the "lever" to open the secret door leading to your gear. See that auto-frobbing will not complete the objective, while individual clicking does. Bug 2: In "Cole Hurst 1: Eaton" Individual clicking leaves player with 3 functional maps, while auto-frobbing might result with only 1 or 2 of them usable. Auto-frobbing will cause player to pick up, but not acquire map items to inventory. To replicate: Upon spawning, drop to lower floor and pick up items on your table by individual clicking. See that you should end up with 3 separate maps, all of which become usable by "cycle maps" key. Now restart and pick up everything by auto-frobbing. Sometimes you are only left with 1 or 2 maps instead of the 3. If you keep your eye on pickup messages while auto-frobbing, you can briefly notice "acquired -", instead of "acquired (map item name)" You can also see that once first map is picked up, you might have to release the "frob" key and click again to pick up other maps, while other item types do not need the key to be released. Also, inventory item in the corner of the screen might say "special" with no visible icon.
-
That is like running TDM blind-folded and not nice to the user. Just Set the log-settings in the config file, to create a log. Or use the start-arguments to create a condump, all i mentioned earlier. Like: do keyboardshortcut: windows-key + r to display a command window enter a command and hit ok. (or run a console screen from explorer) c:\mygames\darkmod\thedarkmod.exe +condump mylog.txt +quit This to create a condump name mylog.txt at start end after this quit the game. (if c > mygames > darkmod is the location of the game folder) or do: thedarkmod.exe +seta r_useNewBackend 0 +seta r_useBindlessTextures 0 +seta r_glCoreProfile 0 +seta r_fboColorBits 32 (to set the settings nbohr1more mentioned)
-
https://wiki.thedarkmod.com/index.php?title=Console_Useful_Controls Try CTRL+ALT+ ^ or whatever key is in the upper left of your keyboard. If everything is still black, just try typing the command as if you did enter the console and see whether any file was created.
-
Here is my darkmod.cfg file. pressing CTRL+ALT+~ does not bring any console command.I only get a dark screen. But i can hear music. BTW:can i get this music in mp3 format?Its good. Darkmod.cfg
-
Before all the buttons of the failed screen become visible. I didn't wait long when it happened, so probably before the first button fades in. I have to try it again a few times.
-
And If you cant see the console, during that black screen. Then you to create a log using start-arguments https://wiki.thedarkmod.com/index.php?title=Debugging_TDM_systemerrors And see the following topic:
-
I can confirm this. The first time I tried it on "Collateral" everything worked fine. On the second try I didn't wait until all the buttons on the "Mission failed" screen appeared and after the quickload it replaced the main menu. So maybe it only happens if you reload within a certain time after the Fail screen comes up. Can someone try this?
-
Can someone reproduce? Make a mission fail. The screen with multiple options like restart mission appears. Hit quick load key. Let the reload end. Hit esc. See the mission failed screen again instead of main menu.
-
Here's another example. Klatremus' Mission 2: The Tears of St. Lucia video linked at 1:15:59. I've attached a series of images that show a regular view, a translucent view, a loading screen, a translucent view, and finally a regular view. To see it yourself, you can step frame by frame on YouTube by first pausing and then using the "." key to step forwards (and the "," key to step backwards). Just translucent images as well, so they can be seen a little more clearly.
-
Here's another example. Klatremus' Iris video linked at 1:33:01. I've attached a series of images that show a regular view, a translucent view, a loading screen, a translucent view, and finally a regular view. To see it yourself, you can step frame by frame on YouTube by first pausing and then using the "." key to step forwards (and the "," key to step backwards). Just translucent image as well, so it can be seen a little more clearly. The object inside the chest can be seen.
-
When quick loading, the screen usually flashes a little brighter and shows something odd for a brief moment before and after the loading screen. I had trouble seeing exactly what it was until I recorded it. The attached image shows a series of screenshots that show the regular view, what looks like some sort of view where objects become translucent, the loading screen, a translucent view again, and finally the regular view. Note: I recorded this with my phone, so the translucent view is showing roughly 2/3 of that frame due to the camera and monitor being out of sync. (Recorded at 60 fps, Game 60fps) Edit: The "flash" that is seen is from the objects/solids becoming translucent. When they are translucent, they appear brighter. This can be seen in the images. Bug: https://bugs.thedarkmod.com/view.php?id=6149 This site recompresses uploaded images, reducing the quality a lot. I've attached just the translucent image as well, so it can be seen a little more clearly.
-
When launching the game (from the OS desktop) with antialiasing turned on, there is a distorted frame before the main menu is shown. After the brief distortion, the main menu displays correctly and the game can be played without issue. I've included a photo of my screen that I took with a camera. With antialiasing turned off, I do not see any distortion when launching the game. Anyone else notice this or just me? Linux, Ubuntu 22.04 AMD Radeon RX 6000 Series OpenGL version: 4.6 (Core Profile) Mesa 22.0.5 core Bug: https://bugs.thedarkmod.com/view.php?id=6150
-
As of the title, If I turn on Ambient Occlusion, shadows are turned into pitch black. Cannot see things, It feels like being a real guard in the game. Any solution? AO is too nice, I want to keep this. (Turning it off is a simple solution for it, though) My gpu is AMD RX6700XT and its driver is almost latest version(adrenalin 22.9.1) Sorry for my poor English.
-
It's been like that for as long as I can remember, and I never really considered it a problem as such. This is a 3D game with constant mouselook — I expect it to grab the mouse while it is in the foreground. With in_grabMouse 1 I get a permanently grabbed mouse, as if I were playing the game exclusively. Bringing down the console releases the mouse, as does Alt+Tab or Super+Tab to another application. With in_grabMouse 0 the normal cursor displays on top of the window, in addition to the TDM cursor (if on a menu screen). If the cursor is moved outside of the window, the game stops receiving mouse events, which means there is a limit to how far you can rotate the player camera. This is probably useful for testing GUIs and menus but doesn't seem that useful for actual player navigation.
-
If you mean the Windows Smart Screen, it works in a very simple way: Files which are not known to the filter are being flagged as suspicious, and it warns the user from exeucting them. That's all there is to it really. You can happily click on "More info", and "Allow" after that every time. I'd rather upload the file to VirusTotal, as @stgatilov wrote above, because that will run the file through many, many antivirus engines, and, if that says it's clean, or if only 1 or 2 or 3 engines detect something (a false positive in that case), then it is clean.
-
@greebo, confirmed that works. Wonderful! But now some questions, starting with the .script side. I did play around with setGuiInt for a while, but then concluded that it (and other setGui... SDK calls) couldn't work, because inside the C++ code, it looks to confirm that the passed handle is in the m_overlays list. I kinda thought that a handle for a gui that was on a world object's surface would not have an overlay defined for it. So I'm confused again. Does overlay not refer to a 2D pane rendered in the same plane as the screen? When I was working with setGuiInt, since I wasn't instantiating the world surface gui myself, but relying on autoload, I didn't have the handle number, so I would find it using: string s; sys.println("handle hunt"); for (i = 0; i < 10000; i++) { s = me.getGui(i); if(s != "") // could do a better job of string comparison here, but works for test map { handle = i; sys.println(s); break; } } sys.println("handle =" + i); That was returning a value of 1. But what you seem to be saying is, the handle has to be 1 for the gui defined by "gui". True? And presumably that goes for "gui2" (handle = 2) and "gui3" (handle =3), but maybe not beyond that?
-
Models with missing textures, missing models showing up as black cubes, missing sounds, maps not loading due to missing scripts or broken entityDefs... the list could go on forever. This is why the TDM team is very conservative with modifying existing assets, especially renaming or relocating them, and only makes such changes after close scrutiny to make sure nothing that relies on these assets (both in core assets and any released FM) will break as a result. Obviously just fixing whatever you see in front of you produces fast and easy results, but it's unlikely someone else will do the remaining work to make sure it won't break things elsewhere.