Jump to content
The Dark Mod Forums

HMart

Member
  • Content Count

    928
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by HMart

  1. No problem you guys deserve it. DR now works and I most say the user guide is very nice.
  2. Thank you guys for your work on maintaining this tool, I know how hard it can be to work on a project for free on your spare time. edit: The new version crashs to me with error VCRUNTIME_140_1.dll was not found, used the portable version, I assume I need to install a runtime for visual studio 2019?
  3. Totally agree with AluminumHaste, I hope you have some lore on why the thief can walk for ages centimeters above open lava, he must have clothes and shoes made of titanium strings. ;D But the design looks very good, one thing that you could do to give the impression the metal is getting hot, is make the side looking into the lava glow a little orange, (material trick, vertex colors could help here). Now a friendly critic on the gameplay, this is only my opinion based on limited information, that being a maze, could feel repetitive after a while, to be walking back and forth, specially if you have no clue where to go and heat doesn't seem to really affect you. To give more "urgency" to the moment, you could try turn this into a more linear thing, with one or two dead ends to spice things up and make it more urgent to the player to get out of there fast or get killed by the heat and the moving statues. I know this is totally different from the idea you are showing there but imo it could be something to consider, at least in this particular situation, you could use your current idea to another area without lava, but the mission is yours and you do what you like.
  4. Sorry for going somewhat off topic but I've seen this problem before in fhdoom and it can be a clue for TDM has well. When using a custom post process glsl shader, a small window at the lower left corner of the main window shows up, the effect works in the small window and the rest of the screen gets like you said. I know almost nothing about shader coding, but it could be connected to the way id tech 4 renders the screen first to 640x480 then converts it to the users screen size after. Here is one of the shaders with problems, for those that want to see it. Btw this code was not written totally by me (just made changes to try blindly convert it to fhdoom), this is a modification of a shader from Total Chaos a free game (gzDoom engine), nice game btw and credit for it should be giving to them. Btw how do you hide text in the forum? (so the reply doesn't get so big) hope this helps. Global.inc #version 330 #extension GL_ARB_shading_language_420pack: enable uniform mat4 rpModelMatrix; uniform mat4 rpViewMatrix; uniform mat4 rpModelViewMatrix; uniform mat4 rpProjectionMatrix; uniform vec4 rpLocalLightOrigin; uniform vec4 rpLocalViewOrigin; uniform vec4 rpLightProjectionS; uniform vec4 rpLightProjectionT; uniform vec4 rpLightProjectionQ; uniform vec4 rpLightFallOff; uniform vec4 rpBumpMatrixS; uniform vec4 rpBumpMatrixT; uniform vec4 rpDiffuseMatrixS; uniform vec4 rpDiffuseMatrixT; uniform vec4 rpSpecularMatrixS; uniform vec4 rpSpecularMatrixT; uniform vec4 rpColorModulate; uniform vec4 rpColorAdd; uniform vec4 rpDiffuseColor; uniform vec4 rpSpecularColor; uniform vec4 shaderParm0; //this shaderParm's seem to be connected to the ARB program.local[0], etc uniform vec4 shaderParm1; uniform vec4 shaderParm2; uniform vec4 shaderParm3; uniform mat4 textureMatrix0; uniform int rpAlphaTestEnabled; uniform float rpAlphaTestThreshold; uniform vec4 rpCurrentRenderSize; uniform vec2 rpClipRange; uniform int rpDepthBlendMode; uniform float rpDepthBlendRange; uniform float rpPomMaxHeight; uniform int rpShading; uniform float rpSpecularExp; uniform int rpShadowMappingMode; uniform mat4 rpSpotlightProjection; uniform mat4 rpPointlightProjection[6]; uniform vec4 rpGlobalLightOrigin; uniform vec4 rpShadowParams; //x=minBias, y=maxbias, z=fuzzyness, w=samples uniform vec4 rpShadowCoords[6]; uniform vec4 rpShadowMapSize[6]; //xy = width/height of far plane, zw = near/far clip distance //TODO(johl): is width/height correctly set for non-parallel lights? uniform float rpCascadeDistances[5]; uniform mat4 rpInverseLightRotation; 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(void) { gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0); vec4 vertex_texcoord4 = vec4(vertex_texcoord, 1.0, 1.0); result.texcoord.x = dot(rpBumpMatrixS, vertex_texcoord4); result.texcoord.y = dot(rpBumpMatrixT, vertex_texcoord4); } Pixel shader/frag program #include "global.inc" layout(binding = 0) uniform sampler2D currentRender; in vs_output { vec2 texcoord; } vert; out vec4 fragColor; vec2 fixScreenTexCoord(vec2 st) { float x = rpCurrentRenderSize.z / rpCurrentRenderSize.x; float y = rpCurrentRenderSize.w / rpCurrentRenderSize.y; return st * vec2(x, y); } void main() { float samples = shaderParm0.x; float amount = shaderParm0.y; float dist = shaderParm0.z; float threshold = shaderParm0.w; vec2 texSize = textureSize(currentRender, 0); vec2 uv = vert.texcoord; uv *= 1.0 - uv.yx; vec4 src = texture(currentRender, vert.texcoord); vec4 c = vec4(src.rgb, 1.0); vec4 fsrc = texture(currentRender, vert.texcoord); vec4 fc = vec4(src.rgb, 1.0); vec2 tc = vert.texcoord; float size = 0.5; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 0.35; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 0.8; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 1.0; for(int i = 0; i < samples; i ++) { vec2 tc = vert.texcoord; size += dist; tc.x *= 1.0-size; tc.x += size/2; tc.y *= 1.0-size; tc.y += size/2; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } size = 0.98; for(int i = 0; i < samples; i ++) { size += dist*2; vec2 tc = vert.texcoord; tc.x *= size; tc.y *= size; fsrc = texture(currentRender, tc); fc += vec4(fsrc.rgb, 1.0); } fc = fc /(samples*3); fc = fc - threshold; fc = clamp(fc,0.0,1000000.0); fragColor = vec4(c + (fc * vec4(0.8, 0.8, 1.0, 1.0))*amount); }
  5. They look good enough for me now but just getting TDM assets into UE4 (like is) will not make them look any more realistic than they do now, TDM assets were not made for PBR (physically based rendering) and that imo is 99% of what makes UE4 games look like that. Also IMO TDM team will never change engines now, not after so many years of work (and learning to master) the current one, specially with so many missions already made. That would be throwing peoples years of work into the trash. No TDM will stay in id tech 4 for years to come and personally I don't see anything bad on that, for the contrary.
  6. Sorry for the necro but I've seen this strange bounding boxes on my modified fhdoom engine, has this been fixed for TDM? If so can someone direct me to the necessary files/code that needs to be fixed. Using a idBox did helped me visualize a good BBox on my debug code but i'm afraid it only masks the problem and even tho it looks fine, the underlying AABB is in reality broken and will cause problems later.
  7. Totally agree with Springheel, if the shadow doesn't "work" properly ( I have not played TDM for a while now) in that case this idea is really not viable, afaik there's no one working on animations for the character and it has been like this for years. Btw why don't you guys use mixamo? Something in their licence prevents it? I'm asking because they give free animations and characters, I was able to download a bunch of animations right now in fbx format, totally free (you need to make a account but is free). I've seen a animation pack there called "longbow locomotion pack" (and many others) that using the female archer character there, looks perfect for TDM.
  8. Afaik John Carmack is the single creator of the id tech 4 engine, other programmers from id worked on the gaming part of the c++ code and the game scripting itself but the underlying engine, was totally written by John Carmack. Ok with a small intervention from Creative, because of a patent lawsuit they won against John, they implemented EAX 4 into the engine. Btw TDM team removed EAX and implemented EFX instead, is exactly the same thing but the latter runs totally on the CPU. Btw is funny how John changed from procedural C to OOP C++ in mid development, so you have a engine code that has both C and C++ OOP coding philosophies, but man is a fantastic code base, everytime I see the pure c++ OOP code of other engines sources, the more I appreciate the way id tech 4 was written.
  9. I remember this idea being discussed before and the conclusion (that i agree) is that it would cause unwanted frustration for the player. But i'm not saying that you shouldn't try to do it, if you know how that is, i'm sure some players will like the added difficulty. Make a mod and post it here, this is the beauty of totally open games like TDM, if you know how you can change it to your heart desire.
  10. Woah I based my experience on the few games I played on a friends PSVR system, I think I have yet to experience the smooth locomotion that you talk about, unless the Rally simulator he has can be considered smooth motion, it has indeed constant motion (no teleportation) but it makes me sick in seconds, so i didn't played it much. I also get sick very easily in real world cars for example (not when driving of course). The only VR game I experienced that really made me appreciate it, was a third person platform game, you stay put and you just make a small character jump around, that to me was really awesome, the shark cage demo was also cool, like I said i'm not against VR and I comprehend why some people love it.
  11. I always knew they would use the HL IP to try to sell VR, the dreamed "killer app", even tho i've nothing against VR, is still just to damn expensive to me, PC version of course. And like me there's millions outhere but Valve is really not making this for the quick money. Personally I love FPS's and VR ones even tho cool and all, are just not what i'm used to, movement in a VR FPS imo is really bad, or you just move on rails (on a vehicle for example) and just pop shoots at enemies as they pass by you or you use "jump" teleport to move around the world, the later is much better but is also much more sickness inducing (at least for me) and is just not the smooth traveling that normal "flat" FPS's provide, this unless you move on the real world, but that will never be practical outside of specialized gaming centers.
  12. I'm with peter_spy on this and I assume John Carmack/id software also agrees, why, because the Doom 3 game and engine is full of warnings and even missing asset errors that do not cause a crash! Is totally normal during development to mess around with assets, materials, models, fonts, etc that never end being used and so get broken definitions to stick around, like i said, Doom 3 came with many broken/missing .mrt and .def files but the game worked just fine. When you are developing, specially in a multi-user environment you don't want your game and tools to constantly crash because someone else failed to delete a material file!? IMO crashes (asserts) and game-stop errors should be used for things that can potentially make harm to the user PC or cause serious visual problems in the game, all the rest should just be developer warnings that may or not be solved until shipping. And if you really want to cause crashes for everything during development then, use assert, those only trigger on Debug mode not release mode so there's no danger of the final release mode game crashing because of something that should be a simple warning.
  13. I most say that i'm not a TDM mission maker nor I even made that much scripts for TDM so I don't really know how they handle their weapon system, if it is similar to the Doom 3 way you could try this idea below. warning: This code is untested code, based on the way Doom 3 works and could be totally wrong for TDM, don't take it as a plug and play sort of thing, is just something for you to try, a direction of sorts. Btw if it throws any error at game startup post here and me and I hope others will try to help. I'm very busy so it could take some time for me to reply tho be patient. // in the player script file (if the TDM player script looks anything like the Doom 3 one...) object player : player_base { ... // Create a thread handle float discardthreadNumber; ... ... // create a new function // NOTE: notice the float data type, threads always return a float id number float DiscardWeapon(entity ent); }; void player::init() { ... discardthreadNumber = 0; // init the thread handle to zero ... } float player::DiscardWeapon(entity ent) { eachFrame{ // NOTE: a gui parm, is a variable in a entity gui (fullscreen or otherwise) that looks something like this, gui::parmName, // so, for this to work the player hud gui, most have a onNamedEvent or a windowDef // where a gui text cmd, is updated by a gui::message parm. // In Doom 3 idSoftware used gui::parm1, gui::parm2, etc but you can use any name you want. // BTW you cannot access any other script variable, using script or the engine c++ code but those, using // the gui:: naming convention, so no use trying to access a float defined inside a gui script, // those are only to be used by the gui code itself. self.setGuiParm("message", "Theres something wrong with this weapon!"); wait( 5 ); // clear message self.setGuiParm("message", ""); disableWeapon(); waitFor(ent); // kill the thread function if(ent.weaponHolstered()){ sys.terminate(discardthreadNumber); discardthreadNumber = 0; } } } void player::RaiseWeapon() { weapon = getWeaponEntity(); animState( ANIMCHANNEL_TORSO, "Torso_RaiseWeapon", 2 ); // Did not used weapon.getName() because that returns the entity name has defined in the editor // and not the weapon name has defined in the player def file, don't know if they match. string weaponName = getCurrentWeapon(); if(weaponName == "weapon_pistol"){ // start the thread function if(!discardthreadNumber){ discardthreadNumber = thread DiscardWeapon(weapon); } } }
  14. Btw i'm sure someone will use that Modding Kit to bring Dragons and magic into KCD ;D Can't wait for the Lord of the rings and Game of Thrones mods.
  15. Not exactly, Cryengine is not a brush based engine like idtech 4, is a full mesh based engine, you make your terrain in the editor using the editor tools to sculpt the terrain and then you import meshes made in Blender, Modo, Maya, etc into the level editor to populate your world but nothing prevents you from making brushes in DR, then export those as a obj, but you would need to UV map and texture them in the previous mentioned tools. Cryengine editor is a tool set suited to make huge open worlds. Is possible to make small indoors levels but they are not build exactly like with DR. peter_spy Cryengine has visportals (portals and anti-portals) they are mostly used for the indoor sections. p.s - Forgot to mention Cryengine editor has a entire set of tools to build and edit box primitives (designer tool), you can think of them has brushes but they are in reality triangle meshes and work exactly like those in Blender for example. You can then edit and construct full structures like buildings using those, this tools are mostly used to "white box" a level before the real objects get imported but I've seen people build complex structures with it that stay in the final game.
  16. TDM is open source and anyone can do with it what they want, I'm also no one to demand others to stop but I most ask, why would you want that? Just to spread the word on the game? Running a game in a browser, is very slow compared to running it natively on the PC and that is also slower than it can theoretically be that is why Vulkan and dx12 were invented. If the first contact people have with TDM is with the slowest version of the game, why do you guys think they would go then try the faster version? IMO they would just say the game is trash and forget it, first impressions are very important. TDM is already more demanding than Doom 3 ever was, they are two different games, not to mention that the engine version used in TDM has many changes and requires newer and updated GPU's, IMO Doom 3 is not and should not be a benchmark for what TDM should be capable off. Also Would the TDM team be fine with the game being known by many people has a browser game? We all know the stigma that those games have. Now again, if you want to try doing it, go for it, I bet it would be a fun exercise but I ask, what good would it make to the future improvements of the game/engine to have two different versions outhere? Who would maintain them? TDM team of volunteer coders is already small and even tho I don't speak for them, I bet they don't have much free time to work on something like this. Ultimately I certainly don't believe this would help people with slow computers (or slow internet), there's a reason you only see a few games running on browsers and none of them have the complexity or more complexity than Crysis for example, a 12 years old game. (google stadia will change this tho...)
  17. If the effect is subtle (that based in the video seems to be) imo it doesn't effect the identification of dark/light areas, personally I could very well see where was dark and where was not, this is like a person being in a dark spot and his eyes adjust to the darkness and imo that looks cool. I also think this would not affect gameplay at all, besides making it easier to see in the dark, imo is no different from people bringing gama up but at the same time seems to look better and to me is more realistic.
  18. Don't know if the TDM frob is based on a trace but if it is, you could try turning on (g_showCollisionModels 1) and make sure the collision box of the readeble is not inside the door collision box. You can do the same on the editor by displaying the collision proxies (green texture with collision text on it) and fix it there.
  19. Imo most be windows defender AI system flagging the exe has a virus, personally I don't use it, I use Avast instead and I have no such problem. See in the windows defender "vault" if it has any I don't know, if the exe is there restore it and make a exception. A relatively famous game developer, Casey Muratori, made a twitter some days ago about this same problem. https://twitter.com/cmuratori/status/1185242609737818113?s=20
  20. Personally I have a 3D screen and I don't play games that way for the most part, I don't even remember the last time I played a game using the 3D capability of my screen, but for VR I comprehend why people would want it. Btw idtech 3 (quake 3 engine) if i'm not mistaken has stereo capabilities perhaps someone with good knowledge of rendering code could see how it was done back then? Or even see how BFG does it? On my basic comprehension on how this stereo stuff works, it could be made by rendering two views (using two player cameras?!) with a small separation between them, then you just, interleave them for a 3D screen (like mine) or you color one view red and the other cyan for all screens, how that would be done on code is for a rendering programer to think about.
  21. I like it, it perhaps could be used to help optimization? I'm asking cause the outside view of a well lit room would be totally dark (at night) and so many things could be culled out of view (even if the visportal is open and things apparently should be visible to the player), the run time cost of doing the testing for visibility, would needed to be evaluated tho.
  22. You can also try renderDoc it has the benefit that it is GPU and OS agnostic. Handmade hero coder experience with renderDoc
×
×
  • Create New...