questions about game engines

[Darkcrafter]

there was talk about how gzdoom is limited

Well of course it is. While there's been a lot of work done to refactor the original Doom engine code, extend it, and generalize it, at its core it remains a program made to play Doom engine games, and that will always dictate some limits on what can be done with it.

The limits, for modders, are actually part of the appeal, as it makes modding easier and more accessible. Drawing a map in a 2D way is simpler and faster than creating a fully 3D environment. The low-fidelity aesthetics from using sectors also help. You're simultaneously freer to experiment with weird shape, and more limited to the kind of things you can do, because extremely complex shapes are excessively hard to make.

Golden words about mapping, because indeed, mapping for doom is super fast compared to quake, but if one day someone wants to implement quake's renderer in GZDoom I will not be against it (at all )

By the way, what is that Xash engine? I have found this work somewhere on the Russian internet a while ago and now I recorded what it offers: https://youtu.be/qAl33xb1keo

[wildweasel]

Golden words about mapping, because indeed, mapping for doom is super fast compared to quake, but if one day someone wants to implement quake's renderer in GZDoom I will not be against it (at all )

Hey, you're in luck, someone already technically did!

Correct me if I'm wrong, but Vavoom recently was revived by ketmar as k8vavoom: https://www.doomworld.com/forum/topic/1 ... -01-build/

[sirudoom]

its crazy how many doom source ports there are. witch will be the best?

[Rachael]

witch will be the best?

The one you like the most obviously. Why does anyone think there's a solid answer to such subjective questions?

[sirudoom]

witch will be the best?

The one you like the most obviously. Why does anyone think there's a solid answer to such subjective questions?

witch can you make the most complex levels? that's pretty much the only thing that matters now that the graphics are already really good.

[Rachael]

Again, that's subjective and it depends on who you ask.

Ask anyone here and they'll say GZDoom, hands down. Ask anyone on Doomworld and they might say things like Eternity or PrBoom or Crispy Doom.

It also depends in what way the levels are complex. If you're talking a bunch of actors, PrBoom handles that much better than GZDoom does. If you're talking complex level geometry they are both about the same (with PrBoom having a slight advantage of an Intel-optimized compiler).

The only question you really should be asking is what source port fits your needs. There is no "best". Period.

[Graf Zahl]

its crazy how many doom source ports there are. witch will be the best?

The more, the better. Just have a look at the Build source scene. EDuke32 and its forks for other game are the only one available if you want some more advanced features and everybody is utterly dependent on its developers' whims. If they decide they do not need a specific feature, it's gone - you either can stick to an old version or grudgingly accept their decision (or if you can code yourself, fork the project...) - or switch to the only real alternative BuildGDX only to find out that it's far more basic.

The only problem I have with the Doom port landscape is that there's so many crowded in the low end niche and too few that try to advance the game. But there is no port which can dictate where things are heading and that's a good thing.

[sirudoom]

I was just thinking about how if a game came out that was like gzdoom but better, once something new comes out the old thing dies. but that probably wont happen because its sorta like with those old buildings that we cant even build today or like the pyramids. today we build bridges and buildings that don't last long. the older doom is the cooler it is.

[Darkcrafter]

Golden words about mapping, because indeed, mapping for doom is super fast compared to quake, but if one day someone wants to implement quake's renderer in GZDoom I will not be against it (at all )

Hey, you're in luck, someone already technically did!

Correct me if I'm wrong, but Vavoom recently was revived by ketmar as k8vavoom: https://www.doomworld.com/forum/topic/1 ... -01-build/

Thanks for the link, really sorry to say that but I gave it a try and surprisingly my big maps lag much worse in K8Vavoom, I thought quake renderer would gain the speed up. There are nice quake alike shadows, yet I don't know if 3d floors cast them. Maybe it's just a beginning of the source port but to me it seems like that invisible geometry behind 3d floors and sectors slows down the renderer way more than in GZDoom. I can't believe quake renderer behaves this way, or does it? There are such types of scenes that are almost nothing for my system yet they slow down like hell. If I export the same map in OBJ via GZDoom Builder everything works smooth and fast in any 3d editor, be it mesh lab, blender or 3ds max. To me it's getting even more strange that even if I remove all the textures replacing them with "-" sign in the builder, remove all the 3d models and the maps still renders in 30 fps, seems like the only thing that slow down the renderer is regular level geometry, even by having no textures it affects the performance in a bad way. I should convert that big map into md3 and see what it performs like if one actor placed inside of a big sector.

