Do you think Zandronum should merge with [G/L]ZDoom at some point?

[DwarfCleric]

@drfrag It's my assumption that people in general (at least the sane ones) don't want to have to look for configs in forums, specially when they are newcomers and don't know exactly what to look for or how to call it. The configs are inside of the ZIP if they want, and there's also backups, in case the default one gets overwritten.

 

Now, viruses? Doesn't that happen at the source code/compiling phase? I'm not sure of what you're talking about there.

This is a Dev release that I downloaded back in december, I don't care for what version number it is (should it make a difference? people can compare the MD5 checksums anyway...) and I don't care for updating my Doom folders every single week. I want to do this ONCE, like most people, and I want it simply to work.

If other people also have the same priorites as mine, they can download the nice pre-configured packages. I'm not forcing anyone, I'm simply providing more options than the ones available at the moment. Jesus...

 

@Senor500

I will wait for your reply to provide more help...

What mod or mods exactly are you trying to run exactly? Give me one or two examples.

 

Would you try to open these same mods using ZDoom32 ?  (renderer is done by cPU, not gPU)

Download link for it already pre-configured right here: https://www.dropbox.com/sh/8m9wrub7k42p22z/AAC8-H3Avpn2qZ1Y9ef3xxV8a?dl=0

 

You load it like this: zdoom32.exe -file mod1.deh mod2.wad mod3.pk3

[DwarfCleric]

14 minutes ago, drfrag said:

Those are not the original release zips and that could be a concern (possible viruses among other things

 

executable MD5 checksums can be checked regardless of a new ZIP or not... is this dude really going this far? Ok then, just remember there are people watching, if you want to do this to yourself go ahead I'm not holding ya

[V-Pariah]

I can only imagine more of ZScript C/S in our immediate future if we tried it the "fast and furious" way.  Take everything, ram everything together, make it work as fast as possible.  That would leave no time to alter the foundation of which these things actually render by/with.  Winter Fury as an example by itself adds overhead to any ports supporting it and that's an amount of overhead that can roughly be seen visually if looking at it through a relic of a LUMP editor such as SLumpEd.  They just show up as unknown information, interpreted in any way possible as what's known.  Which is why when you load, say, a ZDoom in Hexen Format as, let's say Doom 2 format, you get something like:

 

 

Which as you know is complete gibberish, but still surprisingly the data is mapped exactly the same each time it's loaded as Doom 2 format.  Now, add ZScript to it (I won't) and more likely than not these pointless lines would be extremely long since it contains so much data.  That's all data to process in ports like Zandronum.

Going the "fast and furious" method to get GZDoom C/S?  Nobody's going to modify any of GZDoom to try to make it work faster on your machine.

I believe that's what you were going for @DwarfCleric without all of the abstract and visual nonsense I pointed above heh.  Also, I honestly have no idea what ZScript is actually capable of, but my guess is that it required a lot, and a lot, and even more development on top of the existing framework.  Not exactly fast and furious, but that's the first big step, and I have to give kudos for that.

EDIT: anyone who's more developer-savvy than me, I encourage you to correct this if it's technically incorrect.  so as to not provide any incorrect visual interpretations of GZDoom's complexity

Edited April 12, 2020 by V-Pariah

[drfrag]

I don't know what you're talking about or who are you talking to. So those are not releases but old devbuilds...

If there's a virus in a release it's my problem, if there's one there it's yours. Besides some people could not trust your zips and i don't think they'll check the checksum.

If some dude thinks it's something different (another source modification and not the original ZDoom32) he might ask for the source code, according to the license the source must be available. But that's not my problem either, you could address them to my GitHub i guess. May be i'm just becoming a bit paranoid.

[Senor500]

50 minutes ago, DwarfCleric said:

 

@Senor500

I will wait for your reply to provide more help...

What mod or mods exactly are you trying to run exactly? Give me one or two examples.

 

