Printable View
https://forums.massassi.net/vb3/atta...chmentid=28531
Star Wars: TODOA - formerly known as The Truth of the Destruction of Apocalopolis - available for download on ModDB.
---------------------------------------------------------------------------------------------
At any rate, here's the cheapest solution (bypass) for the waggle issue
https://www.dropbox.com/s/ncwx3gqmcz...Waggle.7z?dl=0
I posted v0.1.0 beta last night. I also made jkhub and moddb profiles to help get the word out.
I think JkGfxMod is stable enough at this point to replace dgVoodoo for regular use (at least, I haven’t heard of many major issues lately - other than the Steam shipping exes being broken, which is fixed by jkversions).
I noticed that jkhubs sticky announcement still points people to a wrapper that doesn’t actually work, and the main post of this thread hasn’t been updated in forever. I’m also not sure what the Massassi main page news process is these days. I’ll keep tilting into this wind tho. ¯\_(ツ)_/¯
Oh yeah, I guess at this point a new JK issues thread should be started and this one closed - to stave off confusion.
I really need to try out those new Steam JK installation instructions on my other computer, even though I've previously installed Steam@JK on it as well, so I can't get rid of the run-as-admin/compatilibity mode stuff even on that one.
All this said, I really wish there was a MotS Neural Upscale texture mod so I could link MOTSGFX2019 to the Neural Upscale mod as well
:ninja:
Well, I suggested "closing and unstickying this thread + starting a new one and stickying that one" to GBK, he just kept on playing the theremin - only stopping to say "That sounds pretty dumb, man." before continuing.
Nice screenshots! I should play through the regular JK SP campaign with these graphics mods sometime.
JkGfxMod v0.2.0 beta is up.
This version adds:
- antialiasing (MSAA and SSAA)
- more accurate lighting and color effects
This version removes:
- some SSAO artifacts
I'm not sure how exactly did the graphics change (should take screenshots), but 16 x SSAA did make TODOA lag in a sluggish (instead of stuttering) way.
Also, Jon, what do you think of this converter? https://bit.ly/30NrptR
That is an insane amount of supersampling.Quote:
Originally Posted by Nikumubeki
Personally I use 8x MSAA with min_sample_factor of 0.25 (8x MSAA with 2x SSAA). That's enough for me.
Also, I was going to work on a more-or-less complete JkGfxMod patch for TODOA (to commemorate its 10th anniversary later this year), but a lot of its light textures didn't originally have emissive texture maps available, so that was the end of that.
If anything, I think I'll try to whip up another 2-minute post-DXN-style FGR level for the anniversary.
Or not, I'm once again conveniently forgetting about adjoins and texture U/V numbers.
That said, I do have at least 90+ textures for which I have to make the emissive textures myself (instead of being able to dig up the original emissive textures from the original texture ZIP files), and having to convert each MAT to a PNG one by one is quite laborous.
(Not as laborous as having to get over the countless instances of "why did 2009mubeki use this texture instead of the other one goddammit")
To make things worse, poking through TODOA's .gob files led me to rediscovering these deleted scenes that were removed/truncated since I couldn't get voice actors for them in time:
https://vimeo.com/339289366
https://vimeo.com/339289250
Both of them of course brimming with "ha-ha! FGR is referring to the comments that the original TODOA got!", so in the long run it's a good thing I got rid of them.
I wish you hadn't deleted that side by side comparison.
I'll probably make a new one once I've made emissive textures for the remaining ones in the area, still haven't found the original texture files from my backups (still hoping that I don't have to make one myself, there's a lotta lights in that one).
Lessons learnt: Just cranking up the lightness etc. values to have only the brightest parts of the texture visible doesn't exactly make good glowmaps, but they'll do for this (after all, 2019mubeki would use different textures altogether among other reasons why there will never be a proper TODOA Special Edition):
[New comparison]
Also, in a similar fashion to the envmap question, it's probably not possible to implement Half-Life 2 style water shaders in JK with the injector?
What are Half-Life 2 style water shaders?
Water that'd look like this pretty much https://developer.valvesoftware.com/...owmap_user.jpg
(Or like this, for that matter: http://www.jkhub.net/project/show.ph...q6GvytXCYu.jpg)
Then again, in that Wiki's water shader page, it says "Expensive water reflects and refracts the world in real-time, while cheap water uses an $envmap and does not refract" so maybe nvm on this
That said, Jon, is there really no easy way to fix the transparency/rendering issues of first person view that aren't present (anymore) in the third person view? It's namely an issue if there are FreeColorEffect(); tints in, well, effect - but it's also apparent in saber clashes against the Dark Jedi
Attachment 28500 Attachment 28501
Saber clashes are additive color effects too, same as addcoloreffect.
That shouldn’t be happening at all. Can you open an issue on GH so I don’t forget?
Thanks to Cheap FGR Solutions Incorporated™, TODOA has never had 3rd person mode enabled for non-saber weapons, so I don't have to worry about the guns appearing weird in his hands.
This is close enough, and as far as I'm gonna be concerned, with the sabers:
Attachment 28505
Attachment 28502
Attachment 28503
Better comparison montage (original, TODOA TC, TODOA 2019):
Attachment 28504
Check dat TODOA 2019 out: https://forums.massassi.net/vb3/show...=1#post1227270
It's nice that the download count of JKGFX2019 has exceeded 500: https://www.moddb.com/mods/jedi-knig...oads/jkgfx2019
(Of course, considering how that mod is essentially by Shred18 (JKE), darthbabe96 (all the original texture/COG/etc. work for the Muzzle Flash mod), SMLiberator (fixing the cogs and providing the neat resources) etc. - and it only works with Jon's JkGfxMod - it doesn't really count as an FGR mod so it doesn't go in the obituary)
I also like how MOTSGFX2019's download count has exceeded 200, which in JK/MotS's scale is as if a Skyrim mod or something had 20,000 downloads.
(And in JK<->MotS terms it's also pretty good, usually the MotS version of a JK mod with 500 downloads had like 4 downloads or sth)
Just to confirm, Jon: Envmaps (or more advanced shaders like that) - whether fancier water or just shinier surfaces - aren't possible to be enabled with the injector?
Nothing has happened to change my earlier answer.
A'ight
Well, if anyone wants to take a shot at upscaling JK's FMVs:
https://www.moddb.com/games/star-war...oads/jkdf2fmvs
I'll see what I can do, FGR.
Jon, I need help with something
I'm working on an "interceptor" of my own for JKGR to act aa an external game loader/saver. What it does is scanning JK's memory for desired values and storing those values in an external file. Upon restart, these values are then injected back into the game.
However, I'm having a problem with variable formats - it seems like there's a problem when converting ints used by JK to floats as stored in the save file and back again into JK. Even though values appear correctly in the saved file, it's pretty hard to tell if they will be injected correctly back into JK. I found I can go around the issue by setting all relevant variables as flex in cog headers, but that's probably not the best solution.
How would you solve this issue? I suppose I should store the variable type into the save file as well, but I don't know how JK keeps track of these.
Here's the source
No idea, sorry. I’d guess a cog value is a 128-byte struct along these lines:
but I haven’t ever tried disassembling jk.exe or reverse engineering it to that end.Code:struct { enum type; union { int i; float f; struct { float x, y, z; } v; } }
If you know where and what value the type field should be, you probably don’t need to write it to the file though.
Okay, I think I got it. I simply added an extra field to the save files specifying whether a value should be loaded as an int or as a float. The reason why this needs to be stored at the save file is because the loading part doesn't know what exactly is being loaded, it just injects whatever is written in the save file back into the game. The saving part on the other hand needs to know what sectors of memory it wants, and for that I'm setting relevant memory offsets manually.
An interesting thing I've done is that the memory offsets which are considered "relevant" aren't hardcoded, but rather listed in an external file. The reason why I did this is because every time you change something in the mod files it's very likely said offsets will change, so if those were hardcoded I'd have to make a new version of the program for every little change I made to the mod files, while now I just need to add/remove/change info from this external file (and I can keep track of them via CheatEngine or something).
Edit: Nevermind, didn't get it. It's slightly less chaotic now than it was before, but it's still not right. It seems this is a result of JK changing variable types dynamically. The inconsistency is killing me.
So, about JK's particle system: Any way to fix that so that the particles wouldn't be square-shaped and single-colored, but would use a(n emissive) texture instead?
Especially when something like jkSetPersuasionInfo(); spawns the "Force Persuasion particles" that utilize a texture, so they actually look competent as opposed to JK's own in-built particles. So of course something like that is hard-coded to the engine...
AFAIK, the only adjustment anyone has been able to make to JK's own particles was rotating them by 45 degrees so they'd be diamond shaped. Sure, it looks nice with non-JkGfxMod versions of JK, but not with JkGfxMod.
Unfortunately no. There’s no reliable way for me to tell whether a particle is being rendered vs anything else, and no way to tell what material to use even if I can guess that.
For that case in particular, those aren't particles but rather sprites. You can change its properties in its spr file (I think it's twinkle.spr or something along those lines) and change its geomode to 4 (textured) from the default 3 (solid). Not only that, not only that effect uses sprites, but each and every one of them that appears is a different thing with a JKL template. The template name itself is hardcoded, but you can change its properties to whatever you want. Now that I think about it, it would be great to have a verb like "SetThingTwinkleTemplate()" or something.Quote:
Originally Posted by Nikumubeki
Oh yeah, I'm just wondering if there could be an "easy" way to replace all of JK's particles with the sprites without having to edit almost every COG (and JKL) in the game to remove all instances of JK's particles and replace them with a new "sprite/3DO spawning particle system".
https://www.nsa.gov/resources/everyone/ghidra/Quote:
Originally Posted by Nikumubeki
and 5 years of free time
Well, or you could use IDA Pro.
Edit: Here's some source recovery stories
Some folks recently did source recovery for Super Mario 64:
https://gbatemp.net/threads/super-ma...mpiled.542918/
which apparently didn't take too long because the executable wasn't compiled with optimizations. Visual C++ 5's default release configuration had full optimizations enabled, so just a wild guess that JK.exe is fully optimized, so it would be a lot more work.
Someone else recently did source recovery for Diablo. Which apparently didn't take too long because Blizzard accidentally shipped a debug executable (no optimizations) and Sony accidentally shipped a file containing debug symbols. There are two different compiled JK.exes and I assume neither of them are debug, otherwise someone would have mentioned it by now. Visual C++ 5.0 and up compiled symbol data into a separate file by default, and either LucasArts knew not to ship it or InstallShield was smart enough to warn you if you tried (I would guess both, I haven't tried InstallShield in about 18 years but I remember it was pretty damn near fool-proof). No help there either.