GroovyMAME 0.227 - Switchres v0.017t

[K-rnivoro]

Just in case it can help somebody:

I had my cab running fine with GM .178 and CRT 2.0 Beta 8. After upgrading CRTE to Beta 15, Progressive modes stop working in GM .178 (out of sync picture). The lowest version of GM working is .183.

So I decided go all the way to .213 now, thing is: Do I have to get all roms from .213 version again, and do some housekeeping of my own? I  have already detected several roms not working with .213

Or there is a way to use newest GM with old roms collection?

[PL1]

So I decided go all the way to .213 now, thing is: Do I have to get all roms from .213 version again, and do some housekeeping of my own? I  have already detected several roms not working with .213

Or there is a way to use newest GM with old roms collection?

At a minimum, you'll need to replace ROMs/drivers/CHDs that have been re-dumped/re-named/changed since the old ROMset.
- There have been a lot of changes between 0.178 and 0.213.
- There's no way to use re-dumped/changed (obsolete) ROMs with a newer version of MAME.
-  If the difference is that the filename(s) have changed, you might get it to work by changing the name of the ROM .zip file and/or the filename(s) inside the .zip.   


Scott

[K-rnivoro]

That´s what I thougt. ClearMAMEPro can find those renamed roms insides zips, if they are the same,  but is not able to "change" it to the newest dump of course.

[schmerzkaufen]

Note to the general ; I did mention on the previous page that the PC performance requirements seemed to have jumped up starting from 0.206, and well, my usage of Groovy has been very spotty this year so I haven't tried every month's update, but at some point the trend seemed to have inverted at least on my main PC (as opposite to my laptop)

And so currently with 0.213 it seems that I actually get better results, like I can afford higher frame_delay levels with close to no-tearing, and when I do get some I don't have to apply as much vsync_offset as even pre-206 (except when I use HLSL of course)

So I don't know what happened at the 'lab' nor from which build exactly the shift happened, but it works better now anyway on my main emulation rig.

The only difference is that I need to have the following off permanently;

Code: [Select]

sleep                     0Otherwise I get framerate instability (oscillating between 99%,100%,101%)

Note: this is without using portaudio.

[Doozer]

I have uploaded the GM 0.214 Linux binary on the google drive. Enjoy!

[b4nd1t0]

Thanks Doozer, the patch is the same of 0.213?

Inviato dal mio EML-L09 utilizzando Tapatalk

[Doozer]

Thanks Doozer, the patch is the same of 0.213?

Inviato dal mio EML-L09 utilizzando Tapatalk

Yes, it is based on 017o.

[dilarconon]

I have triplebuffer and waitvsync off on mame.ini:



but for some reason GroovyMAME does not honor them:



They properly say "SwitchRes: Setting option -notriplebuffer" and "nowaitvsync" in the console when I use "-notriplebuffer -nowaitvsync" in the command line.

Am I doing something wrong?

[Calamity]

GroovyMAME 0.214 is out!

[Substring]

New MAME release ! 0.215 is out !

32bits users say your prayers, 0.217 should be the last build supporting 32bits. After, it won't be maintained. Read the obituary here

[schmerzkaufen]

We’ve updated bgfx, adding preliminary Vulkan support.

Isn't that good news ?

[Substring]

preliminary good news you mean ? 

[schmerzkaufen]

Well ^^ by mamedev standards something like that happens only every 5~10 years or so, even 'preliminary' is news.

Anyway I seem to recall Calamity saying this could be useful Groovy-side.

[donluca]

Doesn't this:

MAME 0.217 will be the last release with pre-built 32-bit Windows binaries supplied. Starting in 2020, you’ll need to compile MAME yourself if you want a 32-bit version. We’ll still support building for 32-bit architectures, but optimisation for 32-bit x86 will not be a priority.

mean that as long as you compile MAME yourself you can have MAME on 32-bits for as long as you want?

[Substring]

indeed, but they won't focus on optimizing 32bits code. New code could be 64bits only one day or another.

