Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Koko Ricky

Can updating the engine be taken too far?

Recommended Posts

54 minutes ago, CBM said:

Well it was mentioned that GZDoom is badly in need of optimization

it is already one of the best optimised sourceports out there. what really needs… ahem… optimisation is people's knowledge about idTech1, GPUs, and why idTech1 is and will always be very hostile to GPU rendering/speed improvements. yes, your GPU can render the latest and fanciest Unreal/Frostbite/etc. title at 120 FPS, and GPU-based idTech1 still could go down to single-digit FPS. and it's not due to "bad/not enough optimisations". GZDoom is using almost every known trick to make things go faster. you simply cannot have both maximum possible speed, and the full set of GZDoom features (while still staying idTech1 compatible).

Share this post


Link to post
9 minutes ago, ketmar said:

 

it also has to do a huge amount of what it does on CPU too, right? so much of how this engine works isn't really "compatible" with modern means of graphic drawing so it's a bunch of tricks on top of other tricks to make it happen. that combined with all of the way we can hook into the original code and more or less "patch" it in real time is a surefire way to bring any machine down.

Share this post


Link to post

I guess taking it too far would be where someone has reached the point that to achieve what they have with the engine took so much effort that it would have been significantly easier for them to learn how to work with another engine to achieve the same thing. Then again maybe they learned something important along the way or hell maybe they had fun along the way, so I would still say that is not too far.

Share this post


Link to post

The Doom engine has been taken too far by patch 1.666, where they made lost souls not count as monsters anymore. WTF was up with that?

Share this post


Link to post
2 hours ago, CBM said:

Well it was mentioned that GZDoom is badly in need of optimization. As someone who sometimes ends up with very few FPS unless I am very carefull when mapping, I concur. Hopefully it will continue to be a focus for the magnificent mr. Graf Z et. al.

 

 

Seconding what Ketmar said.

What you run into here is simply the limitations of the engine, there's only a given distance you can go with a Doom-style BSP and an inherently non-multithreadable play code. The only real problem is performance with thousands of monsters, i.e. stuff like NUTS or ultra-slaughtermaps where the added complexity of the engine just adds up. The biggest performance issue is actually CPU cache performance. So trying to improve code to make things go faster will then immediately be nullified by the next cache stall.

 

1 hour ago, msx2plus said:

it also has to do a huge amount of what it does on CPU too, right? so much of how this engine works isn't really "compatible" with modern means of graphic drawing so it's a bunch of tricks on top of other tricks to make it happen. that combined with all of the way we can hook into the original code and more or less "patch" it in real time is a surefire way to bring any machine down.

 

That's very much it. Virtually all graphics hardware from the last 15 years has been designed for modern design techniques, which mostly means rendering large meshes with very few draw calls. Doom is quite the opposite. Here you render very coarse meshes with a high number of draw calls. This gives an utterly shitty performance ratio, and if the driver adds its own bottlenecks it won't take long until performance tanks.

All that said, a modern low spec computer with a decent CPU (doesn't need to be high end but shouldn't also be bottom of the barrel entry level stuff!) will still be able to display most levels at +100 fps easily. On my brother's recent €500 laptop even a map like Frozen Time, which is the worst performance killer I know, still runs at 46 fps on its integrated chipset.

Share this post


Link to post
1 hour ago, Graf Zahl said:

Seconding what Ketmar said.

What you run into here is simply the limitations of the engine, there's only a given distance you can go with a Doom-style BSP and an inherently non-multithreadable play code. The only real problem is performance with thousands of monsters, i.e. stuff like NUTS or ultra-slaughtermaps where the added complexity of the engine just adds up. The biggest performance issue is actually CPU cache performance. So trying to improve code to make things go faster will then immediately be nullified by the next cache stall.

Well ok, I guess I must just continue learning about the GZDoom engine then.

I have learned many of the tricks the engine can do, but there are still many things I still don't know and the biggest thing I need to learn is zscript. I am hoping to come across a complete zscript tutorial at some point. I am used to coding in c, so once I can get over the initial hurdle of making my first couple of scripts, then I should be good to go.

 

maybe this will help me:

https://github.com/jekyllgrim/ZScript_Basics/blob/master/Variables_and_data_types.md

 

are 3d models less taxing than 3d floors?

 

Once I have learned a sufficient amount of zscript then I plan on remaking an old game I made once but in 3D

 

