GroovyMAME 0.171 - SwitchRes v0.015m

[Calamity]

So 0.170 is officially the last release to support DDraw, correct?

Correct.

From now on WinXP will have to use D3D and Win7+ will use D3D9ex.

Win7 can either use D3D, D3D9ex or BGFX (DirectX 11)
WinXP can use D3D (BGFX D3D9 backend still not supported by GroovyMAME, it is by mainline)

[schmerzkaufen]

GroovyMAME 0.171 is out.

What's new in SwitchRes v0.015m

- (Windows 7+) Preliminar support for the new BGFX renderer (currently only DirectX 11). Mode setting is implemented. Dynamic resolution switching may be buggy yet. Frame delay not implemented yet.

Still using d3d9ex here, I suppose as long as SwitchRes is on in the .INI we should leave the new UI's 'Display Options' menu alone, right ?

[Calamity]

Still using d3d9ex here, I suppose as long as SwitchRes is on in the .INI we should leave the new UI's 'Display Options' menu alone, right ?

As far as I've seen, UI options apply to mame.ini, not per-game. E.g. forcing syncrefresh in mame.ini will override automatic behaviour, so it's not a good idea.

[donluca]

I'm wondering if the new BGFX will bring something new and interesting to the tables for GroovyMAME.

What can we expect from it? More accurate refresh rate generation? Honestly DDraw did everything great so I can't see how BGFX might bring better solutions to us.

[Calamity]

Accurate refresh generation (which might see an improvement in the near future) has nothing to do with the video API.

Because BGFX is the future MAME renderer, what is important is to realize that as long as we have support for it in GroovyMAME, there is future for GroovyMAME.

I'm amazed so many of you were still using DirectDraw, even when GM's default has been D3D for years. It was really problematic to provide support for DirectDraw on Windows 7, and it got totally broken on Windows 8/10.

[sean_sk]

Honestly DDraw did everything great so I can't see how BGFX might bring better solutions to us.

It's got nothing to do with it being better than ddraw. It has got to do with future proofing GroovyMAME to ensure it can accurately work the way it was intended to work on future operating systems and API's.
Windows XP and ddraw are dead and it's a very wise thing to adapt GM to work with newer technologies so that it can continue to survive. That's why we are all a part of this forum. We love the project, we want to see it flourish and we all help out where our abilities allow us to do so.

[sean_sk]

Thanks Calamity for this speedy update. I'm really really loving this one. Having pretty much jumped from 0.160 to 0.170/0.171, is it my imagination or does everything (ie controls) seem so much more responsive with D3D9ex with frame delay? It's a real joy to use. Thanks again.

[brywalker]

Thanks Calamity for this speedy update. I'm really really loving this one. Having pretty much jumped from 0.160 to 0.170/0.171, is it my imagination or does everything (ie controls) seem so much more responsive with D3D9ex with frame delay? It's a real joy to use. Thanks again.

So I must be wrong, but I thought using D3D9EX was to "remove" the frame buffer so you don't need frame delay. So you use them together? What do you have it set to currently?

[sean_sk]

I thought using D3D9EX was to "remove" the frame buffer

That's true, but according to here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=290

"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."

Apparently it's best to set it on a per-game basis and if the game requires it. For me I set it in mame.ini and forget. I've seen no adverse effects although my rig can handle it.
I have mine set to 5, to ensure next frame input........I hope.      I'm not an expert.

[u-man]

I am really curious how BGFX will affect input-lag and will wait for new tests regarding this. BGFX can be a good thing, as it is a cross-platform API, so i assume official MAME is targeting tablets and smartphones too in the near future (just like Retroarch). Sadly i still dont see multi-pass shader support. Sure the JSON files will help converting existing shaders easily, but without multi-pass, i will not invest any afford to do this.

Regarding ddraw, it was nice to see that the MAME dev team at least try to port the integer-scaling to directx. I am more worried about the drop to not support CRTs anymore in general. God bless Calamity and i honor him for his afford to keep the CRT community satisfied. Sad thing is, that he can only keep up the different video modes to support CRTs, but not the drivers itself.

What does this mean? It means that the devs are already starting to optimize the drivers for LCDs, which in turn can falsify the result what we see on our loved CRTs. Take Atari 2600 for example and start any game with high motion in it and then pause it and examine the screen. You will explore the blending of frames, which the devs did to avoid flicker on a LCD. This frame-blending did not exist on real hardware.

Here is a example of HERO and now notice the blending on the hero-figure:



