GroovyMAME 0.171 - SwitchRes v0.015m

[rCadeGaming]

 

[zebidia]

Does anyone have a patched version of GroovyMame/GroovyUME for Linux, and if so, is there a reason it can't be made available for download here?

Thanks.

[Sledge]

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?

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

Is the PS timing feature usable with 'super resolutions' ?
I get a bit of uneven scrolling happening with vertical games, and i'm just wondering whether to do the same thing to get smoother gameplay etc...

[Ansa89]

I have problems downloading patches from first post.
Can someone post them (both "hi_156.txt" and "0156_groovymame_015d.diff") as post-attachment?

[Calamity]

Here are the diffs.

I've also uploaded the Linux binaries to the Google Drive site, for anyone interested.

[haynor666]

Any plans for 157? window.c and window.h in sdl was changed much.

[Calamity]

GroovyMAME 0.157 is out.

What's new in SwitchRes v0.015e

- Starting from this version hiscore.dat must be placed in the same folder where mame.exe is, instead of inside the .\hi directory as before. This is to avoid confussion to new users. Please make sure to move hiscore.dat to the right place if you're upgrading from previous versions.

- Now GroovyMAME code relies on a simplified osd-independent version of MKChamp's hiscore patch. It's purpose is to make it easier to update both patches on the new update schedule, by keeping their entanglement as shallow as possible.

[Paradroid]

Excellent work!

Your updates are coming fast and furious these days...

Much appreciated!

[Calamity]

Linux binaries uploaded. Notice you need the Qt libraries installed since SDL MAME depends on them since recent versions. Because of this new binaries won't work in older Groovy Arcade distros.

[cools]

Ugh.

I'll get the AUR packages done soon, I'm not able to test on a cabinet at the moment.

[lettuce]

Calamity have just downloaded the latest GM build, can you just refresh my memory of what settings need to be changed from the default mame.ini file when using an LCD screen??, i know change the display type to LCD and LCD Range to 51-61 is there any other settings that need to be changed??

Just that i have gone from an AMD 7979 to an Nvidia GTX 970 and have notice Buggy Boy Jr is displaying in 16:9 not 4:3

[Calamity]

Yes, apart from "monitor lcd" you need to change "aspect 16:9" or whatever aspect your LCD is.

[lettuce]

Yes, apart from "monitor lcd" you need to change "aspect 16:9" or whatever aspect your LCD is.

Cool. So PowerStrip isnt really need anymore then?

One thing i have noticed and not sure if you know a fix, is say in triple screen game theres an new option now in the i game menu under video that has '3 screen Gapless' option. With HLSL disable then you do indeed get a gapless display but with HLSL enabled (and curvature and pincushion disabled) you get a very slight black line separating the screens. Do you know how to remove this when HLSL is enabled?

[Calamity]

Cool. So PowerStrip isnt really need anymore then?

Powerstrip was never needed. It was a very interesting feature to have, when combined with both a supported card and an LCD capable of outputting custom refresh rates. Powerstrip no longer supports new hardware. If you can put up with LCDs, nowadays it makes more sense to invest on a G-sync or Free-Sync monitor.

One thing i have noticed and not sure if you know a fix, is say in triple screen game theres an new option now in the i game menu under video that has '3 screen Gapless' option. With HLSL disable then you do indeed get a gapless display but with HLSL enabled (and curvature and pincushion disabled) you get a very slight black line separating the screens. Do you know how to remove this when HLSL is enabled?

No idea, sorry.

[lettuce]

Have G-Sync and Free Sync monitors actually been tested with MAME, to they allow for smooth scrolling like on Mortal Kombat's title screen

[haynor666]

I've just checked latest mame git source and there are lots of changes. Both no nag/highscore and groovymame will require modifications :/

[Calamity]

I've just checked latest mame git source and there are lots of changes. Both no nag/highscore and groovymame will require modifications :/

Yeah, sure. I've been following it and there are lots of changes in the sdl part. I'm afraid this time it will take me longer than with previous two versions, I'm stuck with work at the moment.

[smsmonkey]

Is there a known issue with the 0.157 Win x64 binary?  I notice the logs still reference SwitchRes v0.015d.

[Calamity]

Is there a known issue with the 0.157 Win x64 binary?  I notice the logs still reference SwitchRes v0.015d.

Maybe it was compiled before updating the version number in switchres.h. Anyway it is ok despite of that.

With regards to version 0.158: I won't be able to update in a week or two. Please be patient.

[krick]

With regards to version 0.158: I won't be able to update in a week or two. Please be patient.

No hurry.  I don't think there were any must-have changes in MAME 0.158 anyway.

In other news, have you looked at the MAME git repo lately?  There appears to be some possibly major changes to the MAME rendering code.

They've added a cross-platform rendering library called BGFX to the MAME codebase.

I'm don't know what, if anything, this means for the future of GroovyMAME, but I'm sure we'll find out come MAME 0.159

[PL1]

They've added a cross-platform rendering library called BGFX to the MAME codebase.

This looks like it could be good.      

23-vectordisplay

Rendering lines as oldschool vectors.

Scott

[Calamity]

No hurry.  I don't think there were any must-have changes in MAME 0.158 anyway.

In other news, have you looked at the MAME git repo lately?  There appears to be some possibly major changes to the MAME rendering code.

They've added a cross-platform rendering library called BGFX to the MAME codebase.

I'm don't know what, if anything, this means for the future of GroovyMAME, but I'm sure we'll find out come MAME 0.159

