Quo Vadis ZDoom?

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Quo Vadis ZDoom?

Postby Kotti » Tue Dec 27, 2016 5:12 am

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.
Kotti
 
Joined: 27 Dec 2016

Re: Quo Vadis ZDoom?

Postby Graf Zahl » Tue Dec 27, 2016 9:21 am

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
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Quo Vadis ZDoom?

Postby Nash » Tue Dec 27, 2016 11:19 am

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?
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Quo Vadis ZDoom?

Postby dpJudas » Tue Dec 27, 2016 4:58 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Quo Vadis ZDoom?

Postby Graf Zahl » Tue Dec 27, 2016 5:40 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Quo Vadis ZDoom?

Postby dpJudas » Tue Dec 27, 2016 6:00 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Quo Vadis ZDoom?

Postby Rachael » Tue Dec 27, 2016 6:01 pm

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Quo Vadis ZDoom?

Postby Graf Zahl » Tue Dec 27, 2016 6:12 pm

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
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Quo Vadis ZDoom?

Postby Rachael » Tue Dec 27, 2016 6:36 pm

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
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Quo Vadis ZDoom?

Postby dpJudas » Tue Dec 27, 2016 7:07 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Quo Vadis ZDoom?

Postby Graf Zahl » Tue Dec 27, 2016 7:11 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Quo Vadis ZDoom?

Postby dpJudas » Tue Dec 27, 2016 7:12 pm

Oh - crap. That ruins that plan. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: Quo Vadis ZDoom?

Postby Rachael » Tue Dec 27, 2016 7:18 pm

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
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Quo Vadis ZDoom?

Postby dpJudas » Tue Dec 27, 2016 7:30 pm

The stencil is actually indirectly defined by the cliptop/clipbottom buffers handled by the sky portal drawing code. Need the triangle drawer tho.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Quo Vadis ZDoom?

Postby Kinsie » Wed Dec 28, 2016 12:28 am

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?
User avatar
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Next

Return to General

Who is online

Users browsing this forum: Grizzly, Yandex [Bot] and 9 guests