Would you try to open these same mods using ZDoom32 ?  (renderer is done by cPU, not gPU)

Download link for it already pre-configured right here: https://www.dropbox.com/sh/8m9wrub7k42p22z/AAC8-H3Avpn2qZ1Y9ef3xxV8a?dl=0

 

You load it like this: zdoom32.exe -file mod1.deh mod2.wad mod3.pk3

I compared the performance of Final Doomer's effects and BDLite.

Overall now though I figured out why LZDoom wasn't running that well, just had to tone down some settings I missed, works better than GZDoom but Zandronum is the best one in terms of performance as far as I can tell.

I've been keeping an eye out for ZDoom32 and will try it out later, seems interesting.

[drfrag]

https://github.com/drfrag666/gzdoom/releases/tag/2.8.5c

[-TDRR-]

In all honesty, all I want is that Zandronum catches up with GZDoom's DECORATE, and nothing else. I personally don't want Zandronum to suddenly start requiring OpenGL 5 billion to run freaking Doom from 1993 less efficiently than Doom Eternal, I believe that if it ain't broke, don't fix it.

[DwarfCleric]

9 minutes ago, -TDRR- said:

all I want is that Zandronum catches up with GZDoom's DECORATE, and nothing else. I personally don't want Zandronum to suddenly start requiring OpenGL 5 billion to run

+1 That sums up perfectly, yeah. It's not needed that 100% of mods will run on it, of course some of them will only run in gzdoom. If they start pursuing 100% compatibility they are on for some endless fruitless fight, when some other things could be done with the same time. It's hard enough.

[DwarfCleric]

25 minutes ago, Senor500 said:

I've been keeping an eye out for ZDoom32 and will try it out later, seems interesting.

If you download my packages there please report back here if there was any "virus" or strange activity in your computer, okay? HeeHeeHee

 

These are my personal backups for my own convenience. But since I already have those online, I might as well share the link. It literally takes a mouse click to do that and it helps other people.

[Redneckerz]

24 minutes ago, Senor500 said:

I compared the performance of Final Doomer's effects and BDLite.

Overall now though I figured out why LZDoom wasn't running that well, just had to tone down some settings I missed, works better than GZDoom but Zandronum is the best one in terms of performance as far as I can tell.

I've been keeping an eye out for ZDoom32 and will try it out later, seems interesting.

In terms of GZDoom equivalence, its 1.8.6. It might be stable, but its really.. old.
 

12 minutes ago, -TDRR- said:

In all honesty, all I want is that Zandronum catches up with GZDoom's DECORATE, and nothing else. I personally don't want Zandronum to suddenly start requiring OpenGL 5 billion to run freaking Doom from 1993 less efficiently than Doom Eternal, I believe that if it ain't broke, don't fix it.

I am not sure how much of that can be backported to Zandronum's GZDoom base. There is only so much you can do here.

 

One thing i could think of is that Zandro makes the Zandro-specific parts more like a module so that they can be relatively painfree applied to more recent versions. Nevertheless, even such an implementation would require a significant rework.

[Senor500]

6 minutes ago, Redneckerz said:

In terms of GZDoom equivalence, its 1.8.6. It might be stable, but its really.. old.

As long as it works...

[Graf Zahl]

54 minutes ago, Redneckerz said:

I am not sure how much of that can be backported to Zandronum's GZDoom base. There is only so much you can do here.

 

 

The end of the line will be ZDoom 2.8.1, that was the last version before DECORATE was switched over to the scripting VM that also drives ZScript.

If Zandronum wants to get past this it may just as well go all the way., because once the VM works in a C/S context the rest won't be an issue anymore.

 

51 minutes ago, Senor500 said:

As long as it works...

 

If you keep your old computer, no problem - but don't ever think about upgrading your OS then.

[seed]

2 minutes ago, Graf Zahl said:

If you keep your old computer, no problem - but don't ever think about upgrading your OS then.

 

