The official "ZDoom on Linux" thread.

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
DaMan
Posts: 727
Joined: Fri Jan 01, 2010 7:14 am

Re: The official "ZDoom on Linux" thread.

Post by DaMan »

FireFish wrote:The end user needs to register and log in to to FMOD its website to download the API....
r/stallmanwasright
Bugmenot has our back.
User avatar
VoidMage
Posts: 165
Joined: Thu Dec 02, 2010 10:42 am

Re: The official "ZDoom on Linux" thread.

Post by VoidMage »

OK, at this point I'd really like to know: do other people also have that problem in GZDoom with SDL backend ever since SDL2 migration, where the picture ends up in the bottom right corner while fullscreen ?

Cause I really don't see anything special about my old integrated Intel, yet noone else is reporting a similar problem...
User avatar
wildweasel
Moderator Team Lead
Posts: 21384
Joined: Tue Jul 15, 2003 7:33 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support

Re: The official "ZDoom on Linux" thread.

Post by wildweasel »

Do you have high-DPI scaling on your system, by chance? I've heard that can cause problems.
User avatar
Marisa the Magician
 
 
Posts: 3804
Joined: Fri Feb 08, 2008 9:15 am
Discord: Marisa the Magician#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Preferred Pronouns: She/Her
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

Re: The official "ZDoom on Linux" thread.

Post by Marisa the Magician »

Pretty sure EVERYONE should have that problem. GZDoom simply doesn't do scaling of non-native resolutions on fullscreen with SDL2, unlike ZDoom. Would be nice to implement it with an extra option to choose whether or not to use interpolation.
User avatar
VoidMage
Posts: 165
Joined: Thu Dec 02, 2010 10:42 am

Re: The official "ZDoom on Linux" thread.

Post by VoidMage »

Well, I've wrote a (mostly working - at least the way I intended it to work) hack for it and put it on GZDoom forum intended as an opening point for a discussion, but once I've gotten Graf to comment on it, he has simply closed it.

To clarify: this isn't about HighDPI or anything alike. This is simply about a case, where you set GZDoom resolution lower that the desktop.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47992
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: The official "ZDoom on Linux" thread.

Post by Graf Zahl »

VoidMage wrote:Well, I've wrote a (mostly working - at least the way I intended it to work) hack for it and put it on GZDoom forum intended as an opening point for a discussion, but once I've gotten Graf to comment on it, he has simply closed it.
No. What you put on there was a lengthy rant that was far too verbose to make a point. If you want to discuss a problem, present it in a comprehensible fashion. Your post was anything but.
Remember: I do not have a Linux system, I do not know the intricacies of Linux, so without some assistance I can't do anything here - especially when the problem is presented in a manner that fails to bring the point across.

To the matter at hand: I suspect either a bug or a deliberate limitation on SDL2's end. It's outside my control.
Blzut3
 
 
Posts: 3090
Joined: Wed Nov 24, 2004 12:59 pm
Github ID: Blzut3
Graphics Processor: ATI/AMD with Vulkan Support

Re: The official "ZDoom on Linux" thread.

Post by Blzut3 »

Deliberate limitation is closer to the truth, but not exactly. Basically for a combination of reasons it was decided that the preferred way to do full screen is not to change the mode that the monitor runs at, but rather to simply render to a smaller canvas as scale it. For ZDoom's software renderer we're using SDL2's 2D renderer to have OpenGL scale the texture that the game is rendered on. I don't know enough to tell you if SDL has facilities to do the scaling for you for OpenGL games, but the software renderer code path most likely won't help.

A quick solution if no one can be bothered to implement the scaling would be to change the SDL code to use the old fullscreen method.

Side-note: A request for this fullscreen mode on Windows can be seen here. The OS X code also implements full screen this way.
User avatar
VoidMage
Posts: 165
Joined: Thu Dec 02, 2010 10:42 am

Re: The official "ZDoom on Linux" thread.

Post by VoidMage »

I'd consider that "quick solution" completely broken - I really like that ZDoom doesn't change the desktop resolution when going fullscreen.
What my hack does is:
- manipulate the glViewport to get it in sync with desktop size (while keeping 4:3 output size)
- scale the output texture cords, so that they're correct for the viewport (again + 4:3)

There might be a few more minor changes there (like pulling generating savepic offscreen into a vbo).
A more complex (but also more correct) way of fixing this would likely involve making use of SDL_GL_BindTexture and just using SDL_Renderer then, just like ZDoom does, but I don't quite understand how/where to insert that bit in the existing OpenGL renderer.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47992
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: The official "ZDoom on Linux" thread.

Post by Graf Zahl »

I think this makes an excellent case in point why the Windows version deliberately avoids third party libraries which may have their own idea of what an app may need and what not.
Blzut3
 
 
Posts: 3090
Joined: Wed Nov 24, 2004 12:59 pm
Github ID: Blzut3
Graphics Processor: ATI/AMD with Vulkan Support

Re: The official "ZDoom on Linux" thread.

Post by Blzut3 »

