JK 2018     (Moderator: Quib Mask) Previous Topic | Next Topic
Page 1 of 4 Goto page 1, 2, 3, 4  Next
Post 04-Mar-2018 11:00        

Have made enough changes that I need to get things written down or I'll have to reverse-engineer my own work later. =P So leaving some notes for myself and public viewing if anyone happens by:

Revisions 01-40:
- Merged code from .text2 section into .text and removed .text2
- Relocated .idata basically back to vanilla 1.01 position
- Expanded .text section (slightly, there was usable dead space)
- Contracted .data section (slightly, to make more room for .idata)
- Rewrote global variable initialization
- Rewrote command line parser
- Added -noThingLimit command line switch to mimic Extreme Fin Warfare patch (invariant 65535 thing limit)
- Added -fullScreen command line switch to complement -windowGUI, also made windowed default behavior
- Added -abort command line switch to mimic vanilla behavior for unknown switches (JK exits immediately)
- The -? command line switch now shows an informative MessageBox before exiting (vanilla tried to send info to OutputDebugString)
- Implemented multiplayer character rank 9; host can set 9 as maximum, and character editor supports unrestricted star distribution
- Added a workaround for video loss (an issue when using DirectDraw wrappers) when alt-tabbing away and back to fullscreen
- Tamed topmost window behavior of JK main window
- Added useful COG parser error messages (sent to -devMode console)
- Reimplemented vanilla 1.0 unrecognized console command message
- Enabled some useful and non-abusable debug console commands: help, mem, matlist, ailist, aistatus, coglist, cogstatus, cogtrace
- Increased valid range for network tick rate; old 100-300 ms, new 1-1000 ms, may not be useful
- Reduced busy loop CPU usage via Sleep (JK was maxing out a CPU core, is now using ~1% CPU time when minimized / alt-tabbed, and 5-10% when focused, still getting a framerate of ~500 so arguably acceptable)
- Probably stuff I've already forgotten and will add to the list later

Post 06-Mar-2018 01:53        

Revisions 41-47:
- Expanded .rdata section (slightly, there was usable dead space)
- Implemented COM-less loading of A3D.DLL (on failure falls back to original COM-based behavior)
- Tweak to dispstats, bottom row now reads mana: #, force: name, item: name

Revision 48:
- Kludge for heap exhaustion when reading level name strings

Revisions 49-53:
- Initial particle rendering improvement
- Fixed crash in vertex rendering mode
- Lazy fix (SEH) for crash in wireframe rendering mode

Revisions 54-56:
- Video resolution defaults to maximum supported instead of minimum
- More particle rendering adjustments
- Window mode now centered instead of top-left corner

Revisions 57-59:
- Increased range of sound channels (via sound setup UI) from 8-24, to 0-32
- Subtle tweaks to mouse cursor and program icon (for my own enjoyment, basically)

Revision 60:
- Moved DevMode console to upper left corner due to centering main window
- Initial work on COM-less loading of DirectPlay (DPLAYX.DLL)

Revisions 61-65:
- Implemented COM-less loading of DirectPlay (i.e. multiplayer on Win10 without installing legacy components)
- Workaround for Win8 (and newer) PCA stupidity; resolves ERR_NEED_256_COLOR issue without having to set compatibility mode, or other garbage

Revisions 66-71:
- Further refined PCA fixes (for Win8 and Win10)
- Lazy fix (SEH) for inconsistent crash on alt-tab (D3DIM race condition?)

Revisions 72-78:
- Improved transparent level geometry rendering

Revisions 79-88:
- Implemented glowy texture pixels in 32-bit rendering
- Lots of iterations, trying to reduce or eliminate corner cases (8-bit vs 16-bit textures, with or without 1-bit transparency, things with 0x8 flag, etc.)

Revisions 89-91:
- Compacted some execute buffer filling code
- Hopefully final glowy texture pixel code
- Software rendering fix-ups related to changes to hardware rendering (for both transparency and glow)

Revisions 92-97:
- Moved 50% of 32-bit rendering code into main executable, 50% to go
- Optimized ftol, because I wanted a few more FPS

Revisions 98-101:
- Finished moving 32-bit rendering code into main executable; if you ever read this ZeqMacaw, thank you

Revision 102:
- Reorganized some code

Revision 103:
- Added a JKUP_2010-06-19 (32-bit render patch) incompatibility check and error message (since this capability is native to JK2018 and conflicts)

Revision 104:
- Added alternate behavior for jkSetSaberInfo(); if either MAT is -1, then it only sets base, tip and length (vanilla behavior is to crash)

Revisions 105-112:
- Moved global alpha value to a single variable (instead of multiple hardcoded values)
- Prepared variables for rendering blend modes
- Added command line arguments and console commands to set global alpha and rendering blend modes

Revisions 113-115:
- Implemented global variables for some rendering stuff

Revisions 116-121:
- Finished global variables for some rendering stuff

Revision 122:
- Implemented 24-bit z-buffer support with fallback (to 16-bit) behavior

