DRD Team

Graf please stop calling GZDoom 2.0.98x (in title bar for those who haven't noticed yet). I hope you understand and agree that it's kinda weird to mix them, because ZDoom Community Build was designed to add new features that would make their way into official ZDoom, but GZDoom adds features (like OpenGL renderer or 3D floors) that won't be in ZDoom for sure. And also ZDoom Community Build is my project (or at least was in past when I started it) and I feel kinda sad about "losing" it, because I'm still working on it (altough I haven't released nothing new yet).

BTW I have an idea: what about separating GZDoom-exclusive code with some define (e.g. #ifdef GZDOOM ...) or command line switch (e.g. -zdoomx) to keep the projects separate? That would be fine IMO.

x=eXtended so I still feel that the name fits.

It's no longer 2.0.96x and it's neither 2.0.98 - it's a mixture of both.

I've invented the x sucessor, how do you know what I meant with it . It's no longer 2.0.96x but it's no longer anything.x (= community build) too. So why having its name.

EDIT: Ok, you are right about extended .

Grubber wrote:BTW, can I call next versions zdoom .96x (x for extended, grbzdoom sucks, too selfish ) or similar?

No offence intended at all but, why would we need "Grubber" zdoom when we have Gzdoom? Since it has all the same features and extras. I can understand that you want to continue working on your own thing but at the end of the day the features you add might not ever get around to Randy's dark developing ways since he's never open to the public. Sure he adds some but look at the feature request forum compaired to Graf's.

I don't want "Grubber" zdoom too, I want GZDoom to be named properly . We already agreed with Graf that there's no need for another .x, but still, some people (including me) want them separate only because of the feel that GZDoom =/= ZDoom (or .x).

We need the community build because Graf is reluctant to add decorate features to GZDoom because Randy isn't doing so to ZDoom, plus some of us can't use/don't like OpenGL.

Speaking of which, when's the next version of 96x out?

Interesting dilemma ...

The Ultimate DooMer wrote:We need the community build because Graf is reluctant to add decorate features to GZDoom because Randy isn't doing so to ZDoom, plus some of us can't use/don't like OpenGL.

Speaking of which, when's the next version of 96x out?

GZDoom still has the software renderer

Yes but 3D floors don't work in it, and if decorate features won't be added, we need the community build.

Why won't everyone just work together eh?

Tell that to Randy. I'd really like to add new DECORATE stuff but since I have to do most of it again when I finally get a working floating point version I don't really feel motivated to add it now. I'd prefer to work with future-proof code but the current version isn't it.

I really don't get it why he has to sit on his code forever. Nobody is testing it and when he eventually releases ZDoom 2.1.0 (which to be blunt I don't expect to happen in the foreseeable future) it will take twice as long as necessary to find and fix all the bugs.

Cutmanmike wrote:Why won't everyone just work together eh?

Because it requires stuff like cooperation, responsibility, reliability and the list goes on, and it's really not possible over teh internet

It is possible but not if there's someone who doesn't have the slightest intention to cooperate at all.

I am glad that gzdoom has the eXtended decorate features. If you want to release something new, why not add it to gzdoom instead of just zdoom? The software renderer is still there so it's not like if you can't do openGL you can't use those features.

It's no fun writing code you know you have to rewrite anyway.