ZDoom

Hey can we get this thread closed as added?

I've replaced the single triangle drawing with "shape" drawing, which uses a "Shape2D" class containing arrays for vertices, coords and indices for triangles. On the ZScript side all that's available are some functions for sending data and clearing the arrays. If ZScript had Vector dynamic arrays I wouldn't really need that intermediate class, but that's how it is.

An updated version of the test zip is [url=https://marisakirisa.me/tmp/shape_m.zip]here[/url]. I'd say the setup is a bit cleaner now, though at this tiny scale there's not much of a difference in performance. I should bake up something with a larger scale.

I have opened a [url=https://github.com/coelckers/gzdoom/pull/521]PR[/url] now. In the end I went with the shape version.

GZDoom actually does merge successive compatible items. My concern is more with the overhead of the parameter parser and drawlist generator that needs to run for each single triangle.
But your suggestion isn't that bad actually. Having a VertexArray class that can be passed would give users the option to add some custom processing in child classes and if access to the vertex data is made virtual even allow to program some generator classes that do not have to explicitly store each vertex.

Passing an array can probably be done by having a dynamic array of Vertex class wrapped in a VertexArray or VertexBuffer class, thus one can pass VertexBuffer to the drawer function. I don't particularly like this hack though, easier to just draw single triangle.

Even Doom2016 (according to render pipeline reverse engineering) doesn't optimize UI calls and just draws one drawcall per item :P

No. You could just pass in float arrays with 4 values per vertex.

Is this related to the lack of vector arrays in zscript?

The main reason I haven't done anything myself yet is because there should be a way to draw multiple triangles with one call which would necessitate passing an array to the function.

I think it's time to revive this thread. Now that the 2D refactor has made things much cleaner, I decided to try again.

Results are on [url=https://github.com/OrdinaryMagician/gzdoom/tree/triangledrawer]this branch[/url] right now. I'm also going to link an example zip [url=https://marisakirisa.me/tmp/triangle_m.zip]here[/url] showing one of the many things this could be used for: on-screen rotated graphics.

At the moment, I'm trying to figure out how to best approach handling all the scaling parameters, so for now the vertex positions are in absolute screen coords.

If I manage to get this to work 100%, I think psprite drawing could be moved to it, which would easily allow arbitrary scaling and rotation of weapon sprites.

No, but theoretically they could be handled by the same code if a fake square model is created on the fly for it, provided that the model code handles the depth sorting in a way that makes it possible.

They don't really have anything to do with models.

I'm hoping that also means flat/wall sprites working in software too.

No. Apparently dpJudas is working on it again but it is completely separate from the 2D refactor.

I'm just curious as to whether the 2D_Refactor branch also means we'll get 3D models in softpoly (again).

Oh wow, that's pleasantly surprising to hear! :mrgreen:

This was actually the main motivation to clean up that code. Having to implement this 4 times in the different 2D rendering backends was simply an unpalatable proposition. Now with only one backend that is actually clean enough to work with it is an entirely different thing.

All in due time, though. First the thing must be working on all supported hardware and the inevitable kinks be ironed out before we start thinking about new features.