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

How much room of improvement is there for GZDoom?

Recommended Posts

There's lots of room to improve things. The main roadblock is simply lack of manpower to implement it all.

 

@42PercentHealth: I can guess what you consider "compatibility". Rest assured that this kind of compatibility won't happen because it'd require reintroducing a shitload of badly written code we are glad to have gotten rid of.

 

Share this post


Link to post
1 minute ago, Graf Zahl said:

@42PercentHealth: I can guess what you consider "compatibility". Rest assured that this kind of compatibility won't happen because it'd require reintroducing a shitload of badly written code we are glad to have gotten rid of.

I just want to be able to record demos in GZDoom that will play in any other source port. Guess I'll keep using prboom+ then.

Share this post


Link to post

There is no need to start looking for specific things to improve in GZDoom. It's the port most casual players use, because it launches everything, even if the end-user has no idea about formats and whatnot. That in and of itself is the single most striking reason why people say GZDoom is good.

 

That said, GZDoom has a few kinks when it comes to compatibility with formats such as boom (Transfer sector property linedefs come to mind), however none of the format discrepancies are actually gamebreaking, save for the kind of map that aims to abuse things like a certain port's physics (wall-/fence-/thingruns), or slaughtermaps which rely on a certain infight behaviour that you can't get with GZDoom. Unfortunately, most people are oblivious to these things as well as they don't care about infinite height and why it's actually important to have that for certain maps.

 

The one thing that I guess is worth looking into are these "edge cases", but since most people don't get their hand on these maps, or disregard the readme that states what source port the map is to be used with and instead launch all the things with GZDoom (because what could go wrong, and why would an author design a source-port dedicated map, ever? /sarcasm), and then complain about how something doesn't work and give the map a bad rating instead of, you know, launching it proper...

Share this post


Link to post

I'd like to see GZD to be a bit more optimized, and perhaps merged with Zandronum.

 

That's a rumor I've heard going around, GZD and Zandronum merging. I myself would prefer that. I mostly use the Doom Classic Complete IWAD that WADSmoosh generated, and Zandronum unfortunately does not support it.

Share this post


Link to post
44 minutes ago, 42PercentHealth said:

I just want to be able to record demos in GZDoom that will play in any other source port. Guess I'll keep using prboom+ then.

 

The thing is, that's not a 'just'. In fact, the code has gone too far to make it work again. By far the biggest thing, aside from small changes throughout is the fact that GZDoom has mostly abandoned fixed point and uses double precision floats for nearly everything.

Share this post


Link to post
1 hour ago, Nine Inch Heels said:

That said, GZDoom has a few kinks when it comes to compatibility with formats such as boom (Transfer sector property linedefs come to mind), however none of the format discrepancies are actually gamebreaking, save for the kind of map that aims to abuse things like a certain port's physics (wall-/fence-/thingruns), or slaughtermaps which rely on a certain infight behaviour that you can't get with GZDoom. Unfortunately, most people are oblivious to these things as well as they don't care about infinite height and why it's actually important to have that for certain maps.

 

The one thing that I guess is worth looking into are these "edge cases", but since most people don't get their hand on these maps, or disregard the readme that states what source port the map is to be used with and instead launch all the things with GZDoom (because what could go wrong, and why would an author design a source-port dedicated map, ever? /sarcasm), and then complain about how something doesn't work and give the map a bad rating instead of, you know, launching it proper...

https://zdoom.org/wiki/Compatibility_options

"The most important compatibility flags can be set or cleared in MAPINFO as well. This allows to create special map definitions that set the needed parameters to play the map properly. If a compatibility flag is set in MAPINFO this setting will override any change through the menu or by altering the console variable's value."

 

Blame the authors who don't read the manual before making maps. :P

Though yes, sure, can't blame a 2004 map for not doing this and so on, but nowadays your only excuse not to use these is not knowing about it.

Share this post


Link to post

There is a code

inside PrBoom/GLBoom

that allows it to play almost any wad, no matter how large or ridiculous

without lagging

 

I want that code to be in GZDoom.

 

And no, there's nothing wrong with my hardware.

Edited by StalkerZHS

Share this post


Link to post
2 minutes ago, StalkerZHS said:

There is a code

inside PrBoom/GLBoom

that allows it to play almost any wad, no matter how large or ridiculous

without lagging

 

I want that code to be in GZDoom.

Pretty sure you'd need a better computer at that point.

Share this post


Link to post