[Rachael]

Darkcrafter: I think that should serve as a valuable lesson to you: Sometimes "just" throwing another engine at it isn't the best solution.

Doom is locked in its ways; each port does its best to work around it, but you can't just throw something else at it, even if it theoretically works better, and expect it to solve all your problems.

Would a Quake renderer work in a Doom engine? On paper, yes, it's possible to fuse the two together and not have such horrific lag, but it would require a lot of optimizing and having some idea what parts of the level can be assumed to be static and what are not. And herein lies the rub: In Doom, technically nothing is static - so even this kind of optimization, where you attempt to make these assumptions, is going to break things somewhere down the line. And worse yet, a lot of Doom levels are reliant on rendering hacks that just don't work well with modern engines.

I know this is a long post, but my point is this: Nothing is as simple as it seems, when it comes to game engines. You are going to have issues no matter what you do, and no matter with what engine - the only real question is, what is worth the time investment to fix and what isn't.

[Darkcrafter]

Yeah, I should apologize for being that performance maniac here I'm just curious why is everything the way it is

[sirudoom]

if you made a more complex quake 3 with gzdoom and zero master speed ran it in less then 20 min... maybe its happened in another reality.

[Graf Zahl]

Thanks for the link, really sorry to say that but I gave it a try and surprisingly my big maps lag much worse in K8Vavoom, I thought quake renderer would gain the speed up. There are nice quake alike shadows, yet I don't know if 3d floors cast them.

I am not surprised. It's not just the Quake engine, though, but also some inefficiencies introduced by Vavoom. But in the end the lesson to be learned here is that it will ALWAYS be slower to process the level to work with the engine than to tweak the engine to work with the levels. Every single hardware accelerated Doom port trying that failed performance wise - Doomsday being the worst of the bunch but not the only one. ZDoomGL was another one that went a too complicated route and ended up twice as slow as GZDoom in general but made some other mistakes that really tanked its frame rate into the nether regions - not quite as bad as Doomsday but not usable for medium sized maps anymore.

Maybe it's just a beginning of the source port but to me it seems like that invisible geometry behind 3d floors and sectors slows down the renderer way more than in GZDoom. I can't believe quake renderer behaves this way, or does it?

What you do not consider is that Quake's renderer was made for Quake maps, which may be 3D but due to the lighting could use significantly lighter geometry. Quake also has the advantage that the level's mesh is 100% static. Back in 1997 this did not mean much but these days with Vulkan you could just pack the entire map into a single command buffer and flush it out in one go, and get 500+ fps. You cannot do such a thing in Doom - every sector might move, meaning you have to constantly recheck the neat-o lights that you can see, and that simply costs time.

There are such types of scenes that are almost nothing for my system yet they slow down like hell. If I export the same map in OBJ via GZDoom Builder everything works smooth and fast in any 3d editor, be it mesh lab, blender or 3ds max. To me it's getting even more strange that even if I remove all the textures replacing them with "-" sign in the builder, remove all the 3d models and the maps still renders in 30 fps, seems like the only thing that slow down the renderer is regular level geometry, even by having no textures it affects the performance in a bad way. I should convert that big map into md3 and see what it performs like if one actor placed inside of a big sector.

The rendering is the least of the job to be done. The time is lost elsewhere, i.e. by checking the map for changed parts. Unlike a real 3D map you cannot render it as a static mesh and you still have to walk the entire BSP so that you don't get stalled by the CPU on processing sectors that cannot be seen.

[dpJudas]

I think it is very possible to significantly improve the frame rate of a Doom engine, but it requires redesigning completely how rendering is done, as long as one is willing to drop the lame render hacks done by modders in the the 90's.

