[Linux] GUI discussion

Discussion of development and patch submission.
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

iwasaperson wrote:EDIT: The shader does compile on Antergos using fglrx with a 7870, but it doesn't actually do anything. Pixellate (a similar shader) also compiles, but it just slightly blurs the image without actually doing anything useful.
I noticed it doesn't work as well, so I have to look it over.
iwasaperson wrote:On another note, When I select square pixels or integer scale (using the GL3 renderer), it keeps the 4:3 ratio, but makes the image look a lot nicer as opposed to the mess I get when selecting 4:3. This happens on both Antergos with fglrx and Debian with mesa. Even when selecting either of these options, I still do not get either square pixels or an integer scale (the obvious signs are all there).

EDIT2: The aspect ratio only changes with the output stretch mode option. Everything I said about the 4:3 looking nasty and the improvement when using square pixels or integer scale still stands, but it seems like the two options (GL3 settings and the other settings) aren't linked like they should be. When selecting integer scale on both, I do get a proper integer scale.
Yeah I haven't linked them on purpose to make it more configurable. However if it is confusing I'm not against changing it to something more user-friendly.
iwasaperson wrote:EDIT3: Seperate bug report: the Scale filtering (Nearest neighbor or Linear) doesn't seem to do anything on any renderer except for OpenGL (not GL3).

For contrast, DOSBox in RetroArch with sharp-bilinear with a 4:3 ratio looks absolutely fantastic, even when viewing text.

Are you applying the shader before or after the built in scaling?
The scale filter only works as expected on OpenGL (and Direct3D on Windows), with GL3 the filtering follows the input scale-option instead. This is because the shaders might have their own configuration for filtering. However it is confusing that it doesn't behave the same if no shaders are defined.

This is how the rendering works (the scene-texture was created with filtering if requested):
  • Render the scene-texture to an offscreen-texture. Input scale/stretch is applied here.
  • Go through each shader defined in the shader manager.
  • If the last shader rendered to an offscreen-texture it will perform another step to render to screen.
So I think the problem is that input scale/stretch is applied in the first step, it should instead be performed for the first shader in the chain or when rendering to screen if there are no shaders.

Changing that should be easy so I can probably get it up for testing later today if I get some time for it.
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

I took a quick look and I noticed I've understood the filter_linearN-value wrong. I thought the value was about the output texture but it appears to be how it should filter the input texture.
I've replaced the shader_test-branch with a new one which fixes this issue, please try it and see if it looks more as expected.
iwasaperson
Posts: 31
Joined: Sun 02 Nov, 2014 12:48 am

Re: [Linux] GUI discussion

Post by iwasaperson »

Still does not compile on my Intel iGPU machine. I'll test with fglrx and edit this post with results.

EDIT: With fglrx the shader compiles correctly and seems to work just as expected so long as I turn off any input scaling in the GL3 menu. I get smooth scrolling with Keen 4 and ZSNES other than the expected issues with framerate mismatch (judder and tearing), but that's not the emulator's fault. The pixel sizing seems to be even with the slight blur just as expected.

Any more information I can give with the iGPU compiling problem?
basic2004
Posts: 124
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Linux] GUI discussion

Post by basic2004 »

bit wrote:I took a quick look and I noticed I've understood the filter_linearN-value wrong. I thought the value was about the output texture but it appears to be how it should filter the input texture.
I've replaced the shader_test-branch with a new one which fixes this issue, please try it and see if it looks more as expected.
I tested shader_test branch, it's clear... better than master branch now.

Input stretch mode : 4:3, same with output.
Input scale : 4x,
Scale filtering : linear,
Resolution : Custom 1280x960

Current master branch of PCem-wx-SDL2
master.jpg
master.jpg (86.01 KiB) Viewed 28888 times
shader_test branch
shader_test.jpg
shader_test.jpg (80.92 KiB) Viewed 28888 times
Wow! this looks clear!
beforeafter.png
beforeafter.png (29.83 KiB) Viewed 28888 times
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

That's great!
iwasaperson wrote:Any more information I can give with the iGPU compiling problem?
I looked at the source for RetroArch and found out that they set the GLSL-version manually if it isn't defined, which is the case with this shader. I've added that as well and updated the branch, maybe it will compile now.
iwasaperson
Posts: 31
Joined: Sun 02 Nov, 2014 12:48 am

Re: [Linux] GUI discussion

Post by iwasaperson »

bit wrote:I looked at the source for RetroArch and found out that they set the GLSL-version manually if it isn't defined, which is the case with this shader. I've added that as well and updated the branch, maybe it will compile now.
That just broke everything and now GL3 won't work even without any shaders (black screen with the error messages below).

