KarlosTKG now on GitHub

[eXeler0]

What makes sense to me would be a low spec version that is playable on a base clock 060 and a high spec version that pretty much only runs on virtual Amigas (WinUAE, Pistorm etc). There is a pretty dramatic difference in performance between what a 060 can deliver and what you can get from a 2000 mips pistorm. ;-) AGA version of high spec could slso be ditched then.
But from personal experience of doing Quake maps its easier to do low spec first then increase complexity later. (As opposed to optimizing later.) Im not saying its not possible, just that it likely takes more time.

[Karlos]

That depends on your definition of playable. If you want 20+ FPS everywhere you are asking for extreme potato mode or a total ground up engine rewrite.

I don't currently have a working Amiga, let alone an 060 powered one, so I'm in no position to create a version tuned for one. All I can do is scale back from what I built already. A lot of which was built on an 040/25 20 odd years ago with the T17 engine.

[eXeler0]

Originally Posted by Karlos

That depends on your definition of playable. If you want 20+ FPS everywhere you are asking for extreme potato mode or a total ground up engine rewrite.

Id say 12-15 fps is ”playable”.
Below that is not enjoyable as it get hard to aim with precision etc

Probably one could increase the size of the GUI to make the visible screen smaller but Wide screen (without making it annoying to look at)

[Karlos]

You can go fullscreen and use the numeric +/- to adjust the top and bottom margins if you want a wide screen view.

Try to bear in mind that modding the game is entirely asset based and completely unlike modding quake, where you can code any behavioural changes you want thanks to it's virtual machine.

[eXeler0]

Originally Posted by Karlos

You can go fullscreen and use the numeric +/- to adjust the top and bottom margins if you want a wide screen view.

I know, just trying to come up with things that would make it easier to hit that fps target ;-)

Try to bear in mind that modding the game is entirely asset based and completely unlike modding quake, where you can code any behavioural changes you want thanks to it's virtual machine.

Yea, I hear you…
Out of curiosity, is it possible to disable texture rendering and only use Gourard shading to what if any performance penalties you get for textures ( lightning effect, memory usage etc)

[Karlos]

Anything is possible if you are prepared to sit down and code it

[Karlos]

You can force the game to use AB3D1 lighting by using F8, which toggles between the full Gouraud model and the simplified model. In the simplified model, the upper and lower brightness of every wall is averaged so that the only shading gradient is horizontal.
You can also disable dynamic lighting effects with F4.

In my experience, disabling the dynamic lighting doesn't do a lot but forcing the simple shading model can make a noticeable difference.

[eXeler0]

Originally Posted by Karlos

You can force the game to use AB3D1 lighting by using F8, which toggles between the full Gouraud model and the simplified model. In the simplified model, the upper and lower brightness of every wall is averaged so that the only shading gradient is horizontal.
You can also disable dynamic lighting effects with F4.

In my experience, disabling the dynamic lighting doesn't do a lot but forcing the simple shading model can make a noticeable difference.

Its good we have toggles for those already. Maybe Low Spec mode could set all those that matter to the simple alternative as default setting, then it can be toggled back oi if the system can deal with it.

Number 1 framerate killer culprit with Quake maps is usually PVS related. If this is true here as well, most bang for the buck optimizations on low spec maybe aren't to simplify geometry in specific rooms but making sure they are not rendered when not needed.
Hopefully it can be done it some easy way (like swapping lifts for telepoorters etc like we talked before). Is there some easy way to get feedback from playtesting like in Quake where you can enter console commands to se triangle count etc?

Anyhoo, its probably a fair idea to find those optimizations that do the most difference and ignore those that dont matter as much but still take time. :-)
At this point you know the engine better than anyone else, including Andy Clitheroe :-)

[Karlos]

Originally Posted by eXeler0

Its good we have toggles for those already. Maybe Low Spec mode could set all those that matter to the simple alternative as default setting, then it can be toggled back oi if the system can deal with it.

Number 1 framerate killer culprit with Quake maps is usually PVS related. If this is true here as well, most bang for the buck optimizations on low spec maybe aren't to simplify geometry in specific rooms but making sure they are not rendered when not needed.

This has been discussed in the main engine thread, but I'll reiterate here.

Very specifically, it's not the PVS itself per se. That's precalculated and usually makes sense, containing the subset of zones potentially visible from whichever zone you are in.

The problem is in the runtime traversal and culling of the PVS to the actually visible set. The PVS zones are sorted, furthest to nearest and a clipping algorithm works out which portions of each are visible through the connecting walls between the zones in the set. This is a bit like portal rendering, except it's still back to front, rather than front to back. This particular algorithm appears to have a significant number of failure cases, that ultimately end up resulting in distant areas being drawn, then covered by a wall. This is very apparent on closed doors or obstructing lifts.

Hopefully it can be done it some easy way (like swapping lifts for telepoorters etc like we talked before). Is there some easy way to get feedback from playtesting like in Quake where you can enter console commands to se triangle count etc?

Ideally teleporters should be a game mechanic rather than a visibility crutch, but I have been forced to do that once. Not because of a performance hit, but because the engine just wouldn't render the PVS correctly at all.

There's no console for the engine, but there is a key (backtick) that will dump the PVS state for the RTG/dev build. This appears in the console after you quit the game. I've been using it to make sense of the state at runtime. The numericpad dot will toggle the verbosity of the dump.

Dumps are written to a temporary location and will be opened into multiview when the game exits.

