That said, Jon, if you have ESRGAN'd all textures from JK and MotS (MATs and 3DO\MATs), you could still send them my way for I'd always have use for them

Also here's some Solitaire scores:

[Unable to find specified attachment]

Ideally I can get a graphics interceptor working, in which case they’d be useful for pretty much everybody.

By the way, this process is definitely NOT aided by Microsoft’s psychopathic choice to scour all legacy DirectX documentation from MSDN.

Alrighty



... Was that Indiana Jones game even released?

Why would they even do that?

I mean, there’s a bunch of scripting I’d need to do in order for the textures to really be useful to you. I’d be willing to upload the model somewhere if you wanted to mess with it, but before I do that scripting and upload a gig of textures I’d like to have some idea about what form that upload should take. In other words, if I’m gonna do this, I’d rather do it once.

I don’t know.

I'll admit that I did take a look at ESRGAN myself at one point, noticed that it seemed to involve compiling Python code files, so I backed away. >_>

But yeah, no hurry whatsoever with this (current expected target audience for these textures: me and one or two lurkers)

... Come to think of it, both TODOA and DXN only became what they are thanks to the coders who assisted me* with them since I couldn't figure out any of the actually cool stuff on my own, whereas I didn't have such a "house coder" for my costly UE4 attempt which was a large contributor to its failure.

Oh well.

That’s kinda why I’m trying to do this graphics interceptor. The target audience then would be more like 5 or 6.

Dunno if I said, but a working interceptor would be able to do like... a lot. The extent of what you can do mostly depends on what data is in the command buffers (still not sure yet) but stuff like texture replacement, emissive channels, and simple postprocessing effects are all definitely possible if this can be done at all.

Like, I don’t think you’d be looking at PBR materials, but 24-bit color and HDR for sure. Maybe proper sorting for transparency.

Direct3D5 IM did have high ambitions of hardware T&L tho, so if it does turn out that the JK devs used the built in T&L then a lot more cool stuff becomes possible.

Edit: example, if it turns out they used th me D3D5 point lights instead of their own vertex lighting code, then per pixel lighting and normal mapping end up on the table.

This is sort of why I’m willing to try doing this now, because with the texture upgrade there’s enough you can gain that it’s worthwhile even if most of this extra stuff isn’t possible.

I vaguely remember asking Xzero if he could have implemented proper translucent surfaces in-game, utilizing the "separate rendering layers" e.g. how the first-person weapon mode is on a "separate layer" than the rest of the game.

