Pages: [1]
  Print  
Author Topic: Vertex buffer primitives  (Read 36 times)
Offline (Unknown gender) impo
Posted on: March 04, 2019, 09:14:14 PM
Member
Joined: Feb 2019
Posts: 16

View Profile
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
« Last Edit: March 04, 2019, 09:17:34 PM by impo » Logged
Offline (Male) Goombert
Reply #1 Posted on: March 09, 2019, 02:21:47 PM

Contributor
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3129

View Profile
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.
« Last Edit: March 09, 2019, 02:25:52 PM by Goombert » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Pages: [1]
  Print