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: Clarification on using GroovyMAME on a LCD  (Read 2906 times)

0 Members and 1 Guest are viewing this topic.

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Clarification on using GroovyMAME on a LCD
« on: July 29, 2018, 08:31:25 am »
Just wanted to make sure about this (and opened this thread for google indexing purposes):

Should you set monitor lcd in the mame.ini file if you're using an LCD?

I was under the assumption that you should leave it as is and just adjust crt_range to match your LCD monitor refresh rate and resolution.

Is this true for both Radeon and Nvidia cards?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #1 on: July 30, 2018, 06:17:07 am »
Should you set monitor lcd in the mame.ini file if you're using an LCD?

Yes, definitely.

By using the lcd preset you're telling GM to stop video mode switching and stick to desktop's resolution only.

This assumes the user already has the desktop set to its native (optimal) resolution. E.g. you can't switch from desktop at 60 Hz to GM at 120 Hz, or from desktop at 1920x1080 to GM at 1280x720 to say making hlsl more fluent. If you'd like to do such things, then yes, you'd need to create a custom crt_range and do everything manually.

Default lcd range is defined to work between 59-61 Hz. If your LCD supports 120 or 144 Hz, you need to manually extend the lcd_range option accordingly, otherwise GM will fail to find a valid video mode.

Internally, GM creates a crt_range to fit your LCD resolution.  It forces the -resolution option to be that of your desktop, and locks everything else.

The typical problem with uneducated people from of other forums is downloading GM to run on an lcd without any further configuration. This sets the default "monitor generic_15" which tries to set 640x480 @15 kHz, which obviously fails on their crappy laptop lcd, so -switchres is set to 0, and everthing else: scaling, autosync, etc. gets disabled.

Of course I could make lcd the default option to avoid that, but that would make nice people from this forum having to  do specific configuration to just enable basic mode switching at 15 kHz on their cabinets.

Or find a decent solution for everybody...
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

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1911
  • Gotta have blue hair.
Re: Clarification on using GroovyMAME on a LCD
« Reply #2 on: July 30, 2018, 02:26:39 pm »
Or find a decent solution for everybody...

Is there any way at runtime for GroovyMAME to query Windows and tell what KIND of monitor it is based on the monitor description or something?

If not that, how about some kind of algorithm that looks at the supported resolutions in the mode list and tries to make an educated guess about the monitor type.

Or maybe a combination of both methods.
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

Trnzaddict

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 87
Re: Clarification on using GroovyMAME on a LCD
« Reply #3 on: July 30, 2018, 02:37:36 pm »
Should you set monitor lcd in the mame.ini file if you're using an LCD?

Yes, definitely.

By using the lcd preset you're telling GM to stop video mode switching and stick to desktop's resolution only.

This assumes the user already has the desktop set to its native (optimal) resolution. E.g. you can't switch from desktop at 60 Hz to GM at 120 Hz, or from desktop at 1920x1080 to GM at 1280x720 to say making hlsl more fluent. If you'd like to do such things, then yes, you'd need to create a custom crt_range and do everything manually.

Default lcd range is defined to work between 59-61 Hz. If your LCD supports 120 or 144 Hz, you need to manually extend the lcd_range option accordingly, otherwise GM will fail to find a valid video mode.

Internally, GM creates a crt_range to fit your LCD resolution.  It forces the -resolution option to be that of your desktop, and locks everything else.

The typical problem with uneducated people from of other forums is downloading GM to run on an lcd without any further configuration. This sets the default "monitor generic_15" which tries to set 640x480 @15 kHz, which obviously fails on their crappy laptop lcd, so -switchres is set to 0, and everthing else: scaling, autosync, etc. gets disabled.

Of course I could make lcd the default option to avoid that, but that would make nice people from this forum having to  do specific configuration to just enable basic mode switching at 15 kHz on their cabinets.

Or find a decent solution for everybody...

Calamity - so I am confused here. I asked previously if GM was able to utilize custom made LCD resolutions in Nvidia control panel, which you said yes. So for example my native resolution is 1920x1200@60p. So I have created a 1920x1200 55hz custom resolution in Nvidia for R-Type, but you're saying here that GM will only use your native desktop res and lock everything else? I was under the impression that GM would select the closest refresh rate that is available for smooth gameplay? Because even with these custom video modes GM is always at 60hz in machine info.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #4 on: July 30, 2018, 03:47:30 pm »
If your LCD supports 120 or 144 Hz, you need to manually extend the lcd_range option accordingly, otherwise GM will fail to find a valid video mode.
How do you do that if I may ask ?
lcd_range 59-121 ?
or
lcd_range  59-145 ?
Actually how do you even edit the .ini correctly for that purpose ?

Trnzaddict

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 87
Re: Clarification on using GroovyMAME on a LCD
« Reply #5 on: July 30, 2018, 05:30:32 pm »
If your LCD supports 120 or 144 Hz, you need to manually extend the lcd_range option accordingly, otherwise GM will fail to find a valid video mode.
How do you do that if I may ask ?
lcd_range 59-121 ?
or
lcd_range  59-145 ?
Actually how do you even edit the .ini correctly for that purpose ?

I have my LCD range defined as 55-60 and it still doesn’t switch.

Just erase where it says “auto” in the ini then you put in the info as you described above.

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #6 on: July 31, 2018, 11:21:15 am »
Yes, definitely.

By using the lcd preset you're telling GM to stop video mode switching and stick to desktop's resolution only.

This assumes the user already has the desktop set to its native (optimal) resolution. E.g. you can't switch from desktop at 60 Hz to GM at 120 Hz, or from desktop at 1920x1080 to GM at 1280x720 to say making hlsl more fluent. If you'd like to do such things, then yes, you'd need to create a custom crt_range and do everything manually.

Default lcd range is defined to work between 59-61 Hz. If your LCD supports 120 or 144 Hz, you need to manually extend the lcd_range option accordingly, otherwise GM will fail to find a valid video mode.

Internally, GM creates a crt_range to fit your LCD resolution.  It forces the -resolution option to be that of your desktop, and locks everything else.

The typical problem with uneducated people from of other forums is downloading GM to run on an lcd without any further configuration. This sets the default "monitor generic_15" which tries to set 640x480 @15 kHz, which obviously fails on their crappy laptop lcd, so -switchres is set to 0, and everthing else: scaling, autosync, etc. gets disabled.

Of course I could make lcd the default option to avoid that, but that would make nice people from this forum having to  do specific configuration to just enable basic mode switching at 15 kHz on their cabinets.

Or find a decent solution for everybody...

Thanks for the very detailed reply Calamity, hopefully this thread will solve many people's headaches when using GM on a LCD.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #7 on: July 31, 2018, 01:12:02 pm »
Calamity - so I am confused here. I asked previously if GM was able to utilize custom made LCD resolutions in Nvidia control panel, which you said yes. So for example my native resolution is 1920x1200@60p. So I have created a 1920x1200 55hz custom resolution in Nvidia for R-Type, but you're saying here that GM will only use your native desktop res and lock everything else? I was under the impression that GM would select the closest refresh rate that is available for smooth gameplay? Because even with these custom video modes GM is always at 60hz in machine info.

If you use -monitor lcd, then it will NOT switch to a different video mode, it will use whatever your desktop is configured with, period. This is valid for 99% of people using lcds (which, I need to remind, is not the target audience of GM anyway).

GM may of course use whatever video mode you add to your system, say 55 Hz, whatever, AS LONG AS you treat your monitor as a CRT and use a monitor preset or custom crt_range that allows that mode.

Basically in GM's context a "crt" is a monitor that can use different video modes. An "lcd" is a monitor that uses a fixed video mode. Again, this makes sense for 99% of cases, even if there're exceptions, like LCDs that support variable refresh rates, etc.

Newcomers always complain about GM being so strict that you have to specify a valid preset or crt_range just in order to use a system resolution. They ignore that GM was designed to make it very difficult that a system mode was picked that could potentially damage your arcade monitor.

So you have to put some effort on your part to persuade it pick something like 1200p, unless you use "-monitor lcd", which means 1200p is already in use by the desktop so it probably hasn't killed your monitor.

There are no crt presets that accept 1200p currently. So you need to make a custom crt_range, like this one:

crt_range0 65000-85000, 55.00-61.00, 0.704, 1.035, 1.739, 0.040, 0.080, 0.483, 0, 0, 1200, 1200, 0, 0

With that, and selecting "-monitor custom", it should be able to switch between different refresh rates. Besides, set "-resolution 1920x1200@0" so it doesn't accidentally pick something else that is 1200p (unlikely anyway).
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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #8 on: July 31, 2018, 01:25:31 pm »
If your LCD supports 120 or 144 Hz, you need to manually extend the lcd_range option accordingly, otherwise GM will fail to find a valid video mode.
How do you do that if I may ask ?
lcd_range 59-121 ?
or
lcd_range  59-145 ?
Actually how do you even edit the .ini correctly for that purpose ?

Exactly. You edit mame.ini and change "lcd_range auto" by "lcd_range 59-121" or whatever.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #9 on: July 31, 2018, 04:14:49 pm »
So if you 'go custom' with your LCD, what's a sure way to learn about all the modes it can really run at and that GM could successfully use ?

(edit: I mean as they are the nVidia and AMD control panels aren't exactly helpful, the other day I've set 1920x1080@58 on my R7 completely at random since I couldn't find all modes listed anywhere.
It seemed to accept and save it, yet apparently Win 7 Pro didn't, and my monitor still reported 60Hz, which GM followed but I wasn't on 'custom' anyway...quite puzzling still regarding W7)

Then when you know only a single crt_range line edited will suffice ?
« Last Edit: July 31, 2018, 04:41:02 pm by schmerzkaufen »

B2K24

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
Re: Clarification on using GroovyMAME on a LCD
« Reply #10 on: July 31, 2018, 05:12:31 pm »
What would someone recommend to put if your LCD runs at 2560X1440 and it's capable of 144 Hz G-Sync

I've been so blown away by my CRT Triniton setup. I really should get a proper GM running on my desktop LCD at some point.

Trnzaddict

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 87
Re: Clarification on using GroovyMAME on a LCD
« Reply #11 on: July 31, 2018, 08:32:37 pm »
Calamity - so I am confused here. I asked previously if GM was able to utilize custom made LCD resolutions in Nvidia control panel, which you said yes. So for example my native resolution is 1920x1200@60p. So I have created a 1920x1200 55hz custom resolution in Nvidia for R-Type, but you're saying here that GM will only use your native desktop res and lock everything else? I was under the impression that GM would select the closest refresh rate that is available for smooth gameplay? Because even with these custom video modes GM is always at 60hz in machine info.

If you use -monitor lcd, then it will NOT switch to a different video mode, it will use whatever your desktop is configured with, period. This is valid for 99% of people using lcds (which, I need to remind, is not the target audience of GM anyway).

GM may of course use whatever video mode you add to your system, say 55 Hz, whatever, AS LONG AS you treat your monitor as a CRT and use a monitor preset or custom crt_range that allows that mode.

Basically in GM's context a "crt" is a monitor that can use different video modes. An "lcd" is a monitor that uses a fixed video mode. Again, this makes sense for 99% of cases, even if there're exceptions, like LCDs that support variable refresh rates, etc.

Newcomers always complain about GM being so strict that you have to specify a valid preset or crt_range just in order to use a system resolution. They ignore that GM was designed to make it very difficult that a system mode was picked that could potentially damage your arcade monitor.

So you have to put some effort on your part to persuade it pick something like 1200p, unless you use "-monitor lcd", which means 1200p is already in use by the desktop so it probably hasn't killed your monitor.

There are no crt presets that accept 1200p currently. So you need to make a custom crt_range, like this one:

crt_range0 65000-85000, 55.00-61.00, 0.704, 1.035, 1.739, 0.040, 0.080, 0.483, 0, 0, 1200, 1200, 0, 0

