GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[dpJudas]

Maybe the D3D9 driver is more optimized for it. I'd say even the D3D9 version runs rather poorly when considering how little of the scene I can see with the fog distance used. Can you remember if the D3D9 version uses vsync btw?

What's slow here, drawcalls or binding of the buffer?

Binding the buffer. Firing off draw calls should be very fast (GZDoom does one for every wall and plane).

Edit: I can see that the 2D renderer already has some code to share vertex buffers (see SurfaceManager). Its implementation has some issues though. Think I'll try fix the whole thing at a different level as the optimization would benefit everywhere except for the Mesh vertex buffers.

[axredneck]

Works on Wine for me! Spasibo!

[dpJudas]

I changed the backend to only create one physical GPU vertex buffer per vertex format. That reduced the number of vertex buffer binds for the 3D mode to exactly two.

The 2D mode now runs completely smooth on my computer for both Frozen Time and Brigandine in a release build. I'm not sure if it already did that tho. The 3D mode still does not, but now its down to three possible reasons:

1) Setting uniforms is slow
2) Binding textures is slow
3) The high end C# code is slow

I put my changes on this branch: https://github.com/dpjudas/GZDoomBuilde ... imgl_merge

Edit: also pushed the switch to using OpenGL sampler objects. That makes #2 as fast as it gets (only way to make it faster now is if C# calls it less times).

Edit 2: improved the uniform setting code. It revealed that it sets the view matrix a gazillion times per frame. Also discovered you merged an older version of the code as I had actually moved the shader code to C# resources (see the master branch on my repository). :/ In any case, the low level code is now as fast as it gets without additional help from the C# side of things.

[ZZYZX]

Edit 2: improved the uniform setting code. It revealed that it sets the view matrix a gazillion times per frame. Also discovered you merged an older version of the code as I had actually moved the shader code to C# resources (see the master branch on my repository). :/ In any case, the low level code is now as fast as it gets without additional help from the C# side of things.

Older probably because I didn't know about your branch and actually merged Talon's one which was intermixed with the mono build and had older code.
Not sure if it's easy to merge now, will try later, maybe...

Also, 2D mode was quite smooth with Frozen Time in my build too (after moving back to software). Floor/ceiling textures did not slow it down. I guess due to vertex buffer instead of regenerating it every frame, which would require complete 2D renderer rewrite in terms of line drawing, like moving scroll to the shader, and only updating the lines when something really changes, and only at the end of the frame. I thought about this for a bit and then just returned software because it was faster to have.

As for the 3D mode, it seems visually a bit faster, but still slower than SlimDX 3D mode (Frozen Time with 20500 view limit).

Separately big thanks for the uniform rewrite, your continuous array with hardcoded numeric locations confused the shit out of me and was kind of not very safe if C# passed the wrong format...
Though, I think we still don't have the size check on the C++ side in SetUniform.

[dpJudas]

As for the 3D mode, it seems visually a bit faster, but still slower than SlimDX 3D mode (Frozen Time with 20500 view limit).

I suspect the speed difference comes from the fact that it calculates a new view matrix every frame for every Thing and vertex displayed. In the SlimDX version that was done by D3DX which may have had a SSE accelerated matrix muliplication and such, while the GL version does this in a C# matrix class.

In both cases it is a really bad idea to do this. It should cache the calculation so that any Thing not moving does not need to have the matrix recalculated. Or it should store the location as a couple of uniforms (position + rotation + scale) and have the vertex shader do the calculation.

Separately big thanks for the uniform rewrite, your continuous array with hardcoded numeric locations confused the shit out of me and was kind of not very safe if C# passed the wrong format...
Though, I think we still don't have the size check on the C++ side in SetUniform.

The version I had on my master branch had this feature already, plus it allowed the C# side to declare the uniform names too. I fear it is too late to merge that version in at this point, but we may need to scavenge the DeclareShader and DeclareUniform features from it.

[ZZYZX]

As for the 3D mode, it seems visually a bit faster, but still slower than SlimDX 3D mode (Frozen Time with 20500 view limit).

