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 edited my previous post with the updated log. I can only dump the log when I'm on the first screen after loading the mission. The console won't open when the screen goes black.
  2. Don't need the DMAP log. Just open TDM, try to run the mission as normal. When you get to the black screen, then drop down console.
  3. Still this lol. The console will usually show the cause of such issues, black screens are sometimes caused by failures to load textures or gui files etc.
  4. Ok, apparently the problem isn't solved. The mission worked fine on my laptop, when trying again on my desktop, I get the same issue. I have tried reinstalling the Dark Mod with no luck either. When deleting the mission from the fms folder and just loading the mission from console, everything works fine as it should. It is only when I make a .pk4 file and load it via new game that I get the black screen when hitting objectives... When I put that .pk4 mission in my laptop, it worked fine... very confusing...
  5. I know that engine is the most modern but also more similar to the original one, it has full support for all vanilla idtech 4 features and tools, for example the vanilla GUI system, where all engines based on Doom 3 BFG source require Flash, at lest for fullscreen GUI's. There's other stuff on it that is cool has well imo, support for Qt GUI based tools, for example the fhDoom engine light editor is made with it, and looks very nice imo, unfortunately is the only converted tool for now plus i don't know if you can do game based GUI's with it. It also has direct support for GLSL shaders, their usage in materials is very similar to the ARB ones. Btw MirceaKitsune is just a technicality, but fhDoom has support for Parallax Occlusion Mapping or POM (off by default), that is a different tech from Parallax Mapping, that is a older and imo uglier technique (makes everything look like molten glass), POM is similar to Horizon Mapping for example. Also vanilla Doom 3 has support for POM as well but you need to install a modified ARB interaction shader, if i'm not mistaken SIKKmod has one, POM also requires a bump map (black and white texture) in the case of fhDoom that bump map most be put onto the alpha channel of the specular map, btw not confuse with the bump keyword for TDM materials that only convertes a bump map into a normal map.
  6. I'm having a weird issue where I get a black screen whenever I click on objectives before jumping into my mission. I'm not sure what's causing this, and can't find anything on the wiki/forums on this glitch. Any help is appreciated.
  7. That was weird. The difference between vsync on and off was basically that when it was on, it looked more or less as if it was off, just without screen tearing. Only when I used com_fixedTic 1 command, the movement was smooth again. That helped, thanks.
  8. the texture files are not the same size so it looks like one has been altered. maybe the alpha channel has been removed on the later texture. it might depend on a texture editor some use 0 as transparent value and some use 255 as transparent value, if they've been swapped then the alpha channel would appear black.
  9. In 2.05, this model: models/darkmod/nature/bush_small03.lwo using this skin: nature/long_grass_lightyellow_dense displays correctly. In 2.06, the same model with the same skin displays the alpha channel as a black texture. First image is 2.05, second is SVN. Could someone with materials knowledge please figure out what's been broken since releasing 2.05? I took a quick look and didn't see any differences in the material or skin definitions, or the tga file for the grass texture. Other bush skins might have the same problem. The bugtracker issue is #4511.
  10. So, I've been having an issue: I keep freezing on the loading screen for missions. There's no real pattern to it, it just happens on random missions, including ones that I've played before without issue. I don't think it's me not giving the mission time to load, I usually wait about seven to ten minutes of the loading bar not moving at all before I do anything, and again, it's happening on missions I've played before without issue. Anyone else had this?
  11. Check that you do not have epifire's custom materials in your TDM's directory. In the 2.05 update a fair amount of his models got added in so now you'll be having two different .mtr files defining the same thing, which throws an error. Don't worry about "Unable to load texture: _default", these are arguments that make automatic textures in the material files. _black, _white and _flat produce uniform black, white and normalmap colors, respectively. _default either isn't supported or isn't defined in TDM, yet some .mtr file somewhere still probably refers to it.
  12. Yes. You can go that far. Most folks wouldn't wanna lose bump map altogether but it's an option. If you use regular image_downsize make sure Postprocess is off or the screen will be black.
  13. So the good news, the updater didn't give me problems this time. Bad news, when I start The Dark Mod, my screen zooms in and the game is just in a window. It works fine from what I can tell, but I'd like to know how to get it out of that windowed mode. Anyone else had this happen?
  14. Part of this Noodle is how the mapper has setup the ambient darkness levels in their map. By default most mappers here will have this base, "darkness threshold" well within a comfortable spectrum for their play style. The problem is that some players like a darker ambient than what was decided to ship with the map. What you're talking about is something of a hard mix filter for the screen. I think it would be a great addition, but I'm not sure that can be harnessed with the current graphical methods in TDM. A more likely option would be the ability to override the ambient darkness values (since I think there's specific code to target that entity by name?) with a parameter that ensures values would be no brighter than x or darker than y. I could be all wet about that, but I'm pretty sure that's the only method that could work effectively for user customization.
  15. I've played my far bit of TDM missions with gamma on 1 and brightness on 1 and I finally noticed how easy it would actually be able to see the player sneaking around in the dark if there was another player walking around as a guardr. So I finally decided to give the gamma and brightness guide in the training mission a fair amount of effort to get the "best" settings for an immersive experience. After a couple minutes of re-reading the guide and fiddling around with the sliders I was never satisfied. When I was sitting in the corner to the right of the book I kept the darkest corners of the room and the torch in my FOV. When I got the dark corners dark enough to the point where I could barely make out the individual bricks (e.g. "realistic"/immersive), so that if I was a guard looking in that corner I wouldn't see shit if the player was sitting there if I'm just strolling by like most guards in the game, but the torch was incredibly dark or the colors were messed up. So I was thinking, what if there was 2 sliders, one that basically made the "darks" darker and the "lights" lighter individually. I think that contrast basically does what I just said, but if you want to have near black corners e.g. "realistic" to the point where if a real person was walking by that hallway they wouldn't see you, the flaming torch is now going to give off just as much light as a zippo. Anywho I don't even know if its possible to have a slider that just adjusts the dark areas of the game and another for the light. If anyone knows what I'm missing when trying to get the brightness right some help would be greatly appreciated.
  16. It's not just you. I challenge everyone to compare the readability of the top (unselected) line to the bottom (selected) line in this typical mission "purchases" screen: It gets even worse when you're trying to select the screen resolution in the video configuration menu and the current resolution happens to be something other than your LCD monitor's native resolution. White text on a tan background is just a horrible choice.
  17. no need to explain so i finally got the updater to work right and then switched to the nvidia driver and the game works great. i may have to tweak settings simply because it is running the GPU hard and the fan is nuts, but that is not due to the game itself, but the display setup is what i suspect. it is kind of annoying but the problem lies with the fact that it is a laptop, and i have a secondary monitor since the main one went out. if i could figure out how to completely bypass the built in monitor then it would probably behave much better, but i guess i may have to start saving for a refurb desktop from new egg or tiger direct. EDIT: ok, something new to add, for those who want the game to go to their external monitor in linux machines. If they use their Nvidia control panel or equivalent, and save to a new xorg config file, then they can force the laptop monitor off, and make the secondary the primary monitor in the xorg settings, which will allow the game to play in full screen on the external monitor, and the GPU will run a lot cooler. I was having issues with the graphics due to the fact i could not run it in full screen because it was forcing the laptop monitor back on (albeit without the back-lights behind the LCD, so basically black with faint details) and until i adjusted things i had to try playing in windowed mode, which is not very GPU friendly. Still have yet to figure out the controls and what the objective really is in the first mission, but i know it runs ok. I got killed by the first two guards. Now i have to find out if i can balance the graphics settings just right for better eye candy.
  18. (the screen went black for a few seconds and Dark Mod didn't actually started, just saying, because I don't know if that was supposed to happen) logmysound.txt: http://pastebin.com/XCDPQUxa
  19. OK, after a few days of slow, careful, investigation as time was available, I think I've finally got a reasonable handle on the Linux crashes I've been seeing when running TDM 2.05-beta (and, as it turns out, when trying to run the hacked build I'd made from "latest SVN"). TLDR: Duzenko's "lightgem" patch (added via SVN rev #6635, specifically the portion that went into 'renderer/RenderSystem.cpp', BugTracker #4395) needs "hardening". The consistent crashes I've been seeing right after pressing "attack" on the "Press 'attack' to start the mission" screen is indeed coming from the performance-enhancing "lightgem patch", but it's not where we were assuming. That is, it's in a 'memcpy()' call, but not the one that's directly in the patch. It seems to be in a 'memcpy()' call being executed as a result of a call made by the patch to this OpenGL library routine: qglReadPixels(rc->x, rc->y, rc->width, rc->height, GL_RGB, GL_UNSIGNED_BYTE, 0);This is based in part on evidence from examining the source code from the Mesa implementation of OpenGL. But the reason TDM is crashing in that routine is because of one of several undetected 'GL error' conditions in a few of the earlier GL-related calls added by the patch, with 'qglBindBufferARB()' being the 1st of several that actually fail. (This all took me a while because I had to learn enough OpenGL to make sense of things. I've never been a "GL guy" and hadn't even looked at any OpenGL code in over 13 years!) Gory details: The failure of the initial 'qglBindBufferARB()' call, because of the use of the 'GL_PIXEL_PACK_BUFFER' enumeration as the 1st parameter, means that the 'qglReadPixels()' call's last parameter (0 in this patch's case) is NOT representing what the patch author thinks it is! Without the earlier GL calls succeeding, this call basically tries to pass a buffer location 0 (rather than the expected offset of 0) to the 'qglReadPixels()' routine which tries to 'memcpy()' using that bad pointer, resulting in the segmentation faults that I'm seeing. So, the proper fix for this is to "harden" this patch's code by replacing the useless "if (1)" check with a check for GL 'pixel pack' capability. For optimal speed of execution in the area of the patch, there should be some code added to the part of the TDM code (presumably in 'R_CheckPortableExtensions()', in file 'renderer/RenderSystem_init.cpp') that checks for GL capabilities once, at GL initialization. Then that flag should be used in place of the existing "if (1)" check. I've been running with this part of the patch disabled and have not encountered a single crash under Linux (using mostly 32-bit Slackware 14.2 but also testing briefly, both compiled and running, under 32-bit Slackware 13.1). I want to do more testing (with more missions than just "Closemouthed Shadows" and "The Outpost"), but so far, all has been fine, so I'm reasonably confident in my recommendations here. For the record, I've seen no crashes like Baal has seen, so I still think that we must be prepared for that to be a different issue. In retrospect, this patch should really not have gone into SVN. It was exactly the sort of "GL time bomb" that I mentioned in my previous post, awaiting an innocent victim with the right hardware+driver combination to come along. I wonder if there are other such 'GL time bombs' in the code. I hope not. Some additional thoughts: As mentioned in my previous post, my GeForce 7600GT video card and 32-bit nVidia 304.132 driver advertise (via the 'glinfo' app) what appears to me (maybe naively) to be the necessary capability ('GL_EXT_packed_pixels') to successfully implement a call like this one in the patch: qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);And yet it consistently fails on that call with the GL error "GL_INVALID_ENUM", meaning that the use of 'GL_PIXEL_PACK_BUFFER' is not a valid case on this hardware+driver setup! So I don't think that the "GL capability" check that gets added to the GL initialization process should use the presence of 'GL_EXT_packed_pixels' as a "green light" to make such calls. I think it's far safer to do a sample, 1-shot "qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);" call and check the GL error condition, setting the "packed pixel capability flag" accordingly. As an aside, I also tested with the same exact hardware, but using 2.05-beta under Windows XP. It runs fine there, which tends to make me suspect a video driver issue rather than the video hardware. Regardless, the patch needs hardening. So, if you folks can wait for duzenko to return and harden this patch, then I'll move on to looking into Baal's crashes (to the extent possible, with relatively little information). If not, I could try to come up with a patch to harden this "lightgem" code myself. Just let me know. For anyone who's made it this far, sorry for the lengthy explanation. But I like to be thorough and I like to have things well documented. If I've missed anything, please let me know.
  20. On a TDM where DbtR isn't already installed ... I only see one version on the in-game download screen, dated Sept 25 2016. When I select "More", it says it's version 3. When I download it in-game, it describes itself as version 3. There's no version number on the load screen. Once I start the mission, missions.tdminfo has this entry in it: tdm_missioninfo river{"downloaded_version" "3""last_play_date" "2016-10-26"} On a TDM where DbtR v1 is already installed, and I've played it, missions.tdminfo has this entry in it: tdm_missioninfo river{"downloaded_version" "1""last_play_date" "2016-10-26"} I only see one version on the in-game download screen, dated Sept 25 2016. When I select "More", it says it's version 3. When I download it in-game, it describes itself as version 3. There's no version number on the load screen. Once I start the mission, missions.tdminfo has this entry in it: tdm_missioninfo river{"downloaded_version" "3""last_play_date" "2016-12-16"} So, on my system, everything's working as expected.
  21. gcc: gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3 scons: script: v1.2.0.d20100117.r4629, 2010/01/17 22:23:21, by scons on scons-devengine: v1.2.0.d20100117.r4629, 2010/01/17 22:23:21, by scons on scons-dev ------------------------------ 2.05 has already been branched from the trunk. After some fixes I needed to get from duzenko regarding source changes he made, I have no problem compiling 2.05 on my virtual Linux box. We do have a Linux crash that was reported after the load screen of any mission, which is new w/2.05. Hopefully the Linux folks can figure that out, otherwise I'll prolly have to revert the source code back to a working version. Any improvements you make will be included in 2.06; I don't wish to make compilation changes at this late date unless they're going to fix a problem discovered during 2.05 beta that prevents the game from running on Linux.
  22. Disabling vsync did nothing. I cleared the config and nothing really changed other than the resolution becoming tiny. However, in this lower resolution, if I fiddled with the mouse enough, then it actually would eventually come across the small screen, however, it had extremely.....wonky.....sensitivity. Here is a pastebin of the command you recommended me to use: http://pastebin.com/ZMrVvtCm
  23. Its safer to change the game screenresolution inside the game, instead of changing this in the config file. So please delete file "darkmod.cfg" in your tdm-folder and run tdm again (to generate the config file with standard values). Check if the mouse problem still exists. if not, set the game screen resolution and play tdm. If the the mouse problem still exists, some user solllutions are Disable vsyncReinsert mouse cableDisable compiz(I searched with https://www.google.com/search?q=doom+3+linux+mouse+lock&oq=doom+3+linux+mouse+lock ) And does the console or log show something? Can we see some logs created using some console commands and startup arguments, mentioned in/starting from crash in training arena, #entry 396389 (instead using the tdm-launcher, use your terminal. In your terminal window, navigate to your darkmod folder and run the tdm binary with some arguments. For example: ./thedarkmod.x86 +gfxinfo +condump mylog.txt +quit)
  24. I'm running antergos linux. The game is installed, I've changed my resolution in the config file, and everything seems fine, until I load up the game. As soon as I get to the opening menu, my mouse locks to the edges of the screen, and it's nigh impossible for me to move it anywhere else. I've looked through a ton of different articles but nothing seems to help. A fix would be greatly appreciated. I cannot use the ingame config because I can't move the mouse to click on anything. I've tried running it in windowed only to have the same thing happen. I've posted this same thread on reddit but didn't really get a lot of help.
  25. i think i found what caused crashing. I clicked left mouse button when player dying (tilt reddish screen showed up) the game crashed btw, dump file size is about 1.2gb. is there any proper cloud-thing to upload this?
×
×
  • Create New...