Could not compile shader:
0:3(1): error: `in' qualifier in declaration of `VertexCoord' only valid for function parameters in GLSL 1.10
0:4(1): error: `in' qualifier in declaration of `TexCoord' only valid for function parameters in GLSL 1.10
0:6(1): error: `out' qualifier in declaration of `texCoord' only valid for function parameters in GLSL 1.10

Could not compile shader:
0:3(1): error: `in' qualifier in declaration of `VertexCoord' only valid for function parameters in GLSL 1.10
0:4(1): error: `in' qualifier in declaration of `Color' only valid for function parameters in GLSL 1.10
0:6(1): error: `out' qualifier in declaration of `color' only valid for function parameters in GLSL 1.10
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

iwasaperson wrote:
bit wrote:I looked at the source for RetroArch and found out that they set the GLSL-version manually if it isn't defined, which is the case with this shader. I've added that as well and updated the branch, maybe it will compile now.
That just broke everything and now GL3 won't work even without any shaders (black screen with the error messages below).

Could not compile shader:
0:3(1): error: `in' qualifier in declaration of `VertexCoord' only valid for function parameters in GLSL 1.10
0:4(1): error: `in' qualifier in declaration of `TexCoord' only valid for function parameters in GLSL 1.10
0:6(1): error: `out' qualifier in declaration of `texCoord' only valid for function parameters in GLSL 1.10

Could not compile shader:
0:3(1): error: `in' qualifier in declaration of `VertexCoord' only valid for function parameters in GLSL 1.10
0:4(1): error: `in' qualifier in declaration of `Color' only valid for function parameters in GLSL 1.10
0:6(1): error: `out' qualifier in declaration of `color' only valid for function parameters in GLSL 1.10
Hmm that's strange. What does pcem.log say?
iwasaperson
Posts: 31
Joined: Sun 02 Nov, 2014 12:48 am

Re: [Linux] GUI discussion

Post by iwasaperson »

bit wrote: Hmm that's strange. What does pcem.log say?
Attachments
pcem.log
(10.94 KiB) Downloaded 454 times
User avatar
leilei
Posts: 1039
Joined: Fri 25 Apr, 2014 4:47 pm

Re: [Linux] GUI discussion

Post by leilei »

bit wrote:
leilei wrote:focusing problems with some windows
Which windows are misbehaving? I'll take a look at them.
Opening "machine" doesn't put it over the main window. Also quitting a machine back to the config picker doesn't focus the window on top either.
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

iwasaperson wrote:
Oh oops, don't code while tired :) Try it now.
leilei wrote:Opening "machine" doesn't put it over the main window. Also quitting a machine back to the config picker doesn't focus the window on top either.
Thanks! I'll take a look at it.
iwasaperson
Posts: 31
Joined: Sun 02 Nov, 2014 12:48 am

Re: [Linux] GUI discussion

Post by iwasaperson »

bit wrote: Oh oops, don't code while tired :) Try it now.
That worked. Shader is working fine now (iGPU).

I usually code my best while tired :P

On another note, I've noticed that GL3 slows down the emulation quite a bit compared to Software or OpenGL. I can't even run a 486DX2 66 at full speed on my 6600K whereas a Pentium 120 runs full speed with no problem with other renderers.

It also seems like Pixellate (which also works now) looks quite a bit better in PCem than sharp-bilinear, which is weird because in RetroArch I can barely tell the difference between the two. Sharp-bilinear looks quite a bit blurrier than I was expecting in comparison. Perhaps it's the higher resolution.
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

iwasaperson wrote:That worked. Shader is working fine now (iGPU).
Great!
iwasaperson wrote:On another note, I've noticed that GL3 slows down the emulation quite a bit compared to Software or OpenGL. I can't even run a 486DX2 66 at full speed on my 6600K whereas a Pentium 120 runs full speed with no problem with other renderers.
Hmm, the rendering is performed in a separate thread from the emulation so it shouldn't slow it down too much. Not sure what could cause that.
iwasaperson wrote:It also seems like Pixellate (which also works now) looks quite a bit better in PCem than sharp-bilinear, which is weird because in RetroArch I can barely tell the difference between the two. Sharp-bilinear looks quite a bit blurrier than I was expecting in comparison. Perhaps it's the higher resolution.
Pixellate looks really nice :)
No idea why it would be different, but as you say it could be because of a higher resolution.
iwasaperson
Posts: 31
Joined: Sun 02 Nov, 2014 12:48 am

Re: [Linux] GUI discussion

Post by iwasaperson »

bit wrote: Hmm, the rendering is performed in a separate thread from the emulation so it shouldn't slow it down too much. Not sure what could cause that.
Looks like I made a mistake in my analysis. I get equally low performance with both OpenGL and GL3, but with software rendering, I get full speed.

Even 386SX 16 I get the same performance (~85-90%).

Is my iGPU really that weak?
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