With that, and selecting "-monitor custom", it should be able to switch between different refresh rates. Besides, set "-resolution 1920x1200@0" so it doesn't accidentally pick something else that is 1200p (unlikely anyway).


Thankyou so much. It's switching refresh rates now. Character scrolling is smooth in Mortal Kombat and R-Type runs correctly.

Even though GM is made for CRT's, I really think when people realize what it can do it will become the go-to build for LCD users.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #12 on: August 01, 2018, 03:42:47 am »
I haven't had the same luck so far, I'm still trying to figure how this can work for me.
Right now only using a 60Hz full-hd monitor, I've set three custom resolutions in the AMD control panel; 1920x1080@60, 1920x1080@58, 1920x1080@55 ...

The strange thing is that none of the off-60Hz seem to actually work, that is when selected the desktop is still running normally @60, this is what my monitor detects as well.
I suspect the AMD custom resolutions tool might be completely useless in that it must be reverting or converting back to 60 without telling you, dunno exactly what's going on.

Anyway I was wondering if maybe that would work only while an application is running in exclusive fullscreen, of course my goal being GM I've tried setting it like this;
Code: [Select]
#
# CORE SWITCHRES OPTIONS
#
modeline_generation       0
monitor                   custom
orientation               horizontal
connector                 auto
interlace                 1
doublescan                1
super_width               2560
changeres                 1
powerstrip                0
lock_system_modes         1
lock_unsupported_modes    1
refresh_dont_care         0
dotclock_min              0
sync_refresh_tolerance    2
frame_delay               0
vsync_offset              0
black_frame_insertion     0
modeline                  auto
ps_timing                 auto
lcd_range                 auto
crt_range0                49-61
Which of course will not work  :D
Guess I need to enter the full modeline but I don't know what to do from this point, I'm lost.

After I figure the right modeline to use, if no custom modes work, GM not switching to them, it might be because that monitor won't accept them no matter what.
In that case I'll try again with a much older monitor I have in storage that I believe is much more flexible.

PS: does it make a difference if your GPU and monitor are linked via HDMI, DVI or VGA ? I mean is there one connectivity choice here that might support more real modes ?
« Last Edit: August 01, 2018, 03:45:41 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #13 on: August 01, 2018, 07:12:11 am »
I haven't had the same luck so far, I'm still trying to figure how this can work for me.
Right now only using a 60Hz full-hd monitor, I've set three custom resolutions in the AMD control panel; 1920x1080@60, 1920x1080@58, 1920x1080@55 ...

If you're using an AMD card, you'd better use CRT Emudriver and allow GM to update video timings, if that's what you want, rather than adding video modes with external tools. The procedure is not exactly straight-forward, so I'll write a small tutorial in a while.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #14 on: August 01, 2018, 07:33:33 am »
Well I'd like to first try and find out if my monitor and gpu can actually work at refreshes other than 50, 59.94 or 60.
Then do the same experiment switching to my nVidia gpu.

As thin as the chances are to find several non-60Hz modes working, IMHO it's best to explore potential all-accessible options for those who don't have the necessary hardware (in this case that would be an AMD gpu)

But all this of course depends on the monitor at the end of the chain. Although modern 60Hz one are very limited, if I recall some sometimes have modes they can run at that are typically not listed (often older models but you never know before trying, it just worked for Trnzaddict)
Someone actually recommended me to try that in the past when I owned different pc and monitor, but I was just as clueless as how to do it and set things up to find out, just like now.

Of course if all fails and I can't uncover any useful modes, the crt_emudrivers route sounds the most logical.

EDIT: would CRU be the thing? I've never used it before but heh. Then what/how must I configure in the ini once I've unearthed/edited my gpu output modes ?
« Last Edit: August 01, 2018, 07:39:12 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #15 on: August 01, 2018, 08:04:11 am »
Ok, if there's no interest I won't bother. The information to do LCD refresh switching on any gpu is already provided in my previous post.

Using tools to add individual video modes is a regression to last decade but I'm afraid this is where the hobby is going back.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #16 on: August 01, 2018, 08:17:15 am »
Sorry I'm confused as you seem to take offense for a reason that beyond me.

I want to try it the same way as Trnzaddict to see if that works for me. But I don't know how to find/set the below and maybe some things in the .ini
crt_range0 65000-85000, 55.00-61.00, 0.704, 1.035, 1.739, 0.040, 0.080, 0.483, 0, 0, 1200, 1200, 0, 0

Then of course I'm interested in doing it with crt_emudriver too!

I want to explore all options as I'll be changing my setups more than once in the future.

EDIT: some logs attached. This is just with monitor lcd 49-61 to have view. If I try monitor custom and set crt_range0 to the automatically created monitor range found in the logs (copy-pasting it); GM starts but I get a black screen instead of the UI. If I press start though it launches the previous game, but as far as I've seen trying neither rtype or esprade will switch to the 55 and 58 modes I have created (modes are listed though it seems)

EDIT2: ok for some reason it started working, switching rtype and esprade to working smooth 55 & 58 modes, but for some reason the sound speed is audibly reduced in esparrade (when I press F11 to see the video output refresh speed it shows 91% for rtype and 87% for esprade), more logs and ini attached.
« Last Edit: August 01, 2018, 10:43:35 am by schmerzkaufen »

sterbehilfe1980

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #17 on: August 01, 2018, 08:39:30 am »
Hi Guys!

It works for me too.

1.) I created 1600x1200 resolutions with 55,56,57,58,59,60,61hz within the nvidia driver system control center.
2.) Then i added Calamitys crt_range0 65000-85000, 55.00-61.00, 0.704, 1.035, 1.739, 0.040, 0.080, 0.483, 0, 0, 1200, 1200, 0, 0 line in mame.ini
3.) Next thing was setting the following options in mame.ini to 0:
lock_system_modes         0
lock_unsupported_modes    0

If your Monitor supports those refrshrates it will work. I can play Neo Geo, Mortal Kombat, R-Type etc now @100% speed! Realy cool feature for LCD´s Monitors, thanks a lot guys!

Monitor: Samsung Syncmaster 213T 4:3 1600x1200p
Graphic: Nvidia 750Ti
OS: Win 7

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #18 on: August 01, 2018, 10:50:55 am »
A "quick start guide" would be a god send for many people who are not as technically prepared as many users on this forum are.

Just few lines, a step by step guide on how to configure GM to work on a CRT or an LCD monitor.

In a PDF, along with the main download, so we can just start RTFM'ing people who come here asking for very basic questions like the one I did here.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #19 on: August 01, 2018, 12:40:40 pm »
A "quick start guide" would be a god send for many people who are not as technically prepared as many users on this forum are.

Just few lines, a step by step guide on how to configure GM to work on a CRT or an LCD monitor.

In a PDF, along with the main download, so we can just start RTFM'ing people who come here asking for very basic questions like the one I did here.

Configuring GroovyMAME for an LCD monitor:

1.- Download "official" GroovyMAME package (the "D3D9ex" build)
2.- Unzip the package
3.- Go into its folder and open mame.ini (double-click on it)
4.- Search down for the "rompath" option. Edit the option with the path to your roms, e.g.: "rompath c:\roms\mame"
5.- Search down for the "monitor" option. Edit this option with the "lcd" value ("monitor lcd")
6.- Run GroovyMAME (mame64.exe)

-.end of guide.-

 :)

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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #20 on: August 01, 2018, 12:51:36 pm »
3.) Next thing was setting the following options in mame.ini to 0:
lock_system_modes         0
lock_unsupported_modes    0

Yes, that's very important, I forgot that.
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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #21 on: August 01, 2018, 01:00:58 pm »
I want to try it the same way as Trnzaddict to see if that works for me. But I don't know how to find/set the below and maybe some things in the .ini
crt_range0 65000-85000, 55.00-61.00, 0.704, 1.035, 1.739, 0.040, 0.080, 0.483, 0, 0, 1200, 1200, 0, 0

Your setup is messed because GroovyMAME thinks you're using CRT Emudriver, and tries to update timings accordingly. This is because you're using an AMD card, and I never considered the scenerio of someone willing to use AMD in combination with profane video methods. In order to use your external modes you'd need to set "modeline_generation 0".

Still, you'll be limited to a few external modes. Close refresh rates will quickly overlap in your mode list. There's a much better way of doing this with CRT Emudriver and an LCD, hopefully I have some time later to make a writeup.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #22 on: August 01, 2018, 02:05:19 pm »
Thanks!

OK so yes indeed there's really something wrong as contrary to the nVidia users here (note I've since added more external modes like them) because I get some funky results no matter what I do; some games will pick a good 'nearest' mode and play overall better, some will pick a good one too but the musics will play at the wrong speed, sometimes it's the whole game that will play at exactly half the speed! etc.

I'll wait for your writeup for AMD users then of course, thanks. In the meantime I will install crt_emudriver.

Some surprises in this thread eh? ^^

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #23 on: August 02, 2018, 06:29:46 am »
Configuring GroovyMAME for an LCD monitor:

1.- Download "official" GroovyMAME package (the "D3D9ex" build)
2.- Unzip the package
3.- Go into its folder and open mame.ini (double-click on it)
4.- Search down for the "rompath" option. Edit the option with the path to your roms, e.g.: "rompath c:\roms\mame"
5.- Search down for the "monitor" option. Edit this option with the "lcd" value ("monitor lcd")
6.- Run GroovyMAME (mame64.exe)

-.end of guide.-

 :)

Nice!  ;D

Now slam that into a txt file named README_1ST.txt, put it into the groovymame zip and I believe we've solved 99,999% of the issues most users are having!  :lol

Although I'd put an extra line somewhere saying that if you're on a AMD card (as you should), you have to install CRT_Emudriver first.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #24 on: August 02, 2018, 07:52:37 am »
Well if you only do that (set monitor lcd) you don't need crt_emudriver even if you own an AMD card. You'll be stuck at 59-61 but it'll work without issues.
You need it if you want to effectively use other modes on your LCD, and you have an AMD card, because of the drivers confusion it otherwise creates.

It's great that it's working fine for nVidia users without doing anything special apparently.
I think I will swap GPUs now and give that a try with my own nVidia a bit just to experience and confirm it, before re-swapping for the AMD R7 and crt_emudriver.

In any case again this thread was a revelation, I didn't expect GM to be able to function at various non-60Hz modes, whether without or with crt_emudriver depending on the setup, on your average 60Hz panel. That's because I've believed for a long time that most common 60Hz LCD displays these days are locked firmly to a very limited number of modes, the likes you find on the specs sheet. Guess I was wrong and a handful of working modes often stay 'hidden'.

BTW while making logs I was also surprised to see how good GM is at sniffing them all out, that monitor I'm using with the R7 at the moment has some I would have never suspected even existed.
For some reason their numbers expanded considerably while I was tinkering, probably because of something I did...(I was never using custom resolutions from the AMD control panel before, maybe just using it once unveiled the usually hidden modes?)
« Last Edit: August 02, 2018, 07:55:41 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #25 on: August 02, 2018, 08:32:02 am »
The thing with fixed refresh LCDs is they actually do support a certain *range*. E.g. a fixed 60 Hz LCD needs to be able to sync to at least a narrow range of refresh values around 60 Hz. This is because video cards never provide a perfect match for 60 Hz. So if monitors required exact 60 Hz they would be out of sync in 99% of cases. So the matter is, how narrow or wide this range is.

Yesterday doing some tests I've found that my current Dell can sync between 58.5 and 60.60 Hz. This covers many arcade systems.

It's super important not mistaking what refresh a monitor can accept and what it can actually sync to. My monitor accepts from 50 to 75(??)Hz but that doesn't mean it's synchronizing to those frequencies. You know when it's actually synchronizing because scrolling is perfectly smooth. Otherwise you'll notice the scroll stutters.

So you may find in your monitor specifications that it accepts 50-75 Hz as input but probably it will probably only sync to a small window within that range, or several small windows, that is never documented and you need to find it out yourself. Then of course if you're lucky enough it's possible that the monitor's board can sync to the whole range.

