---

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.

---

---

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

---

---

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.

---

---

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

---

---

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.

---

---

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...

---

---

DaniJ said:

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

---

---

So don't put those values in your VBOs.

---

---

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

---

---

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.

---

---

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

---

---

alterworldruler said:
a lot of insulting garbage I won't quote.

---

---

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.

---

---

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.

---

---

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.

---

---

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

---

---

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

---

---

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?

---

---

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.

---

---

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)).

---

---

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?

---

---

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

---

---

Thorgrim103 said:
[B]
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?

---

---

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.

---

---

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 :)

---

---

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.

---

---

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.

---