Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news


  

Author Topic: GroovyMAME 0.206 - Switchres v0.017n  (Read 134986 times)

0 Members and 1 Guest are viewing this topic.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #840 on: December 28, 2018, 09:57:09 am »
GroovyMAME 0.205 is out!

What's new in Switchres v0.017m (December 2018)

- Added feature to autosave UI sliders to make frame delay in-game adjustments non-volatile.

- (Windows) Added capability to toggle frame delay from the UI.

- (Windows) Preliminar work on modifications to the frame delay implementation to improve its accuracy.

- (Windows) Temporarily dropped BFGX support due to upstream overhaul.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

dilarconon

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • I want to build my own arcade controls!
Re: GroovyMAME 0.204 - Switchres v0.017l
« Reply #841 on: December 28, 2018, 10:12:10 am »
Hmm...your settings seem to indicate you mistake frame_delay for run-ahead, but they're not the same thing.

Also more importantly I believe if you have a G-Sync or FreeSync monitor you don't need lag reduction features such as these to get the minumum lag MAME can produce anyway.
Normally you just play without any vsync feature on and you're set, the games should play with a refesh speed and delay equal to the original hardware+game program's intended*, and without tearing.
That's the point of these nVidia and AMD technologies (and also HDMI 2.1 VRR afaik)



*As far as MAME drivers accuracy go individually, of course (some drivers require the intervention of other software included in MAME that might add a thread and/or frame on top, which is also why in theory multi-core CPU should provide an advantage in response)

