GTK/X11 Port (aka Linux/UNIX GUI)

stevejesus · Post by **stevejesus** » Thu Mar 06, 2008 12:03 am

bear0so, I use mythTV at home on my HDTV. What I would like to do is set MythGame to launch SNES games via a pre-defined command. This is how I load all of my roms for other systems. The idea is to populate a list of roms under a selection named "SNES NTSC", and then have another called "SNES RAW", and another called "SNES BLING". So, I need to use 3 separate commands, rather than using on config file. This way, I can play a ROM with whichever filter looks best with that game.

Thanks

BearOso · Post by **BearOso** » Thu Mar 06, 2008 8:40 am

prurigro wrote: after having tried the latest release I gotta say I've never had performance like this in a snes emu on my slower box; very nice work one thing though, this only happens on my computer with an LCD, but there's a line of green about a pixel wide all the way down the right of the window (or fullscreen) in xv mode. I assume my CRT just skips that last pixel, but it could just be some funky driver config on my LCD computer or something too, I'm not sure-- I cant find any problems beyond this though

I seriously thought I'd managed to fix that. The problem is that the green color is the zero color in YUV format and the video card tries to blend the empty edge into the image. I'll have to look at this more. If you look closely, it's probably at the bottom of the window, too.

edit : another problem new to me using xv is input lagging-- after a point of playing pressing a button will take a second or so before taking effect, like, pressing forward will cause the character to move forward a few seconds after pressing it. Non game keys like the ones i defined for fullscreen and system pause have the same wait. this issue disappears by returning to windowed mode and then fullscreen again. fullscreen here is widescreen with no filters if that helps?

This one is new. I know that recent nvidia drivers have some async issues with XV I have to work around, so if you're using a nvidia card that could be an issue. I do need to fix some rare timing issues that might also contribute to this.
*edit*
Oh yeah, I am now seeing this. It coincides perfectly with the 100% CPU problem. Disabling XV vsync "fixes" it.

stevejesus wrote: bear0so, I use mythTV at home on my HDTV. What I would like to do is set MythGame to launch SNES games via a pre-defined command. This is how I load all of my roms for other systems. The idea is to populate a list of roms under a selection named "SNES NTSC", and then have another called "SNES RAW", and another called "SNES BLING". So, I need to use 3 separate commands, rather than using on config file. This way, I can play a ROM with whichever filter looks best with that game.

OK, that's logical reasoning. Coincidentally, do you have any problems when exiting the emulator using MythTV?

prurigro · Post by **prurigro** » Thu Mar 06, 2008 9:40 pm

Oh yeah, I am now seeing this. It coincides perfectly with the 100% CPU problem. Disabling XV vsync "fixes" it.

I'm actually using the i810 driver for intel-- I'll try to figure out how to get rid of vsync for xv with it but I figured it might be handy for you to know its not just nvidia

thanks

