The Still New What Did You Last Do Thread

[leileilol]

UT's skeletal animation was a late bonus pack addition IIRC. It's also put in there for the PS2 version to save loads on the memory since vertex morphs are bloaty

[Marisa the Magician]

About Unreal's model format, I assume that's the same format as the UT99 one, except for some very minor changes to the format. One thing I found interesting was that the model format in the package files don't really seem to have much in common with the model format Marisa used for her Doom UT mod. I had hoped I could just have used her loader code as "documentation" for it, but that approach didn't work.

Yeah, because that's the "compiled" model once it's imported into packages. With precomputed bounding boxes and spheres, animation sequences, textures, scaling, offset, rotation, etc.

[Captain J]

Cacoooooomerang

[Kinsie]

UT's skeletal animation was a late bonus pack addition IIRC. It's also put in there for the PS2 version to save loads on the memory since vertex morphs are bloaty

Yeah, it was implemented in Bonus Pack 4 with the accompanying Xan Mk2 and Warboss player models. I think there was also a third-party mod to implement it separate from the Bonus Pack for whatever reason?

I do wish that there was more reversing of the PS2 formats out there, it'd nice to play through Deus Ex with some of the extra motion-captured animations from the PS2 version.

[dpJudas]

Trying to get UT to render the preferences dialog has forced me down a rabbit hole. The preferences assumes that the player pawns are fully booted. This in turn meant I had to boot all the level actors and implement the Actor.spawn function. Many many hours later here I am with the map loaded, a pawn spawned (that guy without a texture) and unrealscript now rendering the HUD.



Unfortunately I still can't enter the preferences dialog. Some parent reference is still null. Overall I'm pretty happy about the entire thing NOT exploding from ticking all the level actors.

[Rachael]

Wow ... that is pretty fricking sweet

[Gez]

Cacoooooomerang

That caco needs to learn about TOOM.

[dpJudas]

Almost got all of the dialogs working now

[Rachael]

This is looking really nice!

[dpJudas]

I do wonder how far I am from having an actual game working at this point. Seems there are almost no bugs left in the VM itself. If I implement enough of the native functions will the game play?

[Rachael]

You're such a tease.

[Marisa the Magician]

Oh, my excitement cannot be contained.

[KynikossDragonn]

It would be funny if you had something that was conformed around 224, compatible to 225 and then I'd just have a Unreal 1 client that is more robust and runs natively under Linux since Wine as of late has this really annoying regression where "WaitForCriticalSection" just hangs forever and it doesn't seem to just, forcefully wake up from whatever.

But hey I'd settle for something that let's me use UnrealScript so I can actually make my own standalone game finally.

[leileilol]

I hope it also changes the game speed depending on my CPU's dynamic clock rate!!!

My big hopes to see out of this, if it's far enough, is either running it natively on ARM (the Pi's can absolutely not run any Unreal Engine anything), or there's an odd gratuitous DOS port of it (with a software renderer) like there had been for the recent iphonandroid Sonic implementation reimplementation.

By the way, if there is a software renderer, there's an old kernel filter technique bit on flipcode some 21 years ago contributed by some tim dude. Engoo uses a loose derivative of this by Fabien Sanglard.

Another confusing thing about UnrealEngine1 is that the brightness adjustment's never consistent between renderers. This is how I understood it IIRC:

Softdrv: Increase intensity of lighting lookup
GlideDrv: Use 3dfx's gamma correction functions
D3DDrv: More combine, similar to softdrv
OpenGLDrv: Adjust lightmap, but scale and have a clamp because it's blended subtractively (Quake2-ish)
SGLDrv: nothing

and then there's the confusing matter about overbrights
SoftDrv: yes
GlideDrv: No if multitexture, yes if not/og glidedrv (lightmap blended as src_color/dst_color)
D3DDrv: No
OpenGLDrv: No

Then there's arguments about the "true rendering" regarding GlideDrv whether it's correct or not (usually sky lightmap combine arguments), since even between different Voodoo hardware and Unreal versions, it's not the same, and that's affected rendering inspiration for Kentie's drivers and Donhal's drivers. I personally prefer the original Unreal release regarding this matter, as it's got GlideDrv with overbrights looking similar to the software driver, working subdivided "smooth" models, an unclamped lightmap, etc. Also for the sky arguments, the skies were among the last things done for Unreal's original maps, so errors in their construction may be another matter.

[dpJudas]

Theoretically it should run on ARM, or DOS if you can find a C++17 compiler for that. It probably would require someone investing some time into reducing the CPU and memory requirements though. Unlike the original engine, I haven't made any efforts for speed or memory. Right now I just want it to run the game at any frame rate.

About Unreal 1, I'm not entirely sure how compatible UT is with that. My understanding of it is that they're pretty alike with only a few "if package version < XX" statements required to read the data. And then I imagine that the static mesh class (base class of LOD and skeleton meshes) actually is used there.

One of the biggest differences between my implementation and the original engine is that all the script objects aren't sharing variables/memory layout with their C++ counterparts in my version. If you look closely at classes like Actor.uc you'll notice that one of the class variables is a placeholder for the 'vtbl' part of a C++ class, and that this naturally produces a problem once you go 64 bit as the size of that thing is no longer 32 bit, but it is still an 'int' in the scripts. None of those problems are present in my version. I could imagine that this also makes it easier to support Unreal 1 and UT in the same code base if they added new C++ members to the classes between the two.