Search the Community

I was so enchanted by this FM, I had to sign up to the forums the same day I finished it to come thank the authors Genuinely, truly incredible work! I was so overwhelmed in places that I resorted to just shouting joy at my monitor two, three, maybe four entirely separate times while playing. Exploring, puzzling, finding something new, trying to use it, and finding it does a whole new, separate, wonderful thing! There aren't enough words inside me to describe the feeling. It was breathtaking. I don't have any specific feedback that hasn't come through this thread before Thanks so much for making this, for all the inspiration and ingenuity and effort it took. If I never play another level this good, in any other game, in my life, I'd be fine with that.

Regarding packaging. The easiest way is to take some existing build, then use zipsync patch to overwrite some of its files. Before that, you need to do zipsync normalize + zipsync analyze to create a small package from the files you want to overwrite. Regarding server. Yes, you need to make it available on any HTTP server. The HTTPS protocol requires an additional TLS library to make it work, and tdm_installer does not include one currently. To be honest, I don't understand what's the benefit of forcing HTTPS for statically hosting a bunch of files. HTTP 1.1 from 10 years ago works perfectly well today, while in HTTPS they release new version of TLS every so often, then declare the old one as insecure, then block all software from working with it, breaking tons of websites. Maybe I should just add TLS to tdm_installer and allow https:// kind of URLs. Although it can cause even more confusion because people will write https:// instead of http:// and be surprised that it does not work. Regarding installing it. Yes, the user needs to go to "Custom Version" screen, paste the URL of your build and select which stock TDM version it was based on. That's because stock versions have yet another manifest which describes all dependencies between them, but your custom version does not. Regarding shaders. I have been changing shaders extensively, including some changes after the most recent dev build. You need to combine engine with the shaders of the same version. So if you build executable from latest SVN but use glprogs from dev build, then they won't work together. You need to copy glprogs directory from you darkmod_src repo to your zipsync patch, so that your package includes them as replacement. That is rarely a problem today, but now is a particularly unlucky moment.

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

Do you mean through my graphics control panel or through an ENB-type program (like ENB or ReShade)? I don't change anything in my graphics panel, nor use any ENB-type program when running TDM. I want to keep everything on my end as neutral as possible to see what TDM looks like as-intended. That way I can try to enhance something ("try" being the operable word ) without getting too ham-fisted about it. If I had ENB shaders and what-not running to drastically change colors, then I could be modifying the lighting shaders to benefit what *I* see, but when others use it it could look awful. If you're instead wondering why my shaders seem to be a bit more "colorful" (colors are a bit more saturated / enhanced.. like torch lights)... That's b/c specular is faked & added to more things. If a surface doesn't have a built-in specular map texture, I fake it by making a grayscale out of the diffuse rgb color texture. But, I apply it differently in ambient (shadow) vs. direct (torch, lantern, etc) lighting passes: Ambient ... fake spec gets multiplied by 1 - color texture (inverted color) to make it a dull shine before adding it to final ambient light mix. Direct ... fake spec shine added to surfaces was making them too shiny (like everything had car clear-coat on it reflecting light .. EG: bricks were having a bright shine come off them). So, as an alternative, I multiply the spec dot (specular intensity) by the fake spec map, then add that to the light dot (light intensity) which gets multiplied by the color texture. This turns the fake specular into a color enhancer. Also, the original shaders were taking the real specular values (EG: for metal surfaces), and multiplying it by ... (diffuse * 0.25 + vec3(0.75)) This would add in a bit of the color texture, but not too much. My shaders don't do that.. but I'm probably going to add it back in, b/c on some metal surfaces (eg: metal banding on some doors) the light shine is very colorful (eg: the reflection looks glowy yellow, and sort of sticks out like a sore thumb). Shaders are art and science.. can apply the math, but need to tweak based on what looks goods. The other thing is the rimlighting is applied to more things in ambient lighting. There's a parameter set for rimlighting, but, while testing, I didn't see it set, so it wasn't getting done. It could be that this is a feature that will be used in the future, so they built-it out in the shaders now. But, I decided to create a fallback method to do rimlighting if that parameter isn't set. The rimlighting uses the parameter color value if it's passed in, otherwise it uses the (once again) color texture value to enhance the lighting. This might enhance the color of surfaces in shadows a bit. But, the main goal is to make things in shadows have a bit more body / depth to keep them from flattening out too much, and also help the player see a bit better in very dark areas. (The rimlighting acts as a very faint "echo vision" highlighting objects in the dark.) TDM does a gamma correction toward the end of the lighting passes, and does an HDR (high-dynamic range) in the post-processing passes for frames. You can adjust gamma & brightness, but not HDR or color saturation inside the game. The HDR just boosts the range of colors, but keeps them inside a range that's displayable. It's just working with the colors already there. Not sure I answered your question.

