GroovyMAME 0.171 - SwitchRes v0.015m

[minase]

Just posting for future people who have agony getting these patches to apply on a unix machine (every single hunk is rejected), since I don't see any info about this in the thread:

Code: [Select]

$ dos2unix hi_0171.diff
$ dos2unix 0171_groovymame_015m.diff
$ cd mame0171s
$ for file in `grep 'diff -Nru --binary ' ../hi_0171.diff  ../0171_groovymame_015m.diff | cut -d ' ' -f 4`; do dos2unix $file; done
$ patch -p0 -E < ../hi_0171.diff
$ patch -p0 -E < ../0171_groovymame_015m.diff

I'm not sure if this is what the --binary option mentioned in the OP is supposed to do, but it has no effect for me.

[Doozer]

Just posting for future people who have agony getting these patches to apply on a unix machine (every single hunk is rejected), since I don't see any info about this in the thread:
[...]
I'm not sure if this is what the --binary option mentioned in the OP is supposed to do, but it has no effect for me.

Hi Minase,

The subject has already been covered in previous posts. (http://forum.arcadecontrols.com/index.php/topic,135823.msg1563950.html#msg1563950)

The solution is to convert to dos format before applying the patch. The binary flag is necessary to handle the CR/LF properly.

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


[ozfalcon]

I have noticed Mame 0.172 has some Game Speed issues.
eg. Gyruss & Galaga running at ~99% (This is in Throttled mode)
I'm sure there are more games, But these are just two immediate examples.
Perhaps this was noticed/mentioned in previous posts/releases.....?


@Calamity How are you finding the changes to 0.172 - I noticed syncrefresh option has moved again....

[Calamity]

@Calamity How are you finding the changes to 0.172 - I noticed syncrefresh option has moved again....

It sounds like the announcement of MAME 0.172 mentioning GroovyMAME features being added, combined with the delayed release of GroovyMAME 0.172, has confused a few of you. Baseline MAME is NOT GroovyMAME, yet. Only feature that has been added to baseline is integer scaling, which was sort of urgent due to MAME having lost all ability to do integer scaling on non-SDL builds since the DirectDraw renderer was dropped in 0.171.

[schmerzkaufen]

That's incredible, seriously I don't know what people read, because of some post on MW (not even saying that) it even made the news on some emu-centric websites that all GM features have already been ported to baseline and GM was therefore discontinued.
I guess that's from people who don't know about things like SwitchRes+MT/frame_delay/D3D9ex and their benefits, they don't realize baseline is inferior to GM in that area because they've never tried/understood.
(I admit it took me a while to realize, but you would expect websites and communitites dedicated to emulators to show at least a bit more knowledge than the average newb)

[ozfalcon]

What are you talking about relating to my post.

AT NO POINT DID I INFER ANYTHING ABOUT GROOVYMAME BEING INCLUDED IN MAINLINE MAME.
Thanks for reading.
<Rant off><This does not preclude some war of words>

I was asking "How are you finding the changes to 0.172" - Internal function call names etc.

[schmerzkaufen]

Huh? Personally I wasn't reacting to your post, just commenting on that wrong info circulating. Peace! 

[ozfalcon]

Yeah, Sorry - Didn't mean to charge in guns blazing.
Calamity just miss-interpreted my post by the looks of it.

<Added>
I'm not waiting for GroovyMame (Though I am interested to see some of the code changes).
But in light of some people thinking GroovyMame had been merged into Mainline - I see why Calamity might think that.

[Calamity]

No problem, I assumed you thought the merge was complete. Anyway, I'm not sure what changes you mean about syncrefresh, as far as I can see it's in the same place it was previously, and functionality is still the same (broken).

[ozfalcon]

Just had a look, Yes no change there as you remove it from osd & put it in emu.
But it was previously available through machine options, And that is no longer the case.
 

[Calamity]

Just had a look, Yes no change there as you remove it from osd & put it in emu.
But it was previously available through machine options, And that is no longer the case.

It's interesting that you mention that, since the other day I was trying to refresh my memory regarding the syncrefresh patch prior to push it to baseline, and I remind your old post mentioning you could access it through core machine options, which didn't work for me the other day, and I wonder at what point this changed.

[ozfalcon]

Not sure, I was thinking of going back in builds (Mame) to find when it changed.
Though for the AudioSync patch, It's not actually required (syncrefresh) to be able to operate correctly.


For anyone that wants to experiment with the standalone AudioSync Patch or use it for reference.
Also here is the HidePointer patch which applies to SDL branch only.

Special Note:
These patches were built from Linux. They will probably not apply cleanly from Windows.
However they are SO SIMPLE, You can manually type the patches into the source code & compile it.

The patches are numbered in order of application, The HiScore patch is the same patch available by MK_Champ.

[Andypc]

Is there any news on Groovymame 0.173. I haven't updated for a while, can I still stick with the old ctr_emu drivers and just upgrade groovymame.

Also is the soundsync patch now working again? I had problems with it since 0.146 on my non groovymame setup.

http://forum.arcadecontrols.com/index.php?topic=122814.0

[haynor666]

I'm not sure if soundsync was ever used in grooymame but we have better replacement - syncrefresh which works great till 171.

[Andypc]

What happened in 0.172.

Does the Groovymame 0.171 build on the website contain Mess, i.e. what was groovyUME or is it just the arcade build.

[ozfalcon]

I'm not sure if soundsync was ever used in grooymame but we have better replacement - syncrefresh which works great till 171.

Yes the SoundSync patch is used in GroovyMame, There are no problems that I am aware of (Still works for 172 & 173).

GroovyMame 0.171

Code: [Select]

@@ -1077,6 +1104,9 @@
  osd_ticks_t tps = osd_ticks_per_second();
  m_speed_percent = delta_emutime.as_double() * (double)tps / (double)delta_realtime;
 
+ if (m_syncrefresh && m_throttled)
+ m_speed = m_speed_percent * 1000;
+
  // remember the last times
  m_speed_last_realtime = realtime;
  m_speed_last_emutime = emutime;


The main change from 0.156+ comes from SDL2 being asynchronous.
What this means for SDL2 users is that the Mame option WAITVSYNC now acts in a similar way to SYNCREFRESH.
All SDL2 frame writes are automatically synced (No tearing)
And the Mame option SYNCREFRESH is redundant (Correct me if I'm wrong).

[ozfalcon]

Also is the soundsync patch now working again? I had problems with it since 0.146 on my non groovymame setup.

http://forum.arcadecontrols.com/index.php?topic=122814.0

At your CabMame thread link.....
CabMame 0146_emuspeed.diff

Code: [Select]

diff -ruN ../mame/src/emu/machine.h ./src/emu/machine.h
--- ../mame/src/emu/machine.h 2012-04-22 07:07:48.000000000 +0200
+++ ./src/emu/machine.h 2012-09-05 19:42:05.000000000 +0200
@@ -310,6 +310,8 @@
  debugcpu_private * debugcpu_data; // internal data from debugcpu.c
  generic_machine_private *generic_machine_data; // internal data from machine/generic.c
 
+ double speed_percent; // most recent speed percentage
+
 private:
  // internal helpers
  void start();
diff -ruN ../mame/src/emu/video.c ./src/emu/video.c
--- ../mame/src/emu/video.c 2012-04-12 09:35:58.000000000 +0200
+++ ./src/emu/video.c 2012-09-05 19:42:05.000000000 +0200
@@ -995,7 +995,8 @@
  osd_ticks_t delta_realtime = realtime - m_speed_last_realtime;
  osd_ticks_t tps = osd_ticks_per_second();
  m_speed_percent = delta_emutime.as_double() * (double)tps / (double)delta_realtime;
-
+ machine().speed_percent = m_speed_percent;
+
  // remember the last times
  m_speed_last_realtime = realtime;
  m_speed_last_emutime = emutime;

As you can see (To the previous post) the SoundSync code.
So your issue with sound being all over the place will still be present (I'd guess).

Just to note, I had TERRIBLE results using AMD CPU's with Syncrefresh (& SoundSync Patch) ---> EMU speed was all over the place AND Sound followed suit!.
So I ALWAYS stick to Intel when using Mame & Syncrefresh now.
Others seem to have no problems using AMD.....?

The only other time I have had erratic EMU speed was with both Throttle & Syncrefresh enabled, But that was on a SDL/Linux build - Not a windows OS.
(I'm guessing that Throttle adjusted to 100% speed then Syncrefresh adjusted to Refresh speed and it bounced between them causing erratic EMU speed)



Also, This osd "WINDOWS" code was no longer included in GroovyMame from 0.145 onward (While still being present in CabMame 0.146)

Code: [Select]

@@ -203,6 +205,13 @@
  if (stream_buffer == NULL)
  return;
 
+ // if we are active, update the sampling frequency
+ if (g_current_machine->speed_percent > 0.0f && g_current_machine->switchRes.cs.soundsync)
+ {
+ IDirectSoundBuffer_SetFrequency(stream_buffer,
+ g_current_machine->sample_rate() * g_current_machine->speed_percent);
+ }
+


[roccias]

I'm using groovymame 0.171 Asio4all and I saw in the first page of this post that there 2 patches
1) hi_171.diff
2) 0171_groovymame_015m.diff

What are they ?  And where I have to put it...

Thank you

[u-man]

Those are .diff files and they are needed, if you want to compile GroovyMAME for yourself. The files maybe work even with MAME 0173 source, but i cant tell for sure, because i didnt test it on my own.

[roccias]

Ah, ok. Thank you U-man

[roccias]

Hi, I need another advice if it is possible.   How I have to set in Mame.ini the parameters  multithreading and resolution ?

multithreading  0 or 1 ?

resolution  2560x0  or  2560x0 cleanstretch 2? 

[schmerzkaufen]

0.174 ?

[tom5151]

Hi all,
I'm wondering if we will have a new version of GM or if we're going to be stuck on 171 version?
If it's possible to have some clarifications on what's going on, it would be fine.
Thanks in advance.

[pelanas]

I'd like to see a new version too... because pc2jamma has been fixed in 0.174 and must work again with no need of specific option compilation! It was broken since 0.160.

[premuto]

mame go 174.

GM no update???

[u-man]

This is what Calamity wrote in MAMEworld a view days ago:

Wow, this is crazy.

I'm alive, and working 60 hours per week. I'm currently just able to check BYOAC and the mailing list while on the toilet. Sorry, I should have provided some proof of life.

GM had development stalls in the past, it just wasn't so obvious because the update policy of mainline was different. A big overhaul like the ones required for the rewrites of Switchres (version 14 & 15), took me 10-15 days of full-time coding and testing each.

Unfortunately the industry I work in has no predictable holidays and has nothing to do with coding. I can only do serious coding work when my real work load is low enough. A different matter is mantaining a diff in sync with mainline that usually takes me 3-4 hours per month.

Please consider the fact that I recently released CRT Emudriver 2.0 (January 2016). This thing took me a full month of work between Windbg (reverse-engineering of Catalyst), VMMaker/Arcade OSD, GroovyMAME update and beta testing. Well, the point is that I had the whole concept ready in March 2015, but I had to wait for 9 months until I had the time to implement it. I could be implementing the same over the Crimson driver already to support bleeding edge cards but I simply can't afford taking a free month so often.

The possibility of merging GM into mainline is the best thing that could ever happen to GM, devs attitude has been totally receptive, so please be patient and let me do things right.

So all you need is to chillout. What would you do, after a 60hours week? GM is not dead, he will come back, just leave him time. All this hunt for the newest is not healthy anyway . There is not much interesting for GM since 0171, consider that too.

[sean_sk]

So all you need is to chillout. What would you do, after a 60hours week? GM is not dead, he will come back, just leave him time. All this hunt for the newest is not healthy anyway . There is not much interesting for GM since 0171, consider that too.

I completely agree with this. It would be best to stop inundating this thread with questions regarding when GroovyMAME 0.174 will be ready, since it is quite likely there won't be a GM 0.174.

As Calamity stated, GM has had development stalls in the past, sometimes many months apart, but they weren't as obvious because mainline MAME wasn't being released on a monthly basis as it is now and, therefore, no one cared. Don't forget that the differences between each monthly update is relatively incremental compared to those that used to occur between each of the major version releases under the old release schedule, and quite frankly there is little benefit to updating to 0.174, so stick with GM 0.171 and be patient.

[big10p]

I've never understood why some people think they positively have to have the latest version of MAME in general. I'm just thankful we have GroovyMAME at all! If Calamity is taking a break away from it for a while, I think that sounds like a good idea, as it sounds like he's super busy at the moment. Don't burn yourself out, Calamity! 

[RobeeJ]

I think all anyone wanted to know was that GM wasn't dead, I don't think people mind about being a few versions behind, it certainly isn't ruining my regular Rainbow Islands sessions.

I keep meaning to sort out my vector mod, but coding for a living really makes it hard to want to code at the weekends too, so I completely sympathise with Calamity (even if he isn't coding during the week!).

[sean_sk]

I think all anyone wanted to know was that GM wasn't dead

Good point, although I don't think Calamity is the type of guy that would step away from GroovyMAME without letting everyone know as evidenced by the care he has shown towards the project and the community that use it.

[planexcvs]

In the meantime, would anyone know offhand what it would take to update the 0171 diff file to make it patchable with the latest MAME source?

[krick]

In the meantime, would anyone know offhand what it would take to update the 0171 diff file to make it patchable with the latest MAME source?

If it was easy, Calamity would have already done it.

[planexcvs]

Nevermind, figured it out...unified diffs.

If it was easy, Calamity would have already done it.

It's not difficult. It is time consuming though, but straightforward.

Once I get done with the changes and testing, I'll either share a diff or just the whole binary.

[cools]

Just wanted to say thanks again to Calamity for all the work on GM. Picked up an Atom based Windows tablet recently and found MAME normal was a bit hit and miss, stuttering for no good reason. Groovy sorted that out without any fuss, and enabling multithreading seems to help even more. 

[planexcvs]

Nevermind, figured it out...unified diffs.

If it was easy, Calamity would have already done it.

It's not difficult. It is time consuming though, but straightforward.

Once I get done with the changes and testing, I'll either share a diff or just the whole binary.

Ok, I was wrong. I take back what I said. This commit pretty much puts my plans in a bind: https://github.com/mamedev/mame/commit/852bd80d455c46a066fa4f1e6267f679b0096231

It's looking like they're killing off d3d9 with that? I guess BGFX from now on.

[schmerzkaufen]

Mmh, looks like things are getting complicated. Does that include D3D9ex ?

Slightly different topic: would you know if porting back the integer scaling feature Calamity created for standard MAME... to GM 0.171, would be doable ?

I don't know if it exists as a patch or something (?)

[haynor666]

It was only a matter of time. Sadly this commit will cause much problems with Groovymame

[nexusmtz]

Ok, I was wrong. I take back what I said. This commit pretty much puts my plans in a bind: https://github.com/mamedev/mame/commit/852bd80d455c46a066fa4f1e6267f679b0096231

It's looking like they're killing off d3d9 with that? I guess BGFX from now on.

The comment on the commit says:
Remove Direct3D abstraction layer
It was introduced to support Direct3D 8 and 9 with the same code base...

I read that to mean that the code being removed took care of the differences between d3d8 and d3d9, and since d3d8 has been gone for some time, the extra layer isn't needed. Employing an abstraction layer when there's only one target left is kind of like employing a translator who only remembers one language.

If it makes you more comfortable, the extra code is gone from mame175, but you can see below that d3d9 is not:

Code: [Select]

H:\games\mame0175b_64>mame64 dkong -video d3d -v
Video: Monitor 00000000003c3ec8 = "\\.\DISPLAY10" (primary)
Direct3D: Using Direct3D 9

[u-man]

Thats exactly what happened. No reason to panic. There are plans to remove DirectX9, but this will happen maybe in a year or two and maybe not at all .