it will feature a grid of nxnxn objects... for example 20x20x20 3D objects

Edited by CBM

Share this post


Link to post

I believe that the 2d sprites and textures are really what define Doom, so taking them away and replacing them with fancy 3D stuff is probably where we cross the line

Share this post


Link to post
2 hours ago, CBM said:

Well ok, I guess I must just continue learning about the GZDoom engine then.

I have learned many of the tricks the engine can do, but there are still many things I still don't know and the biggest thing I need to learn is zscript. I am hoping to come across a complete zscript tutorial at some point. I am used to coding in c, so once I can get over the initial hurdle of making my first couple of scripts, then I should be good to go.

 

maybe this will help me:

https://github.com/jekyllgrim/ZScript_Basics/blob/master/Variables_and_data_types.md

 

are 3d models less taxing than 3d floors?

 

Once I have learned a sufficient amount of zscript then I plan on remaking an old game I made once but in 3D

 

it will feature a grid of nxnxn objects... for example 20x20x20 3D objects

I'd like to see a port incorporate QuakeC support.

Share this post


Link to post
15 minutes ago, Gibbon said:

I'd like to see a port incorporate QuakeC support.

but what would quakec add that isnt already covered by zscript?

Share this post


Link to post

Any sort of compiled scripting language is a bad idea for source ports and also a bad thing for the community period. ACS should remain the only compiled scripting language.

Share this post


Link to post
33 minutes ago, Cacodemon345 said:

Any sort of compiled scripting language is a bad idea for source ports and also a bad thing for the community period. ACS should remain the only compiled scripting language.

 

Not only that - they also restrict interaction with the game environment quite a bit. ZScript can treat a lot of data that is built on engine startup like static constants. Any precompiled language could not do that.

 

Share this post


Link to post
2 hours ago, CBM said:

but what would quakec add that isnt already covered by zscript?

Quake C is a pretty nice proper scripting language.  I have never really liked any of these scripts that were done for doom ports.

Share this post


Link to post
35 minutes ago, Graf Zahl said:

 

Not only that - they also restrict interaction with the game environment quite a bit. ZScript can treat a lot of data that is built on engine startup like static constants. Any precompiled language could not do that.

 

Except it is not good for performance.  Pre-compiled scripts will always trump interpreted.

Share this post


Link to post

I'd say going too far is only really an issue when there's only a few sourceports out there and there isn't a chocolate variant that perfectly encapsulates the quirks of the original engine -  warts and all. As long as you have damn perfect preservation somewhere, sourceports can run wild. 

Share this post


Link to post

It's all too far. All of it. Even loading the WADs from a CD-ROM as opposed to a handful of floppies is too far. Burn the heretics.

 

Share this post


Link to post
48 minutes ago, Gibbon said:

Except it is not good for performance.  Pre-compiled scripts will always trump interpreted.

normally I would agree... but some JVMs like IBMs have used tricks to obtain same speeds as precompiled code

Share this post


Link to post
10 minutes ago, CBM said:

normally I would agree... but some JVMs like IBMs have used tricks to obtain same speeds as precompiled code

Very true.

Share this post


Link to post
1 hour ago, Gibbon said:

Except it is not good for performance.  Pre-compiled scripts will always trump interpreted.

ZScript isn't necessarily interpreted, however. By default it compiles to native code through asmjit (and it sure is a blessing for some of us who write really stupidly complicated code).

Share this post


Link to post
18 hours ago, TheMagicMushroomMan said:

3D models can be used effectively in unique ways, not just for enemy models. Particle effects could be utilized for things like weapon projectiles and environmental effects.

dunno if that's sarcasm or not but i think people are already doing that lol, total chaos? think i've seen one of @Dragonfly's works using 3D model pieces for scene with actual map geometry hidden beneath them, kinda looks like using a low-poly collision model for a high-poly model like with unity and unreal.

Edited by sluggard

Share this post


Link to post
22 hours ago, msx2plus said:

generally i consider myself pretty vanilla-adjacent despite my current project being heavily reliant on gzdoom, but what i think that means to me is playing things the way they were intended. if a map/wad/etc was designed for a source port, i use that source port. anything else or modding it would be taking it "too far" for me as i'm very into experiencing the creator's intent. as far as the base games go, i admittedly enjoy the niceties of crispy doom, but i still feel like this may be "too far" for that game content in particular.

 

