DRD Team

To tell you the truth, the only thing it really needs to stay playable is support for turning the colormap shader off. I'm pretty sure compared to other things, that's minor.

It plays well with the other shaders.

Gez wrote:Well, when the time comes to ditch the old code from the SVN trunk, make first a last official release of GZDoom with said old code. Then people who complain can be told "just use version 1.2.9, not 1.3" or whatever other number scheme is used.

I'm with Gez on this. Keep a fully functional, bug-free version of GZDooM based on the code prior to branching off in the new direction, but proceed with your upgrades. That way, people who want to keep developing mods for people with low-end hardware, and those with low-end hardware that want to keep playing mods without the new features can continue to do so. Make it clear that the old version is not maintained any further, and therefore it's the users' choice - more features but with greater hardware requirements, or fewer features with old hardware.

Personally, none of my computers is a high-end one targeted at gamers. Therefore, I believe I may pay a slight performance penalty to play GZDooM in the future, but no more than I pay now to play modern games. My concern is more one of development - if my mod gets bogged down because of hardware limitations I may not include those features that slow things down. But then, I might be in the gaming minority and my opinion may be less important.

This is actually something better, I propose:

Make both the GL renderer and Software renderer plug-in based - and merge the Software renderer plugin with the ZDoom code and just use GZDoom's renderer as a plugin. That opens up possibilities, such as a plug-in author adding more features to either renderer on their own, or even just using an older plugin for an older card.

I realize, however, that this could mean a lot of work. But in the end, I think it would be worth it.

Of course, that means ZDoom is going to have to properly support 3D floors and dynamic lights by default - even if it never renders them.

SoulPriestess wrote:This is actually something better, I propose:

Make both the GL renderer and Software renderer plug-in based - and merge the Software renderer plugin with the ZDoom code and just use GZDoom's renderer as a plugin. That opens up possibilities, such as a plug-in author adding more features to either renderer on their own, or even just using an older plugin for an older card.

I realize, however, that this could mean a lot of work. But in the end, I think it would be worth it.

Of course, that means ZDoom is going to have to properly support 3D floors and dynamic lights by default - even if it never renders them.

That would be a nice idea - if Randy's low level code (and the software renderer) was actually maintainable.

I'm sorry but I have no desire whatsoever to wade through that mess of code. It's not good for my brain.

To be honest, I've been meaning to go through that... mess of code...

I haven't read the whole thread but only the initial post and I'd just say go for the future Graf! The majority can easily handle that stuff and I guess if someone has still a gfx card that's older and doesn't have these capabilites, it's easy to get a newer one from ebay or other places for just a few bugs.

Tormentor667 wrote: it's easy to get a newer one from ebay or other places for just a few bugs.

Who wants to trade a graphics card for a pile of rotten insects???

Whops... I actually meant bucks Sorry, but somehow I am glad that my little typos are a general base for public amusement

/makes the world a funnier place

ATI Radeon X1650.
I don't know HOW old it is but I know it can hande games like L4D and F.E.A.R 2 with no hassles. So basically no, It wouldn't bother me much if older GL support is tossed.

I have a 256mb GeFore 6600 which performs remarkably slow when GZDoom's shader options are enabled, and to add insult to injury, everything looks just the same, no improvement whatsoever.

If that's what you plan for the port, the honeymoon is over

Sussudio wrote:I have a 256mb GeFore 6600 which performs remarkably slow when GZDoom's shader options are enabled, and to add insult to injury, everything looks just the same, no improvement whatsoever.

I'm not surprised. That card's shader support is insufficient even for some of the simple things the current shader code does. And it's way below the requirements for the new shader code. That renderer won't even start on your system I'd guess.

I had a GF6800 in my old computer and the shader support in that was way too weak for even the simple effects like warped textures or full screen colormaps.

So I guess you will have to live with the old renderer and not be able to make use of any new features that may come.

I can live without fancy lights, but can you at least keep the texture filtering code fast for older hardware?

Texture filtering is a basic feature of any 3D hardware so no need to remove it. The only thing I may dump from the old renderer is the shader code as people having to use the old renderer are most likely those who can't make proper use of shader effects anyway.

I was wondering if you could give a basic overview of the process that you are going through with the GZdoom code ATM. This is purely because I've been reading your change logs and I'm interested to learn how you see things progressing and maybe get a better understanding of these things myself.

From what I can tell, most of your work recently has been on code reorganisation. You seem to be splitting things into 3 man areas: old renderer, new renderer and common.

I also notice that you have done work on 2D drawing code. If I start GZdoom by adding +gl_testnewrenderer 1 to the command line I see a titlepic and in game I get a status bar and crosshair. I assume that this is all part of the 2D code.

This time from a final implementation perspective: how do you see things working for an end user? will GZdoom try to auto detect the best renderer for a person's hardware or will it default to one mode and have the user optionally chose the other?

And, of course, the compulsory "how long" question. I assume that this is not going to be a quick process. Assuming that you get the time to work on it as you want to, are we talking weeks, months (or more) or is it not really possible to tell? I'm not really bothered about it, obviously GZdoom works for me as it is. As I said, I'm just trying to get a feel for the game-plan and how things are going for my own interest.

Enjay wrote: This time from a final implementation perspective: how do you see things working for an end user? will GZdoom try to auto detect the best renderer for a person's hardware or will it default to one mode and have the user optionally chose the other?

I'll do it semi-automatically:

If I find a GL3.0 driver I will select the new renderer.
I'll do the same if I find a GF8xxx or 9xxx card.
Everything else will default to the old renderer. If I get some information strings from ATI users I might autoselect the new renderer there, too.

And, of course, the compulsory "how long" question. I assume that this is not going to be a quick process. Assuming that you get the time to work on it as you want to, are we talking weeks, months (or more) or is it not really possible to tell? I'm not really bothered about it, obviously GZdoom works for me as it is. As I said, I'm just trying to get a feel for the game-plan and how things are going for my own interest.

When it's done (TM) It depends on many factors. If the weather is good, for example I rather go cycling than programming. If there's a lot to do at work I got less time for Doom and so on.

I'd say it's still a few months off. The 2D part was simple because it's all centralized in 4 or 5 rendering functions. Once these were converted all 2D drawing was working again. The rest is not as easy because I want to get rid of all the cruft that has accumulated over the years and makes the old renderer so hard to maintain. So it's essentially a rewrite from scratch for a lot of code.