With regards to GroovyMAME, I've noticed there's a small problem that's preventing the right refresh from being selected when modeline generation is disabled in certain cases. I'll fix this in the coming version. Bear in mind this has never been tested seriously.

We played with variable refresh rate for LCDs and GM some years ago by means of Powerstrip. But it was never really stable and support for new cards is long over, so this thing was abandoned. Now since HD 5000+ cards support was integrated in GM I figured it could potentially be used for variable refresh LCDs too, natively, but hadn't tested it yet. I was shocked of how well it works.
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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #26 on: August 02, 2018, 09:29:09 am »
Well if you only do that (set monitor lcd) you don't need crt_emudriver even if you own an AMD card. You'll be stuck at 59-61 but it'll work without issues.
You need it if you want to effectively use other modes on your LCD, and you have an AMD card, because of the drivers confusion it otherwise creates.

No, CRT Emudriver is only required for AMD if you want GM to update timings automatically. Without CRT Emudriver, AMD will work exactly the same as Nvidia, it's only that you have to manually disable -modeline_generation, which GM already disables automatically in the Nvidia case. That's all.

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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #27 on: August 02, 2018, 10:43:06 am »
Ah ok. Well I've disabled modeline_generation but the same funky issues persisted. From what you're saying I've probably misconfigured my .ini or the modes I've (very randomly) created in the AMD cpl weren't fit anyway (the handful of games that did pick up either 55, 56, 58 etc though, synced and scrolled smoothly but with issues for most)

I'll wait later for trying again that R7+LCD but with crt_emudriver then, since it sounds like much less hassle and trouble. ^^

About VRR; doesn't that work with almost anything already (emulators, games, whatever) just by disabling vsync, without the need of special drivers and software?
Haven't gotten to experience one of those freesync/gsync monitors myself yet, but I was thinking those basically obsolated lag reduction and smoothness efforts all at once.

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1911
  • Gotta have blue hair.
Re: Clarification on using GroovyMAME on a LCD
« Reply #28 on: August 02, 2018, 11:45:48 am »
Now slam that into a txt file named README_1ST.txt, put it into the groovymame zip and I believe we've solved 99,999% of the issues most users are having!  :lol

Although I'd put an extra line somewhere saying that if you're on a AMD card (as you should), you have to install CRT_Emudriver first.

Honestly, I've always thought that a flowchart would be best.  Or maybe a "choose your own adventure" style website.
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #29 on: August 02, 2018, 12:29:45 pm »
Or maybe a "choose your own adventure" style website.

  :cheers:
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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #30 on: August 02, 2018, 01:09:32 pm »
About VRR; doesn't that work with almost anything already (emulators, games, whatever) just by disabling vsync, without the need of special drivers and software?
Haven't gotten to experience one of those freesync/gsync monitors myself yet, but I was thinking those basically obsolated lag reduction and smoothness efforts all at once.

Sure, that's the correct, logical solution. Still, I haven't seen latency reports measuring baseline MAME on freesync/gsync monitors.

The way we're doing here, custom resolutions on lcd for old school vsync, is cutting-edge-obsolete technology.
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

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #31 on: August 02, 2018, 01:51:00 pm »
Or maybe a "choose your own adventure" style website.

Ah! That would indeed be nice, sounds like a nifty project to make a single page javascript app. Uhm.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #32 on: August 02, 2018, 06:38:37 pm »
cutting-edge-obsolete technology.
Everyone around here's favourite.  8)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #33 on: August 03, 2018, 11:34:36 am »
Guide for variable refresh rate on LCDs using CRT Emudriver

Check video here: https://www.youtube.com/watch?v=N6c32mp_VoQ

GroovyMAME and the CRT Tools can dynamically modify the timings output to an LCD monitor when using an AMD HD 5000 or newer card. In order to do this in an useful way, you first need to overcome some obstacles.

The first and most important obstacle is that the current desktop video mode is read-only. This means neither GM nor Arcade OSD can alter these current video timings. Because LCDs are supposed to work at the desktop (native) resolution all the time, without switching modes, this becomes a problem.

Fortunately there's a very easy workaround. You need to create a dummy mode with the same resolution as your monitor's native resolution, and a different refresh rate. This way, Windows assumes these are separate video modes, and it allows you to change the timings freely.

The second obstacle is to guess your monitor's timing values in order to build a custom "crt range" that can be used by GM. Again, this is very easy to do as I'll show you in a minute.

So the first step is to launch Arcade OSD, select your desktop video mode (which should be marked in cyan to indicate its currently used by the desktop):



Now press "2" to enter non-fullscreen edit. Select "Copy modeline to clipboard". Exit Arcade OSD.



Now open Notepad. Press CTRL+V. You'll see something like this:

Code: [Select]
modeline "2560x1600_60 98.71KHz 59.97Hz" 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync
crt_range 98703.24-98723.24, 50.00-60.00, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1928, 3200, 3857

We're interested is in the second line. Arcade OSD has created a crt_range for you that corresponds to your current LCD timings. What you have to do is make that crt_range a bit more general so it can produce a higher number of refresh rates.

First, limit the progressive line range to the exact vertical resolution (in my case: 1600), and set the interlace range to zero:

crt_range 98703.24-98723.24, 50.00-60.00, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0


Now, as the vast majority of arcade games use refresh rates between 54 and 60,61 Hz, we'll adjust the vertical frequency range:

crt_range 98703.24-98723.24, 54.00-60.61, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0


The next step is vital: we need to adjust the horizontal frequency to make a valid crt_range. This is very easy to do if we have the vertical total value taken from the monitor's default timings. It's the last value in the modeline we got from Arcade OSD (don't mistake modelines and crt_ranges!):

modeline "2560x1600_60 98.71KHz 59.97Hz" 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync


So what we need to do is to multiply this vertical total value by each one of the vertical refresh limits:

1646 x 54.00 = 88884
1646 x 60.61 = 99764

and fill the crt_range line accordingly:

crt_range 88884-99764, 54.00-60.61, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0


That's it. Finally, add a zero to the crt_range word, and we're done:

crt_range0 88884-99764, 54.00-60.61, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0

NOTE: Currently both GroovyMAME and the CRT Tools have an HfreqMax limit of 100000 Hz. This is too low for 4K monitor unfortunately, so bear this in mind if you're going to try this. This limit will be removed in the future.

The next step is to configure VMMaker using this custom crt_range. So let's launch VMMaker, and go to Settings->Monitor settings->Edit monitor presets.

This will open monitor.ini in Notepad. Now we'll create a new monitor preset, by adding our newly created crt_range and a monitor header, like this one:

Code: [Select]
monitor "u3011", "Dell U3011", "4:3"
crt_range0 88884-99764, 54.00-60.61, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0

Here I've filled the fields in the monitor header with my monitor's name. Leave default aspect as 4:3. Save the file and exit Notepad.

Now the new monitor definition will be selectable from the monitor presets dropdown menu.



Now go to the Video card and make sure to select the right output in the Device dropdown menu. When done, press Ok to go back the VMMaker's main window.




Once in VMMaker's console (next to the Ready> prompt), type this:

mode add 2560x1600@59

Notice the "59". This is a dummy refresh. We should type one that's not used by the system. VMMaker will show this:

Code: [Select]
>>mode add 2560x1600@59             
"2560x1600_59 97.06KHz 59.00Hz" 263.99 2560 2608 2640 2720 1600 1603 1609 1645 +hsync -vsync
1 mode added to modelist.

Now type this:

modelist install

VMMaker will prompt:

Code: [Select]
>>modelist install               
Installing modelines in system...
1 modelines installed.

We can close VMMaker now, and go back to Arcade OSD, were we'll see the new mode:



Perfect. The final step is to configure GroovyMAME to use this custom monitor preset. So open mame.ini, and edit these options:

Code: [Select]
monitor custom
crt_range0 88884-99764, 54.00-60.61, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0
resolution 2560x1600@59

Pay attention to the "resolution" option. We're forcing GroovyMAME to pick this dummy mode we've created. GroovyMAME will take this mode and adjust its refresh rate to whatever refresh is required.

E.g., let's launch rtype:



There it is!

If you notice that the scroll is not smooth, then your LCD can't sync to that refresh. This particular monitor I'm testing shows smooth scrolling between 58.50 and 60.61 Hz. Yours will be different. The only way to know it is by testing different games.
« Last Edit: August 12, 2018, 01:17:45 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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #34 on: August 03, 2018, 01:44:45 pm »
OMG you already wrote it !  :o  THANK YOU so much.
I'd like to get to 'work' immediately but it's so hot outside (38~39°C) and inside my house, I think I will break something (I trust my cooling cpu+fan might whistand the heat better than my brain right now)

Just a few questions in preparation;

1. Considering Seibu SPI games @53.986864 and Aero Fighters @61.310000, should I set the range to 53.99-61.31 or rounded to 54.00-61.30 is ok ?

2. Related to the quote below; apparently (as seen from my logs) I have several @59 modes that are listed as system ones, so what dummy value should I pick instead to be safe ?
Quote
Notice the "59". This is a dummy refresh. We should type one that's not used by the system.

3. I'm using GM 0.196 now, should I wait for the next GM release or it doesn't matter ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #35 on: August 03, 2018, 02:01:22 pm »
1. Considering Seibu SPI games @53.986864 and Aero Fighters @61.310000, should I set the range to 53.99-61.31 or rounded to 54.00-61.30 is ok ?

That's ok, adjust the range as you prefer, my values were just a suggestion. You can even set the lower limit to 50 Hz if your monitor can sync to PAL.

Quote
2. Related to the quote below; apparently (as seen from my logs) I have several @59 modes that are listed as system ones, so what dummy value should I pick instead to be safe ?

You can pick 59 as long as it's not currently used by the desktop. That will overwrite the system mode with a custom one. Or simply pick another value like 58.

Quote
3. I'm using GM 0.196 now, should I wait for the next GM release or it doesn't matter ?

You can use your current version.
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

B2K24

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
Re: Clarification on using GroovyMAME on a LCD
« Reply #36 on: August 03, 2018, 02:19:20 pm »
Beautiful guide!

I hope it can be sticky thread here and at eiusdemmodi. If someone could convert it to PDF and attach it, It would be nice to save it locally  :)

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 104
    • Eiusdemmodi
Re: Clarification on using GroovyMAME on a LCD
« Reply #37 on: August 04, 2018, 06:53:36 am »
Eiusdemmodi is currently migrating to another board system and I'm not sure how long it'll take, but making posts will not be possible until then. I'll bookmark this thread to make sure we save the post there too when it happens.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #38 on: August 09, 2018, 01:47:04 am »
OK so here's what I got in the clipboard
Code: [Select]
modeline "1920x1080_60 33.71KHz 59.94Hz" 74.17 1920 2008 2052 2200 1080 1085 1095 1125 interlace +hsync +vsync
crt_range 33703.64-33723.64, 50.00-60.00, 1.186, 0.593, 1.995, 0.148, 0.297, 0.890, 1, 1, 540, 315, 1080, 629
Er...not sure how I should edit this, it doesn't look like the one in your example so I can't locate the values to change (I mean the vertical resolution and interlaced mode ones)
Should I assume they're always the last four?
« Last Edit: August 09, 2018, 01:48:36 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #39 on: August 09, 2018, 03:13:50 am »
You guys always find odd ways to strain through the cracks of my tutorials  :D

Why are you using an interlaced mode on your desktop? Is it the default resolution of your monitor? Is there a progressive 1080p mode available?

My guide assumes you're using a progressive mode.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #40 on: August 09, 2018, 03:24:41 am »
Interlaced? is it really? both windows and my monitor report 1920x1080@60, no 'i' seen anywhere and the picture's perfectly sharp and stable...