VoidMage wrote:A more complex (but also more correct) way of fixing this would likely involve making use of SDL_GL_BindTexture and just using SDL_Renderer then, just like ZDoom does, but I don't quite understand how/where to insert that bit in the existing OpenGL renderer.
With me not being familiar with OpenGL in mind, this doesn't seem like it would help without making changes elsewhere. Specifically this seems to be more for using an SDL texture inside the GL renderer. Probably could be used if binding allows rendering to the bound texture, but I imagine this would have a performance penalty.
Graf Zahl wrote:I think this makes an excellent case in point why the Windows version deliberately avoids third party libraries which may have their own idea of what an app may need and what not.
I fail to see how this statement correlates to anything said unless you stopped reading at my first sentence. The problem isn't caused by SDL, it's caused by an incomplete implementation of the OpenGL interface with one of the new SDL2 features. Doing things the old way would work but it's not considered desirable by users nor the library.

Not saying I disagree with using native code for Windows and OS X, but this is not one of the reasons by any stretch of the imagination. As I pointed out in my last post, even some Windows users would prefer this method of full screen.

A good place to start with this would probably be to get GZDoom to support window resizing like ZDoom does. That's half of the problem, the other half is displaying at the correct aspect ratio which ZDoom doesn't do in windowed mode.
User avatar
VoidMage
Posts: 165
Joined: Thu Dec 02, 2010 10:42 am

Re: The official "ZDoom on Linux" thread.

Post by VoidMage »

Blzut3 wrote:
VoidMage wrote:A more complex (but also more correct) way of fixing this would likely involve making use of SDL_GL_BindTexture and just using SDL_Renderer then, just like ZDoom does, but I don't quite understand how/where to insert that bit in the existing OpenGL renderer.
With me not being familiar with OpenGL in mind, this doesn't seem like it would help without making changes elsewhere. Specifically this seems to be more for using an SDL texture inside the GL renderer. Probably could be used if binding allows rendering to the bound texture, but I imagine this would have a performance penalty.
Well, I'm not all that strong in OpenGL either and I just might be wrong about SDL_GL_BindTexture, yet some changes in the renderer will be needed one way or another.


Now that I think about it, perhaps I shouldn't have tinkered with the viewport as early as I did, but instead made the changes only right before SDL_GL_SwapBufers is about to be run, then popped the matrix...?

-------

This alternative approach gives surprisingly good results, except for two points - startup screen and -/+ changes of viewport...
Needs more tinkering.

-------

OK, so my new approach ended up pretty much equal to the original one.
Yet, this time the changes are simple and consistent, though they may break Windows.
GZdoom window is now resizable, there's a minor gotcha though - as in this version ClearBorders got disabled, what lies beyond borders may sometimes be trashed. I'll see if ClearBorders might be safely reenabled..

Note the changes in ZDoom - those may break Windows, but are unlikely to.
There's a tricky change among them - certain problem, that ZDoom had, seems to be an SDL bug.
You do not have the required permissions to view the files attached to this post.
User avatar
Marisa the Magician
 
 
Posts: 3804
Joined: Fri Feb 08, 2008 9:15 am
Discord: Marisa the Magician#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Preferred Pronouns: She/Her
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia

Re: The official "ZDoom on Linux" thread.

Post by Marisa the Magician »

I will be testing this.

Update: Unfortunately, this just turns gzdoom into a crashy mess. Various resolutions crash instantly when setting them or when switching to fullscreen with the following:

Code: Select all

v_video.cpp:1346: bool V_DoModeSetup(int, int, int): Assertion `CleanWidth >= 320' failed.
Maximizing the window doesn't cause crashes, but rather than having the same stretching effect as ZDoom, it just changes the internal resolution to fit. Also selecting any non-4:3 video modes that don't crash automatically changes to the nearest 4:3 resolution.

Oh well, guess I'll keep using ZDoom then for the true low-res experience.
User avatar
VoidMage
Posts: 165
Joined: Thu Dec 02, 2010 10:42 am

Re: The official "ZDoom on Linux" thread.

Post by VoidMage »

Ah, that little thing...
To be honest, I've only tested (since hack rewrite) changing between fullscreen and window.
Still, that was pretty much just a thinko.
Actually, this is a good thing to find, as using the previous approach at that point might have been a crash-bait (for reason other than the reported).
You do not have the required permissions to view the files attached to this post.
Edward-san
Posts: 1773
Joined: Sat Oct 17, 2009 9:40 am

Re: The official "ZDoom on Linux" thread.

Post by Edward-san »

urgh, I see why the github method is much better than this ...

first, please explain why did you do some unreasonable changes (like commenting some GL calls or that 'return' added at the beginning of FGLRenderer::ClearBorders) ...

[edit] apparently in the patch there's also this moot part which feels weird (or maybe you did truncate the patch at that point?):

Code: Select all

diff --git a/wadsrc/static/sbarinfo/hexen.txt b/wadsrc/static/sbarinfo/hexen.txt
index 6e57550..d09b610 100755
User avatar
VoidMage
Posts: 165
Joined: Thu Dec 02, 2010 10:42 am

Re: The official "ZDoom on Linux" thread.

Post by VoidMage »

No, the patch isn't truncated, it's simply that I can't quite convince myself it's ready to be turned into a commit, so it's produced via 'git diff' and removing a few other - unrelated - changes.

ClearBorders got an early return, cause the way I manipulate the viewport makes it somewhat redundant (well, it would be useful for that resize problem...the catch is ClearBorders is called at a wrong point to help with that - perhaps a function triggered by SDL_WINDOWEVENT_RESIZED ?). As for changes in DrawTexture...TBH, I'm not sure, then again, if I've seen any artifacts caused by it, I must have missed them...

Return to “General”