ZDoom vs. GZDoom

Both ports are at 1024x768, using GL_LINEAR filtering , GL_RGB5_A1. Also by the way, I'm using Glboom, not Glboom+. If I were using Glboom+ those frames probably would be doubled. You can go ahead and evade the evidence I'm throwing at you, because I know you still won't optimize the engine.

Rewrite = optimizing the renderer. But I want to optimize it in a way that's still worth something in a few years when the cards which can't handle it have long disappeared from 99% of all computers.

If I compromise now I'll gain nothing. All I'd have is a renderer that's faster but with all the same limitations as the current one.

So I rather leave the old hardware to what's there now and build something that really is capable of growing with what is to come in the upcoming years.

Then say goodbye to a bunch of users with low end hardware my friend! (Which is quite a lot)

Graf Zahl said:

You need a reality check, seriously! Have you even read Myk's post above about Doom and hardware rendering? Doom will never *ever* be able to get the same performance out of modern hardware as newer games. Modern games optimize their data so that they can handle it with a relatively small overhead before passing it to the hardware. Doom can't do that. A lot of stuff has to be recomputed each single frame - and there's very little that can be done about it.

I don't want to start a big debate on the subject but I honestly believe that a DOOM based engine can indeed present a renderer tuned to make the most of modern graphics hardware. To date there simply hasn't been any real attempt at doing just that. Architecturally speaking, the closest a DOOM port has come to doing things the Right Way (imo) on modern hardware, is/was Timmie's ZDoomGL but even that missed several key opportunities (though from what Timmie said about the rewrite he began it was getting closer to what I consider to be the Right Way).

The apparent dynamic nature of DOOM maps is misleading. Although there is nothing stopping maps from changing very significantly and without warning; in practice this rarely ever happens.

Achieving optimum performance when rendering a DOOM/Hexen world on modern hardware is more a matter of coupling the right world geometry caching scheme(s) with a renderer which applies the inherent dynamics at the right place in the pipeline.

Whoo said:

Then say goodbye to a bunch of users with low end hardware my friend! (Which is quite a lot)

Oh please. You are acting like 'Oh, GZDoom is going to magically break and never run on my hardware again!'

How many times has he stated that older hardware will fall back to a different renderer?

Face it, most people who use GZDoom do so because it's ZDoom with OpenGL, not because of it's own mapping features.

When his re-write is done and you are playing a map built for ZDoom/Boom/Vanilla on GZDoom and it falls back to the old rendering code, exactly what are you missing out on? Fancy effects your card couldn't even make use of?

DaniJ said:

Achieving optimum performance when rendering a DOOM/Hexen world on modern hardware is more a matter of coupling the right world geometry caching scheme(s) with a renderer which applies the inherent dynamics at the right place in the pipeline.

Correct. However, there's just no decent way to cache sprite coordinates, for example. Unless the player doesn't move they change every frame.

For the rest the main issue is not precalculating the vertices as such but the fact that the way they change makes it very hard to upload them into a VBO up front and never touch them again.

A light level change, an animated texture, scrolling effects etc. all invalidate some part of the vertex buffer and to handle rendering hacks some dynamic geometry is needed. I haven't made any performance checks but my feeling is that streaming VBOs are the only way to handle it without running into a dead end. I just have no idea how much performance that will cost over static VBOs. I hope it's faster than immediate mode though but it's far too early to tell.

Whoo said:

Then say goodbye to a bunch of users with low end hardware my friend! (Which is quite a lot)

If I lose users like you who do nothing than complaining and bitching I sure won't lose any sleep over it.

Graf Zahl said:

However, there's just no decent way to cache sprite coordinates, for example. Unless the player doesn't move they change every frame.

AFAIC caching sprite coordinates is entirely unnecessary and I wouldn't waste any time trying to do so.

For the rest the main issue is not precalculating the vertices as such but the fact that the way they change makes it very hard to upload them into a VBO up front and never touch them again.

Precisely. So perhaps VBOs are not entirely suitable for your world geometry representation and/or render strategy?

A light level change, an animated texture, scrolling effects etc. all invalidate some part of the vertex buffer...

So don't put those values in your VBOs.

DaniJ said:

Precisely. So perhaps VBOs are not entirely suitable for your world geometry representation and/or render strategy?

In case you haven't noticed yet: Since OpenGL 3.0 VBOs are the only future-proof method to handle geometry data. Both immediate mode and normal arrays have been deprecated so I don't consider them safe alternatives anymore. Eventually support for them in drivers will be reduced. With normal arrays I can even see the effects now. On my GF8600 they are slower than immediate mode in some situations.

So don't put those values in your VBOs.

Where else? If I don't I'm back at square one. Plus, see my remark above.

The end result remains: static VBOs are not a good way to handle Doom levels. They are - well - too static!