edit: I've double-checked arcade osd and the mode in cyan is indeed listed as interlaced, which I didn't notice at first. I don't know what is happening.
1920x1080@60p is not listed in arcade osd, it's either 59p or 60i, something's wrong.
« Last Edit: August 09, 2018, 03:33:10 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #41 on: August 09, 2018, 03:32:32 am »
The modeline taken from Arcade OSD is certainly interlaced. What I can't say is if it's the real timing in use or Arcade OSD is incorrectly grabbing it from somewhere else.

The logs you posted when using regular Catalyst showed a progressive 1080p mode.

Just in case this is a leftover of your past experiments with GM, in VMMaker, video card type, use the option "Delete all modes from driver".
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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #42 on: August 09, 2018, 03:33:21 am »
edit: I've double-checked arcade osd and the mode in cyan is indeed listed as interlaced, which I didn't notice at first. I don't know what is happening.

Is there a progressive, 60 Hz, counterpart?

Alright, use the 59p version.
« Last Edit: August 09, 2018, 03:35:12 am 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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #43 on: August 09, 2018, 03:45:23 am »
I've deleted all modes in vmmaker and went back to arcade osd but the list didn't change, no 1920x1080@60p...

The 1920x1080@59p mode is listed as native and greyed out, arcade osd won't let me copy to clipboard.

I don't know what is happening, but I know a lot of HD monitors these days have a 59.94Hz mode that is quite often listed as '59p' and very often picked in priority by many machines as the default instead of the optimal 'PC' 60p one, which you then have to force through your GPU or windows.
I remember this R7 for instance by default ran @59 until I created a 1920x1080p mode in the AMD panel.

(edit: for reference my DC in VGA or 360 in HDMI both run @60 on this monitor, but if I connect a laptop or whatever PC with nVidia/AMD/Intel, then the '59p' mode is always the first one to be automatically selected. Had three monitors similar to this one recently, same story)
« Last Edit: August 09, 2018, 03:49:05 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #44 on: August 09, 2018, 03:53:39 am »
I remember this R7 for instance by default ran @59 until I created a 1920x1080p mode in the AMD panel.

Ok, this makes sense.

In VMMaker's console, type:

mode add "1920x1080_60 67.500000KHz 60.000000Hz" 148.500000 1920 2008 2052 2200 1080 1084 1089 1125 -hsync -vsync

Then:

modelist install