[donluca]

You've got it the wrong way.

You'll always be able to compile it on 32-bit platforms (the post states this and even says it will *support* the possibility of building it on 32-bit platforms) but the "optimization" part refers to make the code run faster by using modern CPU features.

That is, as newer CPUs come out, MAME will take advantage of newer architectures/functions they can offer while 32-bit versions won't. That's all.

EDIT: this is to address a statement made in the other thread here: http://forum.arcadecontrols.com/index.php/topic,154799.200.html

So if someone wants they can go and still compile newer MAME versions on 32-bit.

[Calamity]

GroovyMAME 0.215 is out!

-------------

I'd like to say sorry for my lack of support on the forum during the last months. I have nearly no free time lately to focus on answering questions. So sorry if you have posted any question that went unanswered. Fortunately there are some power users here doing a very good job on providing support, thank you for this.

With regards to XP builds, by reading this post it looks like they're not going to be possible starting from 0.216. This means that even if you build for 32 bits, the exe won't work on XP, because the minimum supported compiler will be GCC 7.2 and XP builds require GCC 5.3.

This makes me wonder whether my 64-bit builds labelled as -xp do actually work on Windows XP-64, since I've been using GCC 8.3.0 for some time already. To be honest I don't test on XP anymore. Does anyone use them?

The possibility to build for XP was the only reason to keep the D3D9ex patch separated from GM's patch. I guess I'll keep both separated for a few versions yet in case someone figures out how to build for XP, but I won't be providing the XP build anymore, in order to simplify my monthly build job.

Even Windows 7 is fastly becoming obsolete, and we should already be using 10 when possible. Specially LCD users that want to benefit from the new renderers available.

[schmerzkaufen]

we should already be using 10 when possible. Specially LCD users that want to benefit from the new renderers available.

Could you please tell more on that topic ? does that work just as well with frame_delay, same refresh/sync & lag performance ?
Do we still use d3d9ex for it or if we don't what's up configuration-wise ? still need directx9.0C redistributable ?

I have zero experience using Groovy with W10, only W7+d3d9ex.
10 seems to always mean trouble like this: http://forum.arcadecontrols.com/index.php/topic,160829.0.html
And not just that I've read about other annoyances but that doesn't seem compiled anywhere for information AFAIK.

I can still use my 7 Pro licence to switch to 10 before January, but I don't want to do that if there's anything I will lose in terms of quality/performance for my Groovy experience.

I'd like to say sorry for my lack of support on the forum during the last months. I have nearly no free time lately to focus on answering questions. So sorry if you have posted any question that went unanswered. Fortunately there are some power users here doing a very good job on providing support, thank you for this.

Really missing you around here indeed, it's like the project was lowkey-suspended for a year, there are some questions only you can answer well. Hope you'll find more time in the future! 

[RobeeJ]

I'd like to say sorry for my lack of support on the forum during the last months. I have nearly no free time lately to focus on answering questions.

I'm sure I speak for nearly everyone when I say we are super grateful for any time you spend, it's not as if anybody pays you for your generosity in maintaining GroovyMAME! You have nothing to apologise for!

[haynor666]

GroovyMAME 0.215 is out!

I'd like to say sorry for my lack of support on the forum during the last months. I have nearly no free time lately to focus on answering questions. So sorry if you have posted any question that went unanswered. Fortunately there are some power users here doing a very good job on providing support, thank you for this.

No problem at all. Thanks for everything You did so far

With regards to XP builds, by reading this post it looks like they're not going to be possible starting from 0.216. This means that even if you build for 32 bits, the exe won't work on XP, because the minimum supported compiler will be GCC 7.2 and XP builds require GCC 5.3.

User fdv reported that from some time there is error "dwmapi.dll is not found". Personally I've compiled x32 build with 5.3 for XP compability but looks like at least my builds are not usable from some time on XP x32.

This makes me wonder whether my 64-bit builds labelled as -xp do actually work on Windows XP-64, since I've been using GCC 8.3.0 for some time already. To be honest I don't test on XP anymore. Does anyone use them?