Honestly, I am no longer able to understand the obsession for keeping ancient hardware going instead of upgrading... not to be an asshole or anything...

[hypoactive]

IMO what killed Douk 3D's modding scene was 1. a lack of functional source ports and 2. overly difficult modding. Now for #2, Doom has that down. You really just need GIMP, Slade, and DoomBuilder. It's super simple to make mods compared to Duke 3D. But #1, well, Doom has it better. I don't know whats going on with EDouk but at least ZDoom has a functioning netcode. However, Zandronum-like Multiplayer with GZDoom modding would make the ultimate source port.

 

Still looking for a Vanilla Source Port with multiplayer comparability that isn't Crispy Doom (for now lol until the whole virus thing gets fixed.)

[LexiMax]

1 hour ago, -TDRR- said:

In all honesty, all I want is that Zandronum catches up with GZDoom's DECORATE, and nothing else. I personally don't want Zandronum to suddenly start requiring OpenGL 5 billion to run freaking Doom from 1993 less efficiently than Doom Eternal, I believe that if it ain't broke, don't fix it. 

 

OpenGL itself is fundamentally broken.  It no longer accurately represents what real graphics cards are doing under the covers, and ever since macOS deprecated it, it's not even good as a "common API".  Arguably, it never even was a good common API due to the compatibility issues between OpenGL implementations in different drivers and operating systems - what might be fast on one card and operating system might be slow or completely broken on a different one.

 

You should want support for stuff like Vulkan, Metal and DX12.  Done well, it's going to be faster no matter if you're rendering hundreds of triangles or millions.

[Redneckerz]

1 hour ago, Senor500 said:

As long as it works...

That's the thing really - It can't be trusted that Zandro can keep up for another 5 years in this state alone, because its API support is positively ancient, to the point where major vendor may just suggest to drop support for them altogether.

6 minutes ago, Graf Zahl said:

The end of the line will be ZDoom 2.8.1, that was the last version before DECORATE was switched over to the scripting VM that also drives ZScript.

If Zandronum wants to get past this it may just as well go all the way., because once the VM works in a C/S context the rest won't be an issue anymore.

 

 

If you keep your old computer, no problem - but don't ever think about upgrading your OS then.

A merger of 2.8.1 with the GZ 1.8.6 renderer might be worth while - Atleast 2.8.1 is vastly more modern then what is used now, but it is also discontinued, meaning it is a stable platform to build upon.

 

The resulting FrankenEngine might be a hotchpotch though (2016 ZDoom code running a 2010 OpenGL 1.4 renderer?) but atleast for everything but the GL renderer, they would move up quite a bit.

Could be a reasonable endeavor, even if its bleeding edge.

2 minutes ago, seed said:

 

Honestly, I am no longer able to understand the obsession for keeping ancient hardware going instead of upgrading... not to be an asshole or anything...

Well, legacy support (Not the port). Current GZDoom is far away from Zandronum's underpinnings, but it also exhibits a base hardware level that computers must comply to, OpenGL 3.3. This is however, quite old hardware by itself (Geforce 8x level hardware) but in the Doom source port sphere, its still one of the more recent supported API's.

Zandronum exposes at best OpenGL 1.4 (As OpenGL 2.0 became introduced in GZDoom 1.9.1), which is 2000/2001 grade hardware support. There is something to say for such legacy support in Zandro's case:

• Despite being way out of date, it is stable enough (through Zandro net code) that it allows multiplayer mods to be made.
• It comes with significantly lower requirements, meaning even an exceptionally old rig can function as a server or player.
• Zandro's angle isn't about pushing visuals, but providing a stable netcode with some extra GL fluff. Its intent is significantly different from GZ's.

However, supporting such old code also means that you are subject to OS incompatibility in the future. Its a bit like the story of MMO's. Their engines usually are not the latest and greatest as they need to rely on stable code bases (See Mortal Online, for instance, which uses a rather ancient Unreal Engine 3 build) or Entropia Universe, that still relies on CryEngine 2).

 