It's called "Intel Compiler." Entryway seems to have done some strong optimizations for this compiler as a binary compiled with Visual C++ is quite a bit slower. And GZDoom doesn't profit much from the Intel compiler at all.

 

Seriously, while PrBoom can handle maps like Nuts better, it is not impossible to bring the engine down to a crawl. Ultimately, what we have here is that a simpler program is likely to outpace a more complex one at the simpler task it was made for.

 

 

Share this post


Link to post
29 minutes ago, Albertoni said:

"The most important compatibility flags can be set or cleared in MAPINFO as well. This allows to create special map definitions that set the needed parameters to play the map properly. If a compatibility flag is set in MAPINFO this setting will override any change through the menu or by altering the console variable's value."

I am aware of this, but: How many boom maps/sets have a mapinfo lump?

 

Also, why should I put in the extra work of disabling GZDoom features when the readme clearly states what source port is supposed to be used? Plus, why should I have to do that work when people could simply use GZDoom's compat-presets, because that's also a thing? Also, have you considered that in spite of GZDoom's compat presets it still does not emulate other ports properly?

Share this post


Link to post
2 hours ago, Pyrolex said:

That's a rumor I've heard going around, GZD and Zandronum merging.

I'm pretty sure it has exactly zero basis, as there's a very big reason why Zandronum is so far away from GZDoom and that's because the netcode it uses requires a lot of changes to GZDoom's code to work properly.

 

It seems a lot more likely that the Zandronum team would drop Zandronum and instead use their experience with networked Doom to whip up a new netcode that's better compatible with GZDoom's code out of the box while still being more user-friendly and reliable than GZDoom's current netcode, and then either integrate that netcode into GZDoom or make a new port, but, well, that's not particularly likely either. 

Share this post


Link to post
8 minutes ago, Nine Inch Heels said:

Also, why should I put in the extra work of disabling GZDoom features when the readme clearly states what source port is supposed to be used?

You said it yourself: because folks will just jump into it without looking. This isn't always due to gross negligence-- sometimes it's a legit "oops!" on users' parts, and I don't see the harm in a safety net when it's easy to do*.

 

Directly related: plenty of Boom mapsets have MAPINFO lumps for things like disabling jump/crouch, which is very much in the same vein.

 

