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 Try the site in https mode Site News

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

  

Author Topic: Groovymame with opengl shaders  (Read 2962 times)

0 Members and 1 Guest are viewing this topic.

Cisek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 104
  • Last login:May 19, 2023, 07:35:14 am
Groovymame with opengl shaders
« on: March 22, 2016, 09:50:32 pm »
Hi

I have lcd monitor HP LP2065 monitor which is capable of multisyncing. I am using it with standard mame and lottes shader and I am really pleased with how accurate it looks.
The question is: Is it possible to use groovymame custom timings with 1600x1200 resolution and lottes shader (opengl only?).

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 792
  • Last login:April 16, 2025, 09:46:43 am
  • Multiple Electronic Machine Emulator
Re: Groovymame with opengl shaders
« Reply #1 on: March 23, 2016, 06:12:15 am »
? I don't know of any fixed matrix capable of multi-syncing, people often mistake compatibility via upscanning/upscaling with real multisyncing, which involves pure free syncing of native signals without any conversion steps.
Technically the only displays that are 'kind of' capable of it besides CRTs, and though by using 'special' hard/soft means + obligatory upscaling when not 1:1, are G/F-Sync monitors.
The few lcd monitors around that accept more signals than the common lcd monitor/tv just feature more flexible built-in scalers, those are typically old models, I'm used to read about that 'multisync lcd' misconception here and there, from oldies computer forums for instance.

So yeah you can probably apply a certain range of custom timings but they'll get converted anyway when they're not matching the one or two modes the monitor is actually, really capable of displaying without conversion.
Using ogl w/ a shader doesn't have any influence on this matter, afaik.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7463
  • Last login:July 19, 2025, 04:03:33 am
  • Quote me with care
Re: Groovymame with opengl shaders
« Reply #2 on: March 24, 2016, 12:01:53 pm »
The question is: Is it possible to use groovymame custom timings with 1600x1200 resolution and lottes shader (opengl only?).

That enterely depends on your graphic card. Currently only AMD cards are supported, although if you happen to own an old Nvidia card GroovyMAME might be able to drive it through the Powerstrip api.
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 of pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7463
  • Last login:July 19, 2025, 04:03:33 am
  • Quote me with care
Re: Groovymame with opengl shaders
« Reply #3 on: March 24, 2016, 12:17:09 pm »
So yeah you can probably apply a certain range of custom timings but they'll get converted anyway when they're not matching the one or two modes the monitor is actually, really capable of displaying without conversion.
Using ogl w/ a shader doesn't have any influence on this matter, afaik.

This is not fully true.

If you take your reasoning through reductio ad absurdum, because LCDs only support one native refresh, the slightest deviation from that refresh, I mean tenths of Hz, would cause skipped or duplicated frames. This certainly doesn't happen, even if your card never actually outputs exactly 60 Hz, but something barely close to 60 Hz (59.8, 60.2 Hz, etc).

This means the monitor is actually supporting *a range* of frequencies, even if a narrow one. And I don't mean it just accepts them fine but then ouputs a fixed refresh rate, I mean it's outputting the real input frequency.

We made extensive tests about this years ago in this forum. Some monitors supported stuff about 60 +-1 Hz, then had an isolated working range at 57 Hz, etc. Others, specially older ones, supported the whole 50-60 Hz continuous range natively.

I used to have a VAIO laptop whose internal LCD would do the whole range. I remember reading something about their LVDS pcb being so simple, or maybe it was meant as a way to extend battery life.

If someone figures out how to hook recycled laptop's LCDs properly they could be good for bartops builds. Laptops die all the time and they're fully functional screens end up in the trash bin.
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 of pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 792
  • Last login:April 16, 2025, 09:46:43 am
  • Multiple Electronic Machine Emulator
Re: Groovymame with opengl shaders
« Reply #4 on: March 24, 2016, 01:41:54 pm »
Yes you're right about the accepted small deviations on modern models but really that's not enough to fit the 'multi-sync display' definition so I didn't mention it.

Regarding those old models I'm aware they existed but I'm not convinced those didn't use some form of framerate conversion internally. Not saying people are imagining things, but it's supposed to be immensely more simple to do that rather than designing a lcd capable of adjusting its electrical properties on the fly accross over many Hz like that, or having a crapton of preset and precalibrated modes in memory.

