KarlosTKG now on GitHub

[Karlos]

If Level D is going to be a "get the reactor restarted" mission to prevent the hub and your ship becoming a large debris field in the immediate future, then Level C needs to be something to set it up, part of the engineering and maintenance levels of the station.

There are still some bits of C that are a tad too random, but the AB3D system purge homage area might make sense as part of a control system override to help gain access to the exit to the reactor level.

[Karlos]

So, I'm going to hate myself for this, but I think level C needs a rework. Abu pointed out many pages ago about the rusty look not making a huge amount of sense for a functional space setting, and of course, he's right. That should be for the surface environments.

For the plot diversion, Level C will become the main maintenance/engineering deck of the orbital facility, above the power plants that I intend for level D. For it to make sense, I think I need to convert the existing loop at the start of the level into a more open plan hub, with various instrument panels and various systems stuff. The two doors that you have to find keys for to lower the final lift to the exit can stay but might be moved a little.

The quake based textures and the rusty brown AB3D1 "mechanic" textures all around that part need replacing with something less rusty and run down. I'm slightly loathe to do this the hard way and I think a more sensible way to do it is to perhaps recreate those two texture sets again, but not looking totally rusted out and instead a bit more maintained, but otherwise a drop in replacement in terms of their organisation. I feel like an engineering/maintenance level should have a cleaner overall appearance, neatly aligned wall panels with a few indicators here and there, but not just a basic copy of the "computers" set.

Outside of that central hub, the areas that you need to explore can largely be unchanged, except where they currently rely on all the rusted out stuff.

[eXeler0]

Originally Posted by Karlos

So, I'm going to hate myself for this, but I think level C needs a rework. Abu pointed out many pages ago about the rusty look not making a huge amount of sense for a functional space setting, and of course, he's right. That should be for the surface environments.

For the plot diversion, Level C will become the main maintenance/engineering deck of the orbital facility, above the power plants that I intend for level D. For it to make sense, I think I need to convert the existing loop at the start of the level into a more open plan hub, with various instrument panels and various systems stuff. The two doors that you have to find keys for to lower the final lift to the exit can stay but might be moved a little.

The quake based textures and the rusty brown AB3D1 "mechanic" textures all around that part need replacing with something less rusty and run down. I'm slightly loathe to do this the hard way and I think a more sensible way to do it is to perhaps recreate those two texture sets again, but not looking totally rusted out and instead a bit more maintained, but otherwise a drop in replacement in terms of their organisation. I feel like an engineering/maintenance level should have a cleaner overall appearance, neatly aligned wall panels with a few indicators here and there, but not just a basic copy of the "computers" set.

Outside of that central hub, the areas that you need to explore can largely be unchanged, except where they currently rely on all the rusted out stuff.

Wouldnt it be neat if there was a ”glass” window somewhere on the space station with a view of the planet ;-)

Btw I have a surprise, Edit: will post here later ;-)

[Karlos]

Originally Posted by eXeler0

Wouldnt it be neat if there was a ”glass” window somewhere on the space station with a view of the planet ;-)

It would, but there's two small problems. Firstly, walls can't be transparent, only sprites and vector models. Secondly, only ceilings can be undrawn to expose the backdrop. Walls are always solid.

[Samurai_Crow]

Originally Posted by Karlos

It would, but there's two small problems. Firstly, walls can't be transparent, only sprites and vector models. Secondly, only ceilings can be undrawn to expose the backdrop. Walls are always solid.

How about a skylight then?

[Karlos]

Originally Posted by Samurai_Crow

How about a skylight then?

That's totally doable, though there'll be no indication of a barrier.

I might look into what could be involved to have invisible exterior walls for an engine tweak. The ability to render walls using the glare path would allow for transparent glass windows.

[Karlos]

I made a prototype atrium replacement for that central loop of level C and really angered the PVS, total hall of mirrors. Night have to rethink my layout a bit...

[eXeler0]

So in a moment of "because why not" I decided to remake Level A for Quake 1 in order to have some sort of performance comparison between the original game vs Quake engine. ;-)

Tbh, I have not tested it on a real Amiga myself, but I did test it in old WinQuake to make sure it runs (it does, but some weird draw bugs on the bridge).

Anyway, here's a link to a zip containing the .bsp and .wad files.
https://drive.google.com/file/d/1pXN...ew?usp=sharing
Unpack to Quake directory and in console type "map ex_TKG-A_beta1_q1"

[Karlos]

Will give that a go tomorrow. It's bedtime now

[abu_the_monkey]

Qbreed-TKG

[eXeler0]

A couple of things,
First, its already obvious that larger maps would not fit within the quite narrow restrictions of vanilla Quake 1. This was already a known issue back when QBreed was a thing. I'm not sure if we ever got the "extended" Q1 engine for 68k that runs at useful speeds on original hardware?

I did this map because the performance Im getting in TKG isnt great so I was curious how it compares to Qukae 1. I also did not populate it with tons of monsters, just a few dogs, because it's already obvious to me that the PVS aren't optimal. If I was to design the map from a performance standpoint, this is NOT how I would do it. ;-)

Anyhoo, it is what it is and now "the cat is out of the bag" ;-)

[Karlos]

