ENIGMA Forums

Sharing is caring => Tips, Tutorials, Examples => Topic started by: impo on March 04, 2019, 09:14:14 pm

Title: Vertex buffer primitives
Post by: impo on March 04, 2019, 09:14:14 pm
here's the example https://enigma-dev.org/edc/games.php?game=80

there's scripts to generate cones, walls, blocks,importing d3d/obj models etc via vertex functions which work much faster comparing to default d3d_ ones.

there's also benchmark to compare how fast they are comparing to d3d_draw_primitive and d3d_model_draw functions. the benchmark shows that vertex_submit function works on exactly same speed if all vertices are close to camera. however, if we'll zoom out, vertex_submit becomes much faster, while d3d_functions remain distance-independent and lag just as if they were close to camera. the culling doesn't work and is reversed on all of the 3d primitives and models. matrix functions don't work as well

 the example is a bit unpolished but i don't want to spend any more time on this one
(http://files.enigma-dev.org/game/80/screen/1/ff5e63/phptPa2l1.png) (http://files.enigma-dev.org/game/80/screen/2/480073/phpKxJoyk.png)
Title: Re: Vertex buffer primitives
Post by: Goombert on March 09, 2019, 02:21:47 pm
Haha this example looks really interesting, informative, and useful! I have plans and may create something like this to regression test our lighting functions and fog. But I would like to provide some additional information here being someone whose worked internally on these features.

Quote from: impo
there's scripts to generate cones, walls, blocks,importing d3d/obj models etc via vertex functions which work much faster comparing to default d3d_ ones.
This is actually exactly what I made the internal engine do, all of our shape functions actually just call the d3d model functions, which in turn are implemented using the vertex functions. Now, here's why your method is probably faster, for 3D shapes only, because I hadn't exactly worked out the flushing mechanism, our d3d shape functions are still doing an immediate flush. This means that your version is probably all being submitted in one draw call, which obviously is less overhead and will give better performance.
https://github.com/enigma-dev/enigma-dev/blob/90279d01a1db831f1013e118ddba7645b82802ce/ENIGMAsystem/SHELL/Graphics_Systems/General/GSprimitives.cpp#L205
https://github.com/enigma-dev/enigma-dev/blob/90279d01a1db831f1013e118ddba7645b82802ce/ENIGMAsystem/SHELL/Graphics_Systems/General/GSmodel.cpp#L735

Quote from: impo
the culling doesn't work and is reversed on all of the 3d primitives and models
I can apitrace this and see if we have the same winding order as GM8 and GMSv1.4.