This will affect the game-display on a CRT and is a thing we can not avoid in the future. I was upset that the devs really think, that the CRT community is just 1% of the whole MAME community or their general thoughts about CRT. I am even more wondering what this has to do with accuracy 

We really need to cherish Calamity, as he is the only person, who defended the CRT community in the lately discussions, we had with the devs.

[intealls]

What does this mean? It means that the devs are already starting to optimize the drivers for LCDs, which in turn can falsify the result what we see on our loved CRTs. Take Atari 2600 for example and start any game with high motion in it and then pause it and examine the screen. You will explore the blending of frames, which the devs did to avoid flicker on a LCD. This frame-blending did not exist on real hardware.

Are you sure about this? Doing that at the driver level would encourage inaccurate emulation, which is against the entire philosophy of MAME. Doing that with postprocessing (HLSL etc) is another story, and it's probably also something that can be turned off.

Edit:

I also want to clarify that I don't disagree with you, we should be immensely thankful for Calamity's efforts, since MAME hasn't worked as good as is possible on CRTs since many versions back. And it's not just GroovyMAME, it's the behemoth project of CRT Emudriver as well. A very good technical description written by Calamity highlights some of the relevant MAME-related topics here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=42.

[haynor666]

I'm not using mainline mame from couple of years except for testing. My main mame for play is groovymame 

This problem is probably due some effects applied like simulation of monitor burn. I really don't believe that mame devs could did such a thing.

[u-man]

Are you sure about this? Doing that at the driver level would encourage inaccurate emulation, which is against the entire philosophy of MAME. Doing that with postprocessing (HLSL etc) is another story, and it's probably also something that can be turned off.

yes, i am sure. try it for yourself, with no effects applied... its still there, that frame-blending crap. i just was to lazy, to do another screenshot.
I have same issues like you, regarding philosophy of MAME, but they consider CRT as a dead hardware, so it is nothing wrong in their eyes, to do the drivers itself and this is not the only example, i can asure you.

PS: haynor666: better believe it.

[u-man]

PROOF... D3D, no effects applied:

[Calamity]

yes, i am sure. try it for yourself, with no effects applied... its still there, that frame-blending crap. i just was to lazy, to do another screenshot.
I have same issues like you, regarding philosophy of MAME, but they consider CRT as a dead hardware, so it is nothing wrong in their eyes, to do the drivers itself and this is not the only example, i can asure you.

CRT is indeed a dead technology, otherwise we wouldn't be wasting energy on preserving it. MAME doesn't necessarily need to support CRTs (which nobody knows what it means), but to support certain features. One such feature is integer scaling, which devs have stated that will be re-implemented in 0.172, so that's an important first step.

(I'd like to remind the topic of this thread is just about the current version of GroovyMAME, its new features, etc., so please don't go off-topic).

[haynor666]

Ok so to be on topic are any plans to bring similiar feature ie. force integer scalling ratio no matter resolution like game 320x240 with black bars or trash on side to force work at 304x240 with 8 pixels cutted from both sides?

With ddraw this was possible but right it's not. From what I can see here on BYOAC forum there still some people that needs such option.

[Calamity]

Ok so to be on topic are any plans to bring similiar feature ie. force integer scalling ratio no matter resolution like game 320x240 with black bars or trash on side to force work at 304x240 with 8 pixels cutted from both sides?

With ddraw this was possible but right it's not. From what I can see here on BYOAC forum there still some people that needs such option.

Let me be clear on this: I consider cropping the game frame a very lame way of configuring things. As I have explained several times, the whole modeline engine is based on the premise that the native frame rectangle MUST fit in the target resolution.

From a programming point of view, it would make the modeline generator code unnecessarily complex and prone to bugs, just like if market food scales had to be designed to deal with the special case of antimatter.

I already suggested an alternative way of achieving the same thing for the Neo-Geo case that respects GroovyMAME's logic, this is: hiding the trash into the overscan area by using a custom crt_range with shorter porch values. Nobody tested it.

The other supposed use case was if I remind correctly being able to trim vertical games so they fit on a horizontal monitor. Please guys if you love the games rotate your monitor instead.

Anyway, the reason this was possible with DirectDraw is because its implementation mostly overrided MAME's core renderer internal logic. If there's ever a proper implementation for such feature, it should be in the core renderer.

[haynor666]

People are just prefer easier aproach - change resolution rather than create alternative crt range which is tricky and for most less experienced people time eaters. I know it's possible I tested it long time but I'm TV sometimes makes strange high pitch with certain ranges :/

