Jump to content
The Dark Mod Forums

HMart

Member
  • Content Count

    890
  • Joined

  • Last visited

  • Days Won

    4

HMart last won the day on November 11 2015

HMart had the most liked content!

Community Reputation

207 Excellent

About HMart

  • Rank
    Advanced Member
  1. 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!
  2. 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
  3. 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";
  4. 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...
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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/
  12. 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.
  13. 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
  14. 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.
×
×
  • Create New...