Not me for sure 

The possibility to build for XP was the only reason to keep the D3D9ex patch separated from GM's patch. I guess I'll keep both separated for a few versions yet in case someone figures out how to build for XP, but I won't be providing the XP build anymore, in order to simplify my monthly build job.

Even Windows 7 is fastly becoming obsolete, and we should already be using 10 when possible. Specially LCD users that want to benefit from the new renderers available.

For arcade PC I personally prefer striped a bit windows 7 as is easier to shut down some not needed services (like windows update) and it is less memory hungry.

For the XPx64 users - it was the smallest group here I think. Your builds were available either for windows 7x64 with D3D9ex (so not working on XPx64) or generic x32 build (works probably but does not use x64 possibilities on XPx64) and nobody complained.

[Calamity]

Could you please tell more on that topic ? does that work just as well with frame_delay, same refresh/sync & lag performance ?
Do we still use d3d9ex for it or if we don't what's up configuration-wise ? still need directx9.0C redistributable ?

Nothing still compares to frame delay, except VRR monitors.

But in order to port frame delay to the new renderers (bgfx backends, instead of d3d9ex), we'll probably need a feature that's only present in Windows 10: independent flipping.

[schmerzkaufen]

Ok thanks I definitely wanted to know if there was something like that on the way. I'll wait until that becomes a reality before switching to 10.

But IIRC you were also saying once that would this work, then something like Vulkan would solve the current higher-lag issue with BGFX or something ?

[pmc3]

With regards to XP builds, by reading this post it looks like they're not going to be possible starting from 0.216. This means that even if you build for 32 bits, the exe won't work on XP, because the minimum supported compiler will be GCC 7.2 and XP builds require GCC 5.3.

This makes me wonder whether my 64-bit builds labelled as -xp do actually work on Windows XP-64, since I've been using GCC 8.3.0 for some time already. To be honest I don't test on XP anymore. Does anyone use them?

The possibility to build for XP was the only reason to keep the D3D9ex patch separated from GM's patch. I guess I'll keep both separated for a few versions yet in case someone figures out how to build for XP, but I won't be providing the XP build anymore, in order to simplify my monthly build job.

For info

for MAME:
Gcc 7.2 on XP = false
Gcc 7.2 on 7 and up = 32 bits (with XP compatible)
Gcc 7.4 on 7 and up = 32 bits (7 and up compatible)
Gcc 8.x = 64 bits only

so, MAME work on XP (again and as long as gcc7.2 is supported), tested by me.

+++

[donluca]

Thanks for testing, looks like Windows XP is still an option after all, although I admit I'm more curious to see if it works on something in between windows xp 32-bit and windows 7 64-bit like Windows 2003 64-bit.

Is GCC 8.x required to compile 64-bit MAME binaries?

[pmc3]

Thanks for testing, looks like Windows XP is still an option after all, although I admit I'm more curious to see if it works on something in between windows xp 32-bit and windows 7 64-bit like Windows 2003 64-bit.

Is GCC 8.x required to compile 64-bit MAME binaries?

No.

For resume (and for MAME project):

Buildstool v3 (gcc 7.2) work on 32 (xp compatible) and 64 bits.

Buildstool v4 (gcc 7.4 / gcc 8.x) work on 32 (7 and up compatible) and 64 bits (7 and up).
To create 64bits builds with v4, only gcc8 is offered.

The mameteam stated that the minimum (for compile mame) supported was gcc 7.2.

[donluca]

Thanks for clarifying that.

Hopefully they won't drop gcc7.2 anytime soon.

[wflimusic]

Mame Dev put out a 32bit build for .215. Any chance of getting a Windows .215 32bit Groovy version added to the repository? Marp/wolfmame's last 32bit version was for .193 back in February.

[Sociopathos]

So, MAME 216 just got released, and there's a new feature called low latency, does this have the same effect as using D3D9 Ex? Thanks.

[Calamity]