(IIRC, he said that he'd try to check it out, but then he got hired by CryTek and that was the end of that. Maybe!)

The “separate layer” is probably just a zbuffer clear. As long as JK isn’t doing anything too smart about culling objects the issue should be fixable just by sorting the faces as they come off the command buffers.

Edit: oh right, I forgot. First person weapon polys have to be sorted back to front. It’s not even a z clear, it’s literally just turning off depth testing.

I have no idea wtf IDirect3DTexture::Load does. Does it copy from other texture or something? The interface is baffling.

I have a 23 year old Direct3D 5 book that was obsolete when I bought it, ironically this is the first time I could have ever found use for it but it’s gone missing.

Seems befitting for something JK related.

But yeah, the "layer" thing with its proper transparencies was one of the reasons why I never liked the Seifer cog weapons - the other main reason being that the weapons got stuck in walls.

Jon, QM goes some through some rendering layers/directX related stuff in this topic for his JK2018 patch. I have no idea if any of this could be useful, but just in case.

Interesting! I didn’t know anybody has been working on anything like this. His approach is probably a bit more challenging than detouring createdirectdraw like what I’m doing.

Seems to line up with what I’m seeing so far.

Edit: if I understand correctly, what y’all are calling “layers” are usually called “passes” by graphics programmers.

If you had an ati graphics card way back in the 90s and wondered why grates looked so different, I think I can now explain why.

JK turns on alpha testing and alpha blending at the same time. This makes no sense. Ati drivers were arbitrarily choosing to prioritize alpha testing, while 3dfx and nvidia drivers were arbitrarily prioritizing alpha blending.

From some of the other renderstate ops JK generates, I’m not sure the developers ever intended for non-translucent adjoins to be rendered with alpha blending (/ proper depth sorting). They also turned on stipple alpha. Besides shedding two vector multiplies per fragment, stipple alpha means you don’t need depth sorting. I’m not sure what hardware they tested Jk on but it must have been very strange by modern standards.

Edit: they also turned on fog, even though the fog table mode is off (it would have been fairly trivial for them to expose this to cogs/level headers, and I’m not sure why they didn’t). They also turned on shading and specular even though they’re doing all of their own lighting. I’m not sure whether turning on all of this stuff had a performance cost back in the day. If nothing else, the cache pressure of putting excess crap in the command buffers.

Maybe they intended to use the T&L features in hardware mode but ran out of time. It certainly would have looked better than their homegrown lighting and clipping, especially since they never got clipping to work right with their vertex lighting.

Shouldn't Wine have some old DirectX documentation? They more or less should've already done the work.

I’ve been able to reverse engineer everything the hard way... except for where the friggin texture data comes from!

JK is locking a system memory surface, copying a row of zeroes into it, and then loading it into a hardware texture. This would make a lot of sense if the data it’s copying weren’t all zeroes, which it is.

Current interceptor status



so far I've fixed some minor developer mistakes in the original game:

- Uses premultiplied alpha. Textures are converted as they're loaded. This fixes the dark fringes around sprites and grates. (Injected textures should have alpha premultiplied on disk as part of the packaging process. This is unconditionally what you want, so there is no reason not to do this.)
- Uses a linear colorspace. As above the textures are converted as they're loaded, from the exponential colorspace used to create them (i.e. a monitor) to a linear colorspace appropriate for blending (i.e. a video game using bilinear filtering). This makes it look "better" in a way that's hard to put your finger on, unless you know what you're looking for. (As above, injected textures should be stored in a linear colorspace.)

I, uh. I guess that's it so far?

It needs a lot of fit and finish before it's usable, but it's pretty neat to see a proof of concept working. This is definitely feasible.

Edit: no, the bloom isn't permanent

So far, this is basically what I'm thinking for the texture injection:

- Inject materials instead of textures:
-- Something like an extreme subset of principled BSDF.
-- Albedo texture (32-bit RGBA)
-- Albedo factor (vec4)
-- Emissive texture (32-bit RGB)
-- Emissive factor (vec3)
-- Occlusion texture - maybe? (8-bit, possibly stuck in the alpha channel for the emissive texture)
-- Metallic roughness - MAYBE. The JK engine does populate the specular color on vertices, but so far it only really seems to be used for saber flashes and additive color effects. It might be possible to do something with this, but I'm not convinced it would pay off yet.
-- Normal mapping, displacement mapping - lol. I'm honestly just a little tempted to throw in the kitchen sink, just in case someone figures out how to deliver the extra data that's needed. In other words, the material format should be extensible. Future versions should be backwards-compatible and should populate earlier materials with sensible defaults.

- A texture pack would provide a MAT-to-material mapping
-- Something like MD5 or SHA1 hashes of the raw 16-bit texture data, to a material name/unique ID
-- It would need to provide one entry for every possible variant (colormaps * mipmaps).
-- These mapping files would be loaded at startup.
-- If a matching texture is loaded, the material is silently substituted.
-- If the texture doesn't match anything, use the converted 16-bit texture with a default material (albedo only, albedo factor 1, emissive factor 0).

- Some catches from the editor (person) side:
-- Some of the above isn't user friendly. I'd write a tool to automatically generate the mapping files.
-- Non-unique source MATs in the game would need to be replaced with something that always exhibits a unique signature.
-- The engine converts color-only MATs into vertex colors, so those MATs would also need to be replaced in order to inject a material (either the MAT file or the model/level that uses them). This would be particularly useful for projectiles, which can be made to look ~like the movies~ with bloom and a high emissive factor.
-- If people ever made mods designed around injected materials, they would still need to use placeholder MATs. Those MATs would indicate which actual material is being used, plus would probably be important for editing the levels since you wouldn't be able to see materials in JED.
-- Might be good to start thinking about creative ways to marshal data back into the injector from JK. Many modern features are blocked solely on getting the camera and light positions out of the engine. This game is 23 years old, so there is an awful lot of low hanging fruit around here.

Could you also fix the stupid HUD scaling on large resolutions? The HUD is barely readable at 1920x1080 and even less so at 4k.

Also,



I'm still flabbergasted that Pogs made any kind of an impact. I remember seeing an advert for them on the back cover of a Donald Duck magazine in 1995 or so and thought that they were stupid - flash-forward to 2007 when I discovered TVTropes and found out that Pogs actually were a thing. Luckily not a lasting one, but why were they ever a thing in the first place I mean for f***ing out loud-----

I tried to explain Pogs to my son... it was really funny. He went through the pokeman phase and when we walk by the display at Target or whatever he still walks slower and gazes at them. But he doesn't ask me to buy him cards anymore so that's good.

When I was a kid we bought garbage pail kids. But only for a few months and then everyone lost interest. That's really the only thing I can remember collecting (well, postage stamps but I never told anyone). Once I got an NES it was all over. Prior to that my brother and I used to wait every week to get our $1 allowance and then we'd ride our bikes about 2 miles to the nearest gas station where they had a Double Dragon arcade machine and we'd play the hell out of that thing.

I lived in Renton from the 5th to 8th Grade. 1108 S 22nd Ct, to be precise. I used to ride my bike down to the arcade, Command Center, all summer long. Ice cold AC and video games. It really sucked going home because not only did that mean that I was out of money but it was uphill going that direction.

I never thought there'd exist a game literally called "Faces ...tris III", but hey. This is the universe I'm in. Okay then.

I don't know what that is but it's cool

Reid when are u going to fix the bowcaster informant issue in Spaceport https://www.massassi.net/levels/files/3128.shtml

There's a ton in that level I'd like to fix. It was probably only 20% complete by my original vision. In fact it's basically a demo compared to what I originally envisioned.

Also I remember your review and I'm glad you noticed the cog which makes the shopkeep attack you for stealing his stuff!

I remember wanting to make a trapdoor that dropped you into a hallway, where a Star Warsy forklift tried to crush you and you had to slash out grates to get out. Plus some back alley gangs and such. Had to cut so much..

Also, anyone ever figure out how to make affine transformations decent in JK using Cogs? Since the developers apparently couldn't figure out how that works. IIRC you use a small 3do as an anchor point with an established difference vector from a 3do you want to move, and then you move the anchor 3do and move the other 3do with it based on that difference? Some jank like that.

Reid, I don't get exactly what you mean by affine transformation, being that JK can only do rotation and movement. I'm pretty sure attachments could do the trick for movement, but JK's handling for thing rotation is pretty terrible. IIRC when a thing that has something attached to it rotates, instead of rotating around the same pivot as the "source" thing, the attached things will rotate around themselves too, and it looks incredibly stupid.

As for resizing, it can only be done with custom verbs and it's pretty unreliable as thing's size will be reset every time it rotates. AFAIK I'm the only person who has used resizing in a level or mod

Basically - a rotation paired with a translation.

The area with the rotating thingies in TODOA remains in my list of Top 3 FGR Game Archi: https://www.youtube.com/watch?v=gTeNJreWQAM#t=4m06s

(Not to mention that Xzero explicitly told me that he was impressed by it)

(G'times)

Also, I remember AttachThingToThing(thing1,thing2); working pretty well in my projects

Elmo's The Lost Mercenary recreated the trash compactor scenario from ANH pretty splendidly. [/wink wink]

Also, the latest version of a bloody cool TC for Duke Nukem 3D (made by a DXN collaborator) has been released:

[Unable to find specified attachment]

https://www.moddb.com/games/the-amc-tc

Affine is probably the wrong word in many ways, since the linear transformations in JK are a strict subspace of all linear transformations (since they're angle/distance preserving), but I mentioned affine because I wanted to include translations.

In any case it's probably wrong because what's weird in JK is creating an interpolation between two thing frames which doesn't look janky. IIRC all JK does is linearly interpolate at a constant rate between the angles and position vectors separately. So if you try to make a door rotate naively, the door will slide over before rotating and do all sorts of weird crap. And creating a series of thing frames for the door to follow along a circular path that it appears continuous would probably break JK. So your only option was to use another thing and "attach" them, whatever that means, getting other janky results.

Things also have an "anchor point" - don't remember what they're called - and you can create a new door 3do which has the anchor point where you want it to hinge. This lets you smoothly rotate the door, but JK literally does not recognize collision as the door is rotating, so it's not an option for anything you'd ever use a door for.

Basically the JK engine is crap for not having commands like "rotate relative to a point".