Introducing RZDoom (Retro ZDoom) 3.0.1 - Updated April 17 2022

[GRAU]

On 1/27/2022 at 5:03 PM, drfrag said:

It's not, FWIW i dropped XP support in LZDoom 3.88 since recent mods could not run on 32 bit.

which mods? then what is the reason to use LZDoom then? Its feature was the support for old fashioned OS and HW for me. Ok that means that i will need to for my own version from 3.87 or 3.82 that i liked best.

[drfrag]

25 minutes ago, GRAU said:

If there was an option to compile LZDoom without SSE

There is and you can still compile 3.88x with the VS XP toolset but that toolset has limitations, it uses an old SDK and support for modern C++ is not very good.

The option is TC_USE_SSE2 or something like that, i never use it. But you'd need to compile the sound libraries without SSE2 too and that's the main problem besides truecolor would be slow. I don't remember the mod now but with the XP toolset the 32 bit version is not able to load pk3s with "too many" files.

[GRAU]

1 hour ago, drfrag said:

There is and you can still compile 3.88x with the VS XP toolset but that toolset has limitations, it uses an old SDK and support for modern C++ is not very good.

The option is TC_USE_SSE2 or something like that, i never use it. But you'd need to compile the sound libraries without SSE2 too and that's the main problem besides truecolor would be slow. I don't remember the mod now but with the XP toolset the 32 bit version is not able to load pk3s with "too many" files.