Is it? I was under impression that d3d9ex reduces some.
So if I arleady have gsync with the right Nvidia configuration, GroovyMAME has no improvements on input lag?

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #842 on: December 28, 2018, 11:08:01 am »
Calamity will correct me if I'm wrong but IIRC roughly;
  • D3D/OGL/BGFX with vsync : add 2~3 frames on top of the game's original delay (not sure in regards to SDL)
  • ddraw/D3D9ex with vsync : add only 1 frame (nb: ddraw isn't supported in all OSes and was even dropped, I think)
  • D3D/D3D9ex with vsync and frame_delay : add only a fraction of 1 frame, depending on the setting (frame_delay level 1 is like doing nothing or just using d9d9ex w/out frame_delay, then the higher the setting the more of that 'last frame' you conquer, but level 9 is pretty heavy on the CPU/GPU of your PC so most ppl at best go up to 8 and that depends on the game of course, you don't get that far over a very demanding 3D game)
Then logically;
  • D3D/OGL/BGFX/D3D9ex without vsync : no frames added on top of the game's original delay (but there'll be tearing unless you have G-Sync/FreeSync or equivalent)
EDIT: though this thread suggests that even without vsync there are differences: http://forum.arcadecontrols.com/index.php?topic=153434.0

Now whether you have an advantage running GroovyMAME over baseline MAME for lag in this (your) case I'm not sure...
To activate the proper real refresh rates and speed in baseline MAME you need to turn the switchres option on (1), and if things work as they should with G-Sync/FreeSync activated then you should get what you want.
I'm not certain there aren't other things to set to achieve this properly in baseline MAME, since I haven't tried that myself with an actual G-Sync/FreeSync setup but rather an 'unlocked' monitor which supports all kinds of refresh rates, so it didn't go well and still required me to use the syncrefresh, which in principle unlike waitvsync should force MAME and the monitor to run at the game's refresh without tearing nor added lag (reminder: if switchres is on). Even so it wasn't perfectly smooth.
With my monitor for doing that GroovyMAME with frame_delay works better, but again my setup is not like your setup.

The reason we don't speak much about G-Sync and FreeSync here is because GroovyMAME's or RetroArch's options related to lag and smoothness, are made for people who don't have G-Sync/FreeSync.
Now the latter aren't all perfect either from what I've heard.

It'd be useful maybe to start a dedicated thread to discuss the branded nVidia/AMD variable refresh topic, unless there's already one somewhere?
« Last Edit: December 28, 2018, 12:35:25 pm by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #843 on: December 28, 2018, 12:40:07 pm »
I've noticed that the new frame delay slider breaks hlsl, please be aware. I'll work on a fix.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #844 on: December 28, 2018, 12:56:18 pm »
Development sounds like playing a whack-a-mole game except it's in code.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 384
  • Z80 ERROR
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #845 on: December 28, 2018, 03:27:23 pm »

- Added feature to autosave UI sliders to make frame delay in-game adjustments non-volatile.

- (Windows) Preliminar work on modifications to the frame delay implementation to improve its accuracy.


I assume the autosave UI sliders is also working for Linux users, am I right? (I am currently building GM)

What is the frame delay implementation you are working on? Is it really limited to Windows only?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #846 on: December 28, 2018, 05:06:11 pm »
Hi Doozer,

I assume the autosave UI sliders is also working for Linux users, am I right? (I am currently building GM)

Yeah, that part is OS independent, so everything should work just the same.

Quote
What is the frame delay implementation you are working on? Is it really limited to Windows only?

I'd like to improve the alignment of the theoretical frame delay values with the corresponding scanline numbers. This is a required first step to an eventual auto frame delay feature.

Unfortunately on the Linux side, as we discussed, we don't have access to scanlines, so the implementation will need to achieve the same with timers (which probably requires someone smarter than me).

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #847 on: December 28, 2018, 05:08:28 pm »
Development sounds like playing a whack-a-mole game except it's in code.

Fortunately the issue easy to solve, I just regret not having tested the damned shaders before uploading the builds.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Heian_Shodan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 14
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #848 on: December 28, 2018, 05:27:10 pm »
So, for some reason, I no longer can use frame delay with throttle turned off, otherwise it messes up the speed of the game. This never happened before the 205 version. Any clue on what's going on?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #849 on: December 28, 2018, 05:38:40 pm »
Calamity will correct me if I'm wrong but IIRC roughly;

Yeah, basically all true, just worth pointing out it's AMD/Nvidia drivers the ones that create the buffers when they're allowed freedom, rather than DirectX or SDL. They do that in order to cheat on benchmarks. It's only through the newer apis (e.g. Direct9X+, Vulcan) that the frame buffer size can be controlled.

Quote
EDIT: though this thread suggests that even without vsync there are differences: http://forum.arcadecontrols.com/index.php?topic=153434.0

Now whether you have an advantage running GroovyMAME over baseline MAME for lag in this (your) case I'm not sure...

There's a remaining latency source in baseline MAME of barely one frame, due to how the keyboards are polled, that can be shaved without fancy features like frame delay.

Quote
so it didn't go well and still required me to use the syncrefresh, which in principle unlike waitvsync should force MAME and the monitor to run at the game's refresh without tearing nor added lag (reminder: if switchres is on). Even so it wasn't perfectly smooth.
With my monitor for doing that GroovyMAME with frame_delay works better, but again my setup is not like your setup.

That's because your monitor is not actually refreshing at the input rate. It just accepts it, like most do, but resamples it so it falls within its refresh window. You know it's actually refreshing at the input rate when it's perfectly smooth. That's how I find the refresh range in my monitorst, I run different refresh rates and test them visually, there's no other way.

Quote
The reason we don't speak much about G-Sync and FreeSync here is because GroovyMAME's or RetroArch's options related to lag and smoothness, are made for people who don't have G-Sync/FreeSync.

I recently purchased a Freesync monitor but haven't tested the Freesync feature yet with MAME (it required a new video card, which required a new psu in turn, etc.)
« Last Edit: December 28, 2018, 05:43:40 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #850 on: December 28, 2018, 05:41:35 pm »
So, for some reason, I no longer can use frame delay with throttle turned off, otherwise it messes up the speed of the game. This never happened before the 205 version. Any clue on what's going on?

It's amazing that before you could use frame delay at all with throttle turned off.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Heian_Shodan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 14
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #851 on: December 28, 2018, 06:04:38 pm »
I used to enable autosync or syncrefresh, turn the throttle off, then use frame delay. It worked great in the 204 version. But now its just messing the speed of the game. And if I enable throttle, I get these annoying frame stutters and pitch oscillations, specially on CPS3 emulation.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #852 on: December 28, 2018, 06:18:31 pm »
I used to enable autosync or syncrefresh, turn the throttle off, then use frame delay. It worked great in the 204 version.

It didn't work. Frame delay doesn't work without throttle. Promise. Whatever value you passed was ignored.

Now, lower the value of frame delay to one that your system can handle properly (no stutters, no speed issues).

And consider posting a log.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

dilarconon

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #853 on: December 28, 2018, 07:06:05 pm »
There's a remaining latency source in baseline MAME of barely one frame, due to how the keyboards are polled, that can be shaved without fancy features like frame delay.


How would we be able to shave that?

Also, what exactly is frame delay? I thought it was something like runahead, but I was corrected.
« Last Edit: December 28, 2018, 07:08:42 pm by dilarconon »

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 384
  • Z80 ERROR
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #854 on: December 29, 2018, 02:47:53 am »
I'd like to improve the alignment of the theoretical frame delay values with the corresponding scanline numbers. This is a required first step to an eventual auto frame delay feature.

Unfortunately on the Linux side, as we discussed, we don't have access to scanlines, so the implementation will need to achieve the same with timers (which probably requires someone smarter than me).

Hi Calamity,

The only solution I see right now would be to patch the kernel to export the scanline position. Linux has also a fallback code (timer based) to calculate when vblank should be fired. With some enhancement it might be in a position to report the beam position. This would required libdrm to be patched as well to provide the access function.
Having a user land timer is not a bad idea. It can be re-sync at each vblank int and could be more than precise enough for scanline position reporting.

Could you please share the prototype of the windows function to see how far it can be accommodated on the Linux side?

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 384
  • Z80 ERROR
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #855 on: December 29, 2018, 02:51:55 am »
GroovyMAME 0.205 is out!

What's new in Switchres v0.017m (December 2018)

- Added feature to autosave UI sliders to make frame delay in-game adjustments non-volatile.

- (Windows) Added capability to toggle frame delay from the UI.

- (Windows) Preliminar work on modifications to the frame delay implementation to improve its accuracy.

- (Windows) Temporarily dropped BFGX support due to upstream overhaul.

The Linux binary has been added as well. Thanks Calamity.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #856 on: December 29, 2018, 04:20:11 am »
That's because your monitor is not actually refreshing at the input rate. It just accepts it, like most do, but resamples it so it falls within its refresh window. You know it's actually refreshing at the input rate when it's perfectly smooth. That's how I find the refresh range in my monitorst, I run different refresh rates and test them visually, there's no other way.
Well I though you got that all games at any refresh run absolutely silky smooth on it, and when I check the status it always matches the input on V, I don't believe it resamples but rather it doesn't mind part of the signal information so it can run anything within 50-75 without conversion.
It's a very rare thing on flat panel monitors these days, I think it was more common in the past on early lcd monitors before things like HDMI became the standard and 'locked' everything unwanted out of range.
Actually it works with external sources too, anything through an OSSC for instance works and is silky smooth without a hiccup or added lag as far as I tested.
Or if it's still a type of conversion, well, it is a non-destructive, non-laggy one, dunno. *shrug*
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6434
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #857 on: December 29, 2018, 04:39:20 am »
Ah, ok, I had understood the opposite when you said "Even so it wasn't perfectly smooth."
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #858 on: December 29, 2018, 04:44:59 am »
With baseline MAME! sorry my sentences are always so convoluted because of my lacking english.

In short I tried the same thing but using baseline instead of Groovy, it worked but not 100% smooth, there were hiccups remaining.

(also of course baseline lacks the mod you made to skip the oddball resolutions that gave me black screens before)

EDIT: the question was if you got FreeSync do you still benefit from Groovy or can you just use baseline ?
« Last Edit: December 29, 2018, 04:57:21 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

b4nd1t0

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 51
    • b4nd1t0's repository
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #859 on: December 29, 2018, 12:26:10 pm »
Thanks Calamity, the 64 bit non nag added to the repo, in these days i can test the new features on my cab.

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 656
    • SCART Hunter
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #860 on: December 29, 2018, 01:17:39 pm »
With baseline MAME! sorry my sentences are always so convoluted because of my lacking english.

Are you for real?! Wordy, sure, but your command of the language is better than most native speakers. Especially when it comes to the written form!

All these recent developments are very exciting guys! Thoroughly enjoying watching this unfold...

Sent from my SM-G955F using Tapatalk

My MAME/SCART/CRT blog: SCART Hunter

dilarconon

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #861 on: December 29, 2018, 08:21:29 pm »
Can somebody explain what frame_delay actually does in details? Google doesn't seem to help that much

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #862 on: December 30, 2018, 07:11:35 am »
Personally I don't get all the technique behind it but as far as I understand; most of the games/hardwares emulated are not frame-based, rather they do all what they've been programmed for by their developers within a certain time (which would be better measured in miliseconds)
MAME emulating a game (the driver) if correct/accurate and not using additional software to assist that driver (which is sometimes the case for a number of games) does not expand nor shrink that time, it should be the same as the real thing.
With that MAME's renderer creates as many frames as it can in succession, agnostically, and along that there will be other frames used for vblank and inputs.
(I think understanding how all these are organized in terms of frames/threads/priority is essential to fully explain but that part is beyond my current level)

There what I'll say is speculation again because I don't fully understand, but somehow I think the moment the inputs register happens close to (or same as under conditions?) that of the render frame. If that render frame you see happens late because there's been several buffer frames before (like what happens with vsynced D3D/OGL/BGFX) then of course you feel a lot of lag because it happens several frames even on top of / away from the game's natural delay.
Nth edit: or maybe it's the other way around and the cause of perceptible lag is that they're too far apart.

Using plain D3D9ex (or frame_delay 1) there's only one frame used for vsync so the render and therefore inputs are already much closer to the game.

Using higher values of frame_delay then...delays the rendering of the next/upcoming frame, giving the inputs more chances to register close to (or within the same time frame?) as that 'closest' render frame, instead of missing the opportunity and register with the next.

Frame_delay 0 to 9 represent 10 fractions of a frame (1 step then being a bit over 1.6ms), the higher your setting the more the next frame is delayed and the inputs have a chance to register within the time of the current rendered frame.
In theory if you can set it to 9 then the inputs register as close to the base game's delay as possible, which should be almost unmeasurable (too short)
So in practice if you set frame_delay about 7~8 there's only 5~3.3ms delay on top of the game's.

Of course there you have to consider your PC+OS ability and settings, controller port input polling, controller pcb or adapter's own lag, and display lag.
With carefully selected and set hardware you can keep the lag chain very low adding only a few more ms on top of GroovyMAME and maintain under 1/2 a frame (8.3ms) in total on top of the game's normal lag/time.

This is how I understand it, but of course my explanation is probably wrong in various places. Calamity and a handful of more educated members here would certainly correct and explain better than I do.

In any case contrary to run-ahead, frame_delay is not designed so that it would allow to eliminate frames corresponding to the game's original time/delay, so 'lower lag than real hardware/game' is impossible with it.

There are more matters worthy of consideration on top of it all, which are proper refresh speeds, and in your case the alternative of featured variable refresh-capable hardware such as G-Sync and FreeSync.

Wordy, sure
;D
« Last Edit: December 30, 2018, 08:22:34 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 53
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #863 on: December 30, 2018, 10:12:24 am »
I know this kind of question goes nowhere... but for some time now I'm wondering...

what is the breed of Horses and ration people are using to manage frame delay 8 (even 9 in some cases)? I can't reach FD8 on CPS1/2 games anymore since the ASIO hack days.
Every new mainline Mame release f* up performance so badly that I actually use older versions for more demanding games, like CPS3 or Capcom ZN games of the likes of SF Ex Plus.
I barely keep up with the new releases anymore, unfortunately. After all. it's all bout Tiger Handhelds and even Calculators nowadays. CALCULATORS my man.
Life must be hella boring to someone dedicate time for that, geez.
« Last Edit: December 30, 2018, 10:14:49 am by Dacasks »

neth0c

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 1
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #864 on: December 30, 2018, 10:38:21 am »
Hi,
sorry for my bad english.

I thought frame delay is sth like this:

60hz ist one frame every 16,6ms.

Frame delay 5 => the emulator wait 5ms for an input
Frame delay 8 => the emulator wait 8ms for an input  (i.e. the emulator got only 8ms to emulate = more stress)

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 81
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #865 on: December 30, 2018, 10:56:02 am »
Every new mainline Mame release f* up performance so badly that I actually use older versions for more demanding games, like CPS3 or Capcom ZN games of the likes of SF Ex Plus.
I barely keep up with the new releases anymore, unfortunately. After all. it's all bout Tiger Handhelds and even Calculators nowadays. CALCULATORS my man.
Life must be hella boring to someone dedicate time for that, geez.
If every new MAME release  f* up your PC performance so badly, then it is probably time for a new PC.
Sadly, you did not provide any information about your setup, so we can barely help. If drivers/games are demanding more power, then it is probably because the devs improved the accuracy of the emulation. I dont think that the MAME devs want to make a game worse. You need to understand that the devs do not want to stay at a Windows XP level as a minimum configuration.
While handhelds in the current state may not look interesting, this could easily change if the artwork system can support virtual 3D handhelds with the (playable) game on it and this is no utopia here. Same goes for calculators, they seem of no interest, but are pretty cool for a "newbie" who wants to develop something new for MAME. Any new emulated chip/pcb, is maybe good for another system that needs to be emulated.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

haynor666

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1190
  • retro maniac
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #866 on: December 30, 2018, 12:27:17 pm »
I know this kind of question goes nowhere... but for some time now I'm wondering...

what is the breed of Horses and ration people are using to manage frame delay 8 (even 9 in some cases)? I can't reach FD8 on CPS1/2 games anymore since the ASIO hack days.
Every new mainline Mame release f* up performance so badly that I actually use older versions for more demanding games, like CPS3 or Capcom ZN games of the likes of SF Ex Plus.
I barely keep up with the new releases anymore, unfortunately. After all. it's all bout Tiger Handhelds and even Calculators nowadays. CALCULATORS my man.
Life must be hella boring to someone dedicate time for that, geez.

That's a price of progress I'm affraid. Many drivers are better like stv, taitogn but also slower right now. Also MAME in this year has slightly lower performance. You know, we can't expect to play on single hardware for years, just look at modern PC games.
« Last Edit: January 02, 2019, 12:58:29 pm by haynor666 »

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 53
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #867 on: December 30, 2018, 03:46:26 pm »
Every new mainline Mame release f* up performance so badly that I actually use older versions for more demanding games, like CPS3 or Capcom ZN games of the likes of SF Ex Plus.
I barely keep up with the new releases anymore, unfortunately. After all. it's all bout Tiger Handhelds and even Calculators nowadays. CALCULATORS my man.
Life must be hella boring to someone dedicate time for that, geez.
If every new MAME release  f* up your PC performance so badly, then it is probably time for a new PC.
Sadly, you did not provide any information about your setup, so we can barely help. If drivers/games are demanding more power, then it is probably because the devs improved the accuracy of the emulation. I dont think that the MAME devs want to make a game worse. You need to understand that the devs do not want to stay at a Windows XP level as a minimum configuration.
While handhelds in the current state may not look interesting, this could easily change if the artwork system can support virtual 3D handhelds with the (playable) game on it and this is no utopia here. Same goes for calculators, they seem of no interest, but are pretty cool for a "newbie" who wants to develop something new for MAME. Any new emulated chip/pcb, is maybe good for another system that needs to be emulated.

Nah, I don't need a new pc. I just a made a joke, a bad one I might add, at something that is partially true independent of reasons: emulation on Mame is getting ridiculous demanding for the most trivial things (affecting forks like Gmame, of course). Ironically, Hyper Fighting speed is emulated correctly only on 1999 Callus, for example.
Doesnt help that the guy who announces the new releases on the official website sounds like your local used car salesman
"AND NOW! As a special treat, improvements made the INFAMOUS T-3169 korean calculator partially emulated. It still doesn't make subtractions, but surely AWESOME NEWS for emulation fans out there! Plus, a new Street Fighter 2 clone was added", which I always find, personally, hilarious. I would prefer a cold "what's new" log, but anyway...

Don't be so defensive. I'm not looking for help either and I'm fully aware what the mainline project aims for.

Few years ago an overclocked g3258 was pretty much the "AK-47 deal" for the Gmame fork. Not anymore. I was just wondering what kind of processor people are using for "top performance", specially under Gmame . I use an OCed 4690k here. Mainly FD7 on 2D stuff on newer Mame releases. 3D stuff varies a lot... but, mostly FD3, 2... or those more demanding Namco games with it disabled.
I also wonder if there are delay improvements on the Frame_delay feature as well, comparing it to older, less demanding releases... something on the lines of ".170 Frame_Delay 8 on par with Frame_Delay 7 on newer releases" kind of stuff.

Anyway, happy new year for everyone, specially to those involved on the Gmame project! I STILL DIDN'T COMMIT SUICIDE THANKS TO YOU! I know, it's collateral, it wasn't the main reason.



That's a price of progress I'm affraid. Many drivers are better like stv, taitogn but also slower right now. Also MAME in this year has slightly lower performance. You know, we can expect to play on single hardware for years, just look at modern PC games.

Yeah, that's the way it is, I guess. Eventually we'll reach a point that any low end machine (of a future time) will emulate stuff better than today on high end.
OR MAYBE NOT. But it's fine already...
« Last Edit: December 30, 2018, 03:51:44 pm by Dacasks »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #868 on: December 30, 2018, 04:14:39 pm »
For comparison I have the same processor + an R7, and for the Capcom stuff I do frame_delay 7 without issues (8 works too but with frame drops)
With HLSL on it's rather 6.
Cave cv1k games more like 5.
heavy stuff (STV, gnet, system22 etc) I don't use framedelay, just d3d9ex on default.
Currently my 4690k is OC'd @4.1/4.2GHz, but those same settings worked identically on stock.
I always use the latest build.
But I don't use Portaudio atm (will soon as soon as I've fixed a couple issues)

