DRD Team

dpJudas wrote:Wasn't a cube sky supposed to look horrible? This looks quite alright to me.

E2M1. E3M1. Map12. Map21.

If those all look alright to you, you don't have the same OCD that I do.

But I'll take this feature for the potential that it provides, over something as simple as texture mapping the existing skies onto the cube.

@Nash: Not without a depth buffer.

Eruanna wrote:E2M1. E3M1. Map12. Map21.

If those all look alright to you, you don't have the same OCD that I do.

E2M1 and E3M1 looked okay to me. But Graf is probably right that doing a gradient (which it would have to do to close off the top and bottom with a solid color) will not work as well as it does with a dome. Still, it looked better overall than I expected.

About the zbuffer and modeldef thing - making it use its own depth buffer for triangle stuff shouldn't be too hard to add. I have no idea how many triangles this thing can process at the moment though. Whatever the number is, don't expect it to get close to what a real GPU can do. They kind of rule this game.

I understand.

Got the dome rendering now.

Cool, will this be backported to ZDoom, too?

That's a screenshot from ZDoom, actually.

That's amazing, dpJudas.

dpJudas wrote:About the zbuffer and modeldef thing - making it use its own depth buffer for triangle stuff shouldn't be too hard to add. I have no idea how many triangles this thing can process at the moment though. Whatever the number is, don't expect it to get close to what a real GPU can do. They kind of rule this game.

I suppose this means it wouldn't be suitable for a polygonal renderer. (Yet?) Of course, by that point you've basically remade the Quake renderer.

It is a fully featured perspective-correct triangle drawer, so it can render Quake.

Right now my goal is just to have it render a sky dome, as I personally prefer the GZDoom sky over any of the software variants we have currently. But the drawer is written in such a way that, theoretically, someone could add modeldef info to a vissprite_t and then call the triangle drawer with the usual sprite clipping arrays and it would render 3d models in zdoom, like voxels work today.

One step ahead of me, like usual. I was going to write one of these myself and then plug in GZDoom's model code. I don't know what my week looks like, this week, but I might be able to do that with the present triangle drawer.

However, I do need to know its interface. How does it accept vertexes and how does it accept textures, and how do I access its output?

Right now it's API looks like this: https://github.com/dpjudas/dpDoom/blob/ ... triangle.h, although I might still make some minor adjustments that makes it more flexible.

Shortly explained, you call TriangleDrawer::draw with a "object to world" transform matrix (TriMatrix), a list of vertices (TriVertex, position, texcoord, light level), a draw mode controlling if its triangles, fans or strips, a cull mode (clockwise vs counter-clockwise), the sprite/plane/wall clip buffers and a texture. And that's it! - it renders those vertices like if you had called glDrawArrays in OpenGL.

You can find a simple example of how to call it at https://github.com/dpjudas/dpDoom/blob/ ... e.cpp#L904, where it draws a cube. Top and bottom uses a cap color fill, the rest texturing. Just below that function you can see a more complex example where it draws a dome.

I'm probably going to make it a little bit more flexible with the vertices so that you can use different input than TriVertex. This is mostly because I could imagine that the modeldef stuff got its own vertex struct and converting all that to a TriVertex would be a pain.

Does it make possible to implement properly the 3d floors (and hence also sloped 3d floors) in zdoom?

The problem with sloped 3D floors is not the drawing but the clipping. The current implementation solves this by splitting the map into horizontal slices (note the term 'horizontal'!)

dpJudas wrote:It is a fully featured perspective-correct triangle drawer, so it can render Quake.

Think you could make it work smoothly with GL BSP nodes? That would solve the shearing problem. Maybe could even be backported to the 8BPP renderer as an option. (For those who still mourn the departure of alpha polymost. )

Also, It'd be great if you could render models with it, even if they do end up working like sprites for now. (Voxels are the same way, after all.) It'd be better than nothing.