Are there any "full" instructions - how to compile lzdoom under win xp? I am not a coder but once over 10 years ago i had compiled GZDoom of some version for linux (xubuntu 11.04 maybe) succesfully. I didnt practice from that time because that netbook is lost and later i returned to xp where i had all i need untill previous year - when most of sourceports based on zdoom discontinued support for xp(((

[Graf Zahl]

You'll have a hard time compiling on an actual XP system - the modern toolchains simply won't run on it anymore and older compilers do not support modern C++ standards.

You'll have to do the actual compilation on a more modern system. What you need to do is tell CMake in the setup to use the legacy MSVC toolset - but you'll have to google for it, I can't tell you anymore because I forgot.

 

But even then, keep in mind that time has not stood still. There's no guarantees that what you get will work - and the dependencies all require SSE2 - good luck getting those recompiled - that's a task that's magnitudes harder than getting the engine itself compiled. None of the DLLs being shipped with GZDoom and LZDoom come as a cross-platform-friendly project - they are all *very* Linux-focussed where you virtually have to take the precompiled DLLs.

[Gibbon]

14 hours ago, GRAU said:

 

You got problems with ZDoom 2.8.1 on  Windows 11? or the target os for you is mac? I tested zdoom on win 10 and everything worked fine. See no need in your version for windows users. May be somewhere on mac...

 

Thanks for your meaningless contribution to a pathetic discussion.  As I said:

your opinion > /dev/null 2>&1

 

Tschüss!

[Redneckerz]

I know sir @Gibbon took your post to the garbage bin, but ill make an attempt at explaining.

 

Quote

You got problems with ZDoom 2.8.1 on  Windows 11? or the target os for you is mac? I tested zdoom on win 10 and everything worked fine. See no need in your version for windows users. May be somewhere on mac...

RZDoom is based on a release later than ZDoom 2.8.1. It takes the latest master from ZDoom (2.9pre) (December 2016) and patches that up to a stable basis. ZDoom 2.8.1 is from February 2016. RZDoom thus contains fixes ZDoom 2.8.1 does not have.

 

Because ZDoom 2.8.1 is unsupported, there may or may not be folks that would want to have an updated ZDoom 2.x build. This is where RZDoom comes in.

 

I should note that RZDoom does take distinctions (Correct me if im wrong gib):

• 2.9.0, 2.9.1: ZDoom 2.x core, D3D9 surfaces.
• 3.0.0: Pure DirectDraw, assembly removed
• 3.1.0? Will include a basic OpenGL1.4 renderer taken from Zandronum, in addition to the above.

Quote

I just was interested how really "retro" is your one. Now I see that not at all, just an empty sound.

Retro can have different meanings. To you, this means support for older OS'es and a high end software renderer. To Gibbon, it means stripping down the ZDoom 2.x core, using DDraw only, and making it playable on modern OSes (Windows/MacOS Intel + M1 and Linux).

 

Both approaches are perfectly valid. So why hammer down on his approach?

 

I don't recall you being like this, so color me surprised.

Edited January 29, 2022 by Redneckerz

[drfrag]

1 hour ago, Redneckerz said:

RZDoom is based on a release later than ZDoom 2.8.1. It takes the latest master from ZDoom (2.9pre) (December 2016) and patches that up to a stable basis. ZDoom 2.8.1 is from February 2016. RZDoom thus contains fixes ZDoom 2.8.1 does not have.

Not true, didn't you say something different last time? It was based on the unstable master at first but later Gibbon merged 2.8.1 so now it's based on 2.8.1 AFAIR. He discarded his previous changes back then AFAIK.

Besides earlier in this trhead it's been mentioned that it's demo compatible with 2.8.1.

1 hour ago, Redneckerz said:

Will include a basic OpenGL1.4 renderer taken from Zandronum, in addition to the above.

I've seen in the repo that now D3D is back.

Edited January 29, 2022 by drfrag

[Redneckerz]

1 minute ago, drfrag said:

Not true, didn't you say something different last time? It was based on the unstable master at first but later Gibbon merged 2.8.1 so now it's based on 2.8.1 AFAIR.

Besides earlier in this trhead it's been mentioned that it's demo compatible with 2.8.1.

I've seen in the repo that now D3D is back.

I suppose you are right, but the overall point i had hoped to convey is that retro means many things in these contexts.

[Gibbon]

On 1/29/2022 at 2:56 PM, Redneckerz said:

I suppose you are right, but the overall point i had hoped to convey is that retro means many things in these contexts.

I would agree.  Considering it's lineage (not having modern things like zscript or modern renderer) is pretty retro nowadays, especially for ports like this (which don't target archaic systems like DrFrag does).  Retro is anything from the past that is being used in the present (like 60's clothing habits), open the Oxford dictionary and look ;)

 

Also I have taken numerous patches from Gloome, GZDoom, Zandronum and ZDoom 1.22 so it isn't completely 2.8.1.  The D3D renderer for example is 100% taken from Zandronum (because theirs was clean and had bug fixes).  Good bunch of people in that team.

Edited February 2, 2022 by Gibbon

[NightFright]

Would you consider integrating timidity.exe into the main executable eventually, just like GZDoom did with v3.3.0? IIRC the main advantage of that was that the interruptions between MIDI loops disappeared. Also, it would be one file less in the folder, even simpler. (Then again, not everybody is using Timidity, so I dunno how important this can be.)

Edited February 3, 2022 by NightFright

[Gibbon]

Just now, NightFright said:

Would you consider integrating timidity.exe into the main executable eventually, just like GZDoom did with v3.3.0? IIRC the main advantage of that was that the interruptions between MIDI loops disappeared. Also, it would be one file less in the folder, even simpler. (Then again, not everybody is using Timidity, so I dunno how important this can be.)

That would require quite a lot of restructuring.  Granted I could do something like what ZMusic does but as you say, how many people are using this special timidity version vs fluidsynth?  No idea.

 

But yeah, it 'could' be done.

[NightFright]

Mainly it's for EAWPats, which after all is *THE* reason of using Timidity in any Zdoom-based port. It might not be everybody's favorite, but it's still the best GUS-like music solution there is and a great option for anybody who is into retro-style, less-than-perfect MIDI sound. 

 

No need to put it high on the prio list right now, but it'd be great to see it happen eventually. At least as far as I am concerned, if that counts for anything. ^^

Edited February 3, 2022 by NightFright

[Graf Zahl]

6 hours ago, NightFright said:

Would you consider integrating timidity.exe into the main executable eventually, just like GZDoom did with v3.3.0? IIRC the main advantage of that was that the interruptions between MIDI loops disappeared. Also, it would be one file less in the folder, even simpler. (Then again, not everybody is using Timidity, so I dunno how important this can be.)

 

Can't do - the license won't allow it.

GZDoom only could do it after moving to the GPL.

 

 

[NightFright]

Alright then, didn't know. Guess it's off the table, then.

[Gibbon]

10 hours ago, Graf Zahl said:

 

Can't do - the license won't allow it.

GZDoom only could do it after moving to the GPL.

 

 

Ahhh yes I forgot about that pesky licensing situation for older ZDoom.

[TruthInFiction]

Didn't you switch back to FMOD from OpenAL?  If so it might be a good idea to update the op to reflect that.

[Gibbon]

16 minutes ago, TruthInFiction said:

Didn't you switch back to FMOD from OpenAL?  If so it might be a good idea to update the op to reflect that.

Done

[Mr Nobody]

Hi Gibbon, it is possible to implement some kind of win_borderless option? similar to how ZzDoom borderless option works?.

 

Not sure if this is even remotely possible with RzDoom, I'm totally ignorant about the different engine/ports capabilities, coding and all the internal magic that you guys do. nevertheless I'm just gonna drop the question/petition here hoping to see it implemented one day.

[dregs]

How different is compiling this compared to regular ZDoom?

Would just copying what the ZDoom wiki does work?

Edited March 11, 2022 by dregs
Needs more detail

[Gibbon]

3 minutes ago, dregs said:

How different is compiling this compared to regular ZDoom?

Would just copying what the ZDoom wiki does work?

 

You WILL need the proprietary FMOD libraries to compile it.  I am planning on reintegrating OpenAL once I have fixed all the bugs it had.

 

It also needs MSVC (CMake is used for Unix-like platforms), this is so I can better optimise it for Windows users using Windows-specific API's and optimisations.

[Duderald]

GZDoom... QZDoom... LZDoom... Now RZDoom??!?

Are we gonna see an alphabet of ZDooms??!?!?!??

[Gibbon]

6 minutes ago, Comedy Conniseur said:

GZDoom... QZDoom... LZDoom... Now RZDoom??!?

Are we gonna see an alphabet of ZDooms??!?!?!??

 

Don't forget ZZDoom from DrFrag.

[Duderald]

12 minutes ago, Gibbon said:

 

Don't forget ZZDoom from DrFrag.

AAAARRRRGHHH!

[Gibbon]

So I have decided to discontinue RZDoom, effective now.  Let's face it, nobody uses it (except myself).  I am going to focus my skills when it comes to ZDoom-based stuff into contributing to GZDoom instead.  Graf and I may not see eye to eye, but I respect him as a great developer.

 

I'm happy to have at least significantly cleaned up the codebase of RZDoom.  It leaves it in a nice state.

 

My other ports are unaffected.

[scwiba]

Sorry to see this port discontinued. I was quite excited to use it, and was just checking up to see if anyone had mentioned support for lilith.pk3. I could of course stick with ZDoom 2.8.1 but was wondering if lilith plays okay in RZDoom?

[xX_Lol6_Xx]

1 hour ago, scwiba said:

but was wondering if lilith plays okay in RZDoom?

Apparently yes

[Gibbon]

14 hours ago, scwiba said:

Sorry to see this port discontinued. I was quite excited to use it, and was just checking up to see if anyone had mentioned support for lilith.pk3. I could of course stick with ZDoom 2.8.1 but was wondering if lilith plays okay in RZDoom?

It supports it 100%

 

It support everything ZDoom does, just does it better :P

 

Edit: so I’ve had multiple messages from folks telling me not to abandon it.  I really didn’t know it was used so that is why it factored into my decision.

 

I will unarchive the repository and do a release with what I have developed in the last few weeks / months.

 

Thanks to those that cared to message me about it :)

Edited April 17, 2022 by Gibbon

[Gibbon]

So 3.0.1 is done.  A little bit small.

• Added border texture flats for various popular and historical wads (Sunlust, Community Trunk, Community Chest series, Icarus etc..)
• Fixed some warnings in VS2022
• Code cleanups
• Removal of the green border texture (brdr)

 

Right now, only a Linux binary is up.  I'll do macOS and Windows later.  Note, that it was compiled on Ubuntu 21.10 x64, so if you use an older distro, the libc version may not be compatible).

 

And before anyone asks, no, I won't be doing a 32bit Linux build.  I'd rather not pollute my system with multilibs.  If there are enough users who have issues with Libc, then the next version will be done on my RedHat system (which has older packages).

[Redneckerz]

@Gibbonall this means is that you cant abandon your ports..  ever. Haha.

 

Am i correct in presuming however that the plans for 3.1.0 (OGL rendering) are now defunct?

[Gibbon]

1 hour ago, Redneckerz said:

@Gibbonall this means is that you cant abandon your ports..  ever. Haha.

 

Am i correct in presuming however that the plans for 3.1.0 (OGL rendering) are now defunct?

I’ve experimented but the performance on poor hardware was unacceptable.  The software renderer always beat it, depending on the wad, up to 50%.  I have a truly potatoe laptop with a nearly 10 year old i5 and a HD4000 or GT720m GPU. Performance was absolutely dreadful.

 

Windows was the best but for me, it either works on all 4 of my operating systems or it doesn’t go in.

 

Edit: Windows 32 and 64bit binaries are now up. 

Edited April 18, 2022 by Gibbon