Quo Vadis ZDoom?

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
Kotti
Posts: 86
Joined: Tue Dec 27, 2016 4:08 am

Quo Vadis ZDoom?

Post by Kotti »

I have been lurking here for most of the time, and ZDoom has been my favorite port for many years, but can please someone explain what happened yesterday?

As I understand, Graf Zahl said he would no longer work on ZDoom. So, is the port dead now and we have to use GZDoom in the future? I am not sure what will happen now, just by reading the thread that prompted all this.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Quo Vadis ZDoom?

Post by Graf Zahl »

If you have been around here for longer you may have noticed that Randi has been absent for longer stretches of time.

This makes it nearly impossible to have third-party input on some subsystems - in particular the software renderer which I have repeatedly stated is not code I enjoy working with. But with the recent QZDoom fork it's precisely that code that gets a lot of workover and I simply have no idea how far I should go with accepting pull requests. In such a situation I rather be conservative and leave the ZDoom repo alone. As long as Randi won't come back the only downside will be that there's no more ZDoom devbuilds, but for the time being GZDoom should be an adequate substitute, although if you favor the software renderer QZDoom may be the better option because that's where the work is being done.
Once Randi comes back and gives us some clues what ZDoom's vision is supposed to be and how to best split features between ZDoom and QZDoom and/or merging the ports eventually the situation should resolve itself. But how it will resolve itself I honestly cannot say.
User avatar
Nash
 
 
Posts: 17433
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: Quo Vadis ZDoom?

Post by Nash »

I'm a little unclear as far as feature suggestions or even pull requests are supposed to be from now on.

A) Does this mean that anyone who wants to submit PRs no longer have to concern themselves with doing 2 PRs for both ZDoom and GZDoom - and now should only be concerned with doing a single PR for GZDoom?

Example: In the past, when I sent the view actor roll PR code, there had to be 2 PRs - the ZDoom side and the OpenGL side. Would this no longer be relevant?

B) For feature suggestions, I'm guessing only things that don't concern the renderer would be considered? Like some ZScript function, or UI additions, actor-related extensions or things like that.

C) And 1 more question regarding feature suggestions... how is this even going to be handled? User makes a feature suggestion here on the zdoom.org forum and hopefully someone picks it up and sends a PR to the GZDoom repo?
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Quo Vadis ZDoom?

Post by dpJudas »

Nash wrote:Example: In the past, when I sent the view actor roll PR code, there had to be 2 PRs - the ZDoom side and the OpenGL side. Would this no longer be relevant?
This one is tricky. You can file a single PR against GZDoom, but note that while QZDoom is downstream of GZDoom the swrenderer is not anymore.

I took the official fork as the opportunity to rearrange the file structure and refactor a number of things. As time will pass, any change to zdoom or gzdoom's swrenderer will not make it to QZDoom. I don't know what Graf's long term plans are for the software renderer in GZDoom, but my goal in QZDoom is completely isolate and then refactor it. So you have to take that into account when deciding where to do PR's for the software renderer.

I'm trying to do this in a way that will make both the TC and Softpoly things optional, because I know the LLVM dependency may pose a problem for some usages. Mostly to ensure that IF the refactored version becomes more attractive to GZDoom, it can get it without needing to buy into the more experimental part of QZDoom. When it comes to the QZDoom project, we'd prefer PR's against GZDoom rather than QZDoom if the feature is common between both projects, because it much easier to do a merge downstream than the other way around. Overall, though, I don't know what Graf's plans are in this area.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Quo Vadis ZDoom?

Post by Graf Zahl »

dpJudas wrote: I took the official fork as the opportunity to rearrange the file structure and refactor a number of things. As time will pass, any change to zdoom or gzdoom's swrenderer will not make it to QZDoom. I don't know what Graf's long term plans are for the software renderer in GZDoom, but my goal in QZDoom is completely isolate and then refactor it. So you have to take that into account when deciding where to do PR's for the software renderer.
That's simple: I have no goals with it.
I have considered that code a lost cause many years ago and the only positive outcome I can imagine here is that GZDoom and QZDoom can eventually be merged together into one port, once your heavy experimentation stage is over. I'd think they'd be better off as one engine even now, but in order to do occasional releases I'd rather keep the inevitable instabilities caused by your refactoring out of the picture for the time being.
Furthermore, I won't merge any PRs that alter the software renderer until we have a clear roadmap how ZDoom, GZDoom and QZDoom can coexist.

