GroovyMAME 0.171 - SwitchRes v0.015m

[Calamity]

I'm having a little difficulty getting the "ps_timing" option working in GM 0.154.

Hi sean_skroht,

Unfortunately the logs in version 154 are broken so the information they show is limited. Please wait for the new version and test then. If it keeps failing at least the logs will be more informative.

[sean_sk]

Hi sean_skroht,

Unfortunately the logs in version 154 are broken so the information they show is limited. Please wait for the new version and test then. If it keeps failing at least the logs will be more informative.

No problems. Will do.

[NightSprinter]

Calamity: I have GM working with 240p or equivalent on my linux box.  I am curious as to how to deal with interlaced resolutions (games like Popeye or Tekken 3), or with 480p or higher.  I can post my CRT_specs0 line and post a pic or two if need-be.

[Calamity]

Calamity: I have GM working with 240p or equivalent on my linux box.  I am curious as to how to deal with interlaced resolutions (games like Popeye or Tekken 3), or with 480p or higher.  I can post my CRT_specs0 line and post a pic or two if need-be.

Open a thread or reuse one of your existing ones so I can see what your setup was (monitor, etc.). Then post a picture there, but much better if you post logs too. Interlaced resolutions are managed automatically by GM. However, for games like Popeye that were originally interlaced, it will try to promote them to progressive if it has the chance (i.e. your crt_range allows it).

[lettuce]

Any release date for 0.155??

[Calamity]

Any release date for 0.155??

Still fighting with the Linux side...

[Ansa89]

Still fighting with the Linux side...

What's the problem? SDL2?

[Calamity]

What's the problem? SDL2?

Well the problem is I decided to implement support for rotating desktops and this requires osd specific code (ddraw, d3d, sdl) and tests for each of the three possible scaling methods (cleanstretch 0, 1, 2). Ddraw and d3d are done. But porting this to Linux has coincided with the move to SDL2 and things are messed up now. Vertical synchronization is totally flawed in SDL2 to begin with. The way it's implemented in mainline MAME makes games run at 50 % with some cards and at 100% with others. Modifying the swap interval from 2 to 1, which is what one should do according to SDL docs, and forcing glFinish, works fine in most situations, but in some others runs at 200%. GM needs a fully deterministic vertical synchronization, which just seems impossible to achieve with SDL2. By now I have resorted to completely bypassing SDL2 and using drm for doing vsync, which works perfectly. The second issue with SDL2 is it is designed to not allowing switching video modes while in fullscreen. Hopefully we can find a workaround for this too without having to rely on a pathed SDL2 library.

[Ansa89]

Sounds very messy and difficult.
Hope you will find a way to fix all these issues.

[cools]

So SDL2 sucks more than SDL1 and we're back to a non portable Linux specific OSD?

[Calamity]

So SDL2 sucks more than SDL1 and we're back to a non portable Linux specific OSD?