Graf Zahl said:

In case you haven't noticed yet: Since OpenGL 3.0 VBOs are the only future-proof method to handle geometry data

proof link: Tutorial: OpenGL 3.1 The First Triangle

Doesn't change the fact that Graf Zahl is either on drugs or he is a programming nazi if he doesn't see that making new renderer OGL 3.0 only will like drop 99% of it's current users. Graf, either you get a REALITY check yourself or shut the hell up. It's obvious that everybody dislikes you yet you don't see it! Why is that you ask? Because you're a fucking idiot that thinks making a new renderer which is OGL 3.0 only and which will drop 99% of it's current users and fans is a fucking good idea. Good riddance Graf Zahl.

EDIT: Before you trolls ask a stupid fucking question what kind of GFX card do I have. It's Geforce 8600 GTS Bliss OC 512MB so it's not that old. if you say it's too old, either you are a fucking retard or a no-life. or both at once!

Graf Zahl said:

In case you haven't noticed yet: Since OpenGL 3.0 VBOs are the only future-proof method to handle geometry data. Both immediate mode and normal arrays have been deprecated so I don't consider them safe alternatives anymore.

No I hadn't noticed but that is mostly because I don't even consider OGL 3 to be relevant at this time. Ask me again in a year or so.

Where else? If I don't I'm back at square one.

There are quite a few methods of providing values to OGL so that they can be referenced at different times during render. Just look at the concept of deferred lighting for but one example.

I still don't think it's worth the hassle. Using the VBO is by far the easiest way to pass such parameters without having to switch external state information repeatedly. A static VBO is too hard to maintain anyway so it's not really an issue. I am using a streaming VBO and there it's no problem to have all the lighting information as part of the vertices.

Concerning OGL 3.0 I agree. Right now it's not worth bothering (even though they are already at 3.2) but with the renderer rewrite I sure won't relay too heavily on concepts that have been deprecated.

alterworldruler said:

a lot of insulting garbage I won't quote.

99% of the user base? LOL! Do you really think that most of the people here are that retro that they don't have a decent graphics card? At least the ones preferring hardware rendering sure aren't those with outdated hardware. The minimum requirement for the new renderer is simple: The graphics card needs proper shader support (proper meaning that it can run non-simplistic shaders without choking on them - this being the disqualifying mark for Geforce 7xxx and older.) I repeat what I said before: If I were to aim at such older hardware I'd gain nothing. GZDoom already works on such cards without problems. The problems I am having right now are with shaders on newer hardware - and that's what I'm trying to address.
If I were to write a second renderer that could support all hardware I'd have triple the work and half the power in the end which would be a total waste of my time.

Now better shut up. I have no idea how the mods here deal with such extreme rudeness but if this were my forum I would have thrown you out immediately - permanently.

Graf Zahl said:

Now better shut up. I have no idea how the mods here deal with such extreme rudeness but if this were my forum I would have thrown you out immediately - permanently.

Those kind of outbursts usually land one in the Losers forum for a while. At least, that's my recommendation for handling this one.

Quasar said:

Those kind of outbursts usually land one in the Losers forum for a while. At least, that's my recommendation for handling this one.

Done!

Graf: please keep up the good work and don't pay any attention to idiots like this :-)

Graf Zahl said:

I still don't think it's worth the hassle. Using the VBO is by far the easiest way to pass such parameters without having to switch external state information repeatedly. A static VBO is too hard to maintain anyway so it's not really an issue. I am using a streaming VBO and there it's no problem to have all the lighting information as part of the vertices.

How do you plan to do modern lighting stuff if you are baking per-vertex colours in your engine and packing them into a VBO for transfer to OGL? To me, this seems unnecessary, a waste of memory and as you already said; updating light values then invalidates the VBO meaning it has to be rebuilt.

This is the kind of thing I inferred about needing to apply DOOM engine world dynamics in the right place. I would suggest that particularly in the case of lighting that you investigate deferring until as late as possible for optimum performance.

Since I stream the vertices it's not an issue. If they need changing I just stream different values. If they needed changing more often than the other data I would have put them in a second VBO so that I could have updated it separately.

For the rest I'll use TBOs. They look like the perfect way to handle large amounts of non-vertex related data.

That doesn't really answer the question of how you plan to do modern lighting stuff if you have baked per-vertex lighting in your engine. If for example you want to go the route of an uber lighting + texturing shader (sounds like you plan to) you don't want to apply DOOM sector lighting like that because there are much better solutions to the problem.

I'll think about that when I need it. Right now I have neither plans nor any idea how to do such stuff. But even then I'll still need to pass the sector lighting info somewhere so it's hardly wasted space.

