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

ZDoom vs. GZDoom

Recommended Posts

I know that GZDoom is basically a GL version of ZDoom, but are there any under-the-hood differences that aren't so readily obvious?

Share this post


Link to post

The 3D floor physics code is actually in ZDoom too, but it's still #ifdefed out. You can add a define and get ZDoom with 3D floor support! But they'll be invisible, of course.

Share this post


Link to post

I don't know if this is implied with GL, but the reason I use GZDoom is because it eliminates the warping when looking up and down, and the sky doesn't get "sucked in" to the sides when turning.

Share this post


Link to post

That's both differences in the renderer though - nothing that affects gameplay.

Aside from 3D floor physics, FraggleScript and the dynamic light thing zypes there are no differences in the main game engine.

Share this post


Link to post

I'd say the 3d floor feature is a big step. It's very versatile. Being able to naturally look at high angles helps too.

And you don't have to see sprites billboarded to look like papers when looked at a vertical angle, and neither "blurred" (filtered) textures. Both are settable in the menu.

Share this post


Link to post

The fragglescript support is worth mention, no? ACS is pretty powerful, but I'm sure there's some other things that Fragglescript is useful for.

Share this post


Link to post

Mainly playing the few Legacy maps out there.

Yes, FraggleScript does offer a few features that ACS doesn't have.

One particular deficiency of ACS is that it only knows variables of type int.

FraggleScript on the other hand does have real strings and actor variables so if some project needs those it might indeed be useful. Of course, such a project won't run under ZDoom.


I think the biggest issue is the lack of documentation though.

Share this post


Link to post

I was making a voodoo conveyor in Heretic. And it would work fine in HereticP and Zdoom. But it'd get stuck in GZdoom. Had to do a little modifying and it worked. But there was definitely a difference between Zdoom and GZdoom, however minute.

Share this post


Link to post

How did you do it? Of course there's a few differences due to inclusion of some extended line actions.

And more importantly, which versions of ZDoom and GZdoom did you encounter this with? Do you still have the map so I can check?

Such a glitch is most likely a bug.

Share this post


Link to post
DuckReconMajor said:

I don't know if this is implied with GL, but the reason I use GZDoom is because it eliminates the warping when looking up and down

That's because the Doom renderer is a 2.5d engine, while the GL renderer is 3d.
True color is another great advantage of GL modes. Playing KDIZD, all those colored lights look ugly in software mode and wonderful in GL mode, imho.

Share this post


Link to post

Well in my opinion ZDoom is more software friendly than GZDoom (obviously), But i feel GZDoom is easier on the eyes and displays more eye candy than the latter.

Share this post


Link to post
Graf Zahl said:

How did you do it? Of course there's a few differences due to inclusion of some extended line actions.

And more importantly, which versions of ZDoom and GZdoom did you encounter this with? Do you still have the map so I can check?


I might be able to recreate it. But I don't have the original still.

EDIT: I can't recreate it.

Share this post


Link to post
Nomad said:

The fragglescript support is worth mention, no? ACS is pretty powerful, but I'm sure there's some other things that Fragglescript is useful for.

No.

Share this post


Link to post

Maybe, but it's a normal artistic response to dismiss everything that you've previously done :-)