This will override that interlaced mode with a progressive one (this one is taken from your old log, probably it's the one you created with the AMD panel)
« Last Edit: August 09, 2018, 05:44:35 am 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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #45 on: August 09, 2018, 04:10:19 am »
Just did but the mode is still not showing in arcade osd.

BTW as mentioned both Windows and my monitor believe they're at 1920x1080@60p, but when I move a window around the desktop for instance, the movement is randomly choppy.

Dunno which thing is telling the truth or is mistaken.

edit; could crt_emudriver lack something for those common consumer Full-HD monitors? the first mode listed as 60p down the list in arcade osd is 1680x1050, then 1600x900, 1440x900...the top of the list is packed with interlaced modes, this isn't normal.
« Last Edit: August 09, 2018, 04:16:44 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #46 on: August 09, 2018, 04:21:17 am »
CRT Emudriver is plain Catalyst with a couple of checks removed. It can't affect that. As you said, it's Windows assuming 59.94 is 59. This probably comes from your monitor's EDID, that's why it happens also when you connect it to other computers.

Is the mode showing as interlaced in Arcade OSD even after restart?

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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #47 on: August 09, 2018, 04:32:15 am »
Nothing's changed even after restart, the mode is not here in (vmmaker did say mode installed, there was no error warning in the console)

I don't know why but I could easily create and set modes with the AMD control panel but here I can't, so something must be missing somewhere.
« Last Edit: August 09, 2018, 04:34:33 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #48 on: August 09, 2018, 04:35:34 am »
Are you pointing to the right output in VMMaker?

What happens if you do the same but using this mode:

"1920x1080_58 65.250000KHz 58.000000Hz" 143.550000 1920 2008 2052 2200 1080 1084 1089 1125   +hsync +vsync
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #49 on: August 09, 2018, 04:43:03 am »
yes the output is ok (monitor #1 R7)

58hz -> mode is rejected by driver (still says installed afterwards though, how strange)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #50 on: August 09, 2018, 04:51:26 am »
Ok, that's bad. Here the driver accepts the modes without issues. Maybe the fact that this monitor is connected through DVI-D instead of HDMI could be making a difference.

Are you able to change any timing at all through Arcade OSD?

It could also be due to your monitor's EDID being more restrictive.
« Last Edit: August 09, 2018, 05:00:49 am 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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #51 on: August 09, 2018, 05:03:13 am »
I'm connected using a DVI>HDMI cable because that's what I had under the arm, but I can use a normal HDMI one too if you want.
(Full-HD monitors never have DVI inputs btw)
I've asked the question of connectivity earlier because I thought it might count.


Using arcade osd I was indeed able to edit and save, only set the cyan mode to progressive and it worked (but i didn't touch the timing values)

EDIT: for the EDID: assume all Full-HD monitors and TVs are practically the same, flat panel displays definitely don't behave the same depending on their category, remember 1200p ones are a very small niche and definitely differ in terms of internals and standards.
BTW I think 4K monitors and TVs are of the same 'breed' as the Full-HD, afaik, they're consumer products expected to be used with consoles, broadcast, BR players etc

EDIT: after another restart for changing to HDMI>HDMI, went back to arcade osd and the cyan mode I had previously changed to progressive, went back to interlaced.
« Last Edit: August 09, 2018, 05:26:24 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #52 on: August 09, 2018, 05:28:39 am »
I'm using dual link DVI here because at the time this monitor was made it was the only connection to admit the required bandwidth. It shouldn't matter, I'm just trying to figure out the issue.

The fact that the AMD panel was able to insert the modes makes me wonder if the issue could be in VMMaker itself. I believe VMMaker uses the same mechanism as AMD panel to create new modes (I'm just using the AMD api). The difference could be AMD is using the vesa gtf/cvt standard while I'm trying to push the modes as custom.

What if you try this one:

mode add "1920x1080_59 66.375000KHz 59.000000Hz" 146.025000 1920 2008 2052 2200 1080 1084 1089 1125   +hsync +vsync

modelist install

Here, for instance, my 1920x1080@59p mode is marked as native in Arcade OSD. After running the above, I get a custom editable 59 Hz mode in Arcade OSD. Pay a lot of attention to the quotation marks.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #53 on: August 09, 2018, 05:44:46 am »
Pay a lot of attention to the quotation marks.
That must have been the issue. Previously I had a syntax error warning, so I assumed it was because of the quotation marks, after removing them the line would be written in the list though, without error warning.
Maybe there should be more syntax error messages. ^^

OK so the modes are now listed and selectable in arcade osd. I've applied the first 1920x1080@60 you've picked from my logs as well, it's there in arcade OSD but still labelled as 'custom'. I've set it as desktop.
Should I now resume from 'copy to clipboard' using that one ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #54 on: August 09, 2018, 05:46:57 am »
Yeah, my error, I edited my previous posts, sorry.

Quote
Should I now resume from 'copy to clipboard' using that one ?

Yes, start from there now.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #55 on: August 09, 2018, 05:59:04 am »
Here it is
Code: [Select]
modeline "1920x1080_60 67.50KHz 60.00Hz" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 -hsync -vsync
crt_range 67490.00-67510.00, 50.00-60.00, 0.593, 0.296, 0.997, 0.059, 0.074, 0.533, 0, 0, 1080, 1305, 2160, 2610

So I assume
crt_range0 56250-84375, 50.00-75.00, 0.593, 0.296, 0.997, 0.059, 0.074, 0.533, 0, 0, 1080, 1080, 0, 0

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #56 on: August 09, 2018, 06:22:26 am »
It looks correct.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #57 on: August 09, 2018, 06:41:19 am »
OK testing right now, in vmmaker I've added the 55Hz and 58Hz modes I've grabbed in the logs from my original attempt with the regular AMD drivers

For instance both R-Type and Raiden II run fine and smooth at the correct speed.
ESPrade too, locking to 58Hz and this time without distorted sound.
(I've reduced sync_refresh_tolerance to 1 btw because some games didn't seem to grab the nearest mode)

One issue that remained the same after switching to crt_emudriver here, is that Darius Gaiden still runs at half its normal speed, no idea why. I'll drop a log later.

Now I'm trying to figure what's the best method to add more modes manually? because previously the AMD custom utility kinda adjusted all the timings automatically after I set a random **Hz value.
I remember I had tried at least three more modes that worked but I didn't save those unfortunately (54Hz, 56Hz, 57Hz)
Wait I think I've missed a step, I'll come back...
« Last Edit: August 09, 2018, 06:53:33 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #58 on: August 09, 2018, 06:56:27 am »
You're not supposed to create a mode per refresh. Just a dummy 59 Hz mode. That's the point of this method.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #59 on: August 09, 2018, 07:08:24 am »
I was so puzzled and exhausted that I've skipped the vmmaker part where you set the monitor header etc. maybe that's the reason why it's not working 'by itself'.

So now I suppose I need to edit the default 'generic 15' one ?

Should I set the default aspect to 16:9 ?

And the dummy mode will start with 2560x1080, right ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #60 on: August 09, 2018, 07:09:27 am »
I was so puzzled and exhausted that I've skipped the vmmaker part where you set the monitor header etc. maybe that's the reason why it's not working 'by itself'.

So now I suppose I need to edit the default 'generic 15' one ?

Should I set the default aspect to 16:9 ?

And the dummy mode will start with 2560x1080, right ?


No, no, no  :cry:
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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #61 on: August 09, 2018, 07:12:35 am »
Just add the new monitor definition at the top of monitor.ini

Leave aspect 4:3 as explained in my guide.

2560x1600 is my monitor's resolution. Yours is 1920x1080. I thought this was clear.

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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #62 on: August 09, 2018, 07:15:05 am »
Please relax and give a read through the guide carefully first. Don't jump through the steps without knowing the purpose of it.

You don't have to create dozens of modes.

You only have to create a dummy mode. This must be forced in mame.ini later by using the -resolution option (last step).

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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #63 on: August 09, 2018, 07:28:12 am »
This is all a ton of firsts for me and a several hours battle, I hope you realize that for the layman this is really difficult and unusual ?
A ton of things I'm trying to follow in your guide don't make any sense to me yet I'm trying.

Sorry but that part is by far the most confusing one in your guide, it's referring to stuff I don't see. Maybe you should write it not with your own monitor as an example but with in mind what most people will see the first time they arrive.

When I get into vmmaker here what I see as monitor type is 'generic 15', nothing like mine is present in the droplist, then when I click on edit and the ini pops up, the first line is labelled as PAL TV 50Hz, is this where I am supposed to write the dummy mode line ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #64 on: August 09, 2018, 07:36:50 am »
monitor.ini is a text file. You're supposed to just click on the very top of it, press enter a few times so you can type or paste the new monitor definition. You don't have to replace the existing definitions.

You can just ignore this part because you've already added the mode by the other method we've been posting about this morning.

You already have your crt_range definition, edit mame.ini with it, add the "monitor custom" and "resolution 1920x1080@59" part and you're done. Post a log as soon as you have it running so I can check.

Bear in mind all the extra steps were required because by default your screen was reporting an interlaced mode. I know what it feels to always stumble with the "special" case.

« Last Edit: August 09, 2018, 07:38:33 am 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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #65 on: August 09, 2018, 08:10:17 am »
You're supposed to just click on the very top of it, press enter a few times so you can type or paste the new monitor definition. You don't have to replace the existing definitions.
Well you should really state so in the guide, how was I supposed to know that I needed to create a fresh new entry in the ini that pops up? also suddenly the term 'definitions' is used like it's obvious to anyone that in this particular file this is what these entries are called...
It's my first time today using vmmaker and seeing all that, trust me as someone who has near-zero knowledge of all this stuff: that part of your guide is  :dizzy:.

You already have your crt_range definition, edit mame.ini with it, add the "monitor custom"
Ok I've done that a while ago.

You and "resolution 1920x1080@59" part and you're done.
Wait that part is still to do in vmmaker, right ? or is this something I need to write in the mame.ini under the # OSD PER-WINDOW VIDEO OPTIONS category?
(currently there I have: resolution                1920x1080@0)

Post a log as soon as you have it running so I can check.
Bear in mind all the extra steps were required because by default your screen was reporting an interlaced mode. I know what it feels to always stumble with the "special" case.
Sorry at this point I don't know which of all I did was extra or normal lol  ;D

Don't hate me for what I'll say here; but I envy the nVidia guys who didn't have to go through all this.
« Last Edit: August 09, 2018, 08:13:30 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #66 on: August 09, 2018, 08:21:53 am »
Wait that part is still to do in vmmaker, right ? or is this something I need to write in the mame.ini under the # OSD PER-WINDOW VIDEO OPTIONS category?
(currently there I have: resolution                1920x1080@0)

Frankly man, if after reading my guide you still have that in mame.ini, I throw the towel right now, going to the beach  8)

Quote
Don't hate me for what I'll say here; but I envy the nVidia guys who didn't have to go through all this.

I don't hate you, I hate myself for having spent a few hours writing that guide.  :D

The point is, when you write a guide you need to keep a balance between not being too technical and not insulting the average man intelligence (the later imo being having to provide details about hot to insert text in a text file).

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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #67 on: August 09, 2018, 08:46:58 am »
Frankly man, if after reading my guide you still have that in mame.ini, I throw the towel
Once you say write resolution 1920x1080@0 to avoid going off the vertical resolution, once it's about adding mode 1920x1080@59 in vmmaker, next you mention resolution 1920x1080@59.
Am I supposed to know they're directly related? Or what?

I don't hate you, I hate myself for having spent a few hours writing that guide.  :D

The point is, when you write a guide you need to keep a balance between not being too technical and not insulting the average man intelligence (the later imo being having to provide details about hot to insert text in a text file).

I surely won't thank you for the insult. You're like all mamedevs or the average developer/computer engineer in the end, looking down on people who don't share the knowledge in the same fields as yours and overlooking the fact that you lack the ability to put yourself in the layman user's shoes and explain properly.
Maybe it's natural for you but it's not for like 99% of the population, especially when it's their first time being introduced to so many new things.

Shall I remind you that I've spend a considerable about of time on this as well, trying my best because this is what YOU stated should be done if done right ?



Anyway for some reason after restarting my PC it's back to its previous state with interlaced default like all is gone and I don't know why.

I'm tired of this, I feel like GM could be perfect for LCDs as I've witnessed with my own eyes that it actually works, but if that means going through such hair-pulling adventure for at almost the end of the road being treated like an idiot, then to hell with it.
« Last Edit: August 09, 2018, 08:49:46 am by schmerzkaufen »

brad808

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
Re: Clarification on using GroovyMAME on a LCD
« Reply #68 on: August 09, 2018, 09:25:15 am »
... Time for a CRT ;-).

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 532
  • Arcade Otaku sysadmin...
    • Arcade Otaku
Re: Clarification on using GroovyMAME on a LCD
« Reply #69 on: August 09, 2018, 09:48:14 am »
(Full-HD monitors never have DVI inputs btw)

I've installed hundreds, used dozens, and bought a few that do.
Please don't PM me with support questions. Ask in public so everyone can learn!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #70 on: August 09, 2018, 10:48:22 am »
Shall I remind you that I've spend a considerable about of time on this as well, trying my best because this is what YOU stated should be done if done right ?

I keep stating it is the right way to do it. And I'm sorry that it didn't work for you right away.

Quote
looking down on people who don't share the knowledge in the same fields as yours and overlooking the fact that you lack the ability to put yourself in the layman user's shoes and explain properly

See it the other way. Because I consider the folks here smart (otherwise you wouldn't be here but in instagram or whatever) my way to show you respect is to treat you as an equal and provide you with all the information I'd like to have received when I started with this. Treating people like dummies is insulting, this is the way I see things.
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

Amplifuzz

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #71 on: August 09, 2018, 01:00:01 pm »
If you use -monitor lcd, then it will NOT switch to a different video mode, it will use whatever your desktop is configured with, period. This is valid for 99% of people using lcds (which, I need to remind, is not the target audience of GM anyway).

GM may of course use whatever video mode you add to your system, say 55 Hz, whatever, AS LONG AS you treat your monitor as a CRT and use a monitor preset or custom crt_range that allows that mode.

Basically in GM's context a "crt" is a monitor that can use different video modes. An "lcd" is a monitor that uses a fixed video mode. Again, this makes sense for 99% of cases, even if there're exceptions, like LCDs that support variable refresh rates, etc.

Freaking hell, it works. This was never mentioned anywhere AFAIK, in fact I asked you some time ago how to do it with Powerstrip which is obviously deprecated by now. Still can't compare to a good CRT, but very handy in a pinch.

EDIT: Guess I spoke too soon, now the nonstandard refresh games (R-type, Mortal Kombat etc) work fine at their custom refresh but all the 60hz games default to the lowest refresh I have set (50 hz in my case, 54hz if I delete the 50hz one and so on). What could it be?

EDIT 2: Changing crt_range0 to 50000 from 65000 seems to have fixed it.

Anyways, here's a barebones guide on how to do it with an Nvidia card:

- setup your custom refresh resolutions with the Nvidia control panel. Nvidia control panel > Change resolution > Customize > Create custom resolution. Keep your native LCD resolution, 32bpp, just tweak the refresh in 1hz increments.

- edit mame.ini, here are my edits from a newly created one

monitor custom
lock_system_modes 0
lock_unsupported_modes 0
crt_range0 "50000-85000, 50.00-62.00, 0.704, 1.035, 1.739, 0.040, 0.080, 0.483, 0, 0, 1200, 1200, 0, 0"

replace 50.00-62.00 with the refresh range your monitor can support (until it goes 'out of range' when you're testing the custom resolutions in step 1) and 1200 with the native vertical resolution.

Optional:

- Configure Portaudio
- De-suck HLSL with these settings: https://www.youtube.com/watch?v=T9ERMO4I55I

Couple of questions:

- I have 50, 54, 55, 56, 57, 58, 59, 60, 61,62 hz setup now. Anything else needed? Anything that can be removed?
- What are the best vsync settings for d3d with this setup?
« Last Edit: August 09, 2018, 03:52:19 pm by Amplifuzz »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #72 on: August 09, 2018, 01:52:28 pm »
@Calamity: I don't see how after you have said that I'm basically not intelligent enough to understand your guide, that I would be the one being disrespectful.
You are seeing the world upside down if you think a complete beginner who doesn't understand something you have complete mastery of, is lacking you respect.
If you don't understand how complex this is for someone who doesn't have a fraction of your knowledge, or isn't nearly on the level of the long-initiated disciples, then you indeed deserve to be put in the same category as the mamedev who are infamous for dispending that kind of treatment towards users.
Again; try to understand the people who are outside of your world yet admire your work and are trying to catch up/understand. If you can't then set an automatic message somewhere telling newbies it's pointless to ask questions or help until they already have reached a certain level of knowledge and experience of all this.

Again, even putting aside the initial issue with my capricious gpu, after struggling with that interlaced desktop story I already had too much in mind and so eager to get that correct modeline+range, when it finally worked I've pasted it in my ini, relieved!!! then I was lost from the vmmaker part which I incorrectly thought came afet because of fatigue, and yes from there your guide isn't clear period.
Again especially as you're showing preset examples and forget to mention details inexperienced person discovering this would just guess 'just like that'. It's confusing.
Remember the quotation marks incident? If you hadn't mentioned it, how would I have guessed ? well that part of the guide is the same kind of situation, a few things un/mismentioned and for a beginner it's a dead-end.

Then after that I don't know why but my modes were reset and I thought 'to hell', this is too much. I only wanted a handful of modes working with GM, in the fashion the nVidia guys did, but for a reason that still escapes me you've refused to help me like you did for them, and dragged me into this way overcomplicated method.

And I know now that it was overcomplicated because I have since uninstalled everything, went back to the regular AMD drivers, then found an alternative way of doing it that works fantastically, with the regular AMD drivers yes, barely any more work than the nVidia owner's, only a few minutes, incredible success and no longer any anomalies.
No need to install crt_emudriver nor bother with vmmaker and try to learn and understand occult incantations, nor guess the relationships between all these parts, or fight through completely unexpected odd issues.

But I suppose that if I explained here how I did it, you would consider that 'disrespectful', so I'd better keep it to myself.

My advice take it or burn it; if it's not absolutely needed (and it doesn't seem that it is) then leave the LCD users out of the emudriver/vmmaker/modes-editing mumbo jumbo, it's not for them or if you prefer, weighing the possibilities, not worth this much trouble for their case. If they can have a handful of modes working through their GPU control panel and a few ini edits (which works!), that's enough.
Users who expect the full real GM+emudriver experience know it's the CRT way period, and they'll brace for the effort, because it's worth it.
Users who'd expect uncompromised emulation output on a LCD will buy a freesync/gsync setup.
'Normal LCD' users are neither, they just want the little extra mile an expanded configuration (beyond setting 'monitor lcd' in mame.ini) can achieve.

I'm sorry that I got pissed off and dropped the polite attitude but you started it. I'll be rudundant here but: don't blame someone and don't make fun of him for having a hard time understanding when it's you dragging him into something he obviously had few chances of getting right the first time and he was inevitably going to hit many walls.
FYI, as far as I've experienced talking emulation around, I believe most users in my case who would also love to profit from GM's abilities wouldn't have made it even halfway where I've been. Don't be like most mamdev, know your users, and realize what you're putting in front of them.

Unless of course if you only wish to address experienced knowledgeable ones, in which case then just kick the noobs out and link them to retroarch or bizhawk whatever.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #73 on: August 09, 2018, 02:50:46 pm »
@Calamity: I don't see how after you have said that I'm basically not intelligent enough to understand your guide, that I would be the one being disrespectful.
You are seeing the world upside down if you think a complete beginner who doesn't understand something you have complete mastery of, is lacking you respect.

Definitely I'm having a bad day getting myself understood. I didn't say you're disrespectful.

What I said is that *my* way to show respect to users is to not treat them as idiots. I'm afraid I have a personal crusade against the "don't get too technical" attitude (journalists, etc.).

I don't want users that follow a guide blindly. I expect them to understand what they're doing. If they don't at first, no problem, I'm here to answer questions.

And yes, my guide could be better, it was put together in a rush.

But if I write a sequential guide, which last step is:

Quote
Perfect. The final step is to configure GroovyMAME to use this custom monitor preset. So open mame.ini, and edit these options:

monitor custom
crt_range0 88884-99764, 54.00-60.61, 0.179, 0.119, 0.298, 0.030, 0.061, 0.375, 1, 0, 1600, 1600, 0, 0
resolution 2560x1600@59

Pay attention to the "resolution" option. We're forcing GroovyMAME to pick this dummy mode we've created. GroovyMAME will take this mode and adjust its refresh rate to whatever refresh is required.

... and the user complains I didn't warn the -resolution option had to be edited in mame.ini... how would you rewrite that in a simpler way?

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

I suggested this method because I did believe it was simpler.

Now, I'll explain why the NVidia/AMD-regular method is worse. You need to create a mode for each refresh, ok. The problem is arcade systems require hundreds of different refresh rates. You can only add 10 different refresh rates between 50 and 60, each one for an integer Hz value. That sucks.

Want to have 59.18 and 59.61 Hz available? Impossible
57.50 and 57.00 Hz? No way

You may arguee that for a regular user, this doesn't matter. That's subjective.

The thing is, there's a method that avoids that limitation and allows any refresh rate in the range, freely available without having to create individual modes. And because this method exists, I believe it deserves to be known. It's implemented in GM and can be potentially used, but it's not been documented until now.

And I thought you were a good candidate to test it, since you already had an AMD card available, that's all.

In my view of things, driving people through the static mode route is moving backwards in the hobby. Overacting about the supposed difficulty of things puts off new potential users who get intimidated before even trying.


EDIT: Damned, I've even made a change in next GroovyMAME version to make the standard, static mode method work better.


« Last Edit: August 09, 2018, 02:56:10 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

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 584
    • SCART Hunter
Re: Clarification on using GroovyMAME on a LCD
« Reply #74 on: August 09, 2018, 05:45:22 pm »
@Calamity: I don't see how after you have said that I'm basically not intelligent enough to understand your guide, that I would be the one being disrespectful.
You are seeing the world upside down if you think a complete beginner who doesn't understand something you have complete mastery of, is lacking you respect.
If you don't understand how complex this is for someone who doesn't have a fraction of your knowledge, or isn't nearly on the level of the long-initiated disciples, then you indeed deserve to be put in the same category as the mamedev who are infamous for dispending that kind of treatment towards users.

Some self-reflection and a sense of perspective is in order here, dude.

Clearly, the following salient points are not self-evident to you:

• Calamity is unique in the emulation scene because has a rare combination of genius level skills, saintly patience and generosity. Drop the comparisons to cranky ol' mamedev already. We need to keep him enthusiastic about the project, not wear him down with this undue ---That which is odiferous and causeth plants to grow---. We probably would have had a v02.00 build by now if he hadn't spent all his free time on your issue. :)
• The average mainstream MAME user is not GroovyMAME's target: it's specialised software for those who want a pixel-perfect CRT experience and are willing to put in the time to understand the challenges involved (and there are numerous).
• Your usage case (LCD) falls outside the clearly stated purpose for GroovyMAME (CRT!!!). Sure, there are advantages for LCD users to but you're using the software for something outside of its original purpose.
• All this ---steaming pile of meadow muffin--- take time to understand: it's not Calamity's software or guides that are complex - it's the problem itself (i.e. how to reproduce hundreds of different video modes on an endless number of target displays (CRT and LCD) with potentially unknown capabilities).
• It can take years to get your head around all this stuff. There are already so many moving parts (i.e. MAME ini system, parameters, etc.) before you even get to GroovyMAME specifics and the world of video timings.
• In 2018, getting into GroovyMAME is WAAAAY easier than 5 years ago. We've never had it better! Back then there were no guides, compatibility was lower (video cards), we didn't have super resolutions, etc. And guess what? People still got great results after putting in the due diligence.

Stake a step back. Accept that this is going to take time. You're not ordering a cheeseburger at McDonald's here...

Now, to address your fundamental misunderstanding relating to your alternative solution that works "fantastically": I just ran a data query (in Excel) on the full MAME XML output and count over 250+ unique refresh rates (for raster displays, non-clones). Your hand full of custom created video modes has no hope of covering all those potentialities. However, by digesting what Calamity has explained to you, you may end up with a solution that covers the majority of those potentials.

I have attached a summary of top 25 refresh rates (resolution is irrelevant to you since you're using a fixed display).

The whole point of GroovyMAME is that, within the limits of your display, you can hit all those native refresh rates (and resolutions, for CRT) by simply feeding GroovyMAME the bandwidth limits of your monitor. One line of text (monitor specifications) versus creating hundreds of modelines by hand.
« Last Edit: August 09, 2018, 05:51:09 pm by Paradroid »
My MAME/SCART/CRT blog: SCART Hunter

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #75 on: August 10, 2018, 08:16:00 am »

EDIT: not interested in this huge post -> scroll down to TL;DR

Definitely I'm having a bad day getting myself understood. I didn't say you're disrespectful.

What I said is that *my* way to show respect to users is to not treat them as idiots. I'm afraid I have a personal crusade against the "don't get too technical" attitude (journalists, etc.).
Wait, it never occured to you that you could actually get too technical pushing too much volume at once, too fast, and it's not the guy's fault but yours if he's lost and makes mistakes?
I hope you don't believe the world is made of people with training and experience in computer engineering, because most people can't even edit a text file or use command promp, and that includes tons of gamers, it's not their fault, just the majority of people simply learn other trades, and Microsoft/Apple/Google have done everything in their power for decades to help users NOT to learn about computers and everything related. All these people they use tech but don't live in the same world as the people that make it, not at all.

I don't want users that follow a guide blindly. I expect them to understand what they're doing. If they don't at first, no problem, I'm here to answer questions.

And yes, my guide could be better, it was put together in a rush.
Wrong way of thinking if you realize where people stand, when you address random beginners (the status is important) with no experience, and introduce them to a whole lot of new things and terms, you absolutely have to be as broadly understandable, detailed and specific, otherwise it's obvious that if you skips some parts, you will lose a lot of the readers or audience and will inevitably have to deal with a ton of - what will also inevitably at some point in your eyes come as - stupid questions.
Let those who've already graduated from the beginners classes do some individual research and thinking, not the clueless beginners. They can't guess, and they will ask you about a myriad of things you will come to think they do with ill will/motivation or by stupidity, and you'll be wrong.

... and the user complains I didn't warn the -resolution option had to be edited in mame.ini... how would you rewrite that in a simpler way?
No, as I said before I got lost starting with the vmmaker part which was confusing as hell, and it led me to mix up some things with the final part, which is why I asked for further explanations/confirmations, and it's where you made fun of my understanding.
You still don't seem to really realize how tricky this all is to assimilate and manage for a first timer who's barely at the level of monkey-ing a few ini settings and drop logs, how full of pits and traps this was, the volume was just too big.

Seriously I didn't imagine for second you would have produced a guide in such a short time, and I felt compelled to try it asap to honour your time spent on it, while I would have been happy and ok just trying the static method for a while since I was curious and willing to try it first, then wait until you had time to do a writeup for the full method no matter if in months if not longer.

I suggested this method because I did believe it was simpler.
How on earth? maybe from your perspective, but for the layman it involves several more actions and new non-trivial things to deal with compared to using what one already has (just his pc with gpu, regular drivers and GM).
It literally took me minutes to create about 10 resolutions in the amd panel and update a bunch of my already existing game or source ini's in GM, no change of drivers nor dealing with new softwares and manipulations my newbie-self wouldn't really understand so early.
One of the first things you learn when starting with GM is how to use its #1 feature which is framedelay, and therefore to create and manage individual ini's
At that level (call it 'beginner+' lol) it's already there, the knowledge and the material required to benefit from the static method, after creating about 10 custom resolutions (took me 3 minutes) only needed is to update the game or source .ini's with the resolution you want switchres to lock to, and eventually adjust the tolerance.
It's incredibly simpler and most of the knowledge needed is already in the user's head.
The only information he needs and can't guess at his level is in the first part of your guide; how to extract and modify the crtrange, and a couple of precisions like setting monitor custom and turning off modeline generation of course etc (minding that I'm still talking about the amd case here of course)

Now, I'll explain why the NVidia/AMD-regular method is worse. You need to create a mode for each refresh, ok. The problem is arcade systems require hundreds of different refresh rates. You can only add 10 different refresh rates between 50 and 60, each one for an integer Hz value. That sucks.

Want to have 59.18 and 59.61 Hz available? Impossible
57.50 and 57.00 Hz? No way

You may arguee that for a regular user, this doesn't matter. That's subjective.
...
The thing is, there's a method that avoids that limitation and allows any refresh rate in the range, freely available without having to create individual modes. And because this method exists, I believe it deserves to be known. It's implemented in GM and can be potentially used, but it's not been documented until now.

And I thought you were a good candidate to test it, since you already had an AMD card available, that's all.
Well it seems you assumed I didn't know about that... But since I know how to use GM with a LCD - at least the very basic 'monitor lcd' setting - and the basics of SwitchRes for lag reduction since again those are among the very first things one learns when beginning with GM - then I know what it does in practice (playing) and how it locks to the available fixed refresh.
Adding more fixed refreshes from my PC/system would logically make them available to GM for doing the same with those, which naturally results in small game refresh speed variations, but in practically all cases now; smaller ones (about 1% at worst from my tests from ~54 to 61+ hardwares) massively expanding the number of games playing smooth and at even closer-to-correct speeds than before, without doing the often considerable compromises (more % off-speed or triplebuffer) the base 'monitor lcd' configuration alone allows.

It's simple and considerably expands the power and greatness of GM for anyone with very little effort and changes to make to his PC/system.
No perfect results of course but at least this 'static' method doesn't require the user to change his drivers (which can defnitely be a problem) nor to spend like 20Hrs figuring out what's going on.
For someone who is not chasing after an ideal of accuracy and only needs a simple way to improve his GM experience for a handful of games in an accessible fashion, it's absolutely fantastic, universal.

Then of course there's the real thing you wrote a guide for, but it's not up to you to judge what method people should use, from the beginning you should have simply introduced both methods and simply state what they do and why the 'full' one is better, then let it to the users to choose which one they need/want.
Someone who usually just plays a couple of games if not just one (many users get mame for one single game they love), will be happy to benefit from a degree of improvement, let him weigh and judge how far he's ready to involve himself and his system for the results each method achieves.

I think you should really not assume in advance the motivations, level of knowledge and experience, and expectations in place of users kind of like you had the ability to read their minds, you can't, and naturally you shouldn't attempt to force them to do exclusively what you want, only your way.
You've declined to let me know about the static method - despite my stating I was interested in both - and for whatever reason assumed I would be a good ginea pig in an intense/rushed first time experiment, just because I owned an AMD ?

Listen I'll tell you what I think all devs/engineers need to hear as often as possible: 99% people who are using your work don't think like you, not in the least, they can't and won't (only a handful might catch up in time) and that's normal.
That doesn't mean they're wrong nor idiots, when you create something you do it for either yourself only, or a restricted number of same-world initiates, or both plus the broad public audience.
MAME is the latter, but GM even expands the possibilities thanks to what you've brought in it, and it has several levels of use and therefore levels of accessibility, each with a corresponding level of skills and output.
If you want to force all users to go straight to the lets say 'intermediary' levels, you're cutting off and chasing away all the beginner's audience that obviously can't, will give up and even curse GM for making them powerless. Yet that beginner's base, as you say 'uneducated', makes nearly ALL of the users pool.

Seriously I'm baffled that this ability to use more refreshes on even non-VRR LCDs has been there for so many years and everyone unaware of it, it's yet another KILLER power feature of GM that shows how superior it is, afaik no other emulator does this, even the static method which is accessible to almost anyone is crushing all other variants of the emulator.
It allows people who play retro games to break free from the fixed 60Hz prison, even the static method as limited as it is a HUGE leap forward for any user.
Almost-to-actual-VRR without a full freesync/gsync setup? that friggin' MAGIC to a MAME user !
I don't know how long you've known about it, but if you have for a long time yet weren't aware how much users value that and how much popularity exposing it - and I mean both methods - and let people choose which they're going to go for, would have earned GM, then you're living in a dimension paralled to the user's.

I'm very much aware you're - as far as I'm concerned - the greatest contributor to MAME when it comes to the video performance and flexibility, and more! I've been following GM for years so of course I know, and I admire what you've done, but despite that you share with most devs/engineers (mamedev or not) a bit of their unawareness of the fact that it's you as a developer who should adapt to their condition/level if you expect to be understood and not clash with them, not the other way around, of course since almost all of them share no knowledge similar to yours.
If you can't measure how big the gap is and that it's you making a mistake when you get too technical too fast, again doing so you'll alienate too many users and your achievements will remain stuck in a niche where only a handful of people with enough level will ever use it and talk with you, basically remaining in a small bubble world, which is a shame considering the place GM deserves.

You can repeat "it's not GMs original intended use" if you want and limit your support if you are maybe unpleased with the perspective of seeing more people - mostly noobs - flocking around GM after they realize the FACT that it's also the greatest for LCDs but for some not in the manner you personally wish for.
But if you do wish for that yet another incredible side of GM to come out in the light and be known, then by all means listen to people like me, if you need a guinea pig for something it should be for writing those guides in a manner that works for even the layman starting from scratch.
This way people learn, it's the best way, show them everything without skipping portions and in the best understandable formulation (sometimes you suddenly use terms I have no idea about, latest: 'header', I don't know what that is). You can use me; ask me anytime if I understand and if I can do it, and listen every time I tell you I don't get it/can't - and don't misinterpret or make fun of my ignorance when it shows - that is if you plan to expand/refine your guide(s), of course.
In short if you don't know what people don't understand, use them to learn about their ignorance. I don't know if you've ever taught people, but trust me: half the job you learn it from your pupils.


TL;DR  ;D

To conclude;
- I've found the way to the static method on AMD's by deducing bits from here and trial-and-error. I haven't posted it yet, do you want me to tell it here and see about maybe arranging a writeup or did you already know but really don't want people to learn about it ?
- I'll gladly do the crt_emudriver method from scratch again this time being aware I'm a guinea pig, but only if you accept to listen when I tell you there's something I don't get/can't do and should be reformulated/redone in your guide, only if you keep in mind the knowledge/skill gap at all times. If you won't consider this then let's forget about that.
- Yes again I believe the Groovy for LCDs guide should be a multi-chapters one, starting with the basic 'monitor lcd' level (done), then static for nVidia (done) followed by AMD, then the full/VRR level one for crt_emudriver compatible AMD owners (done but definitely in need of some refinement IMO)
- On that topic; you said there was no problem coming from crt_emudrivers but since updating to the most recent AMD regular drivers I've witnessed something different and that could be important, are you interested in knowing what it is ?

--

@Paradroid; I won't answer your post because it's a school case of yet another person who assumes a ton of things really wrong about someone out of nothing but misuderstanding and prejudice.

--

Listen guys I'm not here to start a war against GM, it's exactly the opposite, I think it's so great, even greater now with what I've witnessed these few days, it's insane how much more powerful it is compared to other options, yet IMHO impaired by a too narrow perception of its worth and its potential audience, and that's SO frustrating.
« Last Edit: August 10, 2018, 08:23:23 am by schmerzkaufen »

B2K24

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
Re: Clarification on using GroovyMAME on a LCD
« Reply #76 on: August 10, 2018, 10:27:09 am »
For all the time you've taken to type up a meaningless post with basically no revelant information. If you instead spent that time going over Calamity's guide and carefully reading it very slowly and patiently, you would have probably solved all your issue by now.

If all else fails then get a - Component consumer grade TV + VGA->component transcoder and I promise you it will work

If I can make this work then anyone can
http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=301

It's extremely simple and you don't need to understand very much to get a very good end result.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #77 on: August 10, 2018, 12:09:39 pm »
Would you mind you own business ? it's a thread about using GM with LCDs, it's what I'm here for, so who's making a meaningless post here ?
And no relevant information ? clearly you didn't read. what a petty provocation.

I've read his guide multiple times thank you and there's stuff I didn't get at some point and still don't, which led to uconsequences yet unsolved for my part.

Now those reactions are annoying, am I going to get more condescending posts from random people who don't help me at all ?
I'll listen only to Calamity, he'll either say something or tell me 'nope no more and scram', that's all.
I don't care about random people playing the guard dogs or good groupies trying to make me pass for some bad guy, which I am not, I am very interested in this topic.

And I'm willing to stay on-topic, thanks.
« Last Edit: August 10, 2018, 12:14:29 pm by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #78 on: August 10, 2018, 01:48:47 pm »
- I've found the way to the static method on AMD's by deducing bits from here and trial-and-error. I haven't posted it yet, do you want me to tell it here and see about maybe arranging a writeup or did you already know but really don't want people to learn about it ?

Man, I've been explaining the static method since last week, the involved options have been explained by me and others. How can you say I don't want people to learn about it?

Anyway, if you'd like to arrange a writeup of course it's great. It's exactly the initiative to experiment and learn from trial and error what I like about users. You've found you're own way. Great! Share it with us.

Expect me to critizice what I find wrong or improvable and expect me to judge how others should do custom video because I've been thinking about this problem for the last decade.

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

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1911
  • Gotta have blue hair.
Re: Clarification on using GroovyMAME on a LCD
« Reply #79 on: August 10, 2018, 03:57:07 pm »
@Calamity

Would it make any sense to have two monitor settings for LCD...

LCD_Fixed
LCD_Multi

Or some other wording that makes more sense for the two use cases?
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #80 on: August 10, 2018, 05:26:10 pm »
Man, I've been explaining the static method since last week, the involved options have been explained by me and others. How can you say I don't want people to learn about it?
Dude are you serious? Nope, you've explained one that worked for nVidia then I've asked how to do the same with my AMD, tried, provided information about what i was doing, the issues and more questions, but you either answered partially or not at all, or frankly even opposed it invoking various reasons, so I was about to give up when you've posted your complete solution invloving crt_emudrivers.
Honestly the impression you gave me is that at times you were having a conversation with someone else, or maybe you assumed I was something I'm not (like, not a complete noob with no idea what he's doing)

