Wow ... way too many different topics at once. We really need to sort us, I think.
First: awesome clip! Too bad you don't have the models anymore, they would come in handy. Luckily they aren't very complex. I've never done UV mapping and unwrapping though. So for now I'm working just with different materials and shaders. It does work quite nicely and helps in keeping the "clean" look. Little details like the bolts in the X-strutted walls as actual meshes are no problem anymore. We can rebuild him, we got the technology.
Yep. I did model them back then but it did drag performance down a lot. Especially adding the later particle emitter & physics caused some issues with performance. Last thing I did was a full rendering rewrite to use a different approach that was at least a decade too early - I tried to do scene culling and full instancing on the GPU. Turns out 11 years ago GPUs were really terrible at that. Ran at 6-10 fps for that first room.
That kind of broke my resolve at the time.
> Can't send them by email since the virus scanners don't think 30600 files is reasonable.
Want me to put up a platform for sharing that stuff? Got one or two server available. Don't think Github would like that amount either

on
If you have a server I can dump some stuff on that would help. I'll try to get all shapes & level renderings uploaded that I have. Will also see if I can add one more tool to generate a HTML overview of <entity> plus typeinfo and associated usecode.
I did spend a bit of time looking through the files and splitting them up into modeling difficulty/style/knowledgeset. I have the groups eastereggs (which we do not recreate), guns, humanoids, mechanical, effects and objects.
Guns have 5671 bitmaps, which correspond to ~12 different models to be created.
Humanoids have 15952 bitmaps, which will be about one rig to be created, plus ~20 models with that rig, and a bunch of animations.
Mechanical has 3246 bitmaps, which are ~100 different kinds of things (mechs except android, turrets, guns, cameras, chairs - anything that has all vertices tied to one bone, so no real skinning, and simple rigs)
Effects currently has 1514, which will probably be replaced with shaders and some other trickery to make it look nice. I have some youtube videos on what I had then for teleporting, and I think we can do that instead of making an image sequence ;-)
Then objects has about 4200 left, most of which are actual objects. All rotations of an object count separately, so this is still a few thousand but not quite 4000 actual things to make. To use in the engine I'd suggest auto-generating them as bounding boxes with a texture listing the object ID / number, so that we can see which ones we see in the engine to know what to model next. As with the other thread on the secondary thresher gun model, a bunch of these things likely is never actually used.
> So the levels require a bit of work to work in rotating third-person camera.
Well ... do you want to give it a go?
Of course. That's what this discussion is about :-D
If you'd do that, I would give it a go. Though I did already take a peek at your github repos. Not a pro(grammer) by any means, but I think I can port most of it over to C# for direct in-engine use. Will definitely take a shot at it.
It's a bit of bit fiddling. If you want to move it to C# for use in Unity that sounds good to me. I'm a Linux user and I'm not sure Unity caters to working on Linux; no objection to C# though even though last time I used it was in 2009.
> Mapping already done; they use a 16-bit shape ID and 8-bit frame index.
I like when work is already done

Really need to read up on the current game internals. Just have the bare player memory in my head.
Ah. That's easy to explain.
The levels are laid out on a 64k * 64k grid, with 256 possible height values. Floors are 16 units high. Humanoids (like the Silencer) are 3x3x10 in size. Most floor tiles are modeled as 8x8, and put into a glob to form a 16x16 unit square for making levels out of. Nearly no level actually places things above 48; they instead move to a different part of the map to just place the next floor next to the others.
For example, level 1 from No Remorse has some bits of the level at the top of the map (x 511 y 511) that are not actually used; looking only at the real map bits finds entries with an X between 0x37ff (~14300) to 0x5fff (~25000), and a Y between 0x2dff (~11000) and 0x7bff (~31760). This includes all 4 floors, side by side.
Looking at the byte data, I do see large Z values - up to 192 - but most are either at 0 or 96. Whelp, that has me surprised.
If you take one of the fixed.dat files and hexdump it with 16 columns, the X is the first two, Y is the next two, Z is the 5th, type is byte 6/7, frame is byte 8, and the field I call "count" is byte 11-12. Each of these refers to the actual type *one less* than the one listed, unless the type in here is 0x10 - in that case, the count is the glob ID to fetch. Globs are just a bunch of objects that level editors place in one go, and that are used as a set. They speed up the game by unloading objects when you get further away from them.
The other fields probably say which thing something teleports to, what value to use in a keypad, when to switch levels etc - I have no idea about those yet. Most of the what-is-this of a shape is in typeinfo.