I think a stock G3258 should run the Capcom games with frame_delay 7 too.

It's true that few games can handle 8, guess most that can are pretty low spec / old titles.

PS: now that we have ingame CPU overcloking available you should try it with sf2hf, apply the same CPU underclock as other CPS games, which is 74% (in fact exactly "cpu value = 738' as seen in the game's .cfg) dunno if the result is anything like Callus but connoisseurs might want to have a look at it.
« Last Edit: December 30, 2018, 04:22:28 pm by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 53
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #869 on: December 30, 2018, 04:52:47 pm »
For comparison I have the same processor + an R7, and for the Capcom stuff I do frame_delay 7 without issues (8 works too but with frame drops)
With HLSL on it's rather 6.
Cave cv1k games more like 5.
heavy stuff (STV, gnet, system22 etc) I don't use framedelay, just d3d9ex on default.
Currently my 4690k is OC'd @4.1/4.2GHz, but those same settings worked identically on stock.
I always use the latest build.
But I don't use Portaudio atm (will soon as soon as I've fixed a couple issues)

I think a stock G3258 should run the Capcom games with frame_delay 7 too.

It's true that few games can handle 8, guess most that can are pretty low spec / old titles.

PS: now that we have ingame CPU overcloking available you should try it with sf2hf, apply the same CPU underclock as other CPS games, which is 74% (in fact exactly "cpu value = 738' as seen in the game's .cfg) dunno if the result is anything like Callus but connoisseurs might want to have a look at it.

Yeah I know. I remember being one of the persons who tried to reach Mame devs about that one some years ago (I own the original board, so...). No one gave a f*, and the issue still persist. Now how a 20 year old emulator which relied on Speedfucshacks to work under a Pentium 233 can emulate that better, I sincerely don't know. Same with Carrier Air Wing intro (the jet engine trail being too fast). Actually I remember 70/71% was more accurate, but that was just me and what I felt more right compared to the real board.

IRONICALLY, nowadays I play at 125%. "Wtf?" Yeah, it's great to train reflexes. After the 30th anniversary collection came out I started doing that so I had advantage over online opponents. After sometime the vanilla game becomes so slow you can anti-air with jump kicks on reflex!
Fightcade is even worse. The game is even slower there. Gotta shoryuken those rushing Balrogs like the chosen One!

*and yeah... I actually can notice some fewer drops to none on CPS3 games at FD7 against the stock clock which works better at FD6... It's not much difference really overclocking it. Some other games really make use of it though, mostly heavy 2D games like those Taito F3 stuff or 3d games. I guess depends on the game/driver.
« Last Edit: December 30, 2018, 05:04:06 pm by Dacasks »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #870 on: December 30, 2018, 06:06:54 pm »
Yeah I know. I remember being one of the persons who tried to reach Mame devs about that one some years ago (I own the original board, so...). No one gave a f*, and the issue still persist. Now how a 20 year old emulator which relied on Speedfucshacks to work under a Pentium 233 can emulate that better, I sincerely don't know. Same with Carrier Air Wing intro (the jet engine trail being too fast). Actually I remember 70/71% was more accurate, but that was just me and what I felt more right compared to the real board.
I'm no specialist in the secret but from the bits I gathered here and there over the years it could simply be that MAME like most other emulators lacking wait states emulation, the solution would have been a deep and heavy program redesign, which might have meant halting the drivers development routine for a long time with the risk of losing a number of contributors (to competing projects?) So they chose to not do it and sacrifice accuracy for the sake of keeping working people around.

The 'mame aims at accuracy' priority narrative over time changed to 'the drivers are accurate, this is preservation' and to blaming the critics for being ungrateful, pirates, whatever, anything to shoo them away and avoid admitting that questionable choice they've made, while keeping the contributors happy, even at the cost of losing the trust and like of concerned gamers over time (and stimulate the emergence of nasty rogue alternatives like RA as a side-effect)
It's probably the same scenario in regards to lag which is another taboo topic, the best solution apparently would require the rewrite of the majority of the drivers, which of course is an unthinkable perspective.

Now I don't think they have given up on fixing those technical lackings, rather they've left them unattended / low priority under a veil indefinitely until maybe someone pops up to do the dirty job in a manner that satisfies them and doesn't hurt MAME's routine and reputation on the contribution side, which I believe is in fact their #1 concern much higher than users/gamers because they think contributors are all MAME needs to survive (huge mistake, but don't argue on perspectives with developers, they will only ever understand and trust one: theirs, ever unaware of that bias's toxicity)
The merge with MESS was also probably heavily motivated by that same concern.

For us there isn't considerable progress to expect in the near future, only bits of improvements here and there on already long-time emulated games, once in a while a new hardware long in the wait finally working at a playable level like some of those heavy 3D games, in any case progress at a very low pace.
If those major redesigns/implementations we've been expecting almost since MAME was born ever happen, it'll probably be in a very long time, when we will also probably don't care anymore in our lives anyway.

That's why having something like GroovyMAME is so great, it sure is not here for the purpose of achieving the immaculate emulation MAME preaches the public as a front policy saying is the only acceptable way even if that means waiting literally decades for some hypothetical development completions/fixes, but at least it makes up for some of MAME's most annoying flaws in an acceptable and decent fashion, so we can finally PLAY with a smile for still a good number of years before we're too old.  8)
« Last Edit: December 30, 2018, 06:08:51 pm by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 53
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #871 on: December 30, 2018, 07:30:35 pm »
Yeah I know. I remember being one of the persons who tried to reach Mame devs about that one some years ago (I own the original board, so...). No one gave a f*, and the issue still persist. Now how a 20 year old emulator which relied on Speedfucshacks to work under a Pentium 233 can emulate that better, I sincerely don't know. Same with Carrier Air Wing intro (the jet engine trail being too fast). Actually I remember 70/71% was more accurate, but that was just me and what I felt more right compared to the real board.
I'm no specialist in the secret but from the bits I gathered here and there over the years it could simply be that MAME like most other emulators lacking wait states emulation, the solution would have been a deep and heavy program redesign, which might have meant halting the drivers development routine for a long time with the risk of losing a number of contributors (to competing projects?) So they chose to not do it and sacrifice accuracy for the sake of keeping working people around.

The 'mame aims at accuracy' priority narrative over time changed to 'the drivers are accurate, this is preservation' and to blaming the critics for being ungrateful, pirates, whatever, anything to shoo them away and avoid admitting that questionable choice they've made, while keeping the contributors happy, even at the cost of losing the trust and like of concerned gamers over time (and stimulate the emergence of nasty rogue alternatives like RA as a side-effect)
It's probably the same scenario in regards to lag which is another taboo topic, the best solution apparently would require the rewrite of the majority of the drivers, which of course is an unthinkable perspective.

Now I don't think they have given up on fixing those technical lackings, rather they've left them unattended / low priority under a veil indefinitely until maybe someone pops up to do the dirty job in a manner that satisfies them and doesn't hurt MAME's routine and reputation on the contribution side, which I believe is in fact their #1 concern much higher than users/gamers because they think contributors are all MAME needs to survive (huge mistake, but don't argue on perspectives with developers, they will only ever understand and trust one: theirs, ever unaware of that bias's toxicity)
The merge with MESS was also probably heavily motivated by that same concern.

For us there isn't considerable progress to expect in the near future, only bits of improvements here and there on already long-time emulated games, once in a while a new hardware long in the wait finally working at a playable level like some of those heavy 3D games, in any case progress at a very low pace.
If those major redesigns/implementations we've been expecting almost since MAME was born ever happen, it'll probably be in a very long time, when we will also probably don't care anymore in our lives anyway.

That's why having something like GroovyMAME is so great, it sure is not here for the purpose of achieving the immaculate emulation MAME preaches the public as a front policy saying is the only acceptable way even if that means waiting literally decades for some hypothetical development completions/fixes, but at least it makes up for some of MAME's most annoying flaws in an acceptable and decent fashion, so we can finally PLAY with a smile for still a good number of years before we're too old.  8)

That's a cool insight. I won't "ask for a refund" for "buying Mame" of course... but the project could be a little bit more nowadays in some regards.
And yep, already said dozen of times: Crtemudriver + Gmame combo is the coolest thing in emulation in a long, long time.  Amazing how underrated it is.
« Last Edit: December 30, 2018, 07:34:16 pm by Dacasks »

dilarconon

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • I want to build my own arcade controls!
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #872 on: December 31, 2018, 01:37:00 am »
...
Man, I agree with every point you made. The only time I contributed to the MAME project was when they were trying to get some dump so I pledge some, but I aside from that it's not like I can do better to help the project, but wow like some MAME devs are absolutely horrendous to talk to.
Every time someone does or says something they disagree with, they are all just ungrateful, impatient ---punks--- or pirates to them.

I really appreciate what the MAME devs do as they do that from their own free time, but it doesn't make them free from criticism. The amount of incomplete, barebones emulation of hardware and software they add increases dramatically while nearly all of the MAME endusers are there for the arcades. I know it also emulates some other "everything" and MAME has no goals or milestones other than "just write some driver for something that can be emulated (poorly), if you please" It's not like MAME is a well built emulator feature-wise, although I agree it's painlessly easy and straightforward to use.

The whole MAME dev scene is a mess. When someone points out why they are working on cassette system instead of fixing some bugs on arcades, MAME devs say because no one can and it's usually as good as it can get for now, but this is not true. If you actually follow the MAME scene, there are many things that they can fix that go oversight. It is understandable, but these long-overdue bugs usually get fixed after getting public exposure. So a lot of fixes and improvements can be made. It's just that the devs just want to work on whatever they want to. They are not getting paid and they contribute their own time so it's totally understandable, but that doesn't make how awful MAME progress is in terms of what they are mostly used for.

The 'mame aims at accuracy' priority narrative over time changed to 'the drivers are accurate, this is preservation' and to blaming the critics for being ungrateful, pirates, whatever, anything to shoo them away and avoid admitting that questionable choice they've made, while keeping the contributors happy, even at the cost of losing the trust and like of concerned gamers over time (and stimulate the emergence of nasty rogue alternatives like RA as a side-effect)
You could not have put this any better. They piss on RA all the time (regards to MAME) and tell people to stop using older versions of MAME, but seriously there's a reason why those people choose that. It's easier and more accessible. They also run better for them on their various setups.
I mean I could never use an older version of MAME as the newest version MAME is usually the best (unless some terrible regressions happen), but I would never fault anyone for using older builds.

Every time someone points out something that's valid, I get sad when white knights and the some passive aggressive MAME devs hop in to gang up on the criticism.

Haze may be like that sometimes, but he's in touch with the community and usually reasonable. He's also one of the few that give great fixes on some arcades systems time to time, and his blog reads are absolutely fantastic. arbee and cuavas are the two worst of the bunch for not being able to take criticism well. They both sound very condescending, unfriendly and personally in terms of his awful git commits comments I hate his. If you look at their post history (or git discussions from them), it makes you sad that they are involved in the MAME project you so love. Thankfully, other MAME developers like Moogly are great.

GroovyMAME is absolutely the best thing that has happened to MAME users. I really love what it's trying to do after seeing that despite MAME's "emulate everything and for pure preservation", MAME's exposure, use and love from the community is most if not all from the arcade communities. I hope to contribute more to GM project one day. I've already told all of my friends and families who use MAME to switch over to GM. I hope they get more exposure so it can expand to multi contributor repo when more devs join in the future.

RobeeJ

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 92
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #873 on: December 31, 2018, 05:39:57 am »
I think it's easy to forget that, just like Calamity, people who contribute to MAME in any way at all are doing it in their free time, and nobody has the right to dictate what people should do in their free time.

Some of these issues are really difficult to fix and no fun to debug, and it really doesn't matter what reason the MAME devs give for not doing them, it's their free time to choose what they do with. They owe us absolutely nothing, not even an explanation.

And it's open source, if you don't like it, fork it, use your own free time to do it how you want it to be done! And if you can't do that, well that's a shame.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #874 on: December 31, 2018, 07:12:26 am »
Blah blah blah. No we don't forget, stop that scratched record that's yet another of those irritating reactions we've heard a million times. And why should we always be nice with mame devs anyway?
MAMEdevs never refrained from being horrible with users driving them through the mud with every opportunity in nasty ways regardless of the person and relevancy of the topics, hitting them with loads of hermeticism, contradiction and hypocrisy, an attitude that contributed to empty every board devs are at and pushing users away towards RA and such, all that just because people sometimes naturally came around asking stuff, sharing criticism and suggestions.

If devs whether they do this as a hobby or professionally can't handle that then why do they provide to the world and expose their creation and themselves for 20 years ?
No one forced them to do MAME either, users have all the right to tell their opinion, this is public place and users are not extras paid to stand there and shut up either.

How immensely pretentious from devs to get on stage under the spotlight in front of an audience of millions and expect continued uniterrupted gratitude, applause and zero criticism like forever.
How immensely pretentious also to believe they were always right in their judgement and choices.

In any case, the proportion of criticism MAME received is minuscule compared to the pharaonic accumulation of thanks and admiration, which everyone agrees to, MAME is awesome, don't ignore that.
Just, there were decisions and reponses that disappointed, sometimes greatly, a part of the users demographics and that's how it is, nothing more, and you won't change that: this is reality.
The ever-visceral reactions to even the smallest of critics though, always with the same pre-recoreded arguments, only show how massively sensitive and monolithic ideology-driven developers egos often are, again no matter the environment and circumstances, hobby or professional, this is widespread mentality in that line.

Of course there are very cool, humane, understanding and aware-of-whats-outside-the-bubble ones too, yet unfortunately seeing how things evolved it is clear they're not the ones who've been at the helm of the project all that time.
The only way to share with devs on MAME-related tpics without the toxicity is through circumstances outside enough from the black clouds of mamedev, a minimal safe distance away.

TL;DR as a dev don't like what users have to say if it doesn't please you? don't listen to them, or assume exposing yourself to the public. And the same should go for the user actually, if he criticizes he can expect devs be pissed off like 9 out of 10 times and more no matter the reason, so either don't talk to devs or assume the consequences.
Hardly anything good ever comes out of that kind of direct confrontational interaction anyway, sure. As I've said not long ago: when someone has a remark, something to notify mamedev, a contribution to make, whatever it's best to do it formally via the usual channels like mametesters, then leave them deal or not with it, don't wait for the answers and reactions, then go back to enjoying MAME the way you chose to.
« Last Edit: December 31, 2018, 07:16:29 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1552
  • Web Developer.
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #875 on: December 31, 2018, 07:50:46 am »
Iím just here for groovymame news and education on how it works, not girl drama.

Trnzaddict

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 105
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #876 on: December 31, 2018, 08:04:30 am »
...
Man, I agree with every point you made. The only time I contributed to the MAME project was when they were trying to get some dump so I pledge some, but I aside from that it's not like I can do better to help the project, but wow like some MAME devs are absolutely horrendous to talk to.
Every time someone does or says something they disagree with, they are all just ungrateful, impatient ---punks--- or pirates to them.
y

I agree 100% with this.

A few years ago I headed to mameworld.info and I asked if there was anyway to bypass or shorten the Deco Cassette arcade game drivers long boot up count down.

I got ---my bottom--- totally reamed by a dev, because I wanted to "Screw up the authentic emulation because I'm impatient"

I could not believe how he flipped off the handle on this, ever since then I never posted there until a few months ago and actually made up a new username to avoid any issues there again. I completely understand they they are doing this in their free time and we wouldn't be able to have our own arcade cabinets if it wasn't for the software, but there is no reason, none, to treat people like they are pieces of sh*t for asking simple questions.

I have used MAME since the first release in 1997, and I seriously doubt Nicola Salmoria wanted this type nor had this type of attitude when he wrote MAME for people to enjoy, but instead of being a fun thing, they have slowly turned it into a hardcore preservation project where it seems that being able to play the games is a "side effect" and any constructive criticism or questions they interpret as a dig or jab at them. I think Nicola probably wrote the software for people to play these games on their computers, but again this is all just my opinion.

RobeeJ

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 92
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #877 on: December 31, 2018, 11:52:15 am »
Blah blah blah. No we don't forget, stop that scratched record that's yet another of those irritating reactions we've heard a million times. And why should we always be nice with mame devs anyway?

Speaking as someone who has open sourced things and contributed to the open source community, I have never done it for gratitude or to have people be nice to me in any way, I've just done it because I enjoyed doing it and thought it might be useful to someone else. People whining, being ungrateful and expecting me to do something for them, unsurprisingly makes me way less likely to do anything for them.

I'm guessing things are the same with the MAME devs.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 354
  • I want a large cream coffee
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #878 on: December 31, 2018, 01:29:22 pm »
You don't give a vibe that you really know the topic no, when you have people, users, who have been looking up a project for as long as MAME it's normal they would have many things to say, both positive and negative, requests etc IT'S NORMAL.
It is unfortunately not uncommon to see developers do stuff, give it to people, expect feedback and contribution, and despite what you say they often expect to be treated one-sidedly like heroes or benefactors, they DO demand blind respect no matter what, yet never consider criticism and behave like deaf arrogant ---Deutsche Frankfurters--- with the users.
MAMEdevs are infamous for packing many of that kind.
'open source' aren't magic words giving a free pass to be an ass all you want with other human beings even if you give them away stuff you did in your free time, but for some reason in the world of software development a lot of individuals seem to think it is so. Though I have followed several projects but never came across devs as awful as mamedevs.

You're giving your opinion, I don't know you nor what you've worked on, but don't ask me to like MAMEdev, I've watched them for almost as long as the beginning, no matter all the things they've realized I know too well how they are.
A formal "Thank you for what you've done" is always deserved for MAMEdev, but respect? Nah.
I reserve that for Calamity & Co, here I've discovered what it is to interact with intelligent people doing development and not being brutally horrible with users, and I've brought myself to try and contribute if I can be useful even if only a little, and I consider doing increasingly so to support them. And would Calamity stop for whatever reason I would never resent nor regret.

And a happy new year. Now if you'll excuse me I have to go get wasted.  :cheers:
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

RobeeJ

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 92
Re: GroovyMAME 0.205 - Switchres v0.017m
« Reply #879 on: January 01, 2019, 05:09:03 am »
I'm not asking you to like or grovel to or anything to MAME devs. I'm just saying that if you want them to do what you want them to do, being anything but nice and polite to them will only ever do the opposite because they aren't being paid. They hold all the power in this relationship. You don't have to like it, but you can't do anything about it.

Happy New Year :)

(And apologies to Calamity for derailing this thread!)

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31