GroovyMAME 0.171 - SwitchRes v0.015m

[crispux3]

Hi all. I was wondering a couple things:

1.) Will there ever be an updated version of CRT_emudriver to be able to work with more recent video cards and windows 7 and up? (like vid cards with DX11 capabilities). I ask because some emulators require more than windows xp (which I'm currently using) to be able to run. If not, that's okay, but I'm wondering what are some of the technicalities/difficulties (besides time and money :-) ) that hinder the development.

2.) Do users compile groovymame themselves? I've always just got the builds from the download site. I ask because I was wondering if there was a way to compile a version without the popup messages from save states. For example, if one uses a save state in a game like Donkey Kong (I tested the A7800 version), where the character begins at the bottom of the screen, the savestate save and load messages obscure the bottom of the screen for 1-2 seconds hindering gameplay. Is it possible to remove the popup messages? I've seen another thread suggesting it is with normal builds of mame/mess, but I'm not sure with groovymame.

Thanks.

[Sledge]

Hi all. I was wondering a couple things:

1.) Will there ever be an updated version of CRT_emudriver to be able to work with more recent video cards and windows 7 and up? (like vid cards with DX11 capabilities). I ask because some emulators require more than windows xp (which I'm currently using) to be able to run. If not, that's okay, but I'm wondering what are some of the technicalities/difficulties (besides time and money :-) ) that hinder the development.

New video cards will not be supported for the foreseeable future due to windows limitations..
But yes there is a version for Windows 7

2.) Do users compile groovymame themselves? I've always just got the builds from the download site. I ask because I was wondering if there was a way to compile a version without the popup messages from save states. For example, if one uses a save state in a game like Donkey Kong (I tested the A7800 version), where the character begins at the bottom of the screen, the savestate save and load messages obscure the bottom of the screen for 1-2 seconds hindering gameplay. Is it possible to remove the popup messages? I've seen another thread suggesting it is with normal builds of mame/mess, but I'm not sure with groovymame.

Thanks.

Some people do, but there are also precompiled versions, but i'm not sure about the savestate popups as i never use them.

[Calamity]

New video cards will not be supported for the foreseeable future due to windows limitations..

They will. Hopefully after the summer. But let's don't anticipate things 

[Sledge]

New video cards will not be supported for the foreseeable future due to windows limitations..

They will. Hopefully after the summer. But let's don't anticipate things 

Well.. i wasn't.. but now you are lol
Sounds good though!!

[planexcvs]

New video cards will not be supported for the foreseeable future due to windows limitations..

They will. Hopefully after the summer. But let's don't anticipate things 

I'm wondering would that also help in fixing some of the monitor swap issues that some users' monitors have? I mean without having to use resistors.

I think I remember Calamity mentioning in one post several weeks ago.

[jdsony]

Just want to say thanks Calamity for another great release. Been messing around with 15khz for a few years going back and forth between Windows and Linux. Finally settled on Windows for this laptop and got everything setup almost perfect, just need to do some automation and build it into a cab. I just can't believe how much better games play. The speed is right, the animation and scrolling is so smooth, and the input lag is almost non-existent. I don't think I can go back to emulating any other way.

One think I've noticed is that I was getting artifacts in games that use the lowest resolutions (Congo Bongo for example). Changing my desktop colour mode to 16bit from 32bit fixed this. In previous setups I wasn't sure what was causing this. Works perfect now.

IBM Thinkpad R51 Pentium M 1.6ghz
2GB RAM
Mobility Radeon 9000 (CRT_EMUDRIVER patched with Mobility Modder)
Commodore 1084 CRT
Sony PVM-2030 CRT

I also have a P4 2.8 laptop with Radeon 9000 graphics I'll have to benchmark to see how it compares once I fix the power jack.

[buttersoft]

I just can't believe how much better games play. The speed is right, the animation and scrolling is so smooth, and the input lag is almost non-existent. I don't think I can go back to emulating any other way.

Agreed. So much fun to play around with the software, and the results are just stellar. Can't wait for what's next!

[Calamity]

GroovyMAME v0.164 is out (Switchres v0.015h)

No new features.

This time I've post-processed the diff files to make sure they won't cause problems. Hopefully this will be the end of patch errors.

[Dr.Venom]

Thanks Calamity for the update!

[headkaze]

This time I've post-processed the diff files to make sure they won't cause problems. Hopefully this will be the end of patch errors.

Thanks Calamity 

[Doozer]

GroovyMAME v0.164 is out (Switchres v0.015h)

No new features.

This time I've post-processed the diff files to make sure they won't cause problems. Hopefully this will be the end of patch errors.

The 64bit Linux build is ready and available on the google drive.

Cheers

[Calamity]

The 64bit Linux build is ready and available on the google drive.

Thanks a lot Doozer!

[Doozer]

The 64bit Linux build is ready and available on the google drive.

Thanks a lot Doozer!

You are welcome. All thanks must go to you for the groovy patch and to the community around this.

If I see any request for the NO_XINPUT, I will add it. I am curious to see if people need it.

Cheers my friend.

[gurbzs]

Hi Calamity,