iwasaperson wrote:
bit wrote: Hmm, the rendering is performed in a separate thread from the emulation so it shouldn't slow it down too much. Not sure what could cause that.
Looks like I made a mistake in my analysis. I get equally low performance with both OpenGL and GL3, but with software rendering, I get full speed.

Even 386SX 16 I get the same performance (~85-90%).

Is my iGPU really that weak?
Oh then I see, it probably takes a while for your GPU to copy the display-image. I didn't think that would be an issue.
I have created another branch (performance_test) where I instead copy the display-image to a temporary buffer and then copy that to the GPU later, it might help.
iwasaperson
Posts: 31
Joined: Sun 02 Nov, 2014 12:48 am

Re: [Linux] GUI discussion

Post by iwasaperson »

bit wrote: Oh then I see, it probably takes a while for your GPU to copy the display-image. I didn't think that would be an issue.
I have created another branch (performance_test) where I instead copy the display-image to a temporary buffer and then copy that to the GPU later, it might help.
That fixed it right up. Socket 7 Pentium 120 with GL3 and pixellate isn't dipping below 99% at all anymore.
JosepMa
Posts: 202
Joined: Tue 20 Jun, 2017 6:25 pm

Re: [Linux] GUI discussion

Post by JosepMa »

I thought I'd share the modified Makefile.mingw-wx-sdl2 that I use in msys2 to build this ( works in Pcem's main repo and bit's one. The only change required is to change __MINGW64__ for __MINGW32__ in cdrom-ioctl.c if you build for 32bits )
Attachments
Makefile.mingw-wx-sdl2.zip
modified makefile for msys2
(1.89 KiB) Downloaded 441 times
basic2004
Posts: 124
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Linux] GUI discussion

Post by basic2004 »

wxWidgets version can't access relative path and non-English directories.
I hope this can access like Windows UI version.
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

basic2004 wrote:wxWidgets version can't access relative path and non-English directories.
I hope this can access like Windows UI version.
Hmm has it ever worked with that or has it stopped working recently?
What specifically is not working, file browsing? The normal Windows-version works without issues?
basic2004
Posts: 124
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Linux] GUI discussion

Post by basic2004 »

bit wrote:
basic2004 wrote:wxWidgets version can't access relative path and non-English directories.
I hope this can access like Windows UI version.
Hmm has it ever worked with that or has it stopped working recently?
What specifically is not working, file browsing? The normal Windows-version works without issues?
PCem-wx-sdl2 has an issue about all of path (file and folder) handling.
Is this problem Windows only?
I didn't use Linux yet so I don't know about this issue in linux.

Installed PCem path is English, All works.
pcem-wx-english-path.png
pcem-wx-english-path.png (17.01 KiB) Viewed 28421 times
If installed PCem path is non-English, No works.
This error means 'The system cannot find the path specified'.
pcem-wx-non-english-path.png
pcem-wx-non-english-path.png (7.63 KiB) Viewed 28421 times
But PCem Windows version works.
pcem-win-non-english-path.png
pcem-win-non-english-path.png (5.95 KiB) Viewed 28421 times
basic2004
Posts: 124
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Linux] GUI discussion

Post by basic2004 »

And I found another issue, PCem-wx-sdl2 can't select host CD drive in Windows.
pcem-wx-sdl2-cannot-select-host-cd-drive.png
pcem-wx-sdl2-cannot-select-host-cd-drive.png (23.07 KiB) Viewed 28414 times
Checkmark wasn't changed when I selected host CD drive,
then CD device was eject but still checked 'Image...' when I used a CD Image before select host CD drive.
User avatar
leilei
Posts: 1039
Joined: Fri 25 Apr, 2014 4:47 pm

Re: [Linux] GUI discussion

Post by leilei »

Is copying/duplicating a config file on the launcher in the plans? I often do this manually in the shell when trying different video/sound/mouse configs on the same drives
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Linux] GUI discussion

Post by Battler »

- basic2004: From what I remember, bit did say that the WX-SDL2 UI does not support Unicode.
bit
Posts: 98
Joined: Sun 19 Mar, 2017 7:04 pm

Re: [Linux] GUI discussion

Post by bit »

basic2004 wrote:PCem-wx-sdl2 has an issue about all of path (file and folder) handling.
Oh I see. I was able to reproduce this problem on my Windows-machine. However I couldn't get it to work with the original Windows-version or with the v12-release, it seems like they can't get the path either. Is there something I need to change in Windows to get it to work? I'm using a regular English version.
I also tried to build PCem inside a folder with non-English characters but make failed with an error as well.
I haven't tried it on Linux yet so I don't know if there's an issue there.
basic2004 wrote:And I found another issue, PCem-wx-sdl2 can't select host CD drive in Windows.
I'll take a look at that.
leilei wrote:Is copying/duplicating a config file on the launcher in the plans? I often do this manually in the shell when trying different video/sound/mouse configs on the same drives
That's a good idea, it should be easy to add.
By the way I've tried to reproduce the focus-issues you're experiencing but I can't seem to get them to happen to me. I probably do it wrong, so if possible could you record a video when it happens?
Battler wrote:- basic2004: From what I remember, bit did say that the WX-SDL2 UI does not support Unicode.
It was probably from when I rewrote the Windows-version to use the code from win.c. wxWidgets has Unicode enabled by default but it caused some issues with the title bar so I undefined it to fix them.
It could be that undefine that causes it to not work but I'm not sure since I can't get it to work at all with non-English characters here :)
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Linux] GUI discussion