Anyway, if you'd like to arrange a writeup of course it's great. It's exactly the initiative to experiment and learn from trial and error what I like about users. You've found you're own way. Great! Share it with us.
Tomorrow because it's late, but basically since it wouldn't work whether modelines generation was on or off, I've updated my existing game and driver inis to call for the various resolution modes I've created in the AMD panel individually every time.
Again; in full details tomorrow with some pics.

But honestly you have a weird fashion to deal with people, I don't think you really paid attention to me at the beginning and instead you pushed me into something that was above my level with the consequences we've seen. Very bad idea.
Instead you could have just helped me achieve the static method when I was asking repeatedly about it, then tell me you'd write about the better/complete one later, which I was going to try too of course as I've stated.
There would have been only gratefulness and no escalation towards a messup that ate up a lot of our time an nerves, and actually I think that if you had helped me with the static from the start it would have procured me some training, and you could have recommended me to take the time to get familiar with crt-emudriver plus all the tools and stuff in preparation for your upcoming guide which could have been anytime in the future anyway.
I didn't find that any of what happened afterwards was the result of initiative or whatever, I just had enough of being toyed around and I was lucky to achieve the static method, but that didn't hep me improve, I still only very vaguely comprehend what's going on.
You should rethink you way of dealing with noobs, because it's not good. Or if you dislike doing this explaining cto omplete noobs, just say no from the start.