What's new in Switchres v0.017p (November 2019)

- Updates code since some of the low latency modifications have now been pushed to baseline. There's a new option -lowlatency, enabled by default in GM, that is required by -frame_delay to work.

- (Windows) Dropped modification introduced in v0.017o to reduce input latency in BGFX, because it causes speed issues on Windows 7.



About the new -lowlatency option.

MAME now includes the new option -lowlatency (-lolat). This means that some of the modifications that have been part of GroovyMAME's low latency features are now officially included in MAME. The technical details are explained on MAMEdev's github site.

I'd like to thank Oomek for donating one of his prototype G.I.L.T devices for these tests that was essential to prove the effectiveness of this feature.

If you own a VRR monitor (either Freesync or G-sync), now official MAME's input latency will be exactly as low as GroovyMAME's, virtually matching original hardware behaviour in many cases. Unlike -frame_delay, -lowlatency has no performance penalty.

This new feature won't change input latency on GroovyMAME at all, compared to previous versions, since it was already included in GM before. You only need to make sure the option -lowlatency is enabled, which is by default in GM's generated ini. But take care to update at least your old mame.ini, because failing to have this option enabled will indeed cause a latency penalty since now this feature is optional, while before it was always on.

In the context of non-VRR monitors, the biggest part of input latency is caused by v-sync. VRR monitors don't need v-sync, so they're free of this problem. For this reason on VRR monitors, -lowlatency is enough to get latency as low as it gets.

On the other hand CRT screens and traditional LCDs require v-sync for acceptable results. The latency that's specific to frame buffering associated to v-sync can't be removed by the -lowlatency option. In order to remove it, in addition to -lowlatency you need to keep using -frame_delay, as usual. Now, the difference now is that unless you have -lowlatency enabled, -frame_delay won't have the desired effect, so please pay attention to your setup if you're upgrading.

In short, for low latency, use the following:

- VRR (Freesync or G-sync): official MAME -lowlatency
- CRT or traditional LCD: GroovyMAME -lowlatency -frame_delay #

For VRR, official MAME is simpler to use. You can achieve the same results on VRR with GroovyMAME too, but you need additional config, like this: GroovyMAME -monitor lcd -lowlatency -noautosync (or -nowaitvsync, notriplebuffer, nosyncrefresh).

[pmc3]

Mame Dev put out a 32bit build for .215. Any chance of getting a Windows .215 32bit Groovy version added to the repository? Marp/wolfmame's last 32bit version was for .193 back in February.

http://www.emu-france.com/emulateurs/305-multi-systemes/306-multi-emulateurs/4246-groovymame-x86/
http://www.emu-france.com/emulateurs/305-multi-systemes/306-multi-emulateurs/7461-groovymame-d3d9ex-x86/

http://www.emu-france.com/emulateurs/305-multi-systemes/306-multi-emulateurs/4245-groovymame-x64/  (groovy64 without d3d9ex)

[Recapnation]

Are they trying to simulate an interlaced display now (but just for Popeye?)?

  - There are now three rendering modes selectable via machine config:
  - false progressive: same as before.
  - Interlaced (scanline skip): only the current field is drawn with
    the other field's scanlines blacked. This gives the same flickering
    impression as interlaced display.
  - Interlaced (bitmap): Bitmap is constructed from odd and even fields.
    Result is comparable to PAL/NTSC videos played back on progressive
    displays without additional processing.

https://git.redump.net/mame/commit/?id=069da107280ede7d0efcd5339d705eb1adbbc2c2

[Substring]

just for popeye

[Recapnation]

I'm really curious as to how "scanline skip" looks. Just can't believe the effect is bearable for anybody. Nor the "bitmap" method, for that matter, assuming they're halving the resolutions.

And then, they should also explain why is this only in Popeye. But hey.

[Substring]

That could be because the original hardware had several renering methods deopending on versions, bootlegs or god knows what else

[Recapnation]