Well to be honest I only tested SDL2 for Linux, and the functionality I mentioned is definitely broken (not only for me). I guess the problem is rather with the underlying OpenGL and the way it schedules the buffer swaps. We always wanted to have asynchronous flipping (what we didn't have with DirectX fake triple buffering), but not at the price of loosing the ability to be to be synchronous when required.

[Sledge]

Any chance you can release the windows version? Then we can start big reporting etc on that one first
Who cares about all those Linux elitists any way

[Calamity]

GroovyMAME/UME v0.155 - Switchres v0.1015c released.

- Support for rotated desktops (Windows & Linux).
    - E.g. if you have your desktop rotated 90º, launch GroovyMAME like this: groovymame.exe 1942 -monitor vertical -aspect 3:4
      ("Magic" resolutions won't work with rotated desktops. If you're still using them we encourage you to move to "super" resolutions).

- Finally proper support for "super" resolutions (Windows & Linux):
    - Fix for modeline scoring to properly select the best available "super" resolution.
    - Fix for blank UI due to wrong scaling when in rotated mode and using "super" resolutions.
    - Fix for vector games that didn't show when using "super" resolutions.

- Moved our official build to SDL2 (Linux):
    - Fix for SDL2 broken waitvsync feature, now we perform vsync through DRM.
    - Fix for SDL2 broken mode switching feature while in fullscreen.
    - Added support for asynchronous rendering (equivalent to -triplebuffer in Windows).

- Full logs back in working order.

[krick]

GroovyMAME/UME v0.155 - Switchres v0.1015c released.

- Support for rotated desktops (Windows & Linux).
    - E.g. if you have your desktop rotated 90º, launch GroovyMAME like this: groovymame.exe 1942 -monitor vertical -aspect 3:4
      ("Magic" resolutions won't work with rotated desktops. If you're still using them we encourage you to move to "super" resolutions).

Is this a general recommendation for all GroovyMAME users to move to "super" resolutions going forward?  Even those of us using XP x64?

[cools]

Magic resolutions in XP are only useful for Hyperspin users. Hyperspin on a rotated desktop isn't pretty...

[Calamity]

Is this a general recommendation for all GroovyMAME users to move to "super" resolutions going forward?  Even those of us using XP x64?

While you can keep your current setup if it's working fine for you and GM will support "magic" resolutions as long as possible, I see objective benefits in using "super" over "magic" resolutions, like perfect horizontal centering between resolutions.

[sean_sk]

Hi Calamity,

Thank you very much for this release!!

I mentioned in my last post in this thread that I was getting the error message: "SwitchRes: could not find a video mode that meets your specs" when trying the ps_timing feature.
Well I managed to get it to work and I wanted to ask you a couple of questions about it. I've included a log showing the error as well as the ini settings I'm using.

By default I use the "arcade_15" monitor preset. In order for phoenix to run smoothly it needs to run at 16.784 kHz horizontal and 61.034 Hz vertical. I therefore exported those settings from powerstrip into phoenix.ini.

I discovered that I had to enter a custom crt_range in phoenix.ini. I used:
crt_range0                15625-16800, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576

Because Phoenix is running at horizontal frequency 16.784 kHz, I thought a limit of 16800 would be fine but I had to increase it to a minimum of 16968 for it to actually work. So therefore I was just wondering why I had to increase it so much to get it to work? The game still ran at 16784.

I have a couple of games that run at 352x256 but with different timings. I noticed that the last ps_timing setting, that happens to be used, overwrites the default profile for 352x256 in Powerstrip. Everytime a different timing is used for that same resolution it changes the default profile that I created in Powerstrip (for another purpose). I was hoping not to have this happen. Is there a way to stop that from happening?

As always, thanks for your help.


EDIT: I noticed a commenting mistake i made in phoenix.ini.txt. I meant to say that I had to change "horizontal" frequency range, not vertical.

[Calamity]

I was hoping not to have this happen. Is there a way to stop that from happening?

I'd say it is a rounding problem. In your ps_timing string, you have an H-total that is not 8-multiple (450).

7553 * 1000 / 450 = 16784 kHz

GM internally converts all horizontal  values to 8-multiples. In your case 450 would be rounded to 448.

7553 * 1000 / 448 = 16859 kHz

If you take care to use 8-multiples in PS this probably won't happen. It will produce more accurate results too because the driver also rounds everything to 8-multiples internally.

[sean_sk]

Thanks mate. I'll have a look.

UPDATE: H-Total of 450 is AVGA default. I did change it to 448 but it didn't do much except increase the reported h-frequency to 16859 (as you mentioned) from 16784 originally reported by switchres. Crt_range in phoenix.ini had to stay the same.

The concern I still have is that the ps_timing string overwrites the default profile I have created for the resolution in Powerstrip. The default profile I created simply centers the screen and adds lines to the backporch to eliminate line bunching at the top, but I have kept timings at default. This is so I can use that res with something other than GM.

 If I run a game that changes those timings, then the new timings overwrite the default timings permanently. Even if I restart Powerstrip and select 352x256 in quickres, the new timings still apply. Is there any way to stop that or is it something I have to deal with because of the way Powerstrip works?

[Calamity]

UPDATE: H-Total of 450 is AVGA default. I did change it to 448 but it didn't do much except increase the reported h-frequency to 16859 (as you mentioned) from 16784 originally reported by switchres. Crt_range in phoenix.ini had to stay the same.

Yeah but that's the right value, the previous one was bogus.

Is there any way to stop that or is it something I have to deal with because of the way Powerstrip works?

Unfortunately once we apply the new timings they stay, this is part of how Powerstrip works. In order to restore your previous values we should manage to read them first, and unfortunately the only way to do this is to actually set the mode, then read the values, store them, and finally set the new ones. Then on exit we should restore the original mode, but again the only way to do this is to actually set the mode. So you would probably have a lot of flashing each time you enter/exit a game. If you see the logs we actually restore the desktop default settings on exit, but this is because we set it to stay.

One possibility would be to create a batch file to launch your other emulators and use that .bat to set your default timings with PS before actually launching the emulator. I know the user rCadeGaming was doing this regularly, you could ask him about it.

BTW it makes me happy that someone uses the PS feature, it was challenge to integrate it at the time.

[sean_sk]

BTW it makes me happy that someone uses the PS feature, it was challenge to integrate it at the time.

And it's an awesome feature as well. Thank you for going to the trouble of putting it in there and answering my questions about it. I'm really enjoying using it. Your comments about the batch files has given me some ideas.  Thanks mate!

[krick]

Is this a general recommendation for all GroovyMAME users to move to "super" resolutions going forward?  Even those of us using XP x64?

While you can keep your current setup if it's working fine for you and GM will support "magic" resolutions as long as possible, I see objective benefits in using "super" over "magic" resolutions, like perfect horizontal centering between resolutions.

For some reason, I was under the impression that super resolutions didn't work in XP.

[Calamity]

For some reason, I was under the impression that super resolutions didn't work in XP.

It's "magic" resolutions what doesn't work in W7, and the reason "super" resolutions had to be implemented to replace those in the first place.

[adder]

Hi Calamity can i ask a paranoid question about super resolutions 
because of the super wide horizontal resolution in use, do you think it would have any affect on lag/performance in any way, or is there really no extra overheads here and it's not really any different from using one of the other groovy options?

[Calamity]

Hi Calamity can i ask a paranoid question about super resolutions 
because of the super wide horizontal resolution in use, do you think it would have any affect on lag/performance in any way, or is there really no extra overheads here and it's not really any different from using one of the other groovy options?

To be honest I have only tested "super" resolutions with HD 4xxx cards, and I could see no impact at all. Provided you have a semi-decent video card, the scaling should involve zero pain.

[twistedsymphony]

Maybe this was mentioned somewhere in the thread but I couldn't find it in the top post. I'd like to use the Groovy enhancements with MESS but you don't offer a mess compile only UME, however I can't seem to find an official release on mamedev.org for UME, only MESS.

Where should I get the official UME release to use as a base with the GroovyUME release?

[sean_sk]

I think UME can be found on Haze's site here: http://mamedev.emulab.it/haze/

A few posts down is the download for UME 0.155 which may also include the source. I haven't checked it myself yet.

[krick]

Maybe this was mentioned somewhere in the thread but I couldn't find it in the top post. I'd like to use the Groovy enhancements with MESS but you don't offer a mess compile only UME, however I can't seem to find an official release on mamedev.org for UME, only MESS.

Where should I get the official UME release to use as a base with the GroovyUME release?

Unless I'm mistaken, you just download the combined MAME/MESS source package from mamedev.org and build using:   make TARGET=ume

[twistedsymphony]

Maybe this was mentioned somewhere in the thread but I couldn't find it in the top post. I'd like to use the Groovy enhancements with MESS but you don't offer a mess compile only UME, however I can't seem to find an official release on mamedev.org for UME, only MESS.

Where should I get the official UME release to use as a base with the GroovyUME release?

Unless I'm mistaken, you just download the combined MAME/MESS source package from mamedev.org and build using:   make TARGET=ume

I think I'm being misunderstood. I'm not looking for the source code. I'm looking for the official binary distribution, specifically all of the files OTHER than the .exe

[krick]

I think I'm being misunderstood. I'm not looking for the source code. I'm looking for the official binary distribution, specifically all of the files OTHER than the .exe

UME is just MAME and MESS combined.  So if you're looking for "other files" they have to be either in the MAME distribution or the MESS binary distribution packages on the mamedev site...  http://mamedev.org/release.html

If there are no tools in those packages, then you may need to compile your own.  I think "make all" will build tools and the emulators.

[twistedsymphony]

GroovyMAME/UME v0.155 - Switchres v0.1015c released.

- Support for rotated desktops (Windows & Linux).
    - E.g. if you have your desktop rotated 90º, launch GroovyMAME like this: groovymame.exe 1942 -monitor vertical -aspect 3:4

AWESOME! Thank you for adding this. 

I'm assuming that GroovyMAME doesn't include the patch to add back support for cave shooters. That's fine but is there any known issues when compiling using both the GM diff and the cave shooter diff? I'd assume not but I'd figured I'd ask.

EDIT: Any problems using Headkaze's compiler with GM?

[sean_sk]

I'm assuming that GroovyMAME doesn't include the patch to add back support for cave shooters. That's fine but is there any known issues when compiling using both the GM diff and the cave shooter diff? I'd assume not but I'd figured I'd ask.

You shouldn't have to compile the Cave diff file into MAME as the Cave games have been supported in vanilla MAME since 0.152.

[twistedsymphony]

You shouldn't have to compile the Cave diff file into MAME as the Cave games have been supported in vanilla MAME since 0.152.

oh really? I didn't realize they'd been added back in... thanks 

[Calamity]

GroovyMAME/UME 0.156 is out.

What's new in SwitchRes v0.015d

- Frame_update method slighty reorganized to improve -frame_delay efficiency. Should fix previous issues with analog controls.

[sean_sk]

Whuuu? 0.156 is already out? I only just updated to 0.155. I wasn't expecting the MAME devs to release a new version so soon.
Thanks heaps for that Calamity.

EDIT: i just noticed the following on the mamedev website:

"MAME and MESS 0.156 are now available.
Please note that from now on we will create release every last Wednesday in month."

That's interesting! Calamity, you'll have your work cut out for you to keep up. Then again, at least you'll know when the next release is due out and can prepare for it.

[adder]

Calamity, you'll have your work cut out for you to keep up

or he could just skip every other release, so that would mean 6 groovymame's a year.. or skip 2 of 3 releases, so that's 4 groovymame's a year.
we dont want our hero stressed out

[crispux3]

I'm new to it all, but I concur: Calamity is a hero, and I really appreciate the skills and expertise he brings to the hobby. Seriously, I'm just an end-user and I appreciate all the computer/software engineers out there who can do what I only wish I could do.

[adder]

personally speaking i wouldnt update my mame setup every month, because i do try to play the games frequently, but if updating every month, i think i would end up spending too much time keeping up to date rather than playing anything. also, maybe there wont be a huge amount of changes each month anyway (but dont quote me on that )

[Ansa89]

Doing a simple patch resync (AKA: only fix hunk warnings/errors without implementing new features) in order to let us apply the old patch to newer release, shouldn't that stressful (IMHO).
However I totally agree when you say "If he wants to slow down a bit (4-6 patches per year), it's ok".

[sean_sk]

Doing a simple patch resync (AKA: only fix hunk warnings/errors without implementing new features) in order to let us apply the old patch to newer release, shouldn't that stressful (IMHO).

Yeah definitely. That's probably something we could do, thereby taking the load off Calamity. Like jadder said, not everyone is going to want to update every version, but if someone does want to, perhaps because of a fix for a particular rom then at least the option is there.