Search the Community

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

Currently I temporarily play/work on a Lenovo X220 laptop Specs: CPU: Dual Core Intel Core i5-2520M Memory: 8 gb dual channel ram GPU: Intel hd 3000 Harddrive: 250GB ssd Monitor: 12.5 inch tft 1366x768 OS: Linux Mint XFCE External monitor: IIyama 24" AMVA

I think your view on this is somewhat biased. ips glow and background bleeding is monitor specific, just check reviews and you find plenty of models without the issue. Personally I own an S-PVA (60hz) and an AMVA (75hz) monitor and they play TDM just fine. Not sure if it is the same for playing hardcore FPS online (I do play other fps games on it, but just single player).

Hi guys, I want to buy a new monitor for playing TDM. Right now I have an acer aspire 5750G laptop with an HD LED LCD screen but It sucks at showing dark screens. Are there specific types of monitors that work well for the dark mod?

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

Congratulations on the release. I haven't dived deep in to the 211 version yet but I noticed more screen tearing in older missions (hazard pay for example) with vsync off. With 210 I always had vsync off and no noticeable tearing. Could though be my configuration or the recent gpu driver update. I have my monitor configured to 75hz and an old card gtx760 (planning on updating to gtx 1660 ti this spring).

Well, unlike the original Thief's, the TDM blackjacking always has been ultra finicky. It's still finicky (obviously, as there hasn't been changed anything under the hood about the hit mechanics), but, at least you get a clue now. I still missed yesterday though, when suddenly and immediate, the blackjack went down again, and I didn't have any idea why, once again. But, it's an awful lot better than before, because I actually know and can see now when I can safely blackjack the guard. TDS actually positioned the guard as well when you initiate the blackjacking. Not sure what the technical reasons behind that were. The hit box (if you can talk about that) wasn't nearly as precarious as in TDM as well. Now that you can see when you actually can safe knock out a guard in TDM, you can see how precisely the distance and angle has to be. Which is pretty awkward, considering that you can't really judge distances on a single monitor. It's not 3D in the same way as VR.

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

I've been meaning to broach this topic for awhile but I know it's a sensitive area so I've put it off for far too long. Calibration is very important and is especially important for developers. How many times have we seen comments like "that screen is too dark", "the ambient_world in your map is too bright" (etc). Without a consistent standard, all these judgements are fairly arbitrary. Now calibration is not a cure-all because different displays still have different capabilities but it's the least we can do to attempt to ensure some sort of standard is in place. Here are some calibration sites: http://epaperpress.com/monitorcal/index.html http://www.lagom.nl/lcd-test/ Please attempt to calibrate as best as possible and (if you are willing) take cellphone or camera shot of your screen to show how close it is to ideal calibration. Or at least chime in with a "Calibrated" post. Thanks! Time for me to fiddle with calibration lest I be a hypocrite

Yeah that crashes for me also. I run fullscreen so that I can run TDM at higher than native resolution, have a 1080p monitor but run TDM at 1440p. Minimizing it in task manager as described crashes TDM. Game crashes in FrameBuffer.cpp @ line 337 void GL_ScissorVidSize( int x /* left*/, int y /* bottom */, int w, int h ) { // get [L..R) ranges int x1 = x; int y1 = y; int x2 = x + w; int y2 = y + h; // convert to FBO resolution with conservative outwards rounding int width = frameBuffers->activeFbo->Width(); int height = frameBuffers->activeFbo->Height(); x1 = x1 * width / glConfig.vidWidth; y1 = y1 * height / glConfig.vidHeight; x2 = (x2 * width + glConfig.vidWidth - 1) / glConfig.vidWidth; y2 = (y2 * height + glConfig.vidHeight - 1) / glConfig.vidHeight; <<<----------------Crashes here. // get width/height and apply scissor GL_ScissorAbsolute(x1, y1, x2 - x1, y2 - y1); Unhandled exception at 0x00007FF6712A5F1E in TheDarkModx64.exe: 0xC0000094: Integer division by zero. Stack Trace > TheDarkModx64.exe!GL_ScissorVidSize(int x=0, int y=0, int w=0, int h=0) Line 337 C++ TheDarkModx64.exe!RB_SetDefaultGLState() Line 82 C++ TheDarkModx64.exe!RB_ExecuteBackEndCommands(const emptyCommand_t * cmds=0x000002cd723e9080) Line 842 C++ TheDarkModx64.exe!R_IssueRenderCommands(frameData_t * frameData=0x00007ff6728840a0) Line 145 C++ TheDarkModx64.exe!idRenderSystemLocal::EndFrame(int * frontEndMsec=0x0000000000000000, int * backEndMsec=0x0000000000000000) Line 648 C++ TheDarkModx64.exe!idSessionLocal::UpdateScreen(bool outOfSequence) Line 2782 C++ TheDarkModx64.exe!idCommonLocal::Frame() Line 2544 C++ TheDarkModx64.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance=0x0000000000000001, char * lpCmdLine=0x000002cd562c8dc5, int nCmdShow=0) Line 1151 C++ EDIT: I get the exact same crash whether using windowed, fullscreen or borderless

I just found this thread on ttlg listing Immersive Sims: https://www.ttlg.com/forums/showthread.php?t=151176

Recently revisiting the forums after a longer period of time I wanted to check the unread content. I don't know if I am doing this wrong since.. ever... but on mobile (visiting the unread content page on my smartphone) you have to click on that tiny speech bubble to go to the most recent post in a thread. If you don't click correctly you'll hit the headline and end up at post 1 in the beginning of the thread. It's terrible on mobile, since not only the speech bubble is really small and was to miss. But also the thread headline is just millimeters away from it so you go right to the first post that was ever made instead of the most recent ones. Am I doing it wrong? I just want to go through u read content a d the to the newest post from that topic.

A@datiswous Ah yeah, well sorry, I was quiet busy and only visiting discord. First time here on the forums since months now I think.. Thank you for the subtitles. I encourage everyone who is interested in using them to download it from here as I'm not sure when I'll be able to implement them myself into the mission. Again, thank you for your work.

Not sure but non-primary monitor support is not yet fully implemented in TDM: https://bugs.thedarkmod.com/view.php?id=4430