Expect me to critizice what I find wrong or improvable and expect me to judge how others should do custom video because I've been thinking about this problem for the last decade.
Criticize a noob after you actually helped him graduate from his ignorance, and in a way that's not like pushing him down the stairs, or criticize people you know are on your level.
Tomorrow I'll show you what I've found, whatever you think of it even if you don't like it: either help make it better or shove it up your bottom.
You've dropped me there with the crt_emudriver method you chose to push me into, when I think I wasn't too far from getting it, your reply #66 was like slap and I was puzzled of why you even reacted like that, so I do not feel like I owe you.
« Last Edit: August 10, 2018, 05:34:25 pm by schmerzkaufen »

B2K24

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
Re: Clarification on using GroovyMAME on a LCD
« Reply #81 on: August 10, 2018, 06:07:20 pm »
so I was about to give up

Please do already.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #82 on: August 10, 2018, 06:20:00 pm »
@Calamity

Would it make any sense to have two monitor settings for LCD...

LCD_Fixed
LCD_Multi

Or some other wording that makes more sense for the two use cases?

Yes, that's a possibility.
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

rock145

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 140
Re: Clarification on using GroovyMAME on a LCD
« Reply #83 on: August 10, 2018, 06:21:16 pm »
I can see the benefits of these methods fixed and multi for lcd screens. I know that crt monitors are the best for groovymame, but there are people that don't have the space and crt are not produce anymore. I think the future is lcd whether we like it or not. I use groovymame on lcd's and find it much better than regular mame. I would really like something like this to work.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #84 on: August 10, 2018, 06:42:27 pm »
@schmerzkaufen, man, I have no words. Kill 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

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 584
    • SCART Hunter
Re: Clarification on using GroovyMAME on a LCD
« Reply #85 on: August 10, 2018, 07:56:15 pm »
@Paradroid; I won't answer your post because it's a school case of yet another person who assumes a ton of things really wrong about someone out of nothing but misuderstanding and prejudice.

Haha! The irony... you start the sentence by stating that you "won't answer" and then finish by making condescending assumptions about me. Sure, I had a crack at your impatience and petulance but there was also some good info in my post (including the irrefutable MAME data). I didn't take the time to put that together just to spite you, you know.

Out of curiosity, which part did you think I was prejudiced about? Your ignorance (which is fine... nobody starts out an expert) or your tedious verbosity?

It's not out of "misunderstanding and prejudice" either: your rants have provided plenty of grist for everyone's inbuilt sentiment analyzers.
My MAME/SCART/CRT blog: SCART Hunter

Amplifuzz

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #86 on: August 10, 2018, 08:30:25 pm »
Would it make any sense to have two monitor settings for LCD...

LCD_Fixed
LCD_Multi

Was about to suggest that as well.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #87 on: August 11, 2018, 03:55:14 am »
So here's how I got the static method to work despite using an AMD (apparently the issue is that contrary to the nVidia they can't use modeline generation or switch between the different output display resolution modes, I don't know the reason)

step 0: first I have installed the latest AMD drivers for my R7 (Adrenalin 18.8.1) which unlike the older Crimson I had and Emudrivers, straight away set the monitor to the correct 60Hz mode (which slightly differs from the one I previously had to create manually), tested on two other 60Hz monitors with same good result.

step 1: extract the modeline & crt_range from that default 60Hz mode using arcade osd, and modify it as explained in the first part of Calamity's guide

step 2: this is where it begins to diverge from the method for nVidia. I have edited the mame.ini like this;
Code: [Select]
modeline_generation       0
monitor                   custom
lock_system_modes         0
lock_unsupported_modes    0
crt_range0                56250-84375, 50.00-75.00, 0.593, 0.297, 0.998, 0.059, 0.074, 0.534, 1, 1, 1080, 1080, 0, 0
warning: of course don't write the same crt_range I did, again you have to extract and modify your own, which is explained in the first half of calamity's guide.

step 3: create custom resolutions in your AMD control panel, I have made 8 (54Hz, 55Hz, 56Hz, 57Hz, 58Hz, 59Hz, 61Hz, 62Hz) but you can make more or less as you need.
It's simple click + to add a new one, only change the general refresh you want then click save, the AMD software will adjust the timings by itself.