One thing I've always doubted (and I'm eyeing at nVidia) is that a well-working effective framerate conversion circuit was never that complicated nor expensive to build, I believe AMD are already exploiting what many available internal boards boards can do, which is probably something close to what those old monitors did.

Anyway for me the matter hasn't been completely demystified yet, it's just that I'm extremely sceptic because in over a decade I've used and tried a lot of flat panel displays and know how limited those are in that area, always changing something somewhere in the signal because you're too quickly out of range.
So in a way every time I read someone claiming "my lcd can multi-sync" I'm like "yeah..."

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7463
  • Last login:July 19, 2025, 04:03:33 am
  • Quote me with care
Re: Groovymame with opengl shaders
« Reply #5 on: March 24, 2016, 02:01:42 pm »
Regarding those old models I'm aware they existed but I'm not convinced those didn't use some form of framerate conversion internally. Not saying people are imagining things, but it's supposed to be immensely more simple to do that rather than designing a lcd capable of adjusting its electrical properties on the fly accross over many Hz like that, or having a crapton of preset and precalibrated modes in memory.

It's quite the opposite. LCD panels support arbitrary refresh rates natively (the refresh rate concept comes from the CRT world). You have to add electronics purposely to post-process incoming frequencies. That's probably why older, simpler models just could deal with more frequencies.

We already had this debate with one of the most remarkable trolls this forum has seen: http://forum.arcadecontrols.com/index.php/topic,97200.msg1190726.html#msg1190726

I made thorough tests back then, but unfortunately the pics are lost forever.
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 of pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 792
  • Last login:April 16, 2025, 09:46:43 am
  • Multiple Electronic Machine Emulator
Re: Groovymame with opengl shaders
« Reply #6 on: March 24, 2016, 03:22:54 pm »
Interesting theory (and heated debate lol), though I haven't read everything I suppose the idea is that not all of the signal information is required to 'grab' and display a full frame, or the circuit is just 'cheating' in cases making some values appear as others known instead of converting.
It's a grey area but that would explain lot of things about how it worked 'in the days', and maybe it's the advent of consumer HD video standards and economies of scale that have changed things for the worse, dunno.
Anyway we shouldn't delve too much into this because we could end up finding proof one of those days that nVidia and AMD are making even more scandalous money from gamers selling them an almost 20 years old technology with a new name brand slapped on it.  ;D

PS: we should alway keep pics on dusty old hard drives, even from a decade ago. ^^

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7463
  • Last login:July 19, 2025, 04:03:33 am
  • Quote me with care
Re: Groovymame with opengl shaders
« Reply #7 on: March 24, 2016, 03:52:02 pm »
Interesting theory (and heated debate lol), though I haven't read everything I suppose the idea is that not all of the signal information is required to 'grab' and display a full frame, or the circuit is just 'cheating' in cases making some values appear as others known instead of converting.

Nooooo  :lol

It is a fact, not a theory. You don't need complicated explanations, just apply Occam's razor. I've seen it with my eyes. The monitors weren't cheating, the proof was the scrolling was smooth in all cases. Newer monitors didn't scroll smoothly at refresh rates other than 60 on the same tests.

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 of pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 792
  • Last login:April 16, 2025, 09:46:43 am
  • Multiple Electronic Machine Emulator
Re: Groovymame with opengl shaders
« Reply #8 on: March 24, 2016, 04:11:36 pm »
Okay okay okay (Joe Pesci voice)  :D

Anyway it's a matter of definition and time, since what those old displays did was not 'multisync' so but something else then since it's not required, and they're unfortunately no longer built and sold with that kind of circuitry (building setups around lcd monitors a decade old or more isn't particularily exciting).

What would be exciting would be workarounds/mods on modern day ones to force them to do that again.
Conspiracy theory: it's not like manufacturers source hundreds of different boards/chips for their cheap lcdisplays, one mod could work on half the available monitors or tvs out there.  :P
« Last Edit: March 24, 2016, 04:13:07 pm by schmerzkaufen »