Sound shaders used in conversations are given the reverb effect defined in the associated efx file for the defined info location. If you have a room with an intense reverb (example: efx cathedral), then the voice files are sometimes not easy to understand. If you could use a different reverb for the voice files (then maybe exf Medium Stone Room), it would be more understandable again. Question: Is it possible to define a different reverb effect independent from the Info Location for such voice files? It wouldn't help if I converted the voice files with a more "understandable" reverb using an editing program, because the defined room reverb via the Info Location would still be applied, which would probably only make things worse. @nbohr1more

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

If I understand correctly, there is a specific light shader which does not respond to colour or brightness adjustments? This is something light shaders can do, for example there are certain shaders which use a fixed colour or texture (possibly animated) which are not intended to be controlled via the color spawnargs. Definitely not a DR problem as Greebo says, and it may not even be a "bug" as such, since it is up to the shader author whether a particular shader responds to colour (I wonder if the "_cv" suffix means "colour variable" or something, but that's a wild guess). One could argue that this is a usability issue however. Perhaps we need some better organisation of light shaders, to distinguish the generic shaders which respond to colour and can be used anywhere, and special-purpose shaders which may have fixed colours or textures and are designed for specific purposes like association with a particular entity?

OK I think I've got to the bottom of this. I've created this forum thread (with bug report): https://forums.thedarkmod.com/index.php?/topic/22221-bug-drowning-ai-in-shallow-water/ I can apply a workaround, although it won't be perfect and the bug itself needs fixing in the engine. There are a few other things that need fixing so will put an update together soonish.

If any mappers have encountered weirdness with kill objectives not working with drowning AI, I think I've found out why. I don't think it would be a particularly difficult one to fix either. I've raised this bug report: https://bugs.thedarkmod.com/view.php?id=6323 Some context here: https://forums.thedarkmod.com/index.php?/topic/21837-fan-mission-the-lieutenant-2-high-expectations-by-frost_salamander-20230424/&do=findComment&comment=487316 I think this is a bug, but just raising here in case some people think otherwise.

Like AluminumHaste said MSAA is for edge of geometry/polygons, if you want to affect textures/shaders/transparencies, you need to use a post-process AA like TAA (it will blur the scene a little contrary to old school MSAA thou). You can use Reshade for TAA. Ops: MirceaKitsune sorry you already knew msaa was for geometry only, didn't read your reply well sorry...

Overall these changes sound excellent. You have correctly (as far as I can tell) identified the major issues with the DR renderer and proposed sensible solutions that should improve performance considerably and leave room for future optimisations. In particular, trying to place as much as possible in a big chunk of contiguous RAM is exactly the sort of thing that GPUs should handle well. Some general, high-level comments (since I probably haven't even fully understood the whole design yet, much less looked at the code). Wireframe versus 3D I always thought it was dumb that we had different methods to handle these: at most it should have been an enum/bool parameter. So it's good to see that you're getting rid of this distinction. Unlit versus lit renders As you correctly point out, these are different, particularly in terms of light intersections and entity-based render parameters (neither of which need to be handled in the unlit renderer), so it makes sense to separate them and not have a load of if/then statements in backend render methods which just slow things down. However, if I'm understanding correctly, in the new implementation almost every aspect will be separate, including the backend data storage. Surely a lot of this is going to be the same in both cases — if a brush needs to submit a bunch of quads defined by their vertices, this operation would be the same regardless of whatever light intersection or GLSL setup calculations were performed first? Even if lighting mode needs extra operations to handle lighting-specific tasks, couldn't the actual low-level vertex sorting and submission code be shared? If double RAM buffers and glFenceSync improves performance in lit mode, wouldn't unlit mode also benefit from the same strategy? I guess another way of looking at is is: could "unlit mode" actually be a form of lit mode where lighting intersections were skipped, submitted lights were ignored, and the shader was changed to return full RGB values for every fragment? Or does this introduce performance problems of its own? Non-const shaders I've never liked the fact that Shaders are global (non-threadsafe) modifiable state — it seems to me that a Shader should know how to render things but should not in itself track what is being rendered. Your changes did not introduce this problem and they don't make it any worse, so it's not a criticism of your design at all, but I wonder if there would be scope to move towards a setup whereby the Shaders themselves were const, and all of the state associating shaders with their rendered objects was held locally to the render operation (or maybe the window/view)? This might enable features like a scrollable grid of model previews in the Model Selector, which I've seen used very effectively in other editors. But perhaps that is a problem for the future rather than today. Winding/Geometry/Surface Nothing wrong with the backend having more knowledge about what is being rendered if it helps optimisation, but I'm a little unclear on the precise division of responsibilities between these various geometry types. A Winding is an arbitrary convex polygon which can be rendered with either GL_LINES or GL_POLYGON depending on whether this is a 2D or 3D view (I think), and most of these polygons are expected to be quads. But Geometry can also contain quads, and is used by patches which also need to switch between wireframe and solid rendering, so I guess I'm not clear on where the boundary lies between a Winding and Geometry. Surface, on the other hand, I think is used for models, but in this case the backend just delegates to the Model object for rendering, rather than collating the triangles itself? Is this because models can have a large variation in the number of vertices, and trying to allocate "slots" for them in a big buffer would be more trouble than it's worth? I've never had to write a memory allocator myself so I can can certainly understand the problems that might arise with fragmentation etc, but I wonder if these same problems won't rear their heads even with relatively simple Windings. Render light by light Perfect. This is exactly what we need to be able to implement things like shadows, fog lights etc (if/when anybody wishes to work on this), so this is definitely a step in the right direction. Overall, these seem like major improvements and the initial performance figures you quote are considerable, so I look forward to checking things out when it's ready.

v 0.14 Switched fake AO & fallback Spec maps to use dot(raw normal map, 0.33) in both ambient & common fs. Switched specular over to use diffuse.rgb color as specular color if no specular.rgb / map texture instead of default static value Normals as fake maps... wasn't happy with how over-dark some things were, eg: the pillars on BikerDude's Training MIssion, when using dots of specular or diffuse as fake maps. So, decided to check out normals instead. I knew normals provide edges to help create the bump-mapping. However, using the normalized & TBN'ed version, I got some surfaces that were pitch black. But, when I dotted the raw normal, I got this... This is a more even-tempered grayscale map for the whole scene. (cut-off seam are from piping the dot product straight through w/o light impacting it). Compared to this... Which was using dot of specular map if it had it, otherwise using dot of diffuse. The over-darkening can possibly be considered a half-arsed materials type of variation on surfaces. But, I'd prefer all surfaces having a more even grayscale to them for a fake AO / specular. Reason being.. I got aggravated with FUEL when vehicles and riders would look over-dark in overcast skies. They looked out of place. Couldn't figure out what the deal was until I piped some materials lighting values directly through, and realized they were applying a default dark gray to some objects lighting.. which over-darked them. When I ripped that out, it was easier to blend things together to look more natural in a scene. (crappy base "materials lighting" FUEL game piped to shaders, which made some things over-dark in overcast skies) So, decided to go with the more equalized fake AO / Specular map. The variations in detail should come from diffuse color, lighting, etc, not from drastic differences in fake maps. (The fake maps are crutches. Shouldn't create drastic differences.) Diffuse for Specular Color TDM shaders did variations on this, mixing in diffuse*0.75+0.25 and such to specular. I pulled that out when I decoupled specular from diffuse, because ideally specular shine amount would be set per-surface / texture. So, dull objects would have a dull shine to let more diffuse color mix in. But, there's static params in the shaders setting amount of specular to use. For shiny metals, it looks ok having white shine come off. But, dull rusty pipes, walls, etc.. not so much. So, if the specular.rgb is missing (which acts as both specular map and specular color), I made the shaders fallback to using the diffuse.rgb as the specular color. Using diffuse as-is, everything looks wet like it's raining or just rained. So, toning it down... Diffuse * 0.1 as fallback spec color. Now it's looking normal again. The color variation is more noticeable in shadows, b/c both specular fallback color and fresnel highlight fallback color rely on diffuse colo rnow. So, the brick is a darker highlight. The bronze metal is more orangish. The white metal door is grayish. Vanity shot... fake AO is darkening seams more now while leaving the "body" of objects to shine through. (IE: the stones on the ground are now having a bit easier time having their highlights on top show up, b/c the normal map as fake AO is more interested in darkening the already dark seams between stones. But, the wet-looking speculars brings up the idea of using a value piped in from the game engine to lerp between dry and wet specular values if environment is raining / damp or not. I'm not sure how level designers flag areas to do rain, or if the value could get piped into the shaders. But, it could create more dynamic environments. EG: walking in the streets in rain, and the streets look wet. Then walk inside some place, and the inside uses dry speculars. The next step on that would be to mix in environmental reflection to make the rain sheen look more rain sheeny. (Because just over-shining speculars tends to make a cheap but tacky wet look.) outval = mix( dryval.rgb, wetval.rgb, vec3(rainamount) ) (EG: The dark rain sheen on the road ahead and the white sheen on the tires is from a cubemap reflection that increases as the game engine's rain value increases, which is used as a lerp factor between dry and wet shading. The FUEL game engine piped in a rain value, and did cubemap reflection for water fresnel reflection. I just put them together in other object shaders to create rain effects on ground, vehicles, etc.) Anyways, shaders are attached. glprogs.stages.interaction.014.zip

Author note: It's hard to believe it's already been a year since Act 1 came out! Well during this mission the player will be following Corbin into the Grimwood district to followup on a lead from last night (Act 1) .. the mysterious tablet! This mission is my first time including full EFX support as well as a HD briefing video file, additionally a new script has been added crafted by the talented Obsttorte which has loot flying towards the player when you pick it up. On a level design front I have tried to change things up a bit by really catering towards a number of play styles, this mission can be completely ghosted or you can use the tools at your disposal to wreak havoc on the citizens of Northdale. For the first time I have tried to create more sandbox environments which don't offer clear answers handed directly to you, so if you're having trouble figuring something out try a different method. This mission takes between 1 - 2 hours to finish depending on the difficulty you play on and how thoroughly you explore. I hope you enjoy your night in Northdale! - Goldwell Voice actors Fen Phoenix Goldwell Random_taffer Yandros Beta testers Amadeus Boiler's Hiss Cambridge Spy Chakkman Crowind Epifire Kingsal SquadaFroinx Custom Assets Andreas Rocha DrK Epifire Grayman Kingsal MalachiAD Obsttorte Sotha Springheel SquadaFroinx Purgator With special thanks to Epifire for creating a large collection of custom models, Grayman for helping out with coding, Kingsal for drawing the ingame map and Moonbo for his script revision on the briefing video. Available via in-game downloader MIRROR File Size: 417 mb EDIT: If you are having performance issues please consult this post by Nbohr1more which may address your issue http://forums.thedarkmod.com/topic/19936-fan-mission-shadows-of-northdale-act-ii-by-goldwell-20190320/page-2?do=findComment&comment=436271

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

Hello TDM-ers. I am encountering an issue where textures seem to partially disappear. I tried searching the forums, but, I don't know what to search for. The missing textures are a worldspawn brush acting as a roof with {for now} flat iron texture. There are other worldspawn brushes right below to create an attic ceiling with roof framework board texture. These gaps appeared a few edits ago. I can't "undo" to get back before whatever edit did this. The gaps are only visible during play and are not visible during editing. Closing and reopening DR and TDM do not fix anything. Some of the brushes overlap in areas behind the play area but I have never seen an issue doing that. The attached image has the effect I am now seeing. Ideas on where to start debugging this? Very much appreciated. Clint

(I apologize for the odd poll question layout. I wasn't able to add five yes-no questions, because polls are limited to three questions.) Hi everyone, I've recently been working on some patches for issues that I've read about from players on the TDM and TTLG forums — and Discord. My goal is to make it as easy as possible for players, especially new players and those who need usability/accessibility options, to find what they need in order to have a better TDM experience. I've already written the GUI and game engine code for these settings, which I've been using in my personal build. The reason for this poll and discussion is to both guide the finalization of my work and collect data to help inform the dev team. Which patches I submit depend on the outcome of this poll, discussion, and what the dev team agrees to accept. Once decided, I can coordinate with the dev team. I've attached screenshots of what the new settings menu would look like if all of the settings are accepted. Below, I have detailed each menu setting, so you can have an easier time understanding each one. Very important to keep in mind: None of these settings change TDM default behavior. They are all opt-in. If you are already happy with the behavior of 2.10, 2.11, etc. and these menu settings are accepted, nothing will change for you. Rename "Always Run" to "Run Mode" with options "None, Always, Toggle" After 2.11 was released, @i30817 requested that "toggle run" be added to the settings menu. Its cvar is already in TDM as "in_toggleRun" (same as Doom 3). I propose renaming the "Always Run" setting to "Run Mode" with options: "None", "Always", and "Toggle". None = in_alwaysRun 0; in_toggleRun 0 Always = in_alwaysRun 1; in_toggleRun 0 Toggle = in_alwaysRun 0; in_toggleRun 1 Show Blackjack Helper @Wellingtoncrab suggested that the new blackjack helper be added to the settings menu. Its cvar was added to 2.11 as "tdm_blackjack_indicate". More info: It's the new blackjack helper added to 2.11. When the game detects that the blackjack can be used for a successful hit or KO, the blackjack will rise slightly. I propose a "Yes/No" setting for this. Slider for "View: Head Bob" @ChronA requested a way to disable head bobbing, because a viewer watching him play was having severe motion sickness. Also, there was a bug in TDM that made setting the head bob in the console not stick after loading a saved game. (Even with 2.11, if a mission overrides the "tdm_player_thief.def" file and sets "pm_bobroll", "pm_bobpitch", "pm_bobup", and other cvars, it will override player preferences.) As far back as 2008, players have had trouble setting head bob. Another one from 2018. At the end of 2022, @Shadowex3 registered just to voice the need for a way to control head bob. I propose that a slider be added to adjust the amount of head bob. This would use a new "pm_headbob_mod" cvar with a value between 0.0 and 1.0 (default 1.0, no change). The "pm_headbob_mod" would be a multiplier for "pm_bobroll", "pm_bobpitch", and "pm_bobup". The advantage to this approach is that missions like Volta 2 and Hazard Pay would not need to adjust their "tdm_player_thief.def" files for head bob to work properly. And, the player can still adjust "pm_bobroll", "pm_bobpitch", and "pm_bobup" as they like. Slider for "View: Mantle Roll" This is similar to head bob for those who are sensitive to motion. Its cvar was added to 2.11 as "pm_mantle_roll_mod". A Thief player on Discord said, "2.11 will have a cvar to tune down the mantling animation at last." I propose that a slider be added for "pm_mantle_roll_mod". Auto-Search Bodies @Zaratul requested the "auto-search bodies" feature from Thief 1 & 2. Its cvar was added to 2.12 dev16783-10307 as "tdm_autosearch_bodies". I did a poll on the a Thief Discord server and roughly 20% of players there use the Thief auto-search bodies feature. I propose a menu setting for this, so that players coming from Thief 1 & 2 can easily find it.

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

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.

Personally I think it's unrealistic if it's overdone: It needs to represent not what a camera lens sees but what a person's eyes will, albeit that's different for individuals like people who wear glasses. Anyone can however notice that if you put a finger in front of your eyes then focus either on it or the background the other will become blurry: I don't think that's a bad effect to simulate, which would be both realistic and good looking... for our environments especially I think it would look incredible. It's very much a thing of taste though. Like I said I don't think it should be enabled by default, heck I'd be fine with it even as a hidden cvar I can put in my autoexec.cfg (seems frob highlight ended up like that). If so few others like this effect enough to want to work on it though, I may have to try it myself at some point; Wonder if someone could at least help with the code part so I could try doing the dynamic shader myself based on examples, plus confirm it would be accepted so I wouldn't work for nothing. Also do we still use ARB shaders? I thought we switched everything to GLSL years ago. Also curious if our shaders currently have access to the information needed to produce this effect, namely the Z buffer (grayscale depth pass). I wonder if using an independent resolution per area is possible though I strongly doubt it: I think it's an universal camera property, doubt it could be easily made to work per-pixel. It would be interesting since then it could also improve / recover some performance by rendering near / distant stuff at a smaller resolution? Is there anything left of that on the forum or elsewhere? Maybe it could help with a new implementation.

As for the clever way of getting the light angles for proper bumpmapping normally (atleast in the old days before shaders etc.) you had to use per pixel lighting to get proper moving light sources, quake did not support anything but ambient at the time which were static lightsources so some of us got crafty and hacked together real entity lights using per poly collision as a model. The result looked insane but it was really i mean REALLY heavy to run (tbh i doubt any card today could run it at 4K resolutions without going up in smoke and embers, no not even the 4090 ti). This was ofc not nice so we brainstormed it for some time and came up with an idea to use the players position to calculate the light offset, the result was quite a game changer at the time where the old code could barely run at 30 fps at 800x600 resolutions the new code could run it at several hundred frames per second at 1980x1200 on a geforce 3. I tried out the old engine on my current 1080 ti card and i actually had to limit the framerate it ran that fast.

Hi guys, through the "cheats" topic I got the idea, that it would be quite useful, if there were tags for missions (the post was about removing the killing restriction in some missions to suit the prefered play style). I don't know how easy or difficult this is, but with them, it would be quite convenient to pick missions with playstyles, environment, etc one does want to use. This could also be expanded to other mission properties. I remember a discussion about climbable drains, handles on doors, that cannot be picked and other things the map author chooses for himself. That way these things would be clearer and as I said before, it is easier to choose missions with playstyles that suit oneself. What do think?