Seriously though, it's missing some pretty fundamental things. The original version didn't even include } else { statements (I think it was added in Legacy though). The biggest thing it lacks is probably the ability to set callbacks to be invoked on particular events. For example, if you want to perform a particular action when a monster dies, you have to poll the monster in a loop, constantly checking its state. If I was designing it now, I probably would include that as a built-in feature of the language, via closures or something similar.

That's ignoring the code itself, which as I'm sure you already know is horrible. I'm pretty sure that the string handling system is intrinsically insecure and vulnerable to buffer overruns. All I can say is that I was 17 when I wrote it, I knew nothing about compiler design (I came up with the algorithms myself) and I hadn't really learned yet how to properly design modular and structured code.

It did at least help to get me an interview at Cambridge when I was applying to university! I mentioned it on my application form and it was the first thing they asked me about when I went to the interview. Unfortunately, I didn't get the necessary grades in the end :-)

Graf Zahl said:

I think the biggest issue is the lack of documentation though.

If you really want it, there is some semi-decent documentation:

Share this post


Link to post
Graf Zahl said:

Lol. So little respect for your own creation...? :D

He's honest

Share this post


Link to post
fraggle said:

That's ignoring the code itself, which as I'm sure you already know is horrible. I'm pretty sure that the string handling system is intrinsically insecure and vulnerable to buffer overruns.


The original, definitely. However, I have almost completely rewritten that part so the version in GZDoom doesn't have any memory management issues anymore.

To me the biggest issue with the existing code base is that expression evaluation does not know real operator precedence but I fear if I fixed that some Legacy WADs wouldn't run anymore.


All I can say is that I was 17 when I wrote it, I knew nothing about compiler design (I came up with the algorithms myself) and I hadn't really learned yet how to properly design modular and structured code.


Yeah, well. And yet I have seen much, much worse code from highly paid professionals who should know better.

Share this post


Link to post

Isn't GZDoom typically based on the latest available ZDoom SVN at the time, in essence making it more up to date than the current main release? (Currently 2.3.1).

I remember there was a version of GZDoom where pulling out the gauntlets in Deus Vult II would cause a crash but not in ZDoom (This has since been fixed, though.)

Share this post


Link to post
Mike.Reiner said:

Isn't GZDoom typically based on the latest available ZDoom SVN at the time, in essence making it more up to date than the current main release? (Currently 2.3.1).

I remember there was a version of GZDoom where pulling out the gauntlets in Deus Vult II would cause a crash but not in ZDoom (This has since been fixed, though.)



I did more frequent releases before the unofficial SVN builds appeared. However, since then there's little point in doing so unless something really important was changed.

Share this post


Link to post

GZDoom has cooler particles and texture filtering and the looking up and down isn't screwed. But I still play ZDoom :P

Share this post


Link to post

Whats the latest port to have 3Dfx Glide support? All i know of is Legacy. It really looks nice on my Voodoo5 5500.

Share this post


Link to post

Gzdoom is okay I guess. The only time I use it is for when I download wads that require it(Which isn't very often). Zdoom is okay too, I like it better because I like the idea of having a source port that has new features, but not a new render, like OpenGL.

Share this post


Link to post

I just downloaded the latest SVN version of Zdoom and GZdoom and then tried them with my Heretic wad. The result was interesting.
Zdoom seems to do just fine. But in GZdoom the sky is fubared with it using the TMBSTON1 texture instead of the texture SKY3 that is defined in the Mapinfo. However, it's also interesting. Because in Eternity I get the same error.

Both of them are supporting the level info header for Fraggle Script. But even then it shouldn't show up the TMBSTON1 texture as the sky defined there is Sky4 (because Legacy couldn't handle the wrap around sky I did in Sky3)

Anyway. It appears the level info data is overwriting some of the Mapinfo specifics. Maybe a block should be included for level info in the case of a Mapinfo lump being present in the wad?

*Now I just got to figure out what is wrong with my texture lumps since they suddenly is giving me TMBSTON1 instead of SKY4 in all the ports using Level info*

EDIT: fixed it. Something that seem to happen a bit too often with XWE that it changes the names of some unrelated texture to another texture's name. I've had it happen 3 or 4 times now.

Share this post


Link to post
kristus said:

I just downloaded the latest SVN version of Zdoom and GZdoom and then tried them with my Heretic wad. The result was interesting.
Zdoom seems to do just fine. But in GZdoom the sky is fubared with it using the TMBSTON1 texture instead of the texture SKY3 that is defined in the Mapinfo. However, it's also interesting. Because in Eternity I get the same error.



Can you send me a stripped down version of the WAD so I can check this problem?

Share this post


Link to post

Well. the problem with the tmbstone texture was resolved. It was a texture lump error. But it did make me attentive on that the levelinfo header added with fraggle script overwrites the data added by the mapinfo.

I can send you a demo to show you.

EDIT: here's the file. It shows how both the level name and the sky set in Mapinfo is overwritten by the level info section of fraggle script.
http://www.tfuture.org/kristus/gzdemo.zip

Share this post


Link to post
kristus said:

Well. the problem with the tmbstone texture was resolved. It was a texture lump error.


Ok, good to see it's resolved. This was the thing I was more concerned about.


But it did make me attentive on that the levelinfo header added with fraggle script overwrites the data added by the mapinfo.


Actually, the FS header has to take priority. Otherwise it wouldn't be usable at all since all level and sky names are defined in an internal MAPINFO and there's no way to distinguish between default definitions and custom ones once everything has been set up.

Share this post


Link to post

Ok. Well. it's a minor issue anyway. Only means that GZdoom users won't have the wrap around sky that they get in other ports not supporting [Level Info]
In this instance anyway.

It wouldn't be possible to add a command to the Mapinfo lump then? Something like Ignorelevelinfo or whatever.

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
×