HMart

I know it can sound bad for the TDM team to do that but If TDM became stuck in the past, it would never evolve and things that don't evolve are doomed to die. Just to put things in perspective, a GPU supporting OGL 3.x is a very old GPU by today's standards, my old AMD HD 5770 was a dx11/OGL 4.x GPU and I bought it on 2009 a decade ago! You can find those (and Nvidia equivalent) on ebay very cheap. I also bet that you can buy a new low end dx12 GPU and it will run TDM very well at 1080p medium settings, also afaik this game is currently more CPU bound than GPU bound.

What about moving the world and not the ship? I remember playing, Life Is Strange, and on it there's a bus ride, to me looked like the bus was moving but in the making off of the game I saw that they moved the world instead?! How would you make the AI "walk" on your moving world? If you wanted people to walk about in the streets, you could make them into idAnimated entities (not idActors so no AI) and have them play a walk animation in place, bind them to a func_mover (idMover) and move that around (at different speed to the world), simulating AI walking around. Of course this expects the player to never be able to left out the boat or ship.

Afaik TDM engine (idtech 4) Fog works inside a box volume, so you need to encapsulate the entire area that you want to have fogged, in a way that you don't see the volume edges or you need to tweek the fog material texture gradient to hide the edges. Things I would try, play with the fog alpha, shaderParm3 keyword in DR if i'm recalling well (give it a big value like 1000 ). Try other existing fog materials. Make a custom fog material that has a smooth round gradient, stronger in the middle less at the edges. If that doesn't work in the way you want, you could try putting another fog volume at the border of the other, with much less fog to simulate the fog becoming less and less dense, but I never tried that so I don't know if the edges will go away. Hopes this helps.

I only tested on the 2.08 exes that Duzenko made available to test, and on those it works, I see no visual difference (with one exception, see below...) nor performance difference with normal map compression 1 or 2, what I see is a huge reduction in GPU memory usage, with it off the scene I was on was using 1389 MB of VRAM with with on either on 1 or 2 it fall down to 878 MB, that's the difference between a older 1GB GPU being able to play the game well or not, on mine GPU that has 8GB of VRAM I could, right now, very well play with compression off. ... with RGTC enabled the water in Volta 2, at the beginning, looks even more broken, now it shows a reflection with the colors totally messed up, man that water shader does need to be reworked. p.s I tested on 2.07 now and it worked, what i did was start Volta 2 went in-game and only there change the svar, on the menu I saw no difference, I assume that most be because the menu does not use any normal maps.

Was able to make a quick test of the new exe, again in Volta 2, frame rate with my AMD RX 570X, with persistent mapping on/off and r_useBasePointer on/off IMO was not bad at all, more or less (max locked) 60fps's in both cases. Disabling r_useBasePointer didn't seem to affect anything, framerate apparently stayed the same (Perhaps my GPU is just too fast in Volta 2 and needs a heavier mission to test?), I used the engine fps counter btw (com_showFPS) one thing that I detected was that the water shader of the river in Volta 2 (at the start) is messed up again, with your older exe (and persistent mapping off) the water worked fine! Now to bed...

Sorry for being so triggered, like I said I was not in a good mood but I should not have being so sensitive but I was and I can't take it back now. When you think I should test on radeon again just say it and if i'm available I will test again. edit: I see you already solved the problem, today I can't test because i'm not on my PC, tomorrow I will test it. Sad to hear that it runs slow on AMD tho.

And I should know that why? IMO you need to start using smiles because I don't know if I should take that reply in a bad direction or not, specially today, when my day job was so stressful and i'm not in a good mood. I was wrong to mention 32 bits but why call one x64 and not the other when both are 64bits? In that way there would be no confusion from my part. ? But IMO this should not have been the discussion at hand but the testing of the exe's, I still don't know if my testing helped you or not.

Are you sure? I used your exes, you have two on the 7zip file above one called - TheDarkModNoTools.exe and the other TheDarkModx64NoTools.exe , I assumed the former was 32 bits.

On x64 exe that solved the problem, but not on x32 one. Btw I used to have a water bug in Volta 2, with this exe the water now looks fine, don't know if is related to the cvar above or not.

On the x64 exe, no crash for me but when playing Volta 2 I see only dark, more or less, I see some AI walking around, and some objects and effects like fog but I see no worldspawn geometry (brushes). On the x32 exe, I don't even see the menu, i only hear the music and the mouse interaction sounds. GPU AMD R9 270X 8GB Driver 19.9.2 CON_DUMP.txt