To get slightly wider picture I modified HBackPorch in arcade_15 from default 8 to 4. Picture was moved to left but this can corrected on my TV in service menu.

[krick]

Let me be clear on this: I consider cropping the game frame a very lame way of configuring things. As I have explained several times, the whole modeline engine is based on the premise that the native frame rectangle MUST fit in the target resolution.

From a programming point of view, it would make the modeline generator code unnecessarily complex and prone to bugs, just like if market food scales had to be designed to deal with the special case of antimatter.

Agreed, cropping the frame is wrong.  People need to give up on that approach.  I'm almost certain that at some point in the past, Haze implemented a layout for certain Neo-Geo games in MAME that added a black overlay to the full native resolution to hide the garbage on the sides.  Does that no longer exist?  I'm perfectly fine with that solution.

[Calamity]

Agreed, cropping the frame is wrong.  People need to give up on that approach.  I'm almost certain that at some point in the past, Haze implemented a layout for certain Neo-Geo games in MAME that added a black overlay to the full native resolution to hide the garbage on the sides.  Does that no longer exist?  I'm perfectly fine with that solution.

According to this thread, current GroovyMAME patch seems to break that option. I'm currently trying to figure this out.

[haynor666]

Such options works hovewer for many other games like 2 monitor ones. I tested today Warrior Blade and switching from Dual-side-by-side to gapless mode changes resolution nicely. Changing to screen 0 standard or pixel aspect also nicely switches to 320x240. Probably neo-geo is exception.

[RobeeJ]

Hi guys, having build problems with 171 on Arch Linux, related to bgfx.

Code: [Select]

[root@mame mame171]# make
GCC 5.3.0 detected
Compiling src/osd/modules/render/drawbgfx.cpp...
../../../../../src/osd/modules/render/drawbgfx.cpp: In member function ‘virtual int renderer_bgfx::create()’:
../../../../../src/osd/modules/render/drawbgfx.cpp:135:222: error: too many arguments to function ‘void bgfx::reset(uint32_t, uint32_t, uint32_t)’
 indowed? BGFX_RESET_NONE : BGFX_RESET_FULLSCREEN) | (video_config.waitvsync ? BGFX_RESET_VSYNC : BGFX_RESET_NONE));
                                                                                                                  ^
In file included from ../../../../../3rdparty/bgfx/include/bgfx/bgfxplatform.h:14:0,
                 from ../../../../../src/osd/modules/render/drawbgfx.cpp:27:
../../../../../3rdparty/bgfx/include/bgfx/bgfx.h:801:7: note: declared here
  void reset(uint32_t _width, uint32_t _height, uint32_t _flags = BGFX_RESET_NONE);
Any ideas?

[RobeeJ]

Stock MAME without the hi score or groovymame patches compiles fine.

[Calamity]

Stock MAME without the hi score or groovymame patches compiles fine.

Did the patch applied fine or you had errors?

[RobeeJ]

Ah it looked like they had but there were errors at the start of the groovymame patch I missed:

Code: [Select]