The worst case scenario is that for shaders that work differently it's 3 wasted bytes of vertex space - but only for such shaders! The basic shader for plain old fashioned rendering will still need it.

But even then I'll still need to pass the sector lighting info somewhere so it's hardly wasted space.

But why waste space with unnecessary duplication? DOOM sector lighting can be considered a linear function of the ambient light component for every vertex within a sector.

Why not pass the raw sector light values instead, use an indexing scheme where you encode the sector light radix per-vertex in your VBO and do the look up into an array of sector light values in your uber shader.

With such an approach you remove a reason to update the VBO, which in turn means you save time not needing to update and transfer the VBO, you also save memory but the best part is that sector lighting is applied parametrically (this then makes implementing alternative lighting algorithms cleaner as you may be able to shift the switching logic out of your uber shader and into a shader selection decision (meaning better performance on older hardware)).

Stick to your guns, Graf. Make the best damned modern renderer you can. And I say this as someone with an integrated GeForce 6100.

Obviously I'm due for an upgrade, but I'll make sure it's something that can handle your supercalafragalisticexpealadocious shaders when I do.

from reading the first page this thread comes to mind as a direct 3d verus opengl type of thing.

My pc is incapable to run opengl at all(it's that old) but runs direct 3d fine. I ask why does the doom community always rely on opengl, i know it's easier to work with but really is opengl so great?

Also is there a source port that improves doom eye candy wise with direct 3d?

I'm not so bright when it comes to most oft his stuff but i catch on.

Thorgrim103 said:

Also is there a source port that improves doom eye candy wise with direct 3d?

Older versions of Doomsday feature a Direct3D render but it is not the default; try version 1.8.6

Thorgrim103 said:

I ask why does the doom community always rely on opengl, i know it's easier to work with but really is opengl so great?

opengl is cross-platform

DaniJ said:

But why waste space with unnecessary duplication? DOOM sector lighting can be considered a linear function of the ambient light component for every vertex within a sector.

That it is - but I have to ensure that the stuff that isn't (e.g. fog boundaries) works, too, without resetting and restarting the whole rendering process.

Why not pass the raw sector light values instead, use an indexing scheme where you encode the sector light radix per-vertex in your VBO and do the look up into an array of sector light values in your uber shader.

It may save a few bytes in the VBO, yes. But it also means a lot more overhead elsewhere. Once the whole thing is running I may try to use other means to pass the data - but not before.

With such an approach you remove a reason to update the VBO, which in turn means you save time not needing to update and transfer the VBO,

I am removing one reason to update the VBO, yes, and if it was the only reason to update it I'd do it differently. But due to the way Doom works I can't use a static VBO anyway. I'd have to lock parts of it repeatedly to update sector heights, texture coordinates and a few other things - and don't forget dynamic parts needed for rendering hacks. For a first try it's far too complicated and error prone. I can think about such things once it's all roughly working. But right now the streaming approach makes it much easier to get results.

you also save memory but the best part is that sector lighting is applied parametrically (this then makes implementing alternative lighting algorithms cleaner as you may be able to shift the switching logic out of your uber shader and into a shader selection decision (meaning better performance on older hardware)).

All the shader will get is a regular vertex color - already fully set up by the C++ code. There are no lighting calculations going on in the current shader itself.

All you suggest means to think about step B (improving the code) before step A (implementing the basics.) I can do such things once the renderer works - and I can do meaningful comparisons between different options on the living project. But if I add all the complexity now it may only get into the way later should I find out that it doesn't offer the improvements I'd like to see.

Right now I'm not aiming at any advancement. I just barely started on the code that creates the geometry data. It doesn't even work yet.

Thorgrim103 said:

from reading the first page this thread comes to mind as a direct 3d verus opengl type of thing.

My pc is incapable to run opengl at all(it's that old) but runs direct 3d fine. I ask why does the doom community always rely on opengl, i know it's easier to work with but really is opengl so great?

No, OpenGL is not that great. But it has a few advantages over D3D:

- it's cross platform
- a few years back (around 2001, 2002) when most of the hardware renderers started D3D was not really a good option.
- It doesn't force you to reinvent your code with each new version.

As for your computer, it may run D3D (which version?) but if it's really as old as you are saying chances are that even modernly programmed D3D ports wouldn't work well anymore. The latest D3Ds are even more geared towards modern hardware than OpenGL.

All you suggest means to think about step B (improving the code) before step A (implementing the basics.) I can do such things once the renderer works

To be honest I don't really consider the suggestions I made as improvements on an existing design, they are fundamental design decisions in and of themselves, which will affect how everything else needs to work.

Regarding fog boundaries (I'm assuming you mean translucent texture-less polygons used to "enclose fog volumes"); are those even necessary in a "modern renderer"?

Clearly I thought that the intention with this rewrite is the advanced stuff... Excuse me while I skulk back under my rock :)

Thorgrim103 said:

I ask why does the doom community always rely on opengl.

Also is there a source port that improves doom eye candy wise with direct 3d?

Not always, many people still use software.

You could try glboom or glboom-plus, they actually work on my really old(10 years) laptop with most maps. Excellent doom compatibility while having a nice and fast renderer.

Also you could try Legacy. I think you can choose direct3d mode and there is also MiniGL. MiniGL is a stripped down GL mode thats much faster and worked great on my old laptop too.

This same laptop had completely unplayable performance in gzdoom. Like 1 frame every 5 seconds.

DaniJ said:

To be honest I don't really consider the suggestions I made as improvements on an existing design, they are fundamental design decisions in and of themselves, which will affect how everything else needs to work.

You have been far too vague so far to give me any idea what precisely this would involve. But from this post I gather it's not in line with my ideas.

Regarding fog boundaries (I'm assuming you mean translucent texture-less polygons used to "enclose fog volumes"); are those even necessary in a "modern renderer"?

Modern or not, it still needs to be able to handle the things the game needs.

Clearly I thought that the intention with this rewrite is the advanced stuff... Excuse me while I skulk back under my rock :)

What good would a renderer be that focusses on the advanced stuff and completely loses sight of the basics. I certainly won't turn GZDoom into Doom 3 or Risen3D, that's for sure. That means the basic lighting model will remain what it is, for example.

Graf Zahl said:

You have been far too vague so far to give me any idea what precisely this would involve. But from this post I gather it's not in line with my ideas.

Modern or not, it still needs to be able to handle the things the game needs.

What good would a renderer be that focusses on the advanced stuff and completely loses sight of the basics. I certainly won't turn GZDoom into Doom 3 or Risen3D, that's for sure. That means the basic lighting model will remain what it is, for example.

Indeed I have been vague. In fact, deliberately so because I respect you as a developer. Unfortunately it would appear that in doing so I have miscommunicated, as your (somewhat defensive) reply suggests I'm talking about the common form of "next gen" rendering, as seen in Doom 3. I'll attempt to clarify both my intentions and suggestions.

To reiterate what I said earlier in the thread; it is my opinion that to date, there is no GL, DOOM-engine based renderer that makes the best use of the features available. By this I am referring to ill-conceived architecture which does not integrate the DOOM side of things with the premise of hardware accelerated rendering effectively (within the landscape of modern hardware and graphics library capabilities). Obviously there are many reasons for this; the time required being a predominant factor...

My main motivation was to plant a seed; that there is no requirement to develop yet another atypical renderer but with a backend that attempts to shoehorn DOOM into it. If this statement appears to be in any way condescending then I can assure you that was not my intent.

The ideas I presented were formed with the sole purpose of reproducing similar render results to that which GZdoom produces currently (though they are certainly usable if you did wish to pursue techniques like normal mapping at a later point).

With modern hardware we now have the opportunity to near enough recreate every nuance of the vanilla DOOM software renderer, from light attenuation to colormaps. To achieve this however necessitates leveraging new techniques, which given their role in contemporary, atypical renderers masks their usefulness to solving our problem.

Again, I'm being very vague but that is because this stuff is fun. Figuring out how to use cutting-edge techniques to render crusty old DOOM, exceptionally fast would be very gratifying (and, I don't wish to deprive by handing my own research on a plate).

DaniJ said:

My main motivation was to plant a seed; that there is no requirement to develop yet another atypical renderer but with a backend that attempts to shoehorn DOOM into it. If this statement appears to be in any way condescending then I can assure you that was not my intent.

The ideas I presented were formed with the sole purpose of reproducing similar render results to that which GZdoom produces currently (though they are certainly usable if you did wish to pursue techniques like normal mapping at a later point).

With modern hardware we now have the opportunity to near enough recreate every nuance of the vanilla DOOM software renderer, from light attenuation to colormaps. To achieve this however necessitates leveraging new techniques, which given their role in contemporary, atypical renderers masks their usefulness to solving our problem.

Ok, now I get what you were saying. That's certainly something to be done later. For now though I need to get this thing off the ground so that I can at least see something. Once that's done I can start thinking about optimization or improvements. Thus I prefer to be as conservative as possible because it keeps things simple. So at least the first version does not try to do anything outrageous or in any way out of the ordinary. I'll approach this one step at a time - and the first step will only be to transfer the current renderer's features 1:1 to a VBO/shader architecture while at the same time getting rid of the old code's most glaring shortcomings (most notably not having to recreate all rendering data frame by frame from the map geometry.)

So at some far future point can I expect to see GZDoom with modern lighting, bump-mapping, etc.? That would just thrill the hell out of me. Something similar is happening with the Polymer engine for Duke 3D right now, I believe.