edit : I tried disabling vsync in driconf (http://dri.freedesktop.org/wiki/DriConf) and haven't had the issue since (played around for a while to see if it would pop up) - thanks! btw, theres also no tearing despite having this disabled, I wonder if it would be worth while having snes9x-gtk disable it by default and have an option to reenable it?
edit : while turning vsync off did help for the most part, after playing for quite a while the game was getting choppy here and there and then finally went out of sync with the controls until I went out and back into fullscreen

BearOso · Post by **BearOso** » Fri Mar 07, 2008 8:34 am

prurigro wrote:
Oh yeah, I am now seeing this. It coincides perfectly with the 100% CPU problem. Disabling XV vsync "fixes" it.
I'm actually using the i810 driver for intel-- I'll try to figure out how to get rid of vsync for xv with it but I figured it might be handy for you to know its not just nvidia

thanks

edit : I tried disabling vsync in driconf (http://dri.freedesktop.org/wiki/DriConf) and haven't had the issue since (played around for a while to see if it would pop up) - thanks! btw, theres also no tearing despite having this disabled, I wonder if it would be worth while having snes9x-gtk disable it by default and have an option to reenable it?
edit : while turning vsync off did help for the most part, after playing for quite a while the game was getting choppy here and there and then finally went out of sync with the controls until I went out and back into fullscreen

I've been researching this a bit, and it seems the problem appears when the output is updated faster than the refresh rate. XV seems to lock the X server while waiting to draw and misses the keyboard events somehow. I tested a keyboard and joystick simultaneously, and when the keyboard continues to miss events, the joystick is perfectly responsive, so it definitely only applies to events being trapped by the X server.

The interim "solutions" I found for this problem are:
1. Turning off vsync (which you say only helps, so it must not be the main problem.)
2. Increasing the frame time in Snes9x and setting it to 17ms, which makes things choppy. Auto-framerate helps slightly.

The true solution to this is finding out why the events are being missed. In the mean-time, if anyone is experiencing problems I'd recommend just using OpenGL if you can.

BearOso · Post by **BearOso** » Fri Mar 07, 2008 5:08 pm

Ok, I have hopefully resolved the issues with Xv in this new release. The Xv driver now does a round-trip to the X server both before and after blitting the image, so we don't miss events. I can no longer reproduce the aforementioned issues myself. Feedback is welcome.

stevejesus, I've added a command-line option to change the filter at start-time. The option verbatim:

Code: Select all

-filter [option]               Use a filter to scale the image.
                               [option] is one of: none supereagle 2xsai
                               super2xsai hq2x hq3x hq4x epx ntsc

It'll also end up being saved to the config file, for bad or good. Let me know if the one option's not enough.

*addendum*
If anyone's using a nvidia card and wants to use Xv for some reason, you might still need to add Option "UseEvents" "True" to your xorg.cfg to avoid a 100% cpu issue.

prurigro · Post by **prurigro** » Fri Mar 07, 2008 9:43 pm

hey, the input issue seems to be fixed so props there =D I'll report back if I find it acting up at all

the issue with the line was fixed partially, but theres still some green along the side of the image-- heres a screenshot if it helps http://img292.imageshack.us/img292/720/screenrw3.png

thanks again for all your time and energy into this project

BearOso · Post by **BearOso** » Sun Mar 09, 2008 10:42 am

Another release. This fixes a stupid mistake I made with the -filter option, and tries to fix the Xv green line issue. If this doesn't work, your driver's bugged.

deniseweird · Post by **deniseweird** » Sun Mar 09, 2008 3:20 pm

This may sound very perfectionist. But since I am making such perfectionist suggestions, that means the emulator is just about perfect.

Anyway, is there a way to make sure the filtering is always the same? If I play a game wich occassionally uses hi-res for example, I immediately notice a difference between hi-res and low-res. Not because of more detail or anything, but because the frame wich uses hi-res is less interpolated than the one wich uses low-res. I attached an example from G.O.D:

Only low-res:

Hi-res used:

The effect is the same for both OpenGL and Xv. I am not using any filters apart from the (automatic in Xv) interpolation. Also, switching to fullscreen still takes pretty long if you use a different resolution for fullscreen.

BearOso · Post by **BearOso** » Sun Mar 09, 2008 6:24 pm

deniseweird, you can actually enable the nearest-pixel filtering byuu describes with OpenGL by unchecking the "Bilinear-filter output" checkbox in the OpenGL settings.

On the opposite side, you can't really force the the graphics card to to bilinear filtering all the time, as it special-cases the exact pixel-size situation to not filter. However, if you change the size of the window by just a pixel in one or more directions, you can prevent the size from being exactly the same in either high or low-res, preventing the special case from triggering.

*edit* I just realized what byuu was saying--the game itself is doing pixel-doubling for the non-hires lines when it needs hires in others, which is the primary cause of your situation. The solution is to implement a 2x horizontal filter that doubles pixel width when the original width is 256, which isn't that hard to do.

deniseweird · Post by **deniseweird** » Sun Mar 09, 2008 6:50 pm

Hmmm. When byuu talked about this, it sounded like it was very hard, maybe impossible to fix. Now when you speak about it, it sounds easy. So, if it actually is easy to do, then I would kindly request the 2x horizonal interpolation to be added.

Thanks.

BearOso · Post by **BearOso** » Sun Mar 09, 2008 7:01 pm

deniseweird wrote:Hmmm. When byuu talked about this, it sounded like it was very hard, maybe impossible to fix. Now when you speak about it, it sounds easy. So, if it actually is easy to do, then I would kindly request the 2x horizonal interpolation to be added. Thanks.

What byuu is talking about is a real solution. I'm talking about a hack. I'll have something new up in a few hours.

BearOso · Post by **BearOso** » Sun Mar 09, 2008 8:09 pm

BearOso wrote:
deniseweird wrote:Hmmm. When byuu talked about this, it sounded like it was very hard, maybe impossible to fix. Now when you speak about it, it sounds easy. So, if it actually is easy to do, then I would kindly request the 2x horizonal interpolation to be added. Thanks.
What byuu is talking about is a real solution. I'm talking about a hack. I'll have something new up in a few hours.

Release 22a--I said it would be a hack, and it sure turned out that way. I added a scaling filter called Complex2x that essentially forces the image to be 512x448 pixels. Basically, this means the graphics card will get the same size image every time and filter it the same way every time.

In the next release, I think this will end up as something like a "force hires output" check-box that does an in-place scale instead of an additional copy filter. This is just an interim solution.

deniseweird · Post by **deniseweird** » Sun Mar 09, 2008 8:58 pm

Wow, that was fast! While it may be a hack, it works just fine for me.

Thanks a lot for this!

prurigro · Post by **prurigro** » Sun Mar 09, 2008 9:15 pm

wow- your speed is crazy =D

your xv border fix has it at like 99.9% fixed, you can just see the faintest line on the right, but you might just be right about it being my vid drivers at this point if noone else is getting issues

also, I'm not sure what else you changed- but I think I might have the best performance yet with this release? could just be my imagination tho

thanks!

BearOso · Post by **BearOso** » Sun Mar 09, 2008 9:31 pm

prurigro wrote:wow- your speed is crazy =D

And with such careless speed comes some serious bugs. I just uploaded yet another bug fix release that fixes some fullscreen messes I introduced in the last one.

Update if you are experiencing any problems.

prurigro · Post by **prurigro** » Mon Mar 10, 2008 12:40 am

I have no idea why, but after rebooting following a kernel upgrade snes9x-gtk has no funny borders in the game-- seems like the fix is indeed working; it just took maybe a reboot or something to get it to take effect

nice work either way

-- no fullscreen bugs yet either

edit : I rebooted again and there was a green bar once again-- I tried the intel driver from xorg however (i810 is what I'm normally using) and it fixed this issue along with another one where I cant use xv in any program other than snes9x after using snes9x, so it sounds like its definitely the driver to blame here (shame intel is so slow) -- sorry for making you dig for a fix when it was a driver's fault

deniseweird · Post by **deniseweird** » Mon Mar 10, 2008 12:16 pm

For some reason I can't start Snes9x now. Am I doing something wrong, or is Snes9x looking for ALSA? This is the terminal output:

Code: Select all

[ruti@localhost ~]$ /home/ruti/Apps/snes9x-1.51/snes9x-gtk
snes9x-gtk: src/hostapi/alsa/pa_linux_alsa.c:764: BuildDeviceList: Assertion `snd_config' failed. Aborted.

I am using OSS4 in my system (Though ALSA is everywhere, and if I try to uninstall it completely, every single valuable program goes with it for some reason..). As I understand Snes9x uses portaudio, wich in turn outputs to ALSA or OSS. I had it working with OSS yesterday without a problem, but today it doesn't work. Do you know what the problem is?

BearOso · Post by **BearOso** » Mon Mar 10, 2008 4:33 pm

deniseweird wrote:For some reason I can't start Snes9x now. Am I doing something wrong, or is Snes9x looking for ALSA? This is the terminal output:
Code: Select all
[ruti@localhost ~]$ /home/ruti/Apps/snes9x-1.51/snes9x-gtk
snes9x-gtk: src/hostapi/alsa/pa_linux_alsa.c:764: BuildDeviceList: Assertion `snd_config' failed. Aborted. 
I am using OSS4 in my system (Though ALSA is everywhere, and if I try to uninstall it completely, every single valuable program goes with it for some reason..). As I understand Snes9x uses portaudio, wich in turn outputs to ALSA or OSS. I had it working with OSS yesterday without a problem, but today it doesn't work. Do you know what the problem is?

I've investigated the source, and PortAudio will use OSS by default, but it pulls info on all the APIs it can find. You might have broken alsa somehow, but PortAudio still finds enough of it to try and start it.

It's failing an assertion on a global alsa symbol. Your portaudio lib was built with alsa support, but it fails to update the config because of an error. It should avoid the assertion, even with a broken alsa, but it isn't doing so for some reason. Can you tell me your portaudio version number?

deniseweird · Post by **deniseweird** » Mon Mar 10, 2008 4:43 pm

Like I said ALSA is everywhere :S If anyone knows about a good OSS4-based distro, please tell me. Anyway, if I understood the Mandriva versioning system right, I am using version 19-10. Maybe I will try compiling the library manually.