Revisions 123-125:
- Implemented IDirect3DViewport3::Clear2 support with fallback (to vanilla Blt) behavior


Last edited by Quib Mask on 10-Jul-2018 19:34; edited 12 times in total
Post 19-Mar-2018 04:37        

Jeez, I want to strangle the "Program Compatibility Assistant", especially on Windows 10. I've got JK working just fine on a first run, but after exiting, Windows decides to (invisibly) set some compatibility settings that it thinks will help on subsequent runs, but they're wrong and break things. First tried some of the documented approaches to getting PCA to not kick in on an executable, but the rules change like every version of Windows, and regardless nothing actually makes the Win10 PCA leave it alone. Avoiding anything non-portable (as in install-less, not platform portability) like deleting the PCA registry key for the game after each run, shims, compatibility settings, etc. which affects my options.

Post 19-Mar-2018 14:21        

Hey, I have a question. Would it be possible to up JKs material cell limit? Right now its only 4-bit. I could do some cool stuff if it was higher.
Post 19-Mar-2018 15:49        

Better would be an in-game menu that isn't forced to 640x480 resolution...
Post 21-Mar-2018 21:11        

darthbabe96, I haven't looked at MAT-related code. Time will tell if I get a chance to. Are you positive it's JK that has a MAT cell count limit and not the tools available to edit MATs? The MAT format seems to hold most (all?) of its attributes in 32-bit values so a 4-bit cell count would be surprising.

Xzero, are you referring to the pause / main menu? It's a pain to resize due to the way all the different menu screens are made and that the cutscenes are tied to that window size. I've been exploring Win10 DPI scaling options, but haven't found anything that covers the way JK's populating its window. Microsoft has done a pretty bad job of exposing the DPI scaling stuff via API; I understand that they'd prefer a program be written from the ground up to support (the absolutely stupid concept of) variable screen DPI, and so scaling is a hack for old software, but just being able to tell Windows to scale a window to be x2 or x3 size and lie to it about its size, position and mouse coordinates sure would be useful.

Post 22-Mar-2018 16:07        

I have actually done lots of work with multicelled materials, primarily my muzzle flash mod. Never have I gotten a mat with higher than 16 cells to work. Unless someone else has gotten it to work higher, I have found that to be JK's cell limit.
Post 22-Mar-2018 19:55        

Since we're talking about weird limits here, could the number of joints defined by a puppet (in the "joint" section) be increased? the maximum number appears to be 9
Post 01-Apr-2018 09:38        

Well, I've made a mark for myself in JK's code for both where MAT files are parsed, and the part of PUP parsing where the joints section is parsed, so if I get the chance to explore either at least I've got a starting point.

My JK free time had been focused on wrapping up Win10 compatibility so that ten years from now once I've been forced off Win7 (due to lack of hardware compatibility) I won't have to redo this whole process to play JK again, but, while I think I got that all nailed down, I got distracted with the thought of finally forcing in screen space shaders, so that's been quite the rabbit hole. Ancient DirectX docs, lots of decades old discussions on undocumented aspects of DirectDraw, digging up my old D3D9 shader stuff. Not sure anything will come of it but it's been fun research that's yielded lots of unexpected golden nuggets (like a proxy-based hack of D3DWindower).

Post 12-Apr-2018 18:50        

I'm really curious to see what came out of z-buffer experiments. Does that mean fog effects really are possible???? Mr Green Also, could this somehow be used to fix JK's problems with rendering things behind transparent pixels?

Also I wonder, is there any reason in particular why JK2018 is not being based upon JK2013? I mean, the sabers and the default FOV in JK2018 look the same as in unpatched JK. Will these JK2013 features be brought in in the future?
Post 12-Apr-2018 18:55        

Also, I know this is not what you're currently focusing in in your JK time, but I came up with a somewhat versatile and very basic solution to custom savegames that would involve file input/output. From my (albeit very limited) programming knowledge, I believe such things could be somewhat easily implemented.

File input/output related verbs:

* bool = SetConfigFile(string filename);
Sets a CFG (text) file to read/write user-specific info from/to. This file should be created inside the Mod directory (the one set in the "-path" line) or the Resource folder by default. Returns 1 if file is found and loaded successfully, returns 0 and creates a new file with that name otherwise.

* flex? = WriteToConfig(string linename, linevalue);
Writes a new line in the specified CFG file (as set by SetConfigFile()), containing a variable name and it's value. If line with that name already exists, update its value instead. Returns the old value if line already exists. Returns 0 if variable is not found and -1 if no Config file is loaded.

* int = IsConfigSet(string linename);
Returns 1 if a variable with that name exists in the CFG file specified by SetConfigFile(). Returns 0 if variable is not found and -1 if no Config file is loaded.

* flex? = ReadFromConfig(string linename);
Returns the value of a specified variable in the CFG file specified by SetConfigFile(). Returns 0 if variable is not found and -1 if no Config file is loaded.

Example use:

      WriteToConfig("playerRank", 8);
      WriteToConfig("playerCoords", '0 1 5');
      WriteToConfig("playerSector", 31);

