Jedi Knight Quadranscentennial Edition

[Quib Mask]

i.e. Jedi Knight 25th Anniversary Edition

(starting to get this post created. I'll flesh this out as I'm getting files organized; there's a lot that needs to be documented)

The main JK executable, based on the official 1.01 patch, includes the now-standard assortment of JKUP patches, plus the following features:

• -
• (list to be further populated)
• -
• rotated particles by 45 degrees
• enhanced z-buffer accuracy
• CPU relief (JK should no longer peg a core to 100%)
• toggle enhanced 3D audio without JK restart
• fixed a (big) memory leak in A3D audio code
• fixed a jkSetForceSpeed crash
• added ZeqMacaw's increased synced thing limit
• enabled unused COG extension features:
  
  • hotkey message
  • discrete hotkey filtering
  
  
• added some OpenJKDF2 QOL_IMPROVEMENTS:
  
  • smooth singleplayer aerial physics
  • improved behavior above 100 fps
  • waggle animation scaled to framerate
  • keyboard turning scaled to framerate
  • mouse sensitivity numeric display
  
  
• fixed mouse sensitivity setting drift
• increased mouse sensitivity maximum
• added an adjustable internal framerate (frametime arg and cmd)
• added JkGfxMod detection and compatibility enhancements
• reset debug mode flags at main menu
• tweaked help command to not list itself
• devmode arg skips intro cutscene (can view in cutscene menu)
• added some (all?) OpenJKDF2 memory leak fixes
• added OpenJKDF2 AI awareness fix
• added dual wield weapon mesh rendering
• removed JKUP's increased COG symbol limit:
  
  • it was not actually usable since variables 256 and above disabled COG verbs and rendered a COG functionally useless
  
  
• added mouse wheel support
• made the free look hotkey invert state (since "enable free look" is typical)
• fixed missing F1-F8 hotkeys when player data load fails
• adjustments to default controls (e.g. space = jump, auto run enabled, etc.)
• fixed crash when alt-tabbing during joystick "identify" menu
• added limited controller trigger support (both triggers can't simultaneously cause an action due to limitations in winmm/dinput controller support, but actions that don't really need to occur simultaneously such as "Use Force Power" and "Fire 1" work adequately)
• added left and right stick click-in support (aka L3/R3 or LSB/RSB); these have no defaults bound as I hate them, but they're now available for use
• added rudimentary controller support to the game menus (left stick = move cursor, A = click, B = escape)
• enabled using mouse buttons and joystick (controller) buttons while in-game chat is active

Additionally, external files provide the following features:

• enhanced 3D audio (a3d.dll)
• traditional rendering pipeline (ddraw.dll, wndmode.dll)
• install-free DirectPlay support (dplaysvr.dll, dplayx.dll, dpnhpast.dll, dpnhupnp.dll, dpwsockx.dll)
• CD audio (winmm.dll, libvorbisfile-3.dll, 00_soundtrack.cog, 00_playambient2.cog)
• automatic FOV, mipmap and LOD scaling (item_wrenchyellow.cog)

Where modified COGs are used to provide features, they're designed to match the unmodified vanilla COG in behavior and checksum so as to not cause multiplayer incompatibility.

QM

Edit: I've written down what I've done in the past month, but all prior features are yet to be documented.

[Jon`C]

Feel free to bundle the executable with JkGfxMod if you want. It uses Microsoft Detours to hook the executable. Microsoft provides a tool to patch an executable offline, which in your case would let you skip the extra inject.exe stuff.

[Quib Mask]

I actually want to keep JkGfxMod dynamically patched, both so that if it gets further updates a user can simply drop in the new file(s), and because other stuff I've either done personally or adapted from others' (ZeqMacaw et al.) work has the vanilla rendering pipeline functional (including with 32-bit color modes and glow-in-the-dark colors like the 8-bit software renderer) on modern Windows (and still backwards compatible through at least Win98SE; I never tested on 95/98, nor on 11 yet, but I'm optimistic), so having both options seems better than forcing one. The injector, in spite of the anti-virus false positives, also seems to prove handy for launching via Steam.

The glowing Lightsabers and projectiles possible with JkGfxMod are so damn amazing though, forcing that as a standard sure is tempting. I'm experimenting with the displacement map capability as I'm writing this, but not sure if anything will come of it.

For reference, for JkGfxMod compatibility, I did the following:
- detect if JkGfxMod is loaded (via GetModuleHandleA on renderer.dll, just after JK calls CreateWindowExA); I don't like how hacky this is, but it's simple and reliable
- if detected:
-- skip QueryInterface for Viewport3 (JkGfxMod kills itself otherwise, I wish it just returned E_NOINTERFACE)
-- restore the ZBufferMode for rendering layers 3 (transparent level geometry) and 4 (pov weapon model) which are otherwise modified from vanilla
-- modify some window centering code I added to instead snap the client area to 0, 0
-- modify setting load code for
--- 3DDeviceGUID to return JkGfxMod's GUID
--- displayMode to always return 1
--- b3DAccel to always return true (1)
-- modify setting save code for the above three, to skip saving them

The first two are critical for compatibility.

QM

Edit: Playing around with displacement maps. This is the vertical water shaft in Canyon Oasis:


And here's what the mouse config screen looks like now:

[Quib Mask]

I've been kinda going nuts with JkGfxMod. There wasn't a sane way to resolve a compatibility issue between my new code to let the controller drive the cursor in menus and JkGfxMod, so I went ahead and got a build environment functional for JkGfxMod (not difficult, thank you for making a tidy, self-contained project and sharing it with the world) and started making additions.

So far, I've done the following:
- hook SetCursorPos to translate stretched window coordinates
- tweaked the GetCursorPos hook so that it also affects in-game (for 640x480 software mode mouse use)
- hook CreateFileA to load texture replacements during level load to reduce in-game hitching without random pre-caching (I hated writing this hook in C++, I could've made it hyper efficient in assembly)
- level-load-loading the textures necessitated populating a filename-based dictionary during program load to be used during level load (from ["replaces"][0]["name"] entries, accomodating multi-cel textures)
- added a boolean to jkgm.json to control level-load-loading ("per_level_texture_loader")
- avoid crashes for missing albedo_map, emissive_map and displacement_map files
- automatically use current screen resolution if "resolution" isn't defined in jkgm.json (instead of 640x480)
- added "hud_texture_num_slabs" to jkgm.json to specify number of frames per HUD layer refresh (on my computers, at my preferred screen resolutions, updating every frame doesn't clobber framerate, ymmv)
- added additional non-displaced texture passthrough from displacement mapping to screen space shaders
- rewrote SSAO (including aspects in the DLL)
- modified displacement mapping
- made "enable_vsync": true be the default (there were non-zero complaints about videocard heat)

QM

[Brian]

Wow I don't know how I missed that screenshot but it looks amazing!

[Quib Mask]

More JkGfxMod tweaks:
- altered framebuffer clears to restore vanilla JK HOMing; this is more necessary than is obvious to avoid rare-but-consistent partial screen blackouts as the camera passes sector adjoins
- added relaxed cone mapping as an alternative to standard displacement mapping

Relaxed Cone Mapping and fine tuning the new "Fast" Ambient Occlusion have been what I've been working on the past month. Not sure yet how to (or if it's worth) getting screenshots that show off the differences.

[SMLiberator]

super happy to see this is still going on, plus with jkgm integration
any hints as to when we can see a demo?

- altered framebuffer clears to restore vanilla JK HOMing; this is more necessary than is obvious to avoid rare-but-consistent partial screen blackouts as the camera passes sector adjoins

this is actually super noticeable in levels with 3do skyboxes. also there are some levels and mods that rely on HOM to create certain visual effects, so it's good that consistency with base JK is maintained in this aspect.

[Brian]

I need this!

[SMLiberator]

also, can anything be done to fix this silly wee seaming issue caused by JkGfxMod mipmapping?

[Quib Mask]

I've been working with someone on an all-in-one tool for precedurally generating depth maps (and their matching cone maps). It's technically going to be generically useful and not JkGfxMod-specific. As a baseline, it can be fed a basic (albedo) texture, and will then:
- produce an approximate normal map
- use the normal map to produce a depth map
- apply filters to the depth map (normalizing, changing distribution, blurring, etc.)
- use the (filtered) depth map to produce a cone map
- reconstruct a normal map based on the filtered depth map (not used by JKGM)
It can be fed one of those intermediate data textures, for example, a properly created normal map, or a hand-made depth map, and just start from there to produce the output further down the chain.

While the normal map creation is low cost (computationally) and basically instant (and also really simplistic), calculating a depth map from a normal map is very CPU intensive and can take multiple minutes per texture (once 512x512 or larger), and then generating a cone map from a depth map is very GPU intensive and can also take multiple minutes.

Once this tool is done, and I've processed existing JKGM assets into cone maps, I think I'll be ready to release. All of this already works, but wasn't in a state that could be shared, so it's just been a matter of getting it to that point. No point releasing modified JKGM + shaders if no one can produce the necessary data to feed the shaders.

---

Regarding the mipmapped texture seams, I've definitely witnessed that as well on some of the JK Enhanced models. I'll at least be taking a look to see if there's a practical solution. I assume it's due to the neutral color painted in the "unused" gaps of the UV layout getting blended in during the mipmap generation and affecting visible pixels, so that's where I'll be starting my investigation.

QM

[Jon`C]

Since you're going to so much effort, it might be worthwhile adding your generated normal maps to the material pack anyway. JKGM could ignore them for now, but normal maps would be useful for adding screen space reflections in the future (or for modernizing the lighting in OpenJKDF2).

Also, if by chance your approach could be applied to it, the same goes for a roughness-metallic texture. It is not useful today, but in any situation where you would be able to use the normal maps you would want to have roughness maps. Mipmapping is destructive to fine detail in normal and displacement maps, and roughness maps lets you treat that lost detail as microfacet scattering (which it technically is). There's a siggraph paper from either valve or square-enix that discusses their approach to computing [an]isotropic roughness from normal mip levels. It's pretty straightforward iirc.

[SMLiberator]

also envmaps when

[Quib Mask]

Merry Christmas! Barely made it before the new year when it would be too late to call it a 25th Anniversary version...

https://drive.google.com/drive/folde...GC?usp=sharing
JK_2002.ZIP password is: JK_2022

The password is to keep gdrive from mangling or vaporizing DLL and EXE files now or in the future.

---

This is just JK 2022, not the modified JkGfxMod stuff yet.

Extract the _setup folder into your Jedi Knight folder...

...then go into the _setup folder and run _setup.cmd.

For now, do this in a copy of your JK folder. The setup script tries to take a backup of important files, and running the setup script again will offer to uninstall back to how it was, but I only did enough testing to make sure it worked enough to release.

---

The DirectDraw proxy has special accommodations for the Steam version so that things will work (and even automatically launch JkGfxMod's inject.exe if present) without renaming files, etc. In other words, you can do a fresh Steam install, copy in and run JK 2022's setup script, then launch via Steam and it should just work.

The setup script also undoes some damage Steam's first-run setup does (namely it uninstalls the app compat database for JK.exe that Steam installs).

I've only tested the setup script with the original 1997 JK and the Steam version, but it gets the main executable out of the 1.01 patch installer, so it will probably work under most circumstances.

While you can delete the _setup folder after patching, if you leave it, you can re-run the setup script to verify the patch is still applied, and uninstall the patch.

QM

[SMLiberator]

nice
I couldn't figure a way to apply the patch via Linux, so I resorted to an old windows install to do that, but it was super easy then.

I'm mostly familiar with this patch as I'm (supposedly) the one person to have tested its early 2018 build back then on JKHub (and I also applied some of the OpenJKDF2 stuff via manual hex editing hehe), but neat to see this brings some new stuff.
The first, most obvious and important one is JkGfxMod compatibility - not only this works nicely (unlike the 2018 build which simply crashed when trying to run with JKGM) but it also seems to have solved the super annoying keyboard input lag that happened when framerates dropped when using JKGM coupled with JK13. Speaking of which, JKGM framerates do seem a tad bit better (haven't really compared, but it's better than I remember) on my 7yo PC with integrated Intel graphics.

Hopefully the memory leak fixes will solve the seemingly random crashes that happen in JKGR after some time spent on most maps. I do wonder what "OpenJKDF2 AI awareness fix" is about though, haven't tested thoroughly enough to see a difference. The only negative side effect I've noticed so far is that controlling JKGR cars via arrow keys seems to have been messed up somehow, I believe due to keyboard turning being scaled to framerate. Hopefully I can fix that via some simple cog tweaking.*** [Edit: jesus christ the possibilities with the new hotkey message are scary]

Glad this is out, and hope to see the JKGM tweaks coming out sooner rather than never

[Edit 2: sadly I don't see any way that can be fixed I don't see a way to tell apart keyboard turning input from mouse turning input, so I'll have to make it be either one or the other. Oh well. It's still worth it for everything else.]

[Edit 3: the keyboard (and only keyboard, doesn't affect mouse) input lag wasn't caused by JKGM, but rather by your JK2018 patch. sadly, it is present on this version.]