i think it's less about "too far" and more about how you personally interpret the sanctity of the intended experience. at what point does it stop evoking what it was meant to evoke to you? does that concept even matter to you? does doom unbecome doom for you when you transform it, or does it amplify it? we'll all have different answers to that question, and i want to say that's what this thread is laying out - it's a fun thing to have answers to, as doom has certainly affected all of us differently!

 

[edit] personally i feel like changing something by default - "oh i have to play every new map/wad/etc with my favorite mods" - is quite a bit rude, as if you don't trust the author to provide something worthwhile, or suggesting that the tools the author chose to work with are incapable of providing an interesting experience. it's like adding seasoning to a restaurant meal without trying it. if there is a "too far" that i think is worth assessing, it might be this? as an author it's very frustrating to have people not even attempt to meet your work as it stands, and there have been plenty of times people have complained that (x) thing doesn't work with their method of play. maybe this is a symptom of "too far" rather than "too far" itself? it's an interesting thought regardless.

Wow, I think you tapped into my brain and broadcast what I was thinking.

 

As fascinating and impressive as GZDoom is, I also find it quite frustrating that people "have" to use mods to try out wads, whether they be from 1996 or 2021. My thought is, why not experience it the way the designer intended first, then replay with mods? Someone worked hard on progression and layouts and enemy placement only to have borked by Complex Clusterf*ck (as impressive as the mod is).

 

So I love that UDMF exists and I love that there are dedicated modders making more and more impressive .pk3s for us to enjoy.

 

But just like you said, if the wad is vanilla, I play it in Crispy Doom, if it's Boom, I play in PRBoom+ at the correct complevel, if it's ZDoom, etc. It seems disrespectful to treat designers who make wads for free to initially experience them your own way. Do that second replay lol. 

 

TLDR: mods are great, ZDoom rocks, but respect the designers. Also none of this was intended to be offensive, tone is hard to tell on the internet.

Share this post


Link to post
19 hours ago, smeghammer said:

Each to their own, and long live Doom.

Perfect way of looking at it, no shortage of vanilla or ZDoom maps. Both are great imo.

Share this post


Link to post
10 minutes ago, Dusty_Rhodes said:

Someone worked hard on progression and layouts and enemy placement only to have borked by Complex Clusterf*ck (as impressive as the mod is).

i've been happy to see what seems like more map sets created for mods like these - it's been getting more people into making things and it takes the pressure off people that have never even looked at these mods in regards to making something "compatible". was quite frustrating to release a project and have the first requests be that i create a map-only version so it's compatible with mods <_> i'd have to rework everything from the ground up! weapon/gameplay mods are so complex now that accounting for them just isn't reasonable unless the project was made with them in mind.

Share this post


Link to post
9 hours ago, CBM said:

are 3d models less taxing than 3d floors?

 

Significantly.  Dynamic lights interact with model meshes the same as geometry (actually because models have "back sides" you get twice the load of a dyn-light than with proper geometry), but in terms of the playsim 3D models require significantly less overhead because there's only a very minor amount of collision calculations to do (basically the underlying cuboid Thing and that's it).

 

As an example, there's an Elementalism map I'm working on that natively ran at about 15fps on my laptop.  I converted all the non-interactive geometry to models (and simplified the dynamic light setup accordingly) and it now runs at 120fps and basically looks the same.

 

2 hours ago, sluggard said:

dunno if that's sarcasm or not but i think people are already doing that lol, total chaos? think i've seen one of @Dragonfly's works using 3D model pieces for scene with actual map geometry hidden beneath them, kinda looks like using a low-poly collision model for a high-poly model like with unity and unreal.

 

You're exactly right.  Especially now UDB has a robust geometry-to-model export function, there's a growing trend among UDMF mappers to create complex geometry, then export it to a model and replace it in-game with simple invisible 3D floors or basic hidden geometry.  That's how I did this effect for example:  https://twitter.com/i/status/1358837512244842497

Share this post


Link to post
5 hours ago, Gibbon said:

Except it is not good for performance.  Pre-compiled scripts will always trump interpreted.

 

It's just that you cannot compile game scripts directly to native code because then you are platform locked.  Quake 2 went that route with its game DLLs and now we face the problem that many old mods come with a DLL and no source so they are dead in the water on anything but Windows with strongly backwards compatible ports.

 