thanx for this release. Before I started I ran vmmaker with the new mame.
Instead of 120 modelines it created 26 modelines.
Setup is xp32, 4 connected crt monitors (buggyboy setup)

Am I doing something wrong? everything was fine (mame 0.159)

[gurbzs]

Checked this again.
Used vmmaker on groovymame 0.163, it generated 27 modelines.
After generating mame.xml nothing happens, ini's are not created.

I installed mame 0.159, vmmaker 'sees' 626 modelines, generates 119.

Seems that it appears with mame 0.163 and up but I didn't try the rest.
Picture attached.

[Calamity]

Hi gurbzs,

Check this: http://forum.arcadecontrols.com/index.php/topic,135823.msg1520276.html#msg1520276

Remind you must not create ini's for GM.

[Calamity]

GroovyMAME 0.165 is out.

What's new in SwitchRes v0.015i

- Fixed broken mouse/trackball in SDL (VeS).
- Disabled prescale settings for vector games in SDL (now Windows and SDL builds behave the same).
- Fixed logging of option settings in SDL.

[Doozer]

GroovyMAME 0.165 binary for Linux users is out.

groovymame64_0165.015i_linux.tar.bz2
groovymame64_0165.015i_wiimote_linux.tar.bz2   (NO XINPUT)

[Calamity]

Thanks Doozer!

[Doozer]

Starting from now (including 0.165). The Linux binaries are build using Arch Linux (Groovy Arcade) distribution.

The files have been updated on the google drive accordingly.

Cheers

[Gn0m4]

Hi Calimity, nice work in all your versions of Mame.
Has GroovyMame 0.165 included cave and directinputs?
Could you post a complete versión with all this items? I´m really noob about to compile anything except my woman.


A lot of thanks !

[Calamity]

GroovyMAME v0.166 is out (Switchres v0.015i)

[Fuzzylogic]

Thanks Calamity!

I also used ATOM15 on a ATI card, and it's working beautifully, thanks again!

[Paradroid]

Yusss! As always, thanks so much for all the effort you put into GroovyMAME!

[Doozer]

LINUX GroovyMAME v0.166 builds are available (Switchres v0.015i)

[Calamity]

GroovyMAME 0.167 is out (Switchres v0.015j).

What's new in SwitchRes v0.015j

- Direct3D9ex support [koopah, intealls] (new option: -video d3d9ex): now GroovyMAME supports Direct3D9ex, which is present in all versions of Windows starting with Vista. This allows the application to take control of the frame latency and force it to the minimum allowed by the driver, avoiding the dreaded frame queues. This is specially useful in the situations where frame_delay can't be used reliably without tearing (LCDs, high resolutions). Besides, Direct3D9ex seems to perform better for certain hardware (Nvidia, Intel), so it may be preferred to plain Direct3D9 in general.

- Frame delay (improved) [intealls, Calamity]: now frame_delay polls the video driver for absolute scanline values, totally bypassing the default vertical synchronization functions. Some of the advantages are:

• Improved stability of the vertical synchronization mechanism, that finally makes it possible to extend GroovyMAME's audio/video synchronization to the frame delay use case.
• Awareness of the raster position and notification of missed retraces.
• Allows for anticipating the vertical retrace accurately (see vsync_offset, below).

- Vsync offset [intealls] (new option: -vsync_offset): forces render to happen a certain number of lines before the vertical blank (e.g. -vsync_offset 200). At high resolutions (LCD, etc.), the time it takes the GPU to scale a frame starts being longer than the blanking period itself. This is specially true when HLSL is used. This appears as static tearing when frame_delay is used. To compensate this issue, vsync_offset forces the render code to be called a number of lines ahead of time. Ideally, using a proper value realigns the render completion with the end of the blanking period, cleanly removing all tearing, even on LCDs with frame_delay and HLSL enabled. In practice, you need a fairly fast card in order to fully remove tearing. The higher the tearing line appears on the screen initially, the faster your card is, and the more chances of completely hiding tearing through -vsync_offset. Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.

[Paradroid]

This looks like a really exciting release! Well done and thank you!

[Doozer]

GroovyMAME 0.167 is out (Switchres v0.015j).

What's new in SwitchRes v0.015j

- Direct3D9ex support [koopah, intealls] (new option: -video d3d9ex): now GroovyMAME supports Direct3D9ex, which is present in all versions of Windows starting with Vista. This allows the application to take control of the frame latency and force it to the minimum allowed by the driver, avoiding the dreaded frame queues. This is specially useful in the situations where frame_delay can't be used reliably without tearing (LCDs, high resolutions). Besides, Direct3D9ex seems to perform better for certain hardware (Nvidia, Intel), so it may be preferred to plain Direct3D9 in general.

- Frame delay (improved) [intealls, Calamity]: now frame_delay polls the video driver for absolute scanline values, totally bypassing the default vertical synchronization functions. Some of the advantages are:

• Improved stability of the vertical synchronization mechanism, that finally makes it possible to extend GroovyMAME's audio/video synchronization to the frame delay use case.
• Awareness of the raster position and notification of missed retraces.
• Allows for anticipating the vertical retrace accurately (see vsync_offset, below).

