Can updating the engine be taken too far?

[Marisa the Magician]

3 hours ago, msx2plus said:

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.

Funny enough us gameplay modders have the same sentiments and frustrations about map compatibility. Especially those of us who are OBSESSIVE about trying to make everything work and feel somewhat balanced. There will always be a map out there that will break everything, people will always want to try to play your mod in a map where it most definitely won't work.

 

Or worse, they'll complain that it doesn't work with a certain other mod.

 

Though despite all this, I'm still grateful that I can keep making mods and bring all my wacky ideas to life, no matter how crazy or "not-doom" they may feel.

Edited September 2, 2021 by Marisa Kirisame

[msx2plus]

for sure @Marisa Kirisame, i think it mostly comes down to player expectation and educating them on the how/why of why certain things just will or will not work without intense modification or a full redo

[ketmar]

9 hours ago, Redneckerz said:

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.

yet BSP is not an essential feature at all. it is just a handy way to split polygon soup into convex polygons, that's all. in most modern sourceports BSP isn't even used for hitscan tracing, it's all done on the blockmap. ripping BSP out may be needed to make the engine even slower by implementing freely modifiable geometry, for example, but it can't really make the engine faster. ;-)

 

and to be at least somewhat on-topic: dynamic lighting with shadows is prolly "too far". or, in other words, closer to "Doom3 that people expected". ;-)

Edited September 3, 2021 by ketmar

[CBM]

42 minutes ago, ketmar said:

yet BSP is not an essential feature at all. it is just a handy way to split polygon soup into convex polygons, that's all. in most modern sourceports BSP isn't even used for hitscan tracing, it's all done on the blockmap. ripping BSP out may be needed to make the engine even slower by implementing freely modifiable geometry, for example, but it can't really make the engine faster. ;-)

 

and to be at least somewhat on-topic: dynamic lighting with shadows is prolly "too far". or, in other words, closer to "Doom3 that people expected". ;-)

but what true 3D map format would be the best fit then?

I still think it should be possible to make an idtech engine port that has support for more than one generation of games and the ability to mix and match them... ie. playing doom with a true 3D map format (like bsp and others)

 

bsp: https://quakewiki.org/wiki/Quake_Map_Format

 

@TheMagicMushroomMan

 

I tend to see models as a way to visually improve the look of doom.

I really really really like playing maps with 3d models for enemies, items, weapons, scenery etc but I like the idea of having map elements be 3d models as well and then use an invisible 3d floor section as its collision box

 

 

Edited September 3, 2021 by CBM

[Graf Zahl]

1 hour ago, ketmar said:

in most modern sourceports BSP isn't even used for hitscan tracing, it's all done on the blockmap. ripping BSP out may be needed to make the engine even slower by implementing freely modifiable geometry, for example, but it can't really make the engine faster. ;-)

 

 

BSP was never used for hitscan tracing. The only non-rendering tasks the BSP gets used for is a) finding out what sector something is in and b) sight checks. And the latter was only done after id was unable to fix their far more efficient blockmap based algorithm.

 

1 hour ago, CBM said:

but what true 3D map format would be the best fit then?

I still think it should be possible to make an idtech engine port that has support for more than one generation of games and the ability to mix and match them... ie. playing doom with a true 3D map format (like bsp and others)

 

 

None. Whatever you believe, Doom's and Quake's engines are so fundamentally different on every conceivable level that the only way to make  "combined" engine would be to put both full sets of code into the same executable. There's simply not a single piece of game-side code that can be shared.

Furthermore, Quake (1+2) are strict client/server based, so even seemingly trivial stuff gets send across the network, even in single player games.

 

You cannot even combine Doom with Build because, despite both being based on a 2D map format, there's very little to share - although in this case you could at least have a unified UI that serves both, if it wasn't for the incompatible licenses.
'

[Gez]

12 minutes ago, Graf Zahl said:

There's simply not a single piece of game-side code that can be shared.

Except for P_NewChaseDir! :p

["JL" was too short]