Zandronum is in much of the same bracket. It targets stability first, LTS grade stability to be precise. Whilst it is commendable that the underlying GZDoom 1.8.6 is holding out for so long, eventually you have to make an upgrade. Atleast to OpenGL2, and preferably GL3.

 

If Zandro will ever move to that, then perhaps an Zandronum CL (Classic) should be made that continues the old base and keeps it updated against new OS updates. Because well, there is also something to be said for stability. Why polish an engine when it only needs some new oil?

[Urthar]

Support for multi-tagged sectors is something I'm specifically hoping to see. I'm not sure if there's any other ZDoom 2.8.1 features that lack support in Zandronum.

[Ralphis]

6 minutes ago, hypoactive said:

Still looking for a Vanilla Source Port with multiplayer comparability that isn't Crispy Doom (for now lol until the whole virus thing gets fixed.)

Odamex can play 100% like vanilla out of the box with Zandronum style c/s networking.

[Graf Zahl]

2 minutes ago, Redneckerz said:

Zandronum is in much of the same bracket. It targets stability first, LTS grade stability to be precise. Whilst it is commendable that the underlying GZDoom 1.8.6 is holding out for so long, eventually you have to make an upgrade. Atleast to OpenGL2, and preferably GL3.

 

 

You are forgetting something here. OpenGL is an essentially dead API. Apple has already done it, AMD's support is also dwindling and Intel likes to depecate its old hardware and un-support it even faster than AMD.

The inevitable outcome here will be that down the line OpenGL will be relegated to the one thing it's still critical for - old dinosaur CAD software that cannot be rewritten - definitely not games.

 

Having this as your sole target will mean that rather sooner than later it will be "game over". So, in order to be future-proof at some point Vulkan will become a must - and worse for these old computers - OpenGL support may become irrelevant, especially on the driver level for more modern systems. But once those modern systems on which the software gets developed no longer support it properly, it'd mean the end of the story.Why do you think GZDoom ultimately dropped GL 2? The simple reason is that on a modern Vulkan compatible GPU you cannot test that render path anymore and it'll suffer regressions. And these regressions will inevitable mean that at some point it becomes unviable. The same will also happen with GL 3.3 in a few years, and ultimately for all  OpenGL.

 

[seed]

8 minutes ago, Graf Zahl said:

AMD's support is also dwindling

 

Actually, I've been doing some more research on their OpenGL dilemma, and apparently they still care enough about it to even fix performance issues. They actually reached a milestone back in September when someone managed to locate exactly where a lot of their GL performance was going down the drain and it was since fixed. And they're reportedly still investigating things here and there.

 

But otherwise, yes, locking yourself behind GL is a mistake. It's a soon-to-be-dead and replaced API. It's not the future, and never was.

[Graf Zahl]

Yeah, if they get pointed to the problem...

 

Two years ago they added a shader compiler misoptimization bug that broke GZDoom. The bug got reported to them early but nothing happened - only when someone pointed them to the precise spot where something went wrong they fixed it. Seems to me that they don't do much of their own detective work here...

 

[seed]

5 minutes ago, Graf Zahl said:

Yeah, if they get pointed to the problem...

 

Two years ago they added a shader compiler misoptimization bug that broke GZDoom. The bug got reported to them early but nothing happened - only when someone pointed them to the precise spot where something went wrong they fixed it. Seems to me that they don't do much of their own detective work here...

 

Yeah, that's something I've noticed as well, if you tell the GL team where to look, they will probably fix it, but otherwise they don't seem to be bothered or give generic software assistant replies - "we're looking into it". Can't say I blame them honestly, but it's kinda fun to see things like this after years and years of abysmal GL performance in their drivers. They could've simply dismissed all reports, but they did not.

[Graf Zahl]

It's called "token support". Never openly admit that you are not caring and at least give the impression that work is still being done.

 

[Ron_O_Wallis]