[root@mame mame171-original]# patch -p0 -E --binary < ../0171_groovymame_015m.diff         
patching file 3rdparty/bgfx/include/bgfx/bgfx.h
Hunk #1 FAILED at 798 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/include/bgfx/bgfx.h.rej
patching file 3rdparty/bgfx/include/bgfx/c99/bgfx.h
Hunk #1 FAILED at 480 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/include/bgfx/c99/bgfx.h.rej
patching file 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h
Hunk #1 FAILED at 83 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h.rej
patching file 3rdparty/bgfx/src/bgfx.cpp
Hunk #1 FAILED at 2466 (different line endings).
Hunk #2 FAILED at 3779 (different line endings).
2 out of 2 hunks FAILED -- saving rejects to file 3rdparty/bgfx/src/bgfx.cpp.rej
patching file 3rdparty/bgfx/src/bgfx_p.h
Hunk #1 FAILED at 197 (different line endings).
Hunk #2 FAILED at 1327 (different line endings).
Hunk #3 FAILED at 2122 (different line endings).
3 out of 3 hunks FAILED -- saving rejects to file 3rdparty/bgfx/src/bgfx_p.h.rej
patching file 3rdparty/bgfx/src/config.h
Hunk #1 FAILED at 178 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/src/config.h.rej
patching file 3rdparty/bgfx/src/renderer_d3d11.cpp
Hunk #1 FAILED at 1102 (different line endings).
Hunk #2 FAILED at 2217 (different line endings).
Hunk #3 FAILED at 2256 (different line endings).
3 out of 3 hunks FAILED -- saving rejects to file 3rdparty/bgfx/src/renderer_d3d11.cpp.rej
patching file scripts/src/emu.lua
patching file scripts/src/osd/sdl.lua
patching file scripts/src/osd/sdl_cfg.lua
patching file scripts/src/osd/windows.lua
patching file src/emu/clifront.cpp
patching file src/emu/drivenum.cpp
patching file src/emu/drivers/empty.cpp
patching file src/emu/emu.h
patching file src/emu/emuopts.cpp
patching file src/emu/emuopts.h
patching file src/emu/machine.cpp
patching file src/emu/machine.h
patching file src/emu/render.cpp
patching file src/emu/sound.cpp
patching file src/emu/sound.h
patching file src/emu/switchres/modeline.cpp
patching file src/emu/switchres/modeline.h
patching file src/emu/switchres/monitor.cpp
patching file src/emu/switchres/monitor.h
patching file src/emu/switchres/switchres.cpp
patching file src/emu/switchres/switchres.h
patching file src/emu/switchres/switchres_proto.h
patching file src/emu/switchres/util.cpp
patching file src/emu/ui/dsplmenu.cpp
patching file src/emu/ui/ui.cpp
patching file src/emu/video.cpp
patching file src/emu/video.h
patching file src/osd/modules/lib/osdobj_common.cpp
patching file src/osd/modules/lib/osdobj_common.h
patching file src/osd/modules/osdwindow.cpp
patching file src/osd/modules/osdwindow.h
patching file src/osd/modules/render/d3d/d3d9intf.cpp
patching file src/osd/modules/render/d3d/d3dintf.h
patching file src/osd/modules/render/drawbgfx.cpp
patching file src/osd/modules/render/drawbgfx.h
patching file src/osd/modules/render/drawd3d.cpp
patching file src/osd/modules/render/drawd3d.h
patching file src/osd/modules/render/drawogl.cpp
patching file src/osd/modules/sound/direct_sound.cpp
patching file src/osd/modules/sound/sdl_sound.cpp
patching file src/osd/osdepend.h
patching file src/osd/sdl/input.cpp
patching file src/osd/sdl/osdsdl.h
patching file src/osd/sdl/sdlmain.cpp
patching file src/osd/sdl/switchres_sdl.cpp
patching file src/osd/sdl/video.cpp
patching file src/osd/sdl/window.cpp
patching file src/osd/sdl/window.h
patching file src/osd/windows/custom_video.cpp
patching file src/osd/windows/custom_video.h
patching file src/osd/windows/custom_video_adl.cpp
patching file src/osd/windows/custom_video_adl.h
patching file src/osd/windows/custom_video_ati.cpp
patching file src/osd/windows/custom_video_ati.h
patching file src/osd/windows/custom_video_ati_family.cpp
patching file src/osd/windows/custom_video_pstrip.cpp
patching file src/osd/windows/custom_video_pstrip.h
patching file src/osd/windows/switchres_windows.cpp
patching file src/osd/windows/video.cpp
patching file src/osd/windows/window.cpp
patching file src/osd/windows/window.h
patching file src/osd/windows/winmain.cpp
patching file src/osd/windows/winmain.h

[Doozer]

Hi guys, having build problems with 171 on Arch Linux, related to bgfx.

Code: [Select]

[root@mame mame171]# make
GCC 5.3.0 detected
Compiling src/osd/modules/render/drawbgfx.cpp...
../../../../../src/osd/modules/render/drawbgfx.cpp: In member function ‘virtual int renderer_bgfx::create()’:
../../../../../src/osd/modules/render/drawbgfx.cpp:135:222: error: too many arguments to function ‘void bgfx::reset(uint32_t, uint32_t, uint32_t)’
 indowed? BGFX_RESET_NONE : BGFX_RESET_FULLSCREEN) | (video_config.waitvsync ? BGFX_RESET_VSYNC : BGFX_RESET_NONE));
                                                                                                                  ^
In file included from ../../../../../3rdparty/bgfx/include/bgfx/bgfxplatform.h:14:0,
                 from ../../../../../src/osd/modules/render/drawbgfx.cpp:27:
../../../../../3rdparty/bgfx/include/bgfx/bgfx.h:801:7: note: declared here
  void reset(uint32_t _width, uint32_t _height, uint32_t _flags = BGFX_RESET_NONE);
