Jump to content

Xycaleth

Members
  • Posts

    1,458
  • Joined

  • Last visited

Posts posted by Xycaleth

  1. On 7/26/2020 at 8:16 PM, Darth Futuza said:

    We also need to talk about pathfinding/routing and how that should work, but I figured I'd let Xycaleth weigh in on that first since he's been playing with it the most.

    I'm not sure there's much to say. Pathfinding is a means to an end and usually an NPC will have have some location that they need to reach, whether that's an explicit location (chasing a player, running into a build, investigating a sound, etc), or something implicit (a cover point, anywhere out a player's line of sight, a randomly picked location for patrolling).

    I'm looking into using navigation meshes instead of waypoints since it provides much better information about walkable areas compared to waypoints.

    Futuza likes this
  2. OpenJK is a cleaned up/slightly modified version of the original code which was written back in 2002 which itself is built on the Quake 3 engine from 1997.

     

    C++ wasn’t so popular back then so the vast majority of the code stuck with C89. Some of the newer code written specifically for JKA is in C++ but doesn’t resemble anything you would consider “modern” by today’s standards.

     

    I would say adding/writing C++ code for the sake of writing C++ isn’t particularly useful. Unless something benefits from using C++ then there’s not really much need to do so

    Smoo and Circa like this
  3.  

    Looks like something went wrong with the shader parsing. Line 387 in your paste bin is actually the end of the shader. I probably forgot a null terminator somewhere.

     

    Thanks for the PR. There's a lot of things I disagree with there unfortunately, but I'll comment on it GitHub  :)

  4. I second ensiform here. GLDirect should only be used as a last resort (e.g. your computer is over 10 years old or something) otherwise you might have other issues.

     

    Can you post your hardware specs? JKA always reports players using P4 processor since it doesn't recognise the newer ones. Updating your graphics drivers should fix the problem better without any of the glitches you're seeing now.

  5. @@AshuraDX I don't have time to go through the code right now to see exactly what it does, but this is the function that saves the .wnt file:

     

    https://github.com/JACoders/OpenJK/blob/master/codemp/game/ai_wpnav.c#L2384

     

    And for loading (maybe one is easier to read than the other):

     

    https://github.com/JACoders/OpenJK/blob/master/codemp/game/ai_wpnav.c#L2019

     

    Flags are here:

     

    https://github.com/JACoders/OpenJK/blob/master/codemp/game/ai_main.h#L41-L57

    And looks like the data between the { } should be points that bots can force jump to (or something related to force jump).

    Smoo and AshuraDX like this
  6. Ok, so I’m just wondering if anyone knows or can point me in the right direction, as to what all the dynamic glow and dynamic light commands are, in the console?

     

    r_dynamiclight = 1 (I know “1” is to turn on dynamic light and “0” is to turn it off)

    r_DynamicGlowWidth = 320

    r_DynamicGlowSoft = 1

    r_DynamicGlowPasses = 5

    r_DynamicGlowIntensity = 1.13f

    r_DynamicGlowHeight = 240

    r_DynamicGlowDelta = 0.8f

     

    If there’s any info anywhere, regarding this.. It’d be a big help.

    Thanks!

     

    r_dynamicLight, ent has already explained.

     

    I don't know for sure how the r_dynamicGlow cvars are used, but I do know how dynamic glow works so here's my educated guess:

     

    Any models with shader stage that has a "glow" keyword will have it's glowy portions rendered again to an off-screen image. I think r_dynamicGlowWidth and r_dynamicGlowHeight control the size of this off-screen image. Once all the glowy stages are rendered, you blur the off-screen image a few times. r_dynamicGlowPasses controls how many times, and r_dynamicGlowDelta controls how much to blur. Finally, you blend this off-screen image with what you have on the screen. r_dynamicGlowIntensity controls how strongly to blend and r_dynamicGlowSoft controls the type of blend.

     

    Like ent said, if you load a map with cheats on you can see how each of the cvars affects the size of the glow, and the quality. You don't need to run vid_restart after changing each one (except for r_dynamicGlowWidth and r_dynamicGlowHeight maybe?), they'll take effect immediately.

    General Howard and ent like this
  7. It’s the same for the vanilla (original) renderer. The codebases were developed separately at Raven so the SP and MP codebases diverged. I don’t think it will be possible to merge the two without breaking compatibility in some form...

  8. Hi, I've been following this project for some time now and I'd like to thank those people who are doing their best to keep these games alive!

     

    [...]

     

    Hi! I think many people have proposed using an existing rendering engine to fit into JKA. Personally I would choose the bgfx renderer if I were to do this. Someone else has already made some progress with this for ioq3. There's two problems though: 1. there's a lot of weird things that the Q3 engine does which would still need to be supported by a new renderer, whether or not it's hand-built or uses an existing rendering engine, 2. there's nobody who wants to take on the task :P

     

     

     

    EDIT: On a side note, would it be possible to integrate some parts of the Doom 3 source code into this project? Both are open-source so legally it wouldn't matter. Maybe if we could integrate the D3 renderer into OpenJK?

    Being 'Open Source' doesn't automatically mean you can start using code from another project. Doom 3 code is released with a license which is incompatible with OpenJK which means we can't use, or even write code which is based on, D3 code.

  9. GL_VENDOR: Intel Open Source Technology Center

    GL_RENDERER: Mesa DRI Intel® Ivybridge Desktop

    GL_VERSION: OpenGL ES 3.0 Mesa 17.0.7

    This is interesting - OpenJK only supports the OpenGL graphics API, but your Linux distro is providing the OpenGL ES API (similar name, but not compatible).

     

    Maybe you haven't installed the OpenGL library? Try installing the libgl-mesa-glx package and see if that helps.

  10. I'm wondering if there's a way for you guys to create a single C++ library which each of the plugins can pull in to do what you want, instead of replicating essentially the same functionality across multiple plugins. For Blender you could write a Python wrapper around the C++ library. Just food for thought. I think you can save a lot of effort that way but it would take a bit more programming know-how.

×
×
  • Create New...