Anyhoo, its probably a fair idea to find those optimizations that do the most difference and ignore those that dont matter as much but still take time. :-)
At this point you know the engine better than anyone else, including Andy Clitheroe :-)

I don't think anyone knows it like Andy Clitheroe. Whether or not he still remembers it, is a different matter. I did try to reach out on linkedin, but he's never responded.

[Karlos]

Level B playthrough (pistol start)

[ Show youtube player ]

Contains spoilers of you are going to play it yourself.

[eXeler0]

Originally Posted by Karlos

Level B playthrough (pistol start)

[ Show youtube player ]

Contains spoilers of you are going to play it yourself.

Looks real nice,
btw, any idea what the glitch is caused by at ~3.07?

[Karlos]

Originally Posted by eXeler0

Looks real nice,
btw, any idea what the glitch is caused by at ~3.07?

Rogue vector model polygons. It's another one on the known issues list. It's a lot less of an issue in low spec mode as there are many fewer of them.

[Karlos]

All Level B changes pushed.
Lowspec Level A control points/zone associations updated and pushed.

I think these are ready to merge into main.

[Karlos]

I am interested in having a discussion about ideas for the mod, specifically things like level changes and the like but don't want to intentionally spoil it for anyone that might want to play them.

I don't want to crapflood the forums with TKG threads, but a separate one for that which only interested parties need to be aware of seems to make sense. Any objections/recommendations?

[eXeler0]

Originally Posted by Karlos

I am interested in having a discussion about ideas for the mod, specifically things like level changes and the like but don't want to intentionally spoil it for anyone that might want to play them.

I don't want to crapflood the forums with TKG threads, but a separate one for that which only interested parties need to be aware of seems to make sense. Any objections/recommendations?

Just put a spoiler warning in the post ;-)
This thread is fine, and there’s a second pure dev thread?

[Karlos]

Originally Posted by eXeler0

Just put a spoiler warning in the post ;-)
This thread is fine, and there’s a second pure dev thread?

Yep, the original by pipper. There's also one for LevelEd by abu_the_monkey.

[BigD]

Originally Posted by Karlos

All Level B changes pushed.
Lowspec Level A control points/zone associations updated and pushed.

I think these are ready to merge into main.

Are the level B changes in the main now? 2-player compatible? Have my Zip Disk up and running with the Pistorm32 now so easier to transfer your files!

[Karlos]

Originally Posted by BigD

Are the level B changes in the main now? 2-player compatible? Have my Zip Disk up and running with the Pistorm32 now so easier to transfer your files!

No. But you can download the zip file from the misc/redesign branch now.

There are no 2-player specific changes.

[Karlos]

So far we've esablished that Level A takes place on the Indomitable, which was locked down and evacuated (apparently) and is attached to the Docking Ring in Level B.

This is where the story begins to diverge from the original for me.

The Docking Ring is part of a human structure in orbit around another barely habitable Osiris type planet (which I've named LV-612), with various nefarious installations across the surface. Like the Indomitable, the orbital structure is also evacuated/overrun. In the original game, I suspect the docking ring is just part of the alien ship, as it has sections of alien texturing.

Level C takes place deeper in the orbital facility, still in the human built structure but with signs of alien infestation (hence the name) with areas partially consumed by the alien textures and slime/acid pits. Environmental controls are shot and have been for some time, extreme humidity causing corrosion and other visible damage. Several new classes are introduced and although I was originally going to completely ditch the level, it ended up "OK".

Now there are three levels before you get to the planetary surface (Level G). For me the original game doesn't make a lot of sense here. Level F, for example, makes much more sense as a surface installation.

Level D was just boss level introducing the big red insectoid plasma thrower and I personally found it quite a tedious design (though the teleport pad stuff was kinda neat.

What I want to do is to create a story here. In the 1997 version, I added an area at the beginning that might serve as a reactor type space. What I am thinking now is that it might be fun to resurrect that idea.

Level D could take place in an engineering section of the orbital structure where there is a reactor, or set of reactors that is/are malfunctioning due to a failure of the cooling systems. If left unfixed, it's going to catastrophically fail, taking the Indomitable with it, if the station and docking ring can't be powered up properly. As your only viable escape route, you need to ensure the Indomitable can be brought back up, which means saving the station.

For this to work, I am thinking of having the same reactor room motif duplicated a couple of times and ultimately connected only by teleporters. This way you'll be able to pass through one that is all glowing red and dangerous, succeed in fixing the systems elsewhere and return back through, with it all blue/grey and operational looking (because it's really a different area).

The original boss fight can still be embedded in the level somewhere, resulting in a conclusion that forces you to exit via what is ostensibly the Alien side of the structure. The end of Level D should give some indication of a transition into a more alien environment.

This leaves Level E to be rethought as the large alien vessel/structure with the only signs of human contribution being the various supplies dropped during the fight and a few assimilated marines (note to self, need to make those less Doomguy and more cyborg). The aliens still clearly have technology so I'm not thinking it should be too Geigeresque but it needs to be visually differentiated in some way.

I might swap G and F, so that you come groundside one level sooner and the strange chasm/labyrinth that is F can take place deeper in the complex that begins with level G. It could be part of a large refinery/industrial complex or something that justifies the huge, hot chasm of death. It could also do with a bit less random maze and more purpose.

[eXeler0]

Sound like a good plan. Are you editing the storyline texts between levels too?
I alway though it would be neat to have an image showing some core design feature of the level along with the explaining text ;-) Could help setting the right atmosphere / setting. Sort of like Gloom Deluxe but more focus on environment.