Nah. The original hardware is from 1982; they only had one way to display hi-res graphics. This is just MAME acknowledging in freaking 2019 that interlaced display was a thing, but still not giving enough of a ---steaming pile of meadow muffin--- about it.

[Substring]

Then why add this to a single machine ? One of the code comments states :

+       Worth noting that there are at least 3 different types of picture output
+       for this game - and it will be difficult to make it match 'everything' out there.
+      1) Normal Nintendo board - inverted video output
+      2) Normal Nintendo board with non-inverted video output - has potentiometers to adjust R/G/B
+      3) Bootleg board, non inverted non adjustable output

As I understand it, they are just trying to reproduce some different hardwares. But I may be wrong.

[Recapnation]

Well, none of the new rendering modes is trying to simulate inverted/non-inverted RGB, that's for sure.

[u-man]

Recapnation nailed it absolutely. It is sad to say, but MAME devs have zero knowledge how and what interlace really means. I tried many times to explain them, but i am not a trusted person, because i can not code a thing, beside that i have worked in a broadcaststation for 3 years, at a time where CRTs where the only thing, you can view a picture on.

Even more sad is:
1.) to read here what they plan on github for Popeye. These clearly indicates that they have no clue.
2.) a hundred times i tried to explain them, that if you make a progressive image out of interlaced material, that this is a destructive process and that you can not revert this anymore. So you will lose the information, that initially was there.

This means you only have TRUE interlaced material, if you have recorded (or created) it initially, but in MAME devs eyes (thats also what you can read on github), interlacing is just a flickering and annoying stuff. They dont see 60FPS AND double resolution. Yes, you possibly can have flicker, especially on high contrast areas, like black typo on white background will flicker, but if you do properly care about the image, it wont flicker. Stuff in motion (i.e. racing games) you will not see flicker anyway. Only on still frames it is clearly visible. Off course it is impossible to properly display interlaced stuff on normal modern LCD monitors. You need to blend that stuff before and make it progressive, which MAME do. But MAME is not capable to create interlaced pictures initially and that is a problem for every CRT user here, as you dont get a picture like it was on original hardware.

Interlacing was absolutely genius when it was invented, effectively doubling the temporal resolution while minimally effecting the spatial resolution and reducing phosphor flicker and that for nearly 60 years and yet even Linus on Youtube understands and explains this better, than any person of the MAME dev team.

The only hope is Calamity again, who can hopefully explain them, that interlaced is not pure BS. I mean seriously, elsewise they are sooooo picky about every single hack-stuff and what not and send those stuff to hell. They claim they are sooooo accurate and emulation is 100% and blah blah blah. But interlacing is some magic thing to them.... it would be really funny, if it would not be so sad 

[Recapnation]

Being honest, I personally have never liked interlacing in video games, and always thought that stuff such as Popeye could have looked better if designed as progressive low-res games. Especially stuff like Popeye, which makes use of so many upscaled low-res graphics due to memory constraints, should I say. More detail serves very little when your eyes need to accomodate to flickering and whatnot. The industry soon abandoned this approach in favour of progressive low-res for a reason. (But yeah, in scrolling racing games it should be more palatable.)

Said that, it's quite a shame how MAME has been ignoring the display subject in general. Not unexpected, but still a shame. There's not much they can do to simulate interlacing (and that's why it comes off so surprising (lame?) they're trying it with these new rendering modes in this day and age), but at the very least, this should be already well documented, and having it just for Popeye is misleading. You're wrong regarding GM and CRT usage, though (unless I'm not following you) -- thanks to MAME's design we can use interlacing wherever we want with a 15-kHz CRT, so it's really up to the user and his hardware.

[u-man]

Maybe i was not clear enough regarding interlace. It does not really help, that we can use interlace wherever we want in MAME, because official MAME outputs only progressive Frames. So if a game has originally interlaced output, MAME will change that to progressive output and once this is done, you cant revert that process without losing the data that once where there. You can take that progressive output off course and make it interlace, but the output will never look like the original interlaced output, especially everything that has motion in it.

I hope you understand now, what the real problem is.