I just want zandronum vulkan support (and better DECO).

[Redneckerz]

1 hour ago, Graf Zahl said:

You are forgetting something here. OpenGL is an essentially dead API. Apple has already done it, AMD's support is also dwindling and Intel likes to depecate its old hardware and un-support it even faster than AMD.

The inevitable outcome here will be that down the line OpenGL will be relegated to the one thing it's still critical for - old dinosaur CAD software that cannot be rewritten - definitely not games.

I am aware that OpenGL is on its way out.

 

However, i don't consider the jump to Vulkan realistic with the state of Zandro as is. Whilst moving to the latest API would solve a lot of compatibility issues, Zandro's angle is not bleeding edge by its virtue.  Zandro atleast has a GL renderer. So, a realistic onset would either be:

• Moving to ZD 2.8.1 as its base and merging the old 1.8.6. renderer.
• Moving to GL2 or even better the baseline GL3.

A pipedream answer would indeed be Vulkan, but heaven jettisons, do you really see that become a reality any time soon, given Zandro's current stasis like situation?

1 hour ago, Graf Zahl said:

The same will also happen with GL 3.3 in a few years, and ultimately for all  OpenGL.

That's atleast still a few years, mind you - Removing OpenGL 4.6 altogether would be a considerable effort to do, so in that sense, Zandro can hold out for a few years longer if it would move to a modern GL renderer.

The only other sensible option is as mentioned a ZD 2.8.1 merge, but i dread the possible pitfalls or unexpected behavior that may cause.

 

Lastly, Zandro's future should be discussed by those that run it. I have not seen much activity in that department, atleast in the public eye.

And as for Linux, well, there are folks making upstream patches for Rage128 or even S3 Unichrome IGP stuff :D Who is to say that the community at large won't go after such a hypothetical LTS legacy target?

[drfrag]

2 hours ago, Redneckerz said:

A merger of 2.8.1 with the GZ 1.8.6 renderer might be worth while

Why would they want to keep GL 1.4 support? Why not just merge with GZDoom 1.9.1 (based on ZDoom 2.8.1)?

2 hours ago, Redneckerz said:

Zandronum exposes at best OpenGL 1.4 (As OpenGL 2.0 became introduced in GZDoom 1.9.1)

Why do you think they both don't support higher GL versions?

Quote

there are folks making upstream patches for Rage128 or even S3 Unichrome IGP stuff :D

Have you tried to use a modern linux with those cards? My IBM laptop has a Rage mobility 7500 and it sucks.

[Senor500]

3 hours ago, seed said:

Honestly, I am no longer able to understand the obsession for keeping ancient hardware going instead of upgrading... not to be an asshole or anything...

Money, can't get new hardware as of now.

[Decay]

No because Zandronum/skulltag is pretty done with having shitty admins and devs who throw shit fits whenever someone blinks at them wrong. (G)zdoom's community is also definitely not ready for zandronum's/multiplayer doom's generally toxic populace. True, it sucks where Zan is sitting right now, for a variety of reasons (not least because of inactive devs), but after experiencing skulltag's last years a true merge is anything but desirable.

[Redneckerz]

1 hour ago, drfrag said:

Why would they want to keep GL 1.4 support? Why not just merge with GZDoom 1.9.1 (based on ZDoom 2.8.1)?

Would that incentive be worth it for them? Why not go latest with that GL2 renderer? But that's post-2.8.1.

 

1 hour ago, drfrag said:

Why do you think they both don't support higher GL versions?

Because that's their official support status.

 

1 hour ago, drfrag said:

Have you tried to use a modern linux with those cards? My IBM laptop has a Rage mobility 7500 and it sucks.

That's why there is a guy writing patches for them... to make them suck less ;p

[drfrag]

Becouse ZDoom32 despite not supporting ZScript uses the modern VM and the GL renderer is post floatification.

Where did you got that? That's obviously not true, those were the minimum requirements.

Trust me they still suck.