The trick is to dynamically move parts of a level from a static state to dynamic and back again. A few years back I had a proof-of-concept renderer that ran Frozen Time at 300+ fps on my computer, but it suffered from two problems: 1) it used softpoly's mesh building code, which won't do for a production quality version, and 2) it lacked the ability to know when parts of a level mesh changed and used a simplified bruteforce way that didn't account for all types of changes.

Some dynamic changes in GZDoom is easy to handle via shaders. The sector light levels can be uploaded as a texture or storage buffer - as long as the mesh vertices know which sector they belong to they can perform the lookup in a vertex shader. The dynamic lights hitting walls can be solved by using a deferred light pass. A deferred light pass has the advantage it can use the zbuffer as the primary way of knowing exactly which pixels in a scene a light touches, which in itself should provide a performance boost in maps like Enjay's Waterlabs.

The remaining changes, such as texture or height changes, can be dealt with by generating new mesh data for such sectors only when they change. In my prototype version the static mesh would know in the vertex shader if this sector had become dynamic and generated degenerate triangles when it happened, effectively disabling those sectors. After drawing the static mesh my code generated new mesh data and then drew that afterwards. It ran completely smooth until the very end of Frozen Time where some of the biggest sectors in the entire map suddenly lowered. But even then, that effect eventually ended and if my code had been a little smarter it could have merged the new state back into the static mesh and restored the high frame rate.

So why haven't I attempted to implement an actual production version of such a system? First, a few years back GZDoom's renderer backend was a lot more messy than it is today. Secondly, in order to do this mesh building code in GZDoom needs to be improved in such a way that it can output to some kind of mesh builder. And lastly, the system needs reliable reports from the playsim part of things about when sectors invalidate and in what way it happened. All those things happens in areas I'm not too familiar with.

Anyway, so it isn't that you couldn't make significiant performance improvements. However it does require a much more planned strategy than simply grabbing other old tech like Quake and porting it to Doom. The renderers of both those engines were built around assumptions that doesn't apply or doesn't scale to today's GPU based rendering. Even GZDoom still roughly renders by following the original formulae. Graf made it as fast as it goes - any further (significant) speed improvement requires a different approach.

[Graf Zahl]

So why haven't I attempted to implement an actual production version of such a system? First, a few years back GZDoom's renderer backend was a lot more messy than it is today. Secondly, in order to do this mesh building code in GZDoom needs to be improved in such a way that it can output to some kind of mesh builder. And lastly, the system needs reliable reports from the playsim part of things about when sectors invalidate and in what way it happened. All those things happens in areas I'm not too familiar with.

Adding the tracking code shouldn't be too hard - most of the sector and line structures are sufficiently encapsulated - it may require a bit of work on the ZScript side that it recognizes such protected properties so that it can update a set of change flags.

I don't really think that it's feasible without a persistently mapped storage buffer for the more volatile map info like light levels or light colors, but for modern hardware that shouldn't be a problem.

Anyway, so it isn't that you couldn't make significiant performance improvements. However it does require a much more planned strategy than simply grabbing other old tech like Quake and porting it to Doom. The renderers of both those engines were built around assumptions that doesn't apply or doesn't scale to today's GPU based rendering. Even GZDoom still roughly renders by following the original formulae. Graf made it as fast as it goes - any further (significant) speed improvement requires a different approach.

The thing I got the biggest boost out of was partially multithreading the BSP traversal with the draw list setup, that brought a 20% performance improvement. I think a similar gain could be achieved by multithreading the render data generation - but a more radical approach may be preferrable, like you outlined. But it should be clear that this might help on modern and fast hardware but it'd backfire miserably on weaker hardware limited by pixel fill rate. On my brother's laptop, for example, Frozen Time is rendered at 25 fps, both with OpenGL and Vulkan, with an AMD GPU - on this system the GPU cannot even work fast enough to get throttled by AMD's high draw call overhead.

And while your approach is certainly workable it suffers from one problem and that is the automap - the way this is handled requires traversing the BSP - so it either has to be done in a worker thread periodically or a different means needs to be invented.

But yeah, should I feel some motivation again to work on the renderer, I'd certainly try such a modern approach, if it can assume it got all the buffer features in the world, a lot of the volatile data can be stored in there to reduce setup costs and make the whole thing a lot easier.