GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Tue Dec 17, 2019 5:11 pm

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?

ZZYZX wrote: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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby axredneck » Tue Dec 17, 2019 5:34 pm

Works on Wine for me! Spasibo!
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Tue Dec 17, 2019 7:35 pm

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/GZDoomBuilderGL/tree/slimgl_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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Wed Dec 18, 2019 3:13 am

dpJudas wrote: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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Wed Dec 18, 2019 5:13 am

ZZYZX wrote: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.

ZZYZX wrote: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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Wed Dec 18, 2019 5:18 am

dpJudas wrote:
ZZYZX wrote: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 :roll: 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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Wed Dec 18, 2019 5:37 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Wed Dec 18, 2019 7:14 am

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)
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Gez » Wed Dec 18, 2019 8:33 am

ZZYZX wrote: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. :P

ZZYZX wrote:(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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Wed Dec 18, 2019 8:51 am

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

On a more serious note, I'm going to use GZDoomBuilder-GL if dpJudas is ok with it
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Wed Dec 18, 2019 8:57 am

ZZYZX wrote:
Gez wrote:I want to suggest Doom Builder Z, so that it can be abbreviated as DBZ. :P

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?
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Gez » Wed Dec 18, 2019 9:34 am

boris wrote: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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Wed Dec 18, 2019 9:39 am

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.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Wed Dec 18, 2019 9:57 am

@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.
Last edited by dpJudas on Wed Dec 18, 2019 10:02 am, edited 1 time in total.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Rachael » Wed Dec 18, 2019 10:02 am

GLDB.

And if/when it gets Vulkan... VKDB.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 1 guest