[*Not saying you have to bear this burden yourself. Try dropping a "hey could someone do this thing?" in Discord if you'd rather not bother.]

Share this post


Link to post
24 minutes ago, Nine Inch Heels said:

Plus, why should I have to do that work when people could simply use GZDoom's compat-presets, because that's also a thing?

You want someone to play your map exactly as intended, you have the tools. It's a question of how much effort you're willing to put in, so the player will have the exact experience you want them to have.

 

I agree with you though, never seen anyone use it lol

Share this post


Link to post

I'd love to see continued developments of Dynamic Lights.  With Shadow Maps and per-pixel-model lighting, we're getting a stage where maps can be pretty organically lit.  I totally appreciate that Doom is not at all designed with dynamic lights in mind, so any developments here are a tall order, but if we're asking Santa:

  • "Shaped" lights - as in output a specific shape of light as opposed to a perfect sphere.  For example:
    PointLight_CubeMap_Example.PNG
    This shadow is "baked" into the light object itself.  It would allow us to create very intricate shadows without the need to calculate it based on geometry, or even something as simple as a spotlight.
     
  • Shadow Maps on upper/lower walls (I know, I know!)
  • Shadow Maps on models and sprites (dynamic enemy shadows!  Ooooooh....)
  • Shadow Maps based on transparent textures.
  • Opposite of Ambient Occlusion (i.e. an unlit wall that is perpendicular to a heavily lit flat should be lit too)
  • Refraction properties for textures (i.e. a texture's "shininess").  We could build it into the Brightmap - use the Blue spectrum for Brightmap and the Red spectrum for Refraction (leaving the Yellow spectrum for something else?)

Just those would be great.  Thanks Santa!

Share this post


Link to post
1 minute ago, Bauul said:

Shadow Maps

Maybe when the hardware gets a lot more powerful than what it is right now...

Keep in mind that the current shadowmap feature, simple as it is, needs quite some powerful graphics hardware. On the 5 year old Geforce 550Ti I used to use, it was virtually unusable, even firing a BFG with shadowmaps on made the frame rate tank for a moment.

 

Share this post


Link to post
6 minutes ago, Graf Zahl said:

Maybe when the hardware gets a lot more powerful than what it is right now...

Keep in mind that the current shadowmap feature, simple as it is, needs quite some powerful graphics hardware. On the 5 year old Geforce 550Ti I used to use, it was virtually unusable, even firing a BFG with shadowmaps on made the frame rate tank for a moment.

 

Oh that's worth knowing, thanks!  So, if I may pick your brains for a second, if I was making a map that heavily relied on Shadow Maps to look right, is there a best practice for doing them efficiently?

 

For example in Doom 3 I recall it wasn't the quantity of dynamic lights in a given scene that was the issue, it was having three or more overlap on any single pixel.  Is it similar for GZDoom?

Share this post


Link to post
1 hour ago, StalkerZHS said:

There is a code

inside PrBoom/GLBoom

that allows it to play almost any wad, no matter how large or ridiculous

without lagging

 

I want that code to be in GZDoom.

 

And no, there's nothing wrong with my hardware.

Not GZDoom wads.

Share this post


Link to post
52 minutes ago, Graf Zahl said:

Maybe when the hardware gets a lot more powerful than what it is right now...

Keep in mind that the current shadowmap feature, simple as it is, needs quite some powerful graphics hardware. On the 5 year old Geforce 550Ti I used to use, it was virtually unusable, even firing a BFG with shadowmaps on made the frame rate tank for a moment.

 

Well keep in mind that the shadowmaps I added are applied to all dynamic lights in a scene. If the shadow casters are limited to only a few lights chosen by the mapper the performance costs are different. The cost of a spot light casting a shadow is roughly the same as being able to see camtexture. Omni directional lights are a bit more expensive, somewhere between 2-6 camtextures depending on what strategy is used to build the shadowmap. If the light source is stationary and actors are excluded they can also be cached for sectors that aren't actively moving.

Share this post


Link to post

What about a default GZDoom demo format that can be watched with current and future versions? Doesn't have to be PR+ compatible, just within GZDoom itself.

Share this post


Link to post
1 hour ago, kb1 said:

Not GZDoom wads.

Oh, I meant that should be in Zandronum, because zandro sometimes lags on some maps while gzdoom doesnt

Share this post


Link to post

Graf, since Strife: Veteran Edition's single player campaign is now supported in GZdoom, how about Capture the Chalice?  Sure, not too many here play it, but it is a part of SVE, after all.

Edited by Master O

Share this post


Link to post

It would require copying a lot code from SVE. The single player campaign was a little bit of scripting, actor definitions and a new entry to MAPINFO, but no real code being added to the engine, so that's why I didn't go further.

 

CTC seemed like too much work for too little gain.

 

Share this post


Link to post
11 hours ago, Spectre01 said:

What about a default GZDoom demo format that can be watched with current and future versions? Doesn't have to be PR+ compatible, just within GZDoom itself.

Just using the version was recorded for demo replaying(or using recording softwares), and as I remembered, Graf(or someone) said many times about the engine(physics/rendering etc.)just keep changing too frequently, even the next dev. build may just desync the demo recorded from the previous one if changed something in the engine, so you can imagine the official versions. And now it may getting worse with ZScript happened, a demo format won't change much with the situation, sadly, I can say GZDooM was not designed for demo recording/replaying, the engine just can't handle it well.

 

While it still possible, the problem is spending more time to maintain it, I guess.

Share this post


Link to post
1 hour ago, Player Lin said:

While it still possible, the problem is spending more time to maintain it, I guess.

Precisely that. Demo compatibility is one of the most time consuming and most restrictive features out there. This is something that can grind feature development to a standstill, because even the most minute of changes will affect demo sync.

 

Share this post


Link to post

The funny thing about GZDoom demo compat is that it's exactly like vanilla - which is to say, if you want to watch an old demo, you're going to have to dig up an old version that the demo was recorded for.

 

Granted, considering we've been stuck on a single vanilla version for so long and even have a few tools for playing pre-v1.9 demos without much issue, it's not surprising that people have gotten so used to maximum demo compat that they forget that id had to go and remake the title screen demos with each patch.

 

Though should people ever band together for competitive GZDoom demoing, one thing that could minimize the pain of this is to pick an official release ( likely the most current ) and make it so that only that version can be used. Then once a couple projects of interest pop up that require a later official version, add that version to the list of versions that could be used, and so on and so on. It's nothing exactly elegant, but it cuts out a lot of the version shuffling that would be required, especially if there're significant gaps between each "demo version." Especially since projects that're just mapsets tend to not require the latest version, anyway.

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
×