Expose triangle drawer*

[Major Cooke]

Huh. Rachael, my example works with your latest changes now. Must've done something weird on my side when I attempted it. Ah well.

[Major Cooke]

Alright so Graf says it needs work.

I'm sorry but that interface needs work. FillSimplePoly is meant for rendering flats to the automap and its function parameters reflect that - but for a general use triangle drawer I'd expect something that takes 3 position vertices and 3 texture coordinate vertices, not the convoluted mess that's present here and only owes its existence to the flat data present in the sectors.

So the whole thing needs another function then?

[Rachael]

Yes - and new drawers will have to be made for it. But I really don't want to do that right now.

3 Drawers will have to be made for it, and no it's not softpoly/carmack/opengl - it's actually opengl/direct3d/direct pixel render(software, aka vid_hw2d==false).

Although, Graf said the problem was the interface, so it might be possible to use the FillSimplePoly drawer as long as the maths is handled by the function exposing the ZScript call.

[Major Cooke]

I thought Graf wanted to remove the Direct3D rendering.

[Rachael]

I don't remember specifically that, but until it's gone it has to be coded for anyway.

[Graf Zahl]

Making an OpenGL or D3D renderer for a triangle is a trivial exercise (we are talking the fundamental base case of what hardware rendering is about, after all!) For software, I'm sure that dpJudas already got the issue covered for the softpoly renderer so while it may need a bit more code, the basics should already be present.

As for trying to make it work with the flat renderer, that may not be doable, as it only can do orthogonal transformations - this has actually been by far the largest limiter for flat rendering at all.

[Graf Zahl]

I thought Graf wanted to remove the Direct3D rendering.

DirectDRAW!

Don't mix these two up, please!

[Marisa the Magician]

But... I thought all this triangle drawing stuff was going to be 2D on the canvas...

[dpJudas]

Assuming its for a 2D triangle drawer:

Drawing the triangle is fairly easy in software. I'd recommend building up an edge list either as scanlines and then draw each line with a span drawer, or as columns and use a column drawer. Using one of the existing drawer families for this will allow it to support render styles with little extra work.

Drawing it in hardware for D3D9 and GLSWFB requires some changes to DrawPackedTextures. Randi's code assumes that only quads are batched. This also opens up the question of whether UV texture repeat is allowed. Randi's code uses an atlas that makes texture repeat somewhat problematic.

Support is also required for the 2D drawer that the GL renderer is using.

If it is for a 3D triangle drawer:
Softpoly can draw things with an orthogonal projection, as recently demonstrated with the software model rendering code. The carmack renderer used the softpoly triangle drawer to do it. But as Graf points out, people might not get what they are expecting if they are looking for a true perspective projection. Generally supporting 3D triangles opens up a lot of questions that needs answers - like what coordinate system is it using here? World space? View space? When are they drawn? As part of the 2D drawing step or the weapon model step?

[Graf Zahl]

Randi's code assumes that only quads are batched. This also opens up the question of whether UV texture repeat is allowed. Randi's code uses an atlas that makes texture repeat somewhat problematic.

It's clear that this and the texture atlas cannot coexist. Howewer, since the 2D-drawer can batch both lines and quads, adding triangles should be doable. But to be honest, my main concern with the entire 2D drawer for the software renderer is that all the optimization with batching was completely and utterly pointless. The only place where there's more than a few 100 elements is the option menus where loss of performance is not an issue. This adds a huge level of complication to the picture that makes both the D3D and OpenGL versions very clumsy to use. I guess if we just do away with the texture atlas things will become a lot easier. I have to wonder how bad the hardware was where this made a significant enough difference in performance. Seeing that on a map like Frozen Time I need to start 16000 draw calls to get 9ms draw call time on AMD should make it clear how big the impact of a less 'efficient' approach would be here. I think 90% of that could even be regained if the font batching was done on a higher, platform independent level - WITHOUT all the complications in the low level interface.

Fun stuff: I guess if the code hadn't become so complicated and optimized for the wrong reasons it could have been done with OpenGL 2.x features for the GL version.

Support is also required for the 2D drawer that the GL renderer is using.

That'd be a 15 minute job at most because that code favored simplicity over some wasted efficiency.

[Major Cooke]

Hmmm... I suppose this also means there's no chance of rotating the texture inside of it too? For the simple initial submission I'm not expecting it to be there, really. I just can't help but think that maybe, just maybe, if this works out I might be able to plaster two triangle drawings into a square and get a rotating sprite on screen somehow... even if that sounds grossly hacky and completely counter-intuitive, but hey, just might set the stage for it! (After all, rotated automap is there.)

Again though, I have no expectation of that since that sounds more like the 3D side of things.

[Marisa the Magician]

You can definitely get rotated stuff easily (along with other transforms, like shearing) if the triangle drawer has per-vertex texture coords.

[Major Cooke]

Hmmm... I can't help but still imagine some problems existing such as drawing one half of a sprite and the other to make the full image, then rotating both around the middle and seeing some wacky batshit insanity going on instead of the correct results.

[Marisa the Magician]

With per-vertex coords this will NOT be a problem, I guarantee it. This is how billboard sprites are done in literally every modern game engine.

[Major Cooke]

Great. But it seems like the atlas texture issue will need addressing first before this can move forward, but that's just from what I'm interpreting Graf's post so far...