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 leodoom85 » Fri Dec 20, 2019 6:55 am

I'll jokingly name it as GLDB9000. Yup, that'll do it
User avatar
leodoom85
Dodge this.....
 
 
 
Joined: 15 Sep 2014
Location: Earth-shaking Chile
Discord: leodoom85#6202

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Fri Dec 20, 2019 7:24 am

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Fri Dec 20, 2019 8:17 am

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 ;)
Last edited by ZZYZX on Fri Dec 20, 2019 8:45 am, edited 1 time in total.
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 » Fri Dec 20, 2019 8:40 am

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Fri Dec 20, 2019 8:47 am

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...
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 » Fri Dec 20, 2019 9:24 am

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Fri Dec 20, 2019 11:40 am

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Fri Dec 20, 2019 3:33 pm

dpJudas wrote: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?)
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 » Fri Dec 20, 2019 5:54 pm

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)

Spoiler:
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sat Dec 21, 2019 1:27 pm

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.
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 » Sat Dec 21, 2019 1:51 pm

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Sun Dec 22, 2019 4:49 pm

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Mon Dec 23, 2019 12:07 am

Big thanks! Will work on merging and renaming things a bit later this week, as my job became slightly more intense again :roll:
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 :wink:
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 » Mon Dec 23, 2019 4:11 am

ZZYZX wrote:Big thanks! Will work on merging and renaming things a bit later this week, as my job became slightly more intense again :roll:
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?


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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby _mental_ » Mon Dec 23, 2019 4:19 am

boris wrote: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.
_mental_
 
 
 
Joined: 07 Aug 2011

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 0 guests