Post by Battler »

bit wrote:It was probably from when I rewrote the Windows-version to use the code from win.c. wxWidgets has Unicode enabled by default but it caused some issues with the title bar so I undefined it to fix them.
Because the title bar gets updated by code in pc.c, and that code assumes ANSI. Maybe that should be rewritten to somehow be more Unicode-compatible.
basic2004
Posts: 124
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Linux] GUI discussion

Post by basic2004 »

bit wrote:
basic2004 wrote:And I found another issue, PCem-wx-sdl2 can't select host CD drive in Windows.
I'll take a look at that.
Thanks for fixing. It works correctly in my Windows.
Battler wrote:
bit wrote:It was probably from when I rewrote the Windows-version to use the code from win.c. wxWidgets has Unicode enabled by default but it caused some issues with the title bar so I undefined it to fix them.
Because the title bar gets updated by code in pc.c, and that code assumes ANSI. Maybe that should be rewritten to somehow be more Unicode-compatible.
PCem is using Multibyte yet, maybe I think this will solve to use 'Multibyte to Unicode (Unicode to Multibyte)' conversion in Windows version.
EluanCM
Posts: 112
Joined: Tue 27 Oct, 2015 2:07 pm
Location: Brazil
Contact:

Re: [Linux] GUI discussion

Post by EluanCM »

The screen is not redrawn when switching virtual desktops on Linux. This is worse if emulating a system without mouse, because then we can't just move the mouse to force the screen to be redrawn.
Greatpsycho
Posts: 151
Joined: Tue 22 Mar, 2016 10:03 am
Location: Korea
Contact:

Re: [Linux] GUI discussion

Post by Greatpsycho »

Unlike legacy Allegro version, the wxWidgets version fails to find OpenAL library during configuration on CentOS 6.x. All required library is installed.

This screenshot is legacy Allegro version.
OpenAL-allegro.png
OpenAL-allegro.png (71.83 KiB) Viewed 27737 times
This screenshot is wxWidgets version.
OpenAL-wxWidgets.png
OpenAL-wxWidgets.png (70.67 KiB) Viewed 27737 times
AmatCoder
Posts: 28
Joined: Thu 02 Mar, 2017 8:45 pm

Re: [Linux] GUI discussion

Post by AmatCoder »

It looks like you have not installed the SDL2 libraries.

Rationale:
There is a bug into sdl2.m4 file since version 2.0.5. It causes that the configure script does not exit when it does not find the SDL2 libraries.

The configure script fails when checking OpenAL because it tries to compile a test linking SDL2 libraries.
As compilation fails then it gives that inaccurate error.
Greatpsycho
Posts: 151
Joined: Tue 22 Mar, 2016 10:03 am
Location: Korea
Contact:

Re: [Linux] GUI discussion

Post by Greatpsycho »

AmatCoder wrote:It looks like you have not installed the SDL2 libraries.

Rationale:
There is a bug into sdl2.m4 file since version 2.0.5. It causes that the configure script does not exit when it does not find the SDL2 libraries.

The configure script fails when checking OpenAL because it tries to compile a test linking SDL2 libraries.
As compilation fails then it gives that inaccurate error.
I've reinstalled SDL2 from source that can download at official SDL2 site. But configure script can't find SDL2 library as shown below. I've attached screenshot and config.log file.
SDL2-error.png
SDL2-error.png (72.55 KiB) Viewed 27650 times
Attachments
config.log
(17.31 KiB) Downloaded 393 times
AmatCoder
Posts: 28
Joined: Thu 02 Mar, 2017 8:45 pm

Re: [Linux] GUI discussion

Post by AmatCoder »

It seems that you have installed SDL2 into /usr/local.
Uninstall it and then re-install it with:

Code: Select all

$ ./configure --prefix=/usr
Rationale:
Configure script installs packages into /usr/local/ by default (i.e. if prefix is not set).

As pkg-config* will search for .pc files in the directories /usr/lib/pkgconfig and /usr/share/pkgconfig (on a typical system),
your sdl2.pc is not found (it was into /usr/local/lib/pkgconfig).

(*)The pkg-config program is used to retrieve information about installed libraries in the system.
Post Reply