GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[leodoom85]

I'll jokingly name it as GLDB9000. Yup, that'll do it

[dpJudas]

Looking up "Dictionary" shows me pretty much half of the codebase, though. 654 references... I'd say not fixable.
A lot of these are e.g. almost all resources loaded in DataManager, which means — are used a lot during rendering.

Most of the dictionaries aren't time critical. To see which are the problematic ones you need to run the profiler (Debug->Performance Profiler in Visual Studio 2019, might not exist in 2015) and then look at the call stacks for the dictionary functions showing up to see which.

[ZZYZX]

This view?
https://i.imgur.com/wiufyXS.png

Because it doesn't make sense occasionally. (RenderSky taking 50% of the whole render time, but removing RenderSky doesn't really help at all)

Also this looks like geometry is being pushed/recalculated every frame for some reason:
https://i.imgur.com/ueJrsNk.png
But really isn't, because apparently it counts the whole loading time into this.
Apparently in order for one-time tasks to not be seen here I'd have to run GZDB for an hour or so (because, there is no option to pause/resume/reset profiling, at least for me, while MS page says otherwise).
I will later try VS2019, maybe it's better with profiling indeed. If it is, may as well just upgrade the project. I hate MS with their project upgrading policy...

unrelated: I got tired of our FPS measurement and just added FPS rendering in upper left corner of the 3D view. Supposedly, shows the correct number. 30FPS on FrozenT.wad for me, 60 while looking away.
Also added FPS counter to SlimDX version and merged the two (oops).

SlimDX version shows 21 FPS in FrozenT.wad. 10fps lower

[dpJudas]

Yes, that view. Make sure you select the range at the top where it only has the part where it is rendering 3D - otherwise you get a lot of noise from startup and shutdown.

If you sort it by Self CPU it will show you the slowest functions in the program. From there it should list some collection functions at the top and if you double click on it you can get it to show which functions called them. That will reveal which collection instances are the main offenders.

[ZZYZX]

ok, thanks, will try.

Though, for the main point, I think we could merge already as all GL-specific performance issues are resolved (and it's actually faster).
Is vertex array deallocation working? I'm not quite sure what's not working there and how it should work...

[dpJudas]

It isn't yet, but I can fix that when I get home.

There is one thing that is showstopping a merge: sometimes if you fly around for long enough in 3D mode (including maybe changing maps) it will suddenly die with some OpenGL error.

[boris]

Looks great so far. Fps increase seems to heavily depend on the map for me. On "simple" maps like Planisphere 2 or Frozen Time I get like 50-60% increased fps. On something densely packed like Vela Pax map01 there's no change.

One thing I noticed is that the grid isn't drawn right after loading the map. It is, however, drawn whenever I do anything that results in a OnRedraw.

[ZZYZX]

There is one thing that is showstopping a merge: sometimes if you fly around for long enough in 3D mode (including maybe changing maps) it will suddenly die with some OpenGL error.

Stack trace? Or random error? Anything in OpenGLDebug.log? How long?
(or this happened for someone else?)

[dpJudas]

I saw it a few times yesterday, it had a call stack. I can't remember what it is though and can't reproduce it right now.

Edit: I managed to capture the call stack: (error 1281 is GL_INVALID_VALUE)

---

Code: Select all

***********SYSTEM INFO***********
OS: Microsoft Windows 10 Pro
GPU: NVIDIA GeForce RTX 2080
GZDB: R3050
Platform: x64

********EXCEPTION DETAILS********
OpenGL error: 1281
   at CodeImp.DoomBuilder.Rendering.RenderDevice.ThrowIfFailed(Boolean result)
   at CodeImp.DoomBuilder.VisualModes.VisualSector.Update(RenderDevice graphics)
   at CodeImp.DoomBuilder.Rendering.Renderer3D.RenderSinglePass(Dictionary`2 geopass, Dictionary`2 thingspass)
   at CodeImp.DoomBuilder.Rendering.Renderer3D.FinishGeometry()
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualMode.OnRedrawDisplay()
   at CodeImp.DoomBuilder.Windows.MainForm.RedrawDisplay()
   at CodeImp.DoomBuilder.VisualModes.VisualMode.OnProcess(Int64 deltatime)
   at CodeImp.DoomBuilder.BuilderModes.BaseVisualMode.OnProcess(Int64 deltatime)
   at CodeImp.DoomBuilder.Windows.MainForm.processor_Tick(Object sender, EventArgs e)
   at System.Windows.Forms.Timer.OnTick(EventArgs e)
   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[ZZYZX]

Wonder why is there no method specified (of RenderDevice) under ThrowIfFailed... Does this happen in debug build? It should have line numbers, all functions and also details in the OGL log.
I think we need to put [MethodImpl(MethodImplOptions.NoInlining)] on all RenderDevice methods, otherwise this stack trace is totally useless. Not sure how that will affect performance though, there is already PInvoke...

VisualSector.Update is doing only few things: Dispose() on a vertex buffer, creation of a new vertex buffer, and Lock/Unlock on that. So probably what happens is caused by one of these.

Which map did you use? For how long roughly? (so I could try this locally)
I tried in the few maps I have, didn't happen.

Though I remember some similar issue long time ago which was caused by deleting a thing in visual mode, but apparently it's not that.

[dpJudas]

I haven't tried it in a debug build yet. It usually happens if I switch around between a lot of different maps - some of them even has missing textures.

It *may* have something to do with when the vertex buffer is full and it resizes it to get room for more. That's the only thing I know of that might only trigger this late. Going to research that theory tomorrow where I plan to fix the outstanding buffer/texture clean up (the last major thing missing in the implementation).

[dpJudas]

Okay I pushed the final unimplemented things in BuilderNative. The thing is now feature complete for what I intended for a first version.

I also think I managed to fix the OpenGL error I was seeing - at least it hasn't shown up for me since the last changes I did.

[ZZYZX]

Big thanks! Will work on merging and renaming things a bit later this week, as my job became slightly more intense again
So the thread will most likely be new, Git repo just renamed (to retain all the Git issues), download package for the editor will also be renamed to prevent breaking auto-update for those who cannot run OGL 3.3.
I'll try to make a backport branch somehow (i.e. something that will be auto-mergeable with OGL branch, but without OGL — for now, due to commit history, it's backwards, SlimDX is "upstream") and try to occasionally update the DX one. After all, most changes in the editor are not related to the renderer at all.

P.S. name's UDB

[boris]

Big thanks! Will work on merging and renaming things a bit later this week, as my job became slightly more intense again
So the thread will most likely be new, Git repo just renamed (to retain all the Git issues), download package for the editor will also be renamed to prevent breaking auto-update for those who cannot run OGL 3.3.

Should I wait with pushing commits (unrelated to the renderer) until you're done with that and it's all merged into master?

I'll try to make a backport branch somehow (i.e. something that will be auto-mergeable with OGL branch, but without OGL — for now, due to commit history, it's backwards, SlimDX is "upstream") and try to occasionally update the DX one. After all, most changes in the editor are not related to the renderer at all.

Do you really think that's worth the effort? Unfortunately we don't know what hardware people are running it on, but OpenGL is 10 years old...

[_mental_]

but OpenGL is 10 years old...

The quality of OpenGL drivers varies greatly depending on hardware and platform combination. Sometimes, read with AMD and Intel hardware, Direct3D drivers are better.