The official "ZDoom on Linux" thread.

[DaMan]

The end user needs to register and log in to to FMOD its website to download the API....

r/stallmanwasright
Bugmenot has our back.

[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...

[wildweasel]

Do you have high-DPI scaling on your system, by chance? I've heard that can cause problems.

[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.

[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.

[Graf Zahl]

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]

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.

[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.

[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]

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.

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.

[VoidMage]

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.

[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.

[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).

[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

[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...