Conarium was cool but a tad walking simulator for my tastes, it was surprisingly very stable and bug free for the majority of the gameplay but it did add a bug that made me stuck for some time... IMO because of a bad design choice. At the end of the game, you are inside a temple and you need to get out, you have a pickaxe but it is context sensitive (bad idea), you can't bring it up unless the game lets you, so I see a wall that shows the symbol that you can break it but no matter how many buttons I pressed, I couldn't chose the pickaxe, only when I took a few steps back away from the wall did the pickaxe show up, why couldn't I bring it up near the wall, I was to use it to break the wall after all!

I add that error on my side two times, in both it was a semicolon ; at the end causing the problem values "value1;value2;value3;"; // this is wrong in two ways it has two extra semicolons values "value1;value2;value3" // right way

Hey thanks for the offer duzenko, unfortunately i'm not using TDM version of idtech 4 but a custom fhDoom version of the engine, but in the case of the "a transition does not have a valid destination var windowName::matcolor" I found out what the problem was... On a peace of script code I did this: windowDef { ... float set 0 if("set" == 1){ onTime 1000 { do this } } else { onTime 1000 { do that } } } But it should be done like this: windowDef { ... float set 0 onTime 1000 { if("set" == 1) { do this } else { do that } } } The error message indicated a totally different windowDef from the one with the bad logic, and made me spent hours chasing the bug, making me think the macros where the problem, when in this case they were not, I deleted all the macros from the gui (fortunately made a copy before that) and the gui still didn't worked, only when I disabled each windowDef one by one did I found what caused the problem. About what you could do in the c++ side to solve that, like I said i'm not using TDM engine, but if it suffers of the same problem you could try improving the gui scripting error reporting, if possible and the TDM team thinks is necessary and/or something urgent. Another thing you could try to implement, is make it so anyone making TDM guis can use colors defined with #define on transitions as well, instead of having to use definevec4 in the Desktop window, i'm sure that will help everyone using idtech 4. IMO where idsoftware failed when creating the gui scripting language was the inconsistency of how colors/etc is defined and/or used, sometimes is 1,1,1,1 other times is 1 1 1 1. one time you don't need quotation marks other times you need them, etc. Btw sorry for the slightly off topic, I was able to change the gui scripting so you can call onNamedEvents on the gui itself, using the same code has used in Quake4 guis: namedEvent "eventname"; is a really nice thing to have, that I think everyone should have it, using this you don't need to recompile the engine to run onNamedEvents. It was so easy to implement that I was surprised why idSoftware never implemented it but only Quake 4 team did ( I never saw the quake 4 code so I don't know if they implemented it using the same method). Here is the peace of code that does the magic: GuiScript.cpp /* ========================= Script_NamedEvent ========================= */ void Script_NamedEvent(idWindow *window, idList<idGSWinVar> *src) { idWinStr *parm = dynamic_cast<idWinStr*>((*src)[0].var); if (parm) { window->GetGui()->HandleNamedEvent(*parm); } } Add the gui cmd to the command list guiCommandDef_t commandList[] = { { "set", Script_Set, 2, 999 }, { "setFocus", Script_SetFocus, 1, 1 }, { "endGame", Script_EndGame, 0, 0 }, { "resetTime", Script_ResetTime, 0, 2 }, { "showCursor", Script_ShowCursor, 1, 1 }, { "resetCinematics", Script_ResetCinematics, 0, 2 }, { "transition", Script_Transition, 4, 6 }, { "localSound", Script_LocalSound, 1, 1 }, { "runScript", Script_RunScript, 1, 1 }, { "evalRegs", Script_EvalRegs, 0, 0 }, {"namedEvent", Script_NamedEvent, 1, 1 }, {"setCursor", Script_SetCursor, 1, 1 } }; Then on the gui itself just define a onNamedEvent like always and call it inside the gui itself, onAction for example, using: namedEvent "eventName";

Hello guys i'm working on a more complicated main menu for my game and some things seem to cause confusion to me, specially the use of macros with #define and #include. From my search, idsoftware never used #define in their guis and only used #include esporadically, in conjunction with .pd files and not .gui files, what makes me confused, is that some idtech 4 users use or used #define and specially #include to also include .gui instead of .pd, on my tests this seems to be error prone. But i've seen menus that work fine with them in, so my confusion... when I define a macro for example, #define height 640 and put it at the top of the gui file like so: #define HEIGTH 640 #define WIDTH 480 windowDef Desktop { rec 0,0, HEIGTH,WIDTH ... } That works But this causes problems #define WHITE 1,1,1,1 #define BLACK 0,0,0,1 windowDef Desktop { rec 0,0, 640,480 backcolor BLACK // This works transition "windowName::matcolor" "WHITE" "BLACK" "200"; // this does not work } To try to solve that I did #define WHITE 1,1,1,1 #define BLACK 0,0,0,1 windowDef Desktop { rec 0,0, 640,480 definevec4 "white" 1,1,1,1; definevec4 "black" 0,0,0,1; backcolor BLACK // This works fine matcolor WHITE // again this works fine transition "windowName::matcolor" "$desktop::white" "$desktop::black" "200"; // this works...until it seems it doesn't... } But sometimes it works others times it seems to cause problems, like error "a transition does not have a valid destination var windowName::matcolor", specially because the gui error messages are not very good at saying what is really wrong... Ultimately I want to know how others that worked in idtech4 GUI, dealt with this? Right now by the looks of it I should avoid using #define macros and just do it like idsoftware did, work on the values directly. But man macros would really make life much easier...

Even tho i'm not using HDMI i'm using DVI so i'm using a digital interface. 1- I personally don't mess with gamma on games unless the game itself asks me to do that at init. 2- If you are talking to main users (not mission makers) IMO unfortunately the intuitive thing to do for many users, is to bright a game using the monitor/game gamma option, if the team wants to change that, perhaps a hint should be shown at game load saying to use the main ambient light? 3- Color banding doesn't seem to be a problem to me, at least never got distracted by it, but that is me. If I want to see it fixed? If is not hard and doesn't change the game looks to much, imo go for it.

In Volta 2 the water shader imo is having rendering problems at least to me, what I see is a simple scrawling water texture with a reflection moving back, forward and side to side in a fast motion the heathaze effect that you see in the video bellow is not working to me. Btw not sure if useful but compared to the video bellow the scene looks much darker to me but perhaps the guy just brought up the gamma for the let play. I'm playing on a all AMD PC AMD Ryzen 7 1800X AMD R9 570X 8GB latest (at the time of this post) 19.9.2 drivers Darkmod.cfg CON_DUMP.txt

I'm sure the publishers/developers are giving consent because Epic most pay them a nice amount and promise them more profit (because Epic takes less cut than Steam) by making their store more popular this way. Some games are indeed expensive, 60€ for a game, specially when many are play once and discard is insane. Personally i'm starting to wait and see what free game shows up in the Epic store, right now I have 3 games on my library that were on my wishlist on steam! That is 3 games that I will not buy now. About Unity, at that time it add two versions, a professional version and a personal version, the personal version was free, for non commercial games, if i'm recalling well and didn't supported many of the features of the professional version, like real time shadows, to survive Unity add to blend them into one and make the engine "free" (still not open source tho). I'm all about choice don't take me wrong, is fantastic that many people, is now able to play games that they would never be able to, unless they pirated them, at least pirates now have no excuse. But one thing is certain in the engine space (that matter) many choices is not a thing that you have now.

That is a good question, I'm personally happy with the way TDM (and idtech 4 ) renders picture frames, i must say that the reason I still return to mess with idtech 4 after trying Unity, Esenthel and Unreal 4, not really in that order, is just that to me, its images look so clean and well constructed, compared with other engines (specially those based on deferred rendering) that make the render look slightly blurry and over bloomed/bright, but i'm not personally against trying any other color space and I would be happy to help in any way I can, even tho my time is limited.

Even tho I don't complain about the free games, I'm not comprehending what they are doing, looking at it with reason, it makes me think Epic is insane, imo they will do to gaming what they did to engine marketing, they will devalue them so much that people will not want to pay much, if anything, for games anymore. And those that end paying the heavy price is the ones making small indie games as always. When Epic games made their engine "free" they pretty much killed the engine business for indie engines and even the other top AAA engines have no choice now but be "free" to use as well.

Afaik you can do that or you can also delete all files, minus the tdm_update.exe and the tdm_mirrors.txt and then use the update executable to reinstall the game from the net.

I'm not a expert on PBR (physically based rendering) because i'm not using it myself nor I ever made PBR materials for games but I know it was the way offline renders (Blender, Modo, 3D Max, etc) did their materials for ages, IMO is also the main system that gives UE4 and Unity their modern look. I also know PBR makes more realistic materials, in that they behave as expected in any kind of light condition, older materials like those used now in TDM, work well in some lighting conditions but not others, so one material that worked well, in a scene, may need to be reworked for another, where's a PBR material, is enough for all scenes, so they not only make games look better in all conditions, they bring the material work needed down, you can easily create standard material libraries that are just drag and drop and work for all scenes and objects, only good advantages, no wonder it was imo the fastest system to implement in pretty much all modern engines. I always thought that the idtech 4 engine would need to be heavily reworked to be able to do PBR, that shows how little I really know about engine rendering, if you just need a shader to do PBR in idtech 4, then it was more future proof than I believed! If this is a true PBR system (and performant) I will be very impressed! https://marmoset.co/posts/basic-theory-of-physically-based-rendering/

The problem is not supporting GLSL shaders, afaik TDM already does, the problem is making the glsl shaders themselves. Someone from the team (coders mostly) needs to take some GLSL shaders from shader toy and make them work in TDM engine or make ones from scratch but afaik that requires good trigonometry/math skills. I converted some post-process GLSL shaders to work in the FHDoom engine but it was, hit and miss because I don't know much about writing shaders from scratch. Here is a post-process noise shader that I converted and know it works, in the FHDoom engine, don't know how shaders are written for TDM... 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() { gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0); result.texcoord = vertex_texcoord; } fragment shader (pixel shader) #include "global.inc" layout(binding = 0) uniform sampler2D InputTexture; // vec4 shaderParm0 timer; // vec4 shaderParm1 amount; in vs_output { vec2 texcoord; } frag; out vec4 FragColor; void main() { vec2 texSize = textureSize(InputTexture, 0); vec2 uv = frag.texcoord; uv *= 1.0 - uv.yx; vec4 src = texture(InputTexture, frag.texcoord); vec4 c = vec4(src.rgb, 1.0); float mDot = dot( frag.texcoord.xy , vec2(12.9898,78.233) + shaderParm0.x ); float mFract = fract(sin(mDot) * 43758.5453); c += (mFract - 0.5)*shaderParm1.x; FragColor = vec4(c); } shader material textures/glsltest/debugNoiseShader { noshadows translucent sort postProcess { blend add vertexShader noise.vp fragmentShader noise.fp shaderParm 0 time * 0.05 // timer shaderParm 1 0.1 // amount shaderMap 0 _currentRender } } c++ code called in the playerView.cpp file inside the SingleView() function... if ( !pm_thirdPerson.GetBool() && !g_skipViewEffects.GetBool() ) { ... const idMaterial *mtr = declManager->FindMaterial("textures/glsltest/debugNoiseShader", false); if (pp_noise.GetBool()) { renderSystem->SetColor4(1.0f, 1.0f, 1.0f, 1.0f); renderSystem->DrawStretchPic(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, 0, 0, 1, 1, mtr); } player->DrawHUD( hud ); ... Right now I have a problem rendering more than one post-process effect at the same time, this indicates to me that this is not the best way to render them but my knowledge on this is limited. Any idea would be welcomed.

Very professional work peter_spy love it.

I would use a particle emitter for that, then just tweak it so it looks like they are randomly flying around. But if the TDM team wants to code a special "boids" system that would be awesome. Boids system

Hum, unless you are playing with a debug compiled exe and triggering a c++ assert then that crash indicates that the combat model arg seems to be old code that doesn't work anymore, petty. I will look at the (fhDoom) engine source and see where that arg is defined... edit: peter_spy it seems a combatModel is set by default in the c++ code in all models defined as idActors and they do require a AF (is loaded before the combatModel is set up in the code). idAnimated by the look of it do use the "combatModel" spawn arg, because its spawn function looks for the existence of it and seems to be the only one. So to me looks like that arg was made for idAnimated models only. Not really important for the discussion at hand but when looking at the code, I saw that for idActors you can set the (bullet/projectile) hit detection to use the bounding box instead of the default combatModel (per-triangle hit detection) by using "use_combat_bbox" "1". Could be a good option for performance tuning, at least for non important actors, not sure if really useful in a game like TDM that uses very low projectile counts tho.