I have one question myself: There's two features I plan to add to the GL renderer, that is supplementing the plane texture rotation/scaling/offsetting with a real texture matrix, the second one slanted wall textures that can align to a slope. Both have been suggested many years ago for ZDoom with zero response from Randi. Is this something you can add to QZDoom's renderer once the data structures are implemented? I guess the software renderer could do it but the code as it was was just too hostile for my taste.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Quo Vadis ZDoom?

Post by dpJudas »

Graf Zahl wrote:I have one question myself: There's two features I plan to add to the GL renderer, that is supplementing the plane texture rotation/scaling/offsetting with a real texture matrix, the second one slanted wall textures that can align to a slope. Both have been suggested many years ago for ZDoom with zero response from Randi. Is this something you can add to QZDoom's renderer once the data structures are implemented? I guess the software renderer could do it but the code as it was was just too hostile for my taste.
Sure, I don't see any problem in adding that. The cursed dc_texturemid thing that functions both as the U texture coordinate and the wall vertical offset is what makes it difficult, but I was planning on getting rid of that variable anyway.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Quo Vadis ZDoom?

Post by Rachael »

For the sloped wall textures - that's easy to implement from the r_segs portion of the code, I don't know about actually following slopes though. My idea was to simply follow an algebraic slope for Y (rise/run, with run being a constant of 1, the user providing the variable for rise through UDMF), and also allowing that for Y-scaling too. Editors like GZDB can take care of auto aligning, if needed. The point of origin will always be X=0 in this case.

If we're going to be simultaneously implementing it for OpenGL and software though, let's agree on UDMF variables first. Or at least downstream the proper UDMF code for it.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Quo Vadis ZDoom?

Post by Graf Zahl »

Ok, that's good to know. With ZDoom it would never have worked. Let's hope I can manage everything for a New Year release, but with the two biggest bugs out of the way as of today it should be doable.

One other thing QZDoom still needs is Quake-style cubemapped skyboxes, but I guess they'll come sooner or later. ;) (Yet another thing on ZDoom's eternal waiting list...)
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Quo Vadis ZDoom?

Post by Rachael »

Yet another thing that was on my to-do list but keeps getting shoved down. :P I may just take advantage of the triangle renderer and do it that way since it makes it easy. It uses GZDoom's coordinate system, so all I have to do is plug in the texture faces with (0.0,0.0)-(1.0,1.0) and it should be there.

In cases of portal/alternate skies, though, those cases get considerably more difficult, but drawing a cube in the pre-render phase will actually take care of probably 80% of GZDoom's maps. :P
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Quo Vadis ZDoom?

Post by dpJudas »

The cubemapped skyboxes could be done by having a fake subsector_t with 4 walls and then just draw that subsector instead of the normal ZDoom skybox.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Quo Vadis ZDoom?

Post by Graf Zahl »

Actually, only if it doesn't rotate. Don't forget that you can define the rotation axis for a cubemapped sky, it doesn't need to be vertical.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Quo Vadis ZDoom?

Post by dpJudas »

Oh - crap. That ruins that plan. :)
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Quo Vadis ZDoom?

Post by Rachael »

Maybe it might be better then, to have the Carmack renderer draw a stencil for the triangle renderer to overlay into. Then the triangle renderer can also do two skies - as long as there are two separate stencils. I am not sure if this is possible or if it would work, but the idea is to allow those multi-sky areas to be properly rendered. I doubt we'd ever need/want to support something like this, though: viewtopic.php?f=19&t=53202&p=933238#p933238
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Quo Vadis ZDoom?

Post by dpJudas »

The stencil is actually indirectly defined by the cliptop/clipbottom buffers handled by the sky portal drawing code. Need the triangle drawer tho.
User avatar
Kinsie
Posts: 7399
Joined: Fri Oct 22, 2004 9:22 am
Graphics Processor: nVidia with Vulkan support
Location: MAP33
Contact:

Re: Quo Vadis ZDoom?

Post by Kinsie »

Graf Zahl wrote:Let's hope I can manage everything for a New Year release, but with the two biggest bugs out of the way as of today it should be doable.
Will this enable the ZScript stuff that's been done so far, or will it still be in a "locked behind a command line" state?
Post Reply

Return to “General”