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 » Tue Dec 17, 2019 4:07 am

My laptop has specs from 8 years ago. I use Windows 7 and have an old dedicated card that supports OpenGL 3.3.
Most importantly, there's no warning at all, it works as normal except that...how can I put it...it looks like a HOM in Doom. Whatever menu pops up in the screen, it stays there and gets frozen in screen...
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 ZZYZX » Tue Dec 17, 2019 5:19 am

And that's why I never really wanted to write an own game engine: "it doesn't work" for someone else which is untestable/unfixable...
Not really sure what may cause that. dp, any ideas, maybe? Or any ideas on debugging this? Maybe adding some OpenGL extension listing to the log to see if something is not supported..?

Actually, here is a debug build (x64): https://www.mediafire.com/file/98ugl87k ... d.zip/file
Can you (leo) please try to run it and tell if there is anything meaningful in OpenGLDebug.log? (should be generated in the editor's directory)
Last edited by ZZYZX on Tue Dec 17, 2019 6:07 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 » Tue Dec 17, 2019 6:03 am

Adding the OpenGL render info that GZDoom also displays would be the first step. That way we'd at least know which GPU and driver version we are dealing with.

Since it is a HOM there's two likely candidates:

1) OpenGL context isn't positioned correctly, SwapBuffers not working, viewport or scissor rects not updating correctly, OpenGL context failed and error handling was missing. This could be tested with a glClear with a red color.
2) The vertex shader is acting up - this is a lot more tricky to track down.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby leodoom85 » Tue Dec 17, 2019 6:11 am

Gimme 10 hours and I'll do it. I have a job to deal with daily ;)
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 Clay » Tue Dec 17, 2019 9:05 am

Tried it out. Did some things like copy pasting playing around in visual mode and such. There is a slight kind of choppiness. Similar to a frame rate drop but it was minimal at most times only rarely getting to an annoying level.

I did notice a difference in the way lines are displayed(see Image). Left is new build, right is R3064. The seem to be outlined in white. Which isnt really a problem unless lines are rather dense and clustered. Wasn't sure if this was indicative of anything so I decided it was worth the mention.

Win7, AMD CPU, Nvidia GTX-970 GPU.
You do not have the required permissions to view the files attached to this post.
User avatar
Clay
Join my model specific Dicord! https://discord.gg/hQD9Va
 
Joined: 23 Sep 2017
Location: That one secret you always miss.
Discord: SomeOtherDoomGuy#7217

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Enjay » Tue Dec 17, 2019 12:21 pm

I'm not in a position to check anything right now, but talk of visual mode slowing down by 10% (if that's still the current estimate) does worry me. Visual mode can already be quite slow/choppy if a mod has a lot of resources or has a complicated map. For some mods, I already toggle things display to off for general editing in 3D mode unless I really need to see the things. Displaying things in 3D mode can really cause some significant slow down. So, an estimate of 10% slower for something that is already slow-ish is really quite concerning IMO.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Dec 17, 2019 1:09 pm

Note that for some people performance actually improved. This is not 100% stable. Though, yes, it is a problem.

Gray outline in 2D is probably due to different rendering mode, will fix.
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 Clay » Tue Dec 17, 2019 1:57 pm

Any performance impact I felt was indeed minimal. I have no idea about the difficulty of doing what guys are and just point out what I notice.

Thanks a bunch for everything!!!
User avatar
Clay
Join my model specific Dicord! https://discord.gg/hQD9Va
 
Joined: 23 Sep 2017
Location: That one secret you always miss.
Discord: SomeOtherDoomGuy#7217

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Dec 17, 2019 3:42 pm

Debug build just crashed with null dereference for Leo, so probably OGL version not supported or not able to initialize altogether.
Will later add OGL initialization error handling to see where exactly it fails.. for now, just asked for GZDoom's log to see the GL version.
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 » Tue Dec 17, 2019 3:47 pm

I think it is worth mentioning that this patch isn't just a port to OpenGL. It also moves the codebase from a Direct3D 9 age (mixture of fixed function and shaders) to the modern GPU age: OpenGL 3.2 is roughly equivalent to Direct3D 11. Perhaps even more importantly, it establishes an abstraction between the actual graphics API in use and the high level code in GZDB. You could add vulkan support without touching a single line on the C# side of things. That is very different from the old version.

I'm fairly sure the performance of the 3D mode could be improved to surpass the D3D9 version if a little time was spent on it. The code I saw there wasn't exactly doing it in an efficient way.

About leo's crash - does modern GZDoom work for him? It should be having the same minimum OpenGL version.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Dec 17, 2019 3:54 pm

GZDoom does. Asked for hardware relevant logs:

Spoiler:


AMD, obviously.

About being very different, sure. I remember one major blocker for me to remove SlimDX was hard dependency on vectors, matrices and some other classes from SlimDX, thank god you removed these...
Wasn't very fixed-pipeline before either though from what I remember. Everything happened through uniforms and D3D "effect" shader compiler (which also used to not work on WINE, I guess it's not very popular...)

Separately: tried to request OpenGL 5.0, got C# exception, not crash or HOM. So it's something more tricky than that.
Going to compare initialization code to GZDoom later. And also maybe we are not setting the context correctly to the window... (and some drivers ignore that whereas some others die instantly)
And/or that may be related to WINE crashing with X11-something-cursor during SwapBuffers (which for me means that SwapBuffers was called against a bad DC, with null rectangle)
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 » Tue Dec 17, 2019 4:18 pm

I agree it was mostly non fixed-pipeline, but Direct3D 9 in itself was in this weird hybrid age where you could do a bit of both. In GZDB that surfaced in how you declared the vertices, some of the fixed function transform matrices and the way it did fog. In any case, you want the high level rendering work to be separated from the low level part. That is much more true in the codebase now.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Dec 17, 2019 4:35 pm

So I tested my wild guess from above and added wglMakeCurrent right in front of ::SwapBuffers and it started working for Leo :lol:


x86: http://www.mediafire.com/file/zlecwnz2m ... 09.7z/file
x64: http://www.mediafire.com/file/vv7d5qany ... 64.7z/file

Supposedly this should also work on WINE.
If it does, that would also explain why Windows version crashed, but Mono doesn't (because Mono uses a different native library with GLX in place of WGL).

edit: I tested it on my Ubuntu with fresh prefix, worked flawlessly.
I guess that saves me a native build ;)
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 » Tue Dec 17, 2019 4:57 pm

Looking at your branch, did you add those unconditional 'ApplyViewport' lines to all the Draw calls?

The RenderDevice.Draw calls are very performance sensitive. Any additional call you make there you risk that the driver re-evaluates the GPU pipeline serving the whole thing below the surface. That's what that whole need apply thing is about - to only disturb the GPU waters when a state actually changed.

Also figured out why the 3D mode is not very fast: it creates a vertex buffer for every sector. While that saves it from generating them again (which is good, what GZDoom should be doing), it also means it does a hell of a lot of vertex buffer binds (very bad). I think we need to create some abstraction somewhere that ensures a lot of sectors share GPU vertex buffers so only a few buffer binds are needed.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Dec 17, 2019 5:07 pm

Yes, I did, during some debugging. Thought viewport was leaking. Will remove later.
Why did vertices not lag before in D3D though?

Also, I think we could store all vertices in a single buffer and just reference different positions within that. The buffer will only need to be regenerated when we edit a sector, since its a map editor. Do you think this is a good idea? Or it won't help with performance due to many drawcalls needed anyway?

What's slow here, drawcalls or binding of the buffer?
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 1 guest