To answer the question in the title, I do not think that updating the engine can be taken too far.

 

Why?

 

Because I'm positive that anytime you could point to something and say "updating the engine was taken too far here", it would in fact be a case of shitty mapping/modding, and dumping it at the engine's doorstep would be horribly unfair.

 

Case in point: My reaction to the first "hi-res" Doom texturepacks I saw was that they looked fucking atrocious in the game.  Is that a problem with the engine?  Hell no, it's a problem with the taste and/or talents of whoever barfed out the textures.  It makes no sense to say that having the capability to use high-res textures in GZDoom (or whatever port) is a bad idea per se.  The ability to use high-res textures is just a tool; it can be used well or poorly.  Maybe the number of modders who can use it well (which is a vague stipulation, so let's say we mean that the textures look like they fit in Doom and don't break my immersion) is so small that the feature will, for all practical purposes, never be used well.  Still doesn't mean anything was "taken too far" on the engine-coding side of things. 

 

You can apply the same logic to 3D models, colored lighting, the entire Brutal Doom featurelist... whatever it is that you personally think should have stayed safely straitjacketed in the local asylum.  It is always going to be a modder problem. 

Edited September 3, 2021 by jerrysheppy

[Gibbon]

1 hour ago, Gez said:

Except for P_NewChaseDir! :p

Depending on the source port, even that is not compatible (MBF combined these into a new function).  Plus, that is Doom 3, not Quake.

[Graf Zahl]

The Code was also in Quake, which you can see if you follow the link. But as it is just a small self-contained utility function for the AI pathfinding it doesn't negate anything that was said. The actors in these games are still totally incompatible objects.

 

 

[Gibbon]

9 minutes ago, Graf Zahl said:

The Code was also in Quake, which you can see if you follow the link. But as it is just a small self-contained utility function for the AI pathfinding it doesn't negate anything that was said. The actors in these games are still totally incompatible objects.

 

 

Seen that now, thanks.  I agree, it is not a direct equivalent just new code based loosely on previous versions.  You won't be able to copy that and slap it on Idtech1.  It is only a snippet, nothing more.

[CBM]

5 hours ago, Graf Zahl said:

None. Whatever you believe, Doom's and Quake's engines are so fundamentally different on every conceivable level that the only way to make  "combined" engine would be to put both full sets of code into the same executable. There's simply not a single piece of game-side code that can be shared.

 

...if it wasn't for the incompatible licenses.

 

Ok, well in that case it makes alot of sense.

I guess I need to explore using 3D Terrain and portals to avoid 3D floors as much as possible.

[Graf Zahl]

3D floors by themselves are not an issue - each single 3D floor costs roughly as much as the base sector it is in. The number of sectors is, so 3D terrain will lead to the same effects, and portals have their own performance bottlenecks.

 

In all cases, it's the number of element that counts.

[ketmar]

On 9/3/2021 at 9:04 AM, Graf Zahl said:

BSP was never used for hitscan tracing. The only non-rendering tasks the BSP gets used for is a) finding out what sector something is in and b) sight checks.

sight check is basically the same thing as hitscan tracing. i meant "ray-vs-geometry" checks as a whole. ;-)

 

On 9/3/2021 at 7:50 AM, CBM said:

but what true 3D map format would be the best fit then?

I still think it should be possible to make an idtech engine port that has support for more than one generation of games and the ability to mix and match them...

what Graf said — this has no sense. in the end you will have two completely different engines, trying to co-exist. and i mean completely different. you cannot share any substantial code between them, including physics. of course, you can make that beast work, but the amout of efforts required… let me say that it will be easier to touch the Moon jumping. ;-)

 

On 9/3/2021 at 9:04 AM, Graf Zahl said:

Furthermore, Quake (1+2) are strict client/server based

ah, Janis solved that in Vavoom! ;-) in some aspects, Vavoom is closer to Quake than to Doom (for example, it is a freestep engine with delta time passed to thinker methods, just as in Quake). and it even says 'Spawning server with map "e1m1"' on map load. it's not a lie. ;-)