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 3663 times)

0 Members and 1 Guest are viewing this topic.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 222
  • 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: 6198
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: 6198
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
  • ***
  • Online Online
  • Posts: 617
    • 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
  • ***
  • Offline Offline
  • Posts: 222
  • 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: 6198
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: 6198
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: 6198
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
  • ***
  • Offline Offline
  • Posts: 222
  • 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: 6198
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
  • ***
  • Offline Offline
  • Posts: 222
  • 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: 6198
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
  • ***
  • Offline Offline
  • Posts: 222
  • 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: 6198
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
  • ***
  • Offline Offline
  • Posts: 222
  • 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
  • ***
  • Offline Offline
  • Posts: 222
  • 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
  • ***
  • Offline Offline
  • Posts: 222
  • 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
  • ***
  • Offline Offline
  • Posts: 222
  • 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