I don't know that comparing quake to TKG is very sound, really. They are completely different engine designs. Quake is a 3D BSP, with portal support and 6 degrees of freedom. TKG is a 2.5D engine that isn't exactly BSP and isn't exactly portal. It's a sort of funky hybrid.

It has some characteristics of a BSP, that is, the map is divided into convex polygons (zones), but that process is totally manual. You will know when you get it wrong because it will go berserk.

It's also partially portal, except it doesn't draw front to back, instead it relies on a per zone precomputed PVS of the other potentially visible zones, which it distance approximates at runtime and draws back to front but clipping against the connecting polygon edges. And when that works, it's actually pretty neat and efficient with almost no overdraw. The problem is, it doesn't work a lot of the time.

[eXeler0]

I know that as far as engine comparison goes we’re not comparing apples to apples, but I still wanna know what kind of real world performance we can get from each (running similar levels)
While there’s no point in comparing Bugatti Chirons 8L quad turbo W16 engine to the Electric Powertrain /AC 3-phase induction motor of the Tesla Model S Plaid it might still be interesting to see which car is faster

[abu_the_monkey]

Originally Posted by eXeler0

A couple of things,
First, its already obvious that larger maps would not fit within the quite narrow restrictions of vanilla Quake 1. This was already a known issue back when QBreed was a thing. I'm not sure if we ever got the "extended" Q1 engine for 68k that runs at useful speeds on original hardware?

I did this map because the performance Im getting in TKG isnt great so I was curious how it compares to Qukae 1. I also did not populate it with tons of monsters, just a few dogs, because it's already obvious to me that the PVS aren't optimal. If I was to design the map from a performance standpoint, this is NOT how I would do it. ;-)

Anyhoo, it is what it is and now "the cat is out of the bag" ;-)

the 68k Qbreed engine I was working on (which was a modified version of QUAKE68K by Farnk Wille) did have extended coordinates but lack of interest/time/tallent left it feature rich but somewhat broken.

[eXeler0]

Spoiler, the Quake version of Level A map is a Slide Show on real hardware, so no further testing needed to confirm it runs way slower than the TKG engine, although after seeing the compiler message from VIS tool, I suspected this. Simply put, this is the wrong way to build a map for the quake engine if you wanna run it on slow hardware.
I have maps with *much* more geometry and details that run way faster but they are built in a certain way so that VIS and portals can do their thing.

[eXeler0]

Originally Posted by abu_the_monkey

the 68k Qbreed engine I was working on (which was a modified version of QUAKE68K by Farnk Wille) did have extended coordinates but lack of interest/time/tallent left it feature rich but somewhat broken.

I remember this,
a guesstimate, would it be possible to just replace code related to coordinate limits in WinQuake instead? I know I just made it sound 10x easier than it probably is, but theoretically…

Anyway, lesson learned I think. Even if it was technically possible to recreate the TKG maps it wouldnt run on any original Amiga config because of the horrible way the TKG maps murder PVS optimizations ;-)
So instead of Karlos mod, it would be eXeler0 mod with all maps redone for performance purposes

[Karlos]

As neat as a remake in another engine could be (and Osiris is, for instance), I dunno. It's just not the same for me. TKG is something of a bittersweet thing for me and quake was the thing that ended up killing my mod efforts as I was seduced by it instead.

Thanks to Abu's efforts with leveled, the ability to actually change things, fix bugs and add features thanks to pipper and the convenience of UAE, linux and git, what used to be a real challenge has become a much more straightforward workflow. If I lack for anything, it's time.

[Karlos]

Originally Posted by eXeler0

Spoiler, the Quake version of Level A map is a Slide Show on real hardware, so no further testing needed to confirm it runs way slower than the TKG engine, although after seeing the compiler message from VIS tool, I suspected this. Simply put, this is the wrong way to build a map for the quake engine if you wanna run it on slow hardware.
I have maps with *much* more geometry and details that run way faster but they are built in a certain way so that VIS and portals can do their thing.

I've not had a chance to test. Is it particular areas that take a beating? I'm sure the basic sickbay can't be that bad.

[eXeler0]

Originally Posted by Karlos

As neat as a remake in another engine could be (and Osiris is, for instance), I dunno. It's just not the same for me. TKG is something of a bittersweet thing for me and quake was the thing that ended up killing my mod efforts as I was seduced by it instead.

Thanks to Abu's efforts with leveled, the ability to actually change things, fix bugs and add features thanks to pipper and the convenience of UAE, linux and git, what used to be a real challenge has become a much more straightforward workflow. If I lack for anything, it's time.

I hear you.
And basically I agree. And Its for similar reasons I wish that this mod runs nicely on real amiga hardware.
As for quake versions, i got the answer i needed. Ill now focus on original maps that are from the ground up optimized for Amiga. ;-)

[BigD]

Originally Posted by eXeler0

I hear you.
And basically I agree. And Its for similar reasons I wish that this mod runs nicely on real amiga hardware.
As for quake versions, i got the answer i needed. Ill now focus on original maps that are from the ground up optimized for Amiga. ;-)

The Mod works at 20FPS on an 060/105 AGA and at about 14FPS on a 060/50 RTG! Not bad! Obviously a PiStorm32 runs it great and I personally class that as 'real' hardware.