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
Lightguns Arcade1Up --- Bug Reports --- Site News

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

  

Author Topic: Prioritizing refresh over resolution?  (Read 541 times)

0 Members and 1 Guest are viewing this topic.

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:Today at 06:24:08 pm
  • I want to build my own arcade controls!
Prioritizing refresh over resolution?
« on: February 17, 2016, 07:51:00 am »
Hi. Wanted to know if it's possible to prioritize the refresh rate over the resolution.
For example, if a game runs in 320x256@58Hz it will still choose 2560x256 even if the maximum refresh rate possible for that resolution is 56Hz.
I was hoping it would choose an interlaced mode, so the refresh rate will be correct.
EDIT: I should also mention that i am using several crt ranges.
« Last Edit: February 17, 2016, 08:03:55 am by Foxhole »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6634
  • Last login:Today at 11:56:02 am
Re: Prioritizing refresh over resolution?
« Reply #1 on: February 17, 2016, 08:27:15 am »
Post your ranges so I can see how to do it.
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

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:Today at 06:24:08 pm
  • I want to build my own arcade controls!
Re: Prioritizing refresh over resolution?
« Reply #2 on: February 17, 2016, 08:47:25 am »
Here:
crt_range0                15625-15734.26, 59.00-62.00, 2.500, 4.634, 6.780, 0.064, 0.160, 1.056, 1, 1, 184, 240, 448, 480
crt_range1                15625-15734.26, 58.00-59.00, 2.500, 4.634, 6.780, 0.464, 0.160, 0.956, 1, 1, 192, 240, 448, 480
crt_range2                15625-15734.26, 57.00-58.00, 2.500, 4.634, 6.780, 0.764, 0.160, 0.956, 1, 1, 192, 240, 448, 480
crt_range3                15625-15734.26, 56.00-57.00, 2.500, 4.634, 6.780, 0.864, 0.160, 0.856, 1, 1, 192, 248, 448, 496
crt_range4                15625-15734.26, 55.00-56.00, 2.500, 4.634, 6.780, 1.064, 0.160, 0.656, 1, 1, 192, 256, 448, 512
crt_range5                15625-15734.26, 54.30-55.00, 2.500, 4.634, 6.780, 1.064, 0.160, 0.656, 1, 1, 192, 256, 448, 512
crt_range6                15450-15734.26, 54.00-54.30, 2.500, 4.634, 6.780, 1.064, 0.160, 0.656, 1, 1, 192, 256, 448, 512
crt_range7                15250-15734.26, 53.00-54.00, 2.500, 4.634, 6.780, 1.364, 0.160, 0.456, 1, 1, 192, 264, 448, 512
crt_range8                15625-15734.26, 52.00-53.00, 2.500, 4.634, 6.780, 0.064, 0.160, 2.156, 1, 1, 192, 264, 448, 512
crt_range9                15625-15734.26, 49.00-51.99, 2.500, 4.634, 6.780, 0.064, 0.160, 1.056, 1, 1, 192, 288, 448, 576

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6634
  • Last login:Today at 11:56:02 am
Re: Prioritizing refresh over resolution?
« Reply #3 on: February 17, 2016, 12:01:59 pm »
Good question. This is not possible in a clean way right now. Because the problem is likely to be exposed only by vertical games, my suggestion is to create a vertical.ini file and copy your preset in there, limiting all ranges progressive max to 248.

Currently there's an option named -sync_refresh_tolerance that is used by the modeline generator to mark a certain mode as being "vfreq-off", but that doesn't prevent it to be used, because most users would rather keep using that progressive mode rather of an interlaced one, and the "vfreq-off" flag is used to trigger triplebuffer.

My aim since long has been to split this option into two separate options: -refresh_tolerance & -syncrefresh_tolerance. This way you could use -refresh_tolerance to discard modes completely.
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

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:Today at 06:24:08 pm
  • I want to build my own arcade controls!
Re: Prioritizing refresh over resolution?
« Reply #4 on: February 17, 2016, 02:18:25 pm »
Good question. This is not possible in a clean way right now. Because the problem is likely to be exposed only by vertical games, my suggestion is to create a vertical.ini file and copy your preset in there, limiting all ranges progressive max to 248.

Currently there's an option named -sync_refresh_tolerance that is used by the modeline generator to mark a certain mode as being "vfreq-off", but that doesn't prevent it to be used, because most users would rather keep using that progressive mode rather of an interlaced one, and the "vfreq-off" flag is used to trigger triplebuffer.

My aim since long has been to split this option into two separate options: -refresh_tolerance & -syncrefresh_tolerance. This way you could use -refresh_tolerance to discard modes completely.
About the vertical ini, that's exactly what i've done for the time being. In my case the problem also applies to horizontal games, since i changed the timings.
The -refresh_tolerance sounds like an excellent way to approach this.
« Last Edit: February 17, 2016, 02:24:52 pm by Foxhole »