- Vsync offset [intealls] (new option: -vsync_offset): forces render to happen a certain number of lines before the vertical blank (e.g. -vsync_offset 200). At high resolutions (LCD, etc.), the time it takes the GPU to scale a frame starts being longer than the blanking period itself. This is specially true when HLSL is used. This appears as static tearing when frame_delay is used. To compensate this issue, vsync_offset forces the render code to be called a number of lines ahead of time. Ideally, using a proper value realigns the render completion with the end of the blanking period, cleanly removing all tearing, even on LCDs with frame_delay and HLSL enabled. In practice, you need a fairly fast card in order to fully remove tearing. The higher the tearing line appears on the screen initially, the faster your card is, and the more chances of completely hiding tearing through -vsync_offset. Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.

The 64bit Linux builds are ready and available on the google drive.

Cheers

[Calamity]

The 64bit Linux builds are ready and available on the google drive.

Cheers

Thanks Doozer!

[xga]

Thanks for releasing so quickly, Calamity.   

Do you have a development roadmap for future features in Groovymame that you care to share / disclose or is it all a big surprise for us?

[Calamity]

Thanks for releasing so quickly, Calamity.   

Do you have a development roadmap for future features in Groovymame that you care to share / disclose or is it all a big surprise for us?

Basically adding support for newer ATI cards, when time permits.

[Calamity]

http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=996#p996

There are some important implications to these changes also for CRT users. Now it's no longer necessary to enable frame delay in order to bypass the frame queue. Just switching to Direct3D9ex already removes the frame queue in an ortodox way. This frame queue is the most important source of input latency in modern systems. Notice that Direct3D9ex is not available in Windows XP.

There's still one remaining frame of latency that can't be removed through Direct3D9ex alone: the one caused by double buffering. The reason for frame delay is to remove this last frame of latency and achieve next frame input response, matching real hardware behaviour.

Because the frame queue can usually involve 3 frames of lag or more, most users will find it good enough to simply remove it by switching to Direct3D9ex, as compared to the relatively minor improvement and important hassle of adjusting frame delay in a per game basis. However, the next frame response nirvana is reserved to frame delay users. Be aware that you'll need a powerful machine in order to reliably apply high values of frame delay.

For Windows XP users, however, Direct3D9ex is not an option, so you'll need to stick with Direct3D + frame delay in order to remove the frame queue + the last frame due to double buffering, as we did before and is explained in Recap's guide above.

[big10p]

Great stuff! Looking forward to trying this version out. Thanks Calamity, et al. 

[donluca]

For Windows XP users, however, Direct3D9ex is not an option, so you'll need to stick with Direct3D + frame delay in order to remove the frame queue + the last frame due to double buffering, as we did before and is explained in Recap's guide above.

Oh god, I'm afraid I've been a bit out of the loop.

So what's the ideal setup now? Isn't it WinXP + ddraw anymore? Win7 + Direct3D9ex is boss?

EDIT: and while we're at it... is  multithreading now safe to use in GroovyMame?

[intealls]

Posted a short tutorial here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=293 for finding the correct vsync_offset parameter for your settings.

[Calamity]

Oh god, I'm afraid I've been a bit out of the loop.

So what's the ideal setup now? Isn't it WinXP + ddraw anymore? Win7 + Direct3D9ex is boss?

EDIT: and while we're at it... is  multithreading now safe to use in GroovyMame?

Win XP is still fine, but if you have modern hardware it's better to use Windows 7. All recent tests regarding input/audio latency etc. are being done on Windows 7. Notice the range of video cards you can use with W7 is currently more limited than with XP. Direct3D is preferred in general, specially with W7, but you can still use either of them. The addition of low-latency Direct3D9ex makes DDraw even more irrelevant now (before you could still argue DDraw was not affected by frame queues). Multithreading is safe with GroovyMAME, none of the bad things you read about mt applies to GM. It's only an issue if you run frontends like HS that kill the running process without allowing it to exit cleanly.

[donluca]

Thanks for the reply!

Just to make sure... ignoring the hardware part, are there any benefits upgrading my current  setup from winXP+ddraw to Win7+D3Dex?

I'll be using GM with a Radeon X300SE and a 15Khz sony BVM monitor without super resolutions or any enhancements.
Is it worth the hassle?

[Calamity]

I'll be using GM with a Radeon X300SE and a 15Khz sony BVM monitor without super resolutions or any enhancements.
Is it worth the hassle?

You can't use the the X300 with current W7 drivers. Stick with your setup until you need/feel like updating your hardware.

[donluca]

Silly me, I forgot about that even though I looked at the crt_emudriver page a thousands time!

Looks like I'll still be good with WinXP+ddraw. Eventually, if I find a good deal on a HD4xxx card, I'll think about switching to W7 and take advantage of D3Dex.

[P.H.U.]

New video cards will not be supported for the foreseeable future due to windows limitations..

They will. Hopefully after the summer. But let's don't anticipate things 

Ugggghhhh, in the past few months, I have bought 3 HD4890's. I am picking up 3 cabs tomorrow. Damn you Calamity and your progress . In all seriousness, this is good news.