I suspect the speed difference comes from the fact that it calculates a new view matrix every frame for every Thing and vertex displayed. In the SlimDX version that was done by D3DX which may have had a SSE accelerated matrix muliplication and such, while the GL version does this in a C# matrix class.

Ok, will try to find and remove this today evening and see if it helps Sounds quite wrong to do that, sure. Especially "every vertex" as matrix calculation is quite heavy.
Uniforms in a different format may help here actually, but first I think it makes more sense to look if it's possible to optimize unnecessary matrix calculations out.

[dpJudas]

By vertex I meant whatever the GZDB code calls vertices - which I suspect aren't the actual vertices but the visualization of vertices (maybe it only shows those for something selected, dunno). Either way, my debugger told mere there's basically two uniforms it sets thousands of times per frame: world and vertexcolor. The rest are very rare.

The ideal way of setting uniforms would of course be to send them as a struct, but that's somewhat tricky to add because the layout has to be mirrored exactly in its GLSL declaration. The alignment rules between C# and GLSL also differs a bit. Not that it can't be done - I just don't think its the source of the bottleneck right now.

[ZZYZX]

For world, a quick search led me to ApplyMatrices3D which has like 14 references...

So from what I see world matrix is actually for sprite billboarding. So it indeed changes every frame (or close to that) and needs to be recalculated.
What's bad though is that it sets three uniforms instead of one every time (world, view, projection), whereas only world is needed.
I changed it to update just the world matrix and it seems a tiny bit faster (not sure though, there is no FPS counter...). Pushed to my repo.

It should not have been much of a change, since there is a memcmp() which prevents writing too much to OpenGL.

"vertexcolor" is for various line art in the visual mode.
(action lines/circles, slope vertices, thing cages)

[Gez]

There may be a chance of renaming the builder e.g. to GZDoomBuilderGL/GLDoomBuilder to avoid automatic breaking update from DX to OGL (I think current GZDB allows computers older than OGL 3.2).

I want to suggest Doom Builder Z, so that it can be abbreviated as DBZ.

(Separately, does anyone know which OpenGL version is required by SLADE?)

I believe 2.0, but it looks like it's gonna change to something more recent.

[ZZYZX]

I want to suggest Doom Builder Z, so that it can be abbreviated as DBZ.

On a more serious note, I'm going to use GZDoomBuilder-GL if dpJudas is ok with it

[boris]

I want to suggest Doom Builder Z, so that it can be abbreviated as DBZ.

On a more serious note, I'm going to use GZDoomBuilder-GL if dpJudas is ok with it

Why not seize the opportunity and take something without "GZ" (and possible Doom) in the name? And what if the rendering gets changed to Vulkan?

[Gez]

Why not seize the opportunity and take something without "GZ" (and possible Doom) in the name? And what if the rendering gets changed to Vulkan?

I don't think it'd make sense to remove the "Doom Builder" part.

The "Doom Builder Z" name actually makes sense IMO: the Z still shows the focus of the editor on supporting advanced features, by echoing the Z of ZDoom, but putting it at the end instead of the beginning doesn't forcibly associate it with it, like with GZDoom Builder. It's not tied to a particular technology (like OpenGL). And the other DB2 fork is Doom Builder X.

[boris]

Calling it Doom Builder Z is a terrible idea, IMO, exactly because there's Doom Builder X. Why add to the confusion that already exists? If people talk about "GZDB" now you never know if they actually mean "GZDB" or actually "GZDB-BF". With "GZDB-GL" you'll then not know if they are talking about "GZDB", "GZDB-BF", or "GZDB-GL". And yes, there are still many people using GZDB, and many people will keep using GZDB-BF, so having yet another one with basically the same name will make it more confusing.

[dpJudas]

@ZZYZX you're of course welcome to use the GZDoomBuilderGL name I used. Personally I would just call it GZDB because at this point it is clear the original maintainer is not going to return. Whenever people say GZDB they always mean the GZDB-Bugfix version.

Edit: at least that's been my impression when ppl say GZDB.

[Rachael]

GLDB.

And if/when it gets Vulkan... VKDB.