Would write a file called "PlayerInfo.cfg" in the mod directory containing the following text:
      playerRank = 8;
      playerCoords = '0 1 5';
      playerSector = 5;

Then later running...
      SetInv(GetLocalPlayerThing(), 20, ReadFromConfig("playerRank"));
      SetThingPos(player, ReadFromConfig("playerCoords"));
      SetThingSector(player, ReadFromConfig("playerSector"));

Would set the player's Inventory Bin 20 to 8, the player's position to '0 1 5' and the player's sector to 5. This could be used for providing a custom game saving system, allowing a player's settings, inventory and other stats to be kept even when switching episodes or after leaving the game.

You could also write extra config settings in these files beyond anything JK normally offers. Say, you could write to cfg files for use by whatever level or Mod cogs you used these settings on. Say, you could have a custom "rainDensityMultiplier" for levels that use auto-generated rain, or "corpseRemovalTime" for mods/levels that automatically removes corpses after some time.
Post 13-Apr-2018 14:26        

That would be way cool, LibSa.

Also very curious about the z-buffer. That would be epic if transparent pixels quit acting like poo in game. That would simplify so many of my mod ideas.
Post 14-Apr-2018 04:57        

ZBuffer won't do anything for transparencies, it just shows you the depth of opaque geometry. To fix transparency we'd need to change the sorting/drawing order of surfaces.

Also LibSa I like the config idea, it seems rather easy from a user standpoint. Implementing it on the other hand...
Post 15-Apr-2018 00:05        

Ok, lots to answer, here we go...

I don't actually remember exactly which JKUP variant JK2018 (working title) is based on. I thought it was JK13. It should be whichever version Xzero modified for glowsaber fanciness. While I haven't yet, I'll be integrating 32-bit video mode support into the patched executable so that ZeqMacaw's JKUP2010 ddraw proxy won't be necessary. I'll likely add automatic FOV adjustment to the game's code. I've already written a checksum passing COG that adjusts mipmap / LOD ranges that I'll be including (so that its user configurable, though my default has been good for all but one level I've tested in because said level had a skybox with mipmaps, though it is based on my preferred resolution). I won't be including anything that doesn't pass checksum and that affects gameplay, so if JK13 included glowsabers, etc. that is outside the scope of JK2018.

I don't intend to add any COG verbs. For one thing, I don't have the COG extensions DLL source code. I also only have so much time and I've been spending it on whatever has suited my fancy, and that's been graphics engine fixes and tweaks, sound engine fixes and tweaks, modern OS compatibility, and information output (COG error message, in-game commands). Some stuff, like enabling rank 9, was a side tangent that happened just because I stumbled on that code while doing other stuff. I love COGs, they're what really got me into programming 20 years ago, but new COG verbs just isn't on my agenda.

Now, for the neat stuff...

Jedi Knight uses execute buffers, which is an ancient, arcane part of DirectX. They're not actually that hard: create one, fill it with data and commands for the renderer, then tell it to be executed.

JK renders 3D stuff in 4 stages:
1: opaque level geometry
2: things
3: transparent level geometry
4: first-person weapon model

For each stage, it sets render state stuff (via execute buffer commands) that includes (among other things) whether the Z-buffer should be used for culling and whether it should also update the Z-buffer. The vanilla scheme for the 4 stages is:
1: use z-buffer, update z-buffer
2: use z-buffer, update z-buffer
3: use z-buffer, update z-buffer
4: don't use z-buffer, don't update z-buffer

I've changed stage 3 so that it uses the z-buffer, but doesn't update it; while this was a one byte change, tracking it down took me quite some time (on the bright side, I know quite a bit about JK's rendering now). This allows any number of transparent surfaces to overlap without making farther ones go invisible. Still in the testing phase on this. If someone wants to help they could make me a level full of transparent walls and things, ideally with a wide variety of textures and odd geometry (or point me to an existing level with transparency rendering issues).

This doesn't affect things with transparent surfaces; still exploring options for that. It also doesn't affect the gradient alpha that occurs on non-transparent surfaces that have a texture with binary alpha spots. The gradient part counts as opaque for z-buffer purposes, only the fully transparent part doesn't write to the z-buffer; probably no realistic way to improve that.

For stage 4, it ignoring the z-buffer completely is why face ordering matters for correct rendering, but is also why your gun doesn't poke into a wall if you press your face into a wall. It would likely be possible to clear the z-buffer between stage 3 and 4, and enable z-buffer use for stage 4 to correct first-person rendering issues, but isn't something I've tried yet.

As for distance fog, based on the documentation, there should be execute buffer opcodes to enable and configure it, but I haven't experimented with it and am not sure how to implement controlling it. A fog entry in a level header? Doing so via COG might be really onerous (I think you'd have to set global variables that would get picked up during the next rendering pass).

Post 15-Apr-2018 01:04        

Uploaded transparent level geometry comparison images. For best results, open each image in different browser tabs (or windows, whatever) that you can flip back and forth between.

*** Post commands are unavailable for guests. ***