Yeah Micko has been working on it for a while. GroovyMAME code currently needs to handle the api directly to bypass some of the existing issues. The problem with using wrappers is you no longer can do these things, or it gets more difficult. We will see. I understand MAME devs on this move, although I'd prefer a native DX11 implementation to mess with (I'm cross-platform-skeptic).

[Calamity]

GroovyMAME v0.158 is out.

What's new in SwitchRes v0.015f

- Fixed bug in modeline scoring system that caused incorrect mode selection when running 60.606 Hz games (e.g. frogger) at their native orientation using certain monitor presets.

[Sledge]

Thanks Calamity

[BubbaMc]

Thanks!

[ReelTechnoFreek]

Thanks Calamity, wasn't expecting this so soon

[limner]

i've mame 0.155 and all the complete romset, chd files and extra

i would not to download everything for version 158 but i need groovymame and crt emuldrive: where i can find these softwares for 0.155 version?

[Calamity]

i've mame 0.155 and all the complete romset, chd files and extra

i would not to download everything for version 158 but i need groovymame and crt emuldrive: where i can find these softwares for 0.155 version?

Use the link in the first post.

[Calamity]

GroovyMAME v0.159 is out.

No new features in this release, all efforts have gone into keeping synchronized with the ongoing changes in the osd code. Testing is still needed, specially for Linux.

[Paradroid]

GroovyMAME v0.159 is out.

Woohoo! Thanks!

[lacanian]

Hi @Calamity,
 I just installed GroovyArcade.

What do you need tested in Linux that I can do for you?

[Calamity]

Hi @Calamity,
 I just installed GroovyArcade.

What do you need tested in Linux that I can do for you?

Well actually it's the most recent version 0.159 the one I haven't been able to test yet. No binaries available yet, however.

[MK]

Thanks Calamity!

I've read 0.159 windows native build now includes SDLMAME's OpenGL renderer.

Is this also enabled in GroovyMAME?
Any benefit compared to Direct3D?

[Doozer]

Hi,

I did a fresh compilation of GroovyUME 0.159 - SwitchRes v0.015f on a 64 bit groovvyarcade setup. I see a speed issue (50%) where 0.158_0.015f runs fine (100%). Options in ume.ini are identical for both.

Is someone else having the same issue?

[Calamity]

Hi,

I did a fresh compilation of GroovyUME 0.159 - SwitchRes v0.015f on a 64 bit groovvyarcade setup. I see a speed issue (50%) where 0.158_0.015f runs fine (100%). Options in ume.ini are identical for both.

Is someone else having the same issue?

You're probably the first one to test it. It was a nightmare to bypass the 50% speed issue back in 0.156 when SDL2 was introduced, it was required to use a drm call because sdl2/opengl seems to be designed to make proper vsync impossible. In this version they have moved several things around and probably my workaround is broken. It's going to be hard to keep this working until things settle down in the osd code. Last time it took me more than a week to get it working for the Linux side, this requires lots of tests each time a major change is done in mainline.

[Calamity]

Thanks Calamity!

I've read 0.159 windows native build now includes SDLMAME's OpenGL renderer.

Is this also enabled in GroovyMAME?
Any benefit compared to Direct3D?

No, it's not enabled in GroovyMAME, in Windows builds only d3d and ddraw support the modeline stuff. Probably once things settle down in mainline I'll look into extending it to opengl too.

[Doozer]

You're probably the first one to test it. It was a nightmare to bypass the 50% speed issue back in 0.156 when SDL2 was introduced, it was required to use a drm call because sdl2/opengl seems to be designed to make proper vsync impossible. In this version they have moved several things around and probably my workaround is broken. It's going to be hard to keep this working until things settle down in the osd code. Last time it took me more than a week to get it working for the Linux side, this requires lots of tests each time a major change is done in mainline.

I can imagine ;-) But don't stop, your works really rocks!

I confirm that 32bit binary behave the same. Disabling throttling shows normal hi-speed execution.

If you need test/support don't hesitate.   

[Calamity]

If you want to test, in /osd/sdl/drawogl.c, change:

Code: [Select]

#ifndef OSD_WINDOWS
SDL_GL_SetSwapInterval(video_config.waitvsync ? 1 : 0);
#endif
by

Code: [Select]

#ifndef OSD_WINDOWS
SDL_GL_SetSwapInterval((video_config.waitvsync && fd == 0) ? 1 : 0);
#endif
Then, just in case the change above didn't work, in /osd/sdl/window.c, also change:

Code: [Select]

SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, (video_config.waitvsync && fd == 0) ? 1 : 0);
by

Code: [Select]

SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);
That's because I'm not sure if fd is already defined at the time SDL_GL_SetAttribute is called. In previous versions both calls were inside drawogl.c and it was clearer.

[Doozer]

If you want to test, in /osd/sdl/drawogl.c, change:

Code: [Select]

#ifndef OSD_WINDOWS
   SDL_GL_SetSwapInterval(video_config.waitvsync ? 1 : 0);
#endif

by

Code: [Select]

#ifndef OSD_WINDOWS
   SDL_GL_SetSwapInterval((video_config.waitvsync && fd == 0) ? 1 : 0);
#endif

/osd/sdl/drawogl.c modification is sufficient to enable emulation at 100%

[Calamity]

What's new in SwitchRes v0.015g

- Added support for video mode switching with the OpenGL renderer in Windows (-video opengl). Notice that in order to get any vertical synchronization through the OpenGL renderer, the WGL_EXT_swap_control extension must be present in the system, otherwise the emulation will run unthrottled. This seems to be totally driver dependent. Not a real alternative to Direct3D at the moment.