Quake C compiles to some bytecode, just like ZScript does internally. Whether that bytecode is interpreted or further processed by a JIT compiler is a completely different matter and may even depend on the port or the hardware platform being used.

 

Share this post


Link to post
1 hour ago, Bauul said:

 

Significantly.  Dynamic lights interact with model meshes the same as geometry (actually because models have "back sides" you get twice the load of a dyn-light than with proper geometry), but in terms of the playsim 3D models require significantly less overhead because there's only a very minor amount of collision calculations to do (basically the underlying cuboid Thing and that's it).

 

As an example, there's an Elementalism map I'm working on that natively ran at about 15fps on my laptop.  I converted all the non-interactive geometry to models (and simplified the dynamic light setup accordingly) and it now runs at 120fps and basically looks the same.

 

 

You're exactly right.  Especially now UDB has a robust geometry-to-model export function, there's a growing trend among UDMF mappers to create complex geometry, then export it to a model and replace it in-game with simple invisible 3D floors or basic hidden geometry.  That's how I did this effect for example:  https://twitter.com/i/status/1358837512244842497

interesting.... very very interesting

 

so basically the "bridgething" items are placed inside the 3d model to provide collision detection

 

that could be an alternative to portals to get my castle of secrets map to perform better

Share this post


Link to post

Either bridge things or invisible 3D floors, whatever suits best, sometimes you may even use invisible 3D midtextures. Of course when doing a simple sector bridge, a 3D floor will still be the best way to go, but once you have to split stuff into a large number of small sectors it may make sense to use models with some other means to block their space.

 

Share this post


Link to post

If you really would want to upgrade the engine, you would rip out the BSP rendering out of it and replace it with something more modern, so all performance-wasting antics are gone

 

The reason these things don't happen are multifold:

  • It is time consuming.
  • The BSP is an essential part of Doom's engine. Replacing it wholesale means that its replacement should be able to mimic its behavior exactly.
  • It is time consuming.

A lot of what makes Doom tick is also why its quite wasteful on performance. Even so, a semi-modern machine is well able to push beyond 120+ FPS by brute forcing alone. Nevertheless, on extreme maps with tons of linedefs is where the engine crumbles.

 

So can Doom be taken too far? Well, in a way, yes, by engine's nature.

 

But it does not mean it can be pushed beyond the imaginable. New tricks still get discovered. New games are made that totally change the way Doom looks and feels. From GZDoom (Beyond Sunset) to even the pure vanilla experience (REKKR). And there are the fantastic megawad projects.

 

So, technically the engine can be pushed too far in both positive and negative direction. But imaginatively, the Doom engine remains unbeaten. It is but one of the fastest ways to translate an idea in your brain to visual output.

Share this post


Link to post

Why would you rip out the BSP? For what it does there's not really much out there that can do it faster.

The real problems come with map sizes that cannot even be done on modern engines - there's reasons why they do much with models that needs to be done with linedefs and sectors in Doom.

Share this post


Link to post
9 minutes ago, Graf Zahl said:

Why would you rip out the BSP? For what it does there's not really much out there that can do it faster.

That's why i said what i said. Doom could be oodles amount faster on the heaviest maps but it requires replacing the very heart of what makes the Doom engine be the Doom engine. You would need to mimic its behavior exactly which is practically unworkable.

 

As it stands the engine buckles on things like map sizes or extreme amounts of line defs/sectors, working against the current rendering model.

Share this post


Link to post
4 hours ago, sluggard said:

dunno if that's sarcasm or not but i think people are already doing that lol, total chaos? think i've seen one of @Dragonfly's works using 3D model pieces for scene with actual map geometry hidden beneath them, kinda looks like using a low-poly collision model for a high-poly model like with unity and unreal.

No, it's not sarcasm, and I'm aware that 3D models aren't anything new (I'm assuming you're talking about the tower in Eviternity?). But it's something that could be taken advantage of more often, and it probably would be used more often if there wasn't a dumb stigma around it. What I was trying to point out is the fact that when most people hear the words "3D models" they jump to the conclusion that "OMG they're trying to replace da sprites!!". I think a lot of people don't stop and realize that 3D models can be used for more than just enemies. Anytime 3D models are brought up there is always at least one loudmouth saying it shouldn't be done for one reason or another, usually "because it doesn't belong in DOOM".

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×