Any ideas?

You have to issue the following command before applying the patch:

Code: [Select]

unix2dos 3rdparty/bgfx/include/bgfx/bgfx.h 3rdparty/bgfx/include/bgfx/c99/bgfx.h 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h 3rdparty/bgfx/src/bgfx.cpp 3rdparty/bgfx/src/bgfx_p.h 3rdparty/bgfx/src/config.h 3rdparty/bgfx/src/renderer_d3d11.cpp


[RobeeJ]

Thanks Doozer!

[genius77]

hi guys (sorry for my english),
I am not sure I am writing in the right place, I have problems with the new BGFX render.

I'm using Groovymame 0.171 with windows 7 and the CRT emudriver 2.0 beta8 on a 15khz arcade CRT (videocard HD7750)

When I launch a game with the new plugin I have a black screen and I can hear the sound in background that plays very very fast

I already tried the original Mame exe and the BGFX works fine.

Here in attach a couple of logs

Any suggetion will be appreciated
Thanks

[Calamity]

I am not sure I am writing in the right place, I have problems with the new BGFX render.

You can't use multithreading with the new BGFX renderer yet.

[genius77]

Oh, that's the problem||   

Thank you calamity, you are doing a great job   

[Calamity]

I think you will be interested to know I'm currently working in refactoring the GroovyMAME code for an eventual merge with baseline (partial or total, we don't know yet). My plan is to deconstruct the current patch in smaller blocks and be submitting them in gradual steps, so we make sure nothing gets broken in the process, and basic features can get isolated from the somewhat more experimental ones. First feature I'll be adding is integer scaling, which should be ready for 0.172. Next, I'd like to focus on the synchronization options. Of course, the last word belongs to the team with regards to which features get in and which don't.

[u-man]

This are great news Calamity. IMHO, i think this is the best solution. Working hand in hand, will ensure the support of CRTs for the future and there is no doubt that the GroovyMAME team and especially you, will be the best options for the official MAME dev team. Big applaud here 

Best wishes, u-man

[twistedsymphony]

I think you will be interested to know I'm currently working in refactoring the GroovyMAME code for an eventual merge with baseline (partial or total, we don't know yet). My plan is to deconstruct the current patch in smaller blocks and be submitting them in gradual steps, so we make sure nothing gets broken in the process, and basic features can get isolated from the somewhat more experimental ones. First feature I'll be adding is integer scaling, which should be ready for 0.172. Next, I'd like to focus on the synchronization options. Of course, the last word belongs to the team with regards to which features get in and which don't.

excellent news and an excellent plan.

[krick]

I think you will be interested to know I'm currently working in refactoring the GroovyMAME code for an eventual merge with baseline (partial or total, we don't know yet).

Huzzah!  Finally, a man on the inside.

[sean_sk]

Well all I can say is, it's about time.   This is great news! I'm surprised the MAME developers hadn't encouraged this sooner. I've always thought that GroovyMAME should have been the new standard for MAME.

Calamity, are you prepared to give us a little history on how this came about?

I take it then that as certain features are incorporated into mainline MAME they'll be taken out of the GM patch naturally. Do you know how long the process will take in total, obviously understanding the fact that we don't know if ALL of GM's features will be included.

[donluca]

My plan is to deconstruct the current patch in smaller blocks and be submitting them in gradual steps, so we make sure nothing gets broken in the process, and basic features can get isolated from the somewhat more experimental ones.

Good thinking.

[schmerzkaufen]

Excelent news. GM will make baseline MAME great again. 

[adder]

Calamity, are you prepared to give us a little history on how this came about?

it seemed to develop after the recent news that directdraw was to be removed from mame...... then some people at the mameworld forums were chatting about how it was a shame that directdraw allowed for integer scaling but direct3d did not, and if it was possible to see some additions to direct3d in mame to allow eg. low res crt users the option for an unaltered image (no scaling or stretching etc) displayed using direct3d

it's fantastic to hear about the exciting relations happening between groovymame and baseline mame

in other news a little sad about mameuifx though, i really enjoyed that build of mame in the past and mamesick worked hard and was commited. there's been some kind of meltdown and that mame build appears to now be dead and finished.

[donluca]

Well, it looks like MAME has gone full open source: http://mamedev.org/?p=422

[krick]

Is Groovymame's license compatible?...
http://www.mameworld.info/ubbthreads/showflat.php?Number=351062