step 4: go to MAME's 'ini' folder and edit your individual game or source .ini's there (reminder: source ini's should be placed in a 'source' subfolder, those inis cover the whole range of games of a single hardware emulated by a mame driver, for instance 'cps2.ini')
There in each individual .ini, edit the following according to your game or source hardware refresh, for instance;
in Irem m72.ini
Code: [Select]
sync_refresh_tolerance    1
resolution                1920x1080@55
or in cave.ini
Code: [Select]
sync_refresh_tolerance    1
resolution                1920x1080@58
etc.
Do it for all the hardwares you need, one by one, ini by ini.

step 5 / NOTE: since of course few games fall exactly to round numbers refreshes, whether GM will sync to your created custom AMD refresh up or down the list, will depend on what you write and how narrow you've set your sync_refresh_tolerance (tip: you can set it even narrower than 1 Hz like 0.5)
For instance DoDonpachi runs at 57.55Hz, if you write @58 in the ini the game will lock to that and show 101% ingame when you press F11, if you write @57 the game will show 100% (despite being very slighly slowed down), even 99% with some games if the gap-down is a bit wider.
You will often have to make this choice: a tiny bit faster or slower refresh speed.
I've done this using 0.196 so the way to adjust might change in a future version, I don't know.

Of course it's far from being ideal, the static method is inferior to the one using crt_emudriver, and what I'm showing you here is only a patched-up configuration I found trying things at random, so maybe there's a better and simpler way to do it.
Anyway it works. I've tried a ton of games ranging from 54Hz to over 61Hz, and all could sync smoothly with less than 1% refresh speed deviation.


--

@Paradroid; no irony I was simply stating why I wouldn't reply.
Now since you ask it's simple, your post is a collection of wrong statements that show blantantly that you haven't read me at all and assume plenty of things, some borderline insulting.
.That I'm unaware of Calamity's specificity and value, and that he's wasted his/everyone's time on me (I remind you it was his choice, I only tried my best to follow precisely by respect and interst of course)
.Schooling me about GM's original purpose again which becomes tediouslike a scratched record, like I don't know, but that's not the point of this thread orherwise it wouldn't be and calamity would have ignored it
.Of course I'm aware of the difficulty, as I said I realize there are several levels of accessibility, rather it's you guys and this very tiny bubble-community who clearly are not aware of what it represents for complete noobs with no knowledge at all in this field and few to no computer/hardware skills. otherwise I think Calamity wouldn't have dragged me into something that was too high-level too soon, he must be too used being in an environment where the only people talking with him are already experienced and skilled.
.All your writeup that followed is the balatant demonstration that you're another one who haven't read me at all: everything you show here I know already, and I have stated so several times. Otherwise why would I have attempted to follow Calamity's guide? seems like B2k24 you found time to judge me and my attitude but not to read my posts/history in this thread.

I think this experience has enlightened me on why people stay away from GM saying it's incomprehensible, it's because the developer and the small cicrle of people around him apparently unknowingly to them are standing over the clouds and don't see the floor, so they don't really see and hear the reality below enough to understand it.
It's terrible being around a bunch of people like that, you're only half-heard/read, misunderstood and judged for things you haven's said, and so it's normal that it got on my nerves, I did considerable effort to try and communicate and to catch up (again I was trying very hard to follow Calamity's track) and the moment I lost my footing and messed up settings saying 'I dont get this part' I ended up with only refusal and bullies who clearly arrived to play calamity's defenders like I was attacking him, which is stupidly wrong.
Because I didn't like what he put me through and I think he did something a bit selfish using me as a guinea pig a bit forcefully then quitting as I failed, doesn't mean I don't understand  the value of his work and am not grateful for it all, I've stated how much I admire it several times, but unlike you guys because if I have something to criticize I'll say it, Calamity is awesome and I love GM, but he's not some nobility or king I am forced to always address in an positive-only, critics-free manner. I wasn't heard half as I should have in this thread and pushed around to disaster, this is what happened so I say it period.
Maybe you guys are trying to keep Calamity in a cotton cage, but I'm being true that's all, as much as I admire and support what he does and I keep wishing him success.
Maybe GM would need middle persons to make the bridge between you and the oustside world, because the communication is too painful for someone like me from out there.
Or never change and GM will always remain at the bottom niche level in this bubble place, and never stand in the position it deserves topping crap like Retroarch & Co.

As far as I am concerned with that I'm done and out, maybe my little contribution will help someone with an AMD who would want to use the static method, maybe it will be trashed by you guys no matter what considering the mentalities here, but I don't care.
(I wanted to make it more detailed and add pictures to make it better but the atmosphere put me off here and I've lost some of my motivation)
In the future I won't ask anyone anything nor share my views in this forum, and just go back to the lurker noob status, which I believe you will all be happy about. Ciao!
« Last Edit: August 11, 2018, 05:10:39 am by schmerzkaufen »

Amplifuzz

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16
  • I want to build my own arcade controls!
Re: Clarification on using GroovyMAME on a LCD
« Reply #88 on: August 11, 2018, 11:28:25 am »
Why do you need to tweak individual .ini files for game or platform? With Nvidia once everything is set every game just snaps to the nearest integer refresh value with no further configuration needed, even with refresh tolerance left at 2.0. I'm using GM 0.197.

Honestly, this stuff should've been in mainline MAME since the very first release, if the goal was accurate arcade emulation. While I respect that GM is heavily CRT focused, it's great there's finally a sensible way to do it.


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #89 on: August 11, 2018, 12:10:01 pm »
Why do you need to tweak individual .ini files for game or platform?

GM best mode picking is optimized for modeline generation. When the modeline generation option is disabled, it doesn't work very well because internally it still behaves as if it could adjust the refresh in the last step, so it doesn't take the existing refresh as the first condition to select modes.

As I mentioned earlier in this thread, for next version I've modified how this is handled so now when modeline generation is disabled, the existing refresh rate will have preference over other considerations.

This way it will work as intended, automatically.

The extra adjustment you made to hfreqmin will be unnecessary now too.

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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #90 on: August 11, 2018, 12:24:10 pm »
Honestly, this stuff should've been in mainline MAME since the very first release, if the goal was accurate arcade emulation. While I respect that GM is heavily CRT focused, it's great there's finally a sensible way to do it.

I think you guys are a bit confused about this. Mainline MAME supports this already.

You can add custom modes to your system with any of the existing tools (gpu's control panel, CRU). MAME will pick them later as long as you use its native -switchres option. In case it fails to choose your desired mode, just force it in an ini.

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: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #91 on: August 12, 2018, 01:25:46 pm »
I've uploaded a video to better illustrate the guide of infamy: https://www.youtube.com/watch?v=N6c32mp_VoQ

(If anyone knows a free program to do zoom in videos please let me know. Nothing fancy, just zoom)

With regards to the general method (static), GroovyMAME 0.200 enhances mode selection when modeline generation is disabled. Still no "lcd_multi" thing but things should work smoothly as long as you create a proper crt_range0, as it's been explained in the first posts.


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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #92 on: August 13, 2018, 12:35:31 pm »
So I've tried the static with 0.200 but it doesn't seem to work within certain ranges for me here, tried the below games, when they don't work it means the games run (sound can be heard) but I can only see a black screen.
On the other hand if I set the resolution & refresh in a game or source ini, it works normally. This behaviour is similar to 0.196



Reminder I'm using Adrenalin 18.8.1, which I previously said set itself to 60Hz by default but it was a fake/bastard '60p 59.939' accroding to arcade osd.
so I remade a custom in AMD cpl which this time is 60p 60.000, then extracted the base modeline & range from it.
Here it is;
The modified version is in my mame.ini (attached)
Code: [Select]
modeline "1920x1080_60 67.50KHz 60.00Hz" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
crt_range 67490.00-67510.00, 50.00-60.00, 0.593, 0.296, 0.997, 0.059, 0.074, 0.533, 1, 1, 1080, 1305, 2160, 2610
My currently available modes;


I've attached 4 logs labelled 'black' when there's no image, plus 2 of games displaying normally.
haven't made any with games 'fixed' by the presence of an edited game or source ini, but I can add some if you need them.
« Last Edit: August 13, 2018, 12:40:47 pm by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #93 on: August 13, 2018, 01:04:31 pm »
haven't made any with games 'fixed' by the presence of an edited game or source ini, but I can add some if you need them.

Yes, I'd need to see one log that's been fixed.

Internally, it's picking the right modes in every individual case. Have you tried each of the modes in Arcade OSD to check if they produce a black screen in there?
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #94 on: August 13, 2018, 01:22:05 pm »
As you can see in the chart I have tried all those games, some run normally picking the right mode and playing smooth, some run but with no picture, apparently identically to what I've experienced in 0.196

edit; ah and if you meant directly in arcade osd one by one, yes they all display the grid+hue, no exception

logs attached with the inis that 'fix' the issue.
« Last Edit: August 13, 2018, 01:26:41 pm by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #95 on: August 13, 2018, 01:34:39 pm »
Ok, the logs look virtually identical when compared with the non-fixed version, with regards to mode selection.

Could you test esprade making absolutely sure that in GM's folder there is only one single ini: mame.ini, I mean moving the whole ini folder out of MAME's folder temporarily and just leaving mame.ini where the resolution setting is 1920x1080@0.
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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #96 on: August 13, 2018, 01:48:20 pm »
Yes, no difference. Actually I've tried it before. Also with reverting the resolution@refresh to 'auto'; no difference.

Honestly I don't mind making ini's for all systems that have the black screen problem, rather what's annoying when using inis higher than mame.ini (game.ini or source.ini) is that when you select a new game from the MAME integrated UI, it exits the game and you're back to the list, click on a different one and...the ini settings of the previous game are applied, including the resolution@refresh that's carried over. The only way to 'flush' is to restart MAME (they're aware of that flaw but I don't know the status)

edit: yes since you're gonna ask of course I've minded that when I was trying all the games
« Last Edit: August 13, 2018, 01:50:52 pm by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6082
Re: Clarification on using GroovyMAME on a LCD
« Reply #97 on: August 13, 2018, 02:09:23 pm »
The thing is that using inis shouldn't be required because GM is actually picking the same resolution you're forcing in your ini (you can see it in your logs), however for some reason this resolution doesn't end up being switched to.

And if it was a problem with the resolution itself, it should happen exactly the same whether the resolution is forced or not.

That's why I was thinking of an ini priority issue (quite easy to fall into this, we had a similar issue the other day with another user that ended up being this).

Otherwise it's an odd internal bug related to D3D9ex which obviously doesn't happen here or it'd be fixed already. Just in case I'd test the plain D3D build.

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
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #98 on: August 13, 2018, 02:21:51 pm »
Just in case I'd test the plain D3D build.
I'll try with it later.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #99 on: August 13, 2018, 03:04:36 pm »
^ Just did...produced exactly the same results. *scratching head*
So maybe it's a MAME/MEWUI or AMD thing.

Makes the static method a bit less convenient than with an nVidia but heh, even if it requires specific inis and restarts between games, it's still amazing that this method syncs all games smooth with very little refresh speed deviation, on a random non-free/gsync monitor.

Anyway there's of course the crt_emudriver advanced solution, which I'll retry some time in the future with your video (thanks a ton for that btw).

rock145

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 140
Re: Clarification on using GroovyMAME on a LCD
« Reply #100 on: August 17, 2018, 05:14:05 pm »
Can somebody test this method with an lcd tv. I see the some tvs have 120hz clearmotion is that the same as 1080p@120?

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #101 on: August 19, 2018, 04:38:18 am »
TVs and monitors alike; different models will yield different results, so if someone just tells you "yeah works great with mine" unless you have the same model (or at least same brand and series) it won't help you much.

'clearmotion' 'trumotion' etc are just marketing terms for what's usually heavily processed blur reduction. If you want to know if a set actually supports real 120Hz from a source like a PC you need to check in a test review, like on rtings.com at 'supported resolutions'.
They're few models, and you'll see that currently it's only 1080p@120Hz scaled over 4K panels anyway.

As for GM we were talking about supporting native game refreshes the likes of 54Hz or 58Hz, but are you asking if GM can do variable doubled refreshes over one of those 1080@120 capable 4K TVs? like 108Hz or 116Hz?
If so WOW. I'm no specialist but that sounds a bit far-fetched, until true 4K@120Hz TVs become a thing you have better chances in the realm of monitors, I think...

(lastly: are higher doubled refreshes really useful for these old games anyway? unless it's for adding black frame insertion I wonder if the benefits are really there)

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 146
  • I want a large cream coffee
Re: Clarification on using GroovyMAME on a LCD
« Reply #102 on: October 06, 2018, 02:34:48 pm »
UP!

So with GM 202 d3d9ex set for using the static method, for the past couple of hours I've been through a florilege of roms of various refreshes, and clearly Calamity fixed the issue that was preventing AMD GPU users to use only a fixed number of custom resolutions from their stock drivers control panel without needing a ton of specific ini files, it works like with the nVidia GPUs now.  :applaud:

I've used only the mame.ini then, set for the static method like before (modeline generation off again since I have an AMD, though I don't know if I still need to do that)

Note my R7 is still running under 18.8.1, I can update to 18.9.3 (optional) or downgrade to 18.5.1 (recommended) and redo the test if you want to confirm it's fine too with other versions of the stock AMD driver.
« Last Edit: October 06, 2018, 02:51:44 pm by schmerzkaufen »

  
 

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