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: CabMame  (Read 61411 times)

0 Members and 1 Guest are viewing this topic.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #160 on: March 18, 2011, 09:44:43 pm »
Calamity,

Think it's fixed in 011, both issues most likely.  I just found the glaring error of my previous attempt to fix it, and at least confirmed it will really pick the exact match if it exists, where before it would not have.  Also the debug output at least will be even better at showing possible problems, if it still doesn't pick the right resolution.  Oddly I don't get why the fuzzy match ever picked an exact match, because from what I can tell the width was always going to be at least 8 pixels more.  Yet there may be something fishy still happening so I'm looking into it closer, but curious of course to see if this really fixes it there for your setup.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #161 on: March 20, 2011, 08:16:25 am »
New version 011 works great here, no problem with any game I've tested so far (quite a lot), so for me this version is already perfect, I mean it does all what Switchres does but with the changeres functionallity added (and all the other CabMame patches too).

Just curious of some new debug messages in the log like this one:
SwitchRes: Failed scanning registry modeline label DALDTMCRTBCD184X208X0X60, using values 184x208instead

It's strange as everything seems to work fine so could be a false error message or something?
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

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #162 on: March 20, 2011, 08:32:22 am »
New version 011 works great here, no problem with any game I've tested so far (quite a lot), so for me this version is already perfect, I mean it does all what Switchres does but with the changeres functionallity added (and all the other CabMame patches too).

Just curious of some new debug messages in the log like this one:
SwitchRes: Failed scanning registry modeline label DALDTMCRTBCD184X208X0X60, using values 184x208instead

It's strange as everything seems to work fine so could be a false error message or something?

Cool, I was hoping that last change fixed the two issues.

That error message is interesting, it means that there was a failure scanning the registry label for the values so it uses the actual vactive/hactive values instead.  Not something that is going to hurt anything, but the question is why does it fail to scan that string into the height/width/refresh integer values.    I guess it's good I added that warning, seems like something needs to be perfected there.  Does it do it every single registry entry or just a few?  

Update: Ah I see the logfile :) I fixed it, it's that your registry lines use capitol X instead of lowercase x like Soft15khz ones do which is how I test it.  I just added the fix to git, not probably a bug but more of an annoying warning message.  I'll update with the fix here in a second as 011a to test there and make sure it works right.
« Last Edit: March 20, 2011, 08:42:04 am by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #163 on: March 20, 2011, 01:21:45 pm »
Well, things work perfect here now, no more debug error messages, I've attached the log. I agree it's good to have all that debugging info there, it will help in the future.

There's room for improvement in the Windows changeres method, I'll do some tests in case I can make it smoother, at the moment you can see Mame's window for an instant during resolution switching. However, I'm pretty sure this method is much more stable than the original one, so I'll see if I can get rid of some stuff inside the toogle_fullscreen function if it's possible.

I'm interested in how you achieved SDL reading the new modelines, did it need any kernel change or was it all done inside Mame code?
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

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #164 on: March 20, 2011, 01:30:08 pm »
Well, things work perfect here now, no more debug error messages, I've attached the log. I agree it's good to have all that debugging info there, it will help in the future.

There's room for improvement in the Windows changeres method, I'll do some tests in case I can make it smoother, at the moment you can see Mame's window for an instant during resolution switching. However, I'm pretty sure this method is much more stable than the original one, so I'll see if I can get rid of some stuff inside the toogle_fullscreen function if it's possible.

I'm interested in how you achieved SDL reading the new modelines, did it need any kernel change or was it all done inside Mame code?


Sounds good.  It was a simple one line change in the SDL library, just adding the function to read the system modelines when the ListModes X11 call is made (usually that only happens when SDL is initialized).  That was really all it needed, I had been fighting it for quite awhile thinking it might be something else, but they really allocate a static list of modelines in SDL at init and they usually never update again.  From there it's just at the same point in window.c when it detects the resolution change from the emu/render.c flagging of changeres, I sort of do my own version of checking the SDL resolutions and finding the correct one, feed that into the resize function.  It was quite interesting making it work, actually both the Linux and Windows versions to quite different yet similar things.  Have to admit it was more fun than I thought it would be and feel a lot better now about the general resolution switching since it's recursive now and generally seems to have worked out many of the bugs by requiring it to be capable of getting called multiple times.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #165 on: March 22, 2011, 01:43:07 pm »
I'm testing this patch (over the new groovymame one) to see if changeres can be smoother now, I'm rescuing the original patch by Sailorsat but placing it inside the window thread message processing function, creating a new custom message WM_USER_CHANGERES.

Code: [Select]
diff -Nru b/src/osd/windows/window.c c/src/osd/windows/window.c
--- b/src/osd/windows/window.c 2011-03-22 18:23:17.000000000 +0100
+++ c/src/osd/windows/window.c 2011-03-22 18:24:55.000000000 +0100
@@ -103,6 +103,7 @@
 #define WM_USER_SET_MINSIZE (WM_USER + 5)
 #define WM_USER_UI_TEMP_PAUSE (WM_USER + 6)
 #define WM_USER_EXEC_FUNC (WM_USER + 7)
+#define WM_USER_CHANGERES (WM_USER + 8)
 
 
 
@@ -920,10 +921,6 @@
  window->maxheight =
  window->machine->switchRes.bestMode.a_height;
 
- // Change resolution
- winwindow_toggle_full_screen();
- winwindow_toggle_full_screen();
-
  // Reset old video modeline
  if (window->machine->switchRes.resolution.count > 1) {
                 ModeLine DesktopMode;
@@ -945,9 +942,10 @@
  window->machine->switchRes.resolution.width;
  window->maxheight =
  window->machine->switchRes.resolution.height;
- winwindow_toggle_full_screen();
- winwindow_toggle_full_screen();
  }
+
+ // Change resolution
+ SendMessage(window->hwnd, WM_USER_CHANGERES, 0, 0);
  }
 
  // see if the target has changed significantly in window mode
@@ -1684,6 +1682,11 @@
  case WM_USER_SET_FULLSCREEN:
  set_fullscreen(window, wparam);
  break;
+
+ case WM_USER_CHANGERES:
+ (*draw.window_destroy)(window);
+ (*draw.window_init)(window);
+ break;
 
  // minimum size set
  case WM_USER_SET_MINSIZE:

I'll try this later on my cab and let you know if it works.

Update: I've done basic testing with this patch and looks stable with multithreading on, and it's actually smoother during resolution switching (you won't see the window minimized for an instant any more).

« Last Edit: March 22, 2011, 05:22:20 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 of pasting it.

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

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #166 on: March 23, 2011, 12:16:46 am »
Update: I've done basic testing with this patch and looks stable with multithreading on, and it's actually smoother during resolution switching (you won't see the window minimized for an instant any more).

Looks great, I applied the patch to git, and am uploading builds with these changes.

retrorepair

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #167 on: March 23, 2011, 05:31:32 pm »
Great work both of you, it works great now.  :applaud:

Only thing I noticed is G-Darius now starts off in a progressive mode then when the intro kicks in switches to an interlaced mode. I'm pretty sure it shouldn't, at least the old cabmame didn't.

Everything else I tried is great though :)
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #168 on: April 07, 2011, 11:03:10 pm »
Would there be any value in adding in the SmoothMAME 60Hz patch?

(check out the thread, then read the last post for an update)

http://www.mameworld.info/ubbthreads/showflat.php?Number=207738
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

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #169 on: April 07, 2011, 11:24:11 pm »
Would there be any value in adding in the SmoothMAME 60Hz patch?

(check out the thread, then read the last post for an update)

http://www.mameworld.info/ubbthreads/showflat.php?Number=207738

Interesting, I'll look at how that works and see if that can be non-obtrusively setup as an option.  Looks good for people that either don't have a supported video card for custom modelines, or a LCD monitors fixed at 60hz.  It would be interesting to change this around slightly to basically look at the available refresh rates and alter the game to those, instead of being hard wired at 60hz.  Definitely like the thread states, a non-arcade accurate hack, yet looks like something useful when there's no other choice with the hardware available.

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #170 on: April 08, 2011, 12:48:50 am »
From what I understand, even with a 15KHz arcade monitor and an ArcadeVGA, there will be games that have issues because they have a higher refresh rate than your arcade monitor.  I think this is supposed to cap everything at 60Hz to eliminate that possibility.
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

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #171 on: April 08, 2011, 12:18:17 pm »
Would there be any value in adding in the SmoothMAME 60Hz patch?

(check out the thread, then read the last post for an update)

http://www.mameworld.info/ubbthreads/showflat.php?Number=207738

Interesting, I'll look at how that works and see if that can be non-obtrusively setup as an option.  Looks good for people that either don't have a supported video card for custom modelines, or a LCD monitors fixed at 60hz.  It would be interesting to change this around slightly to basically look at the available refresh rates and alter the game to those, instead of being hard wired at 60hz.  Definitely like the thread states, a non-arcade accurate hack, yet looks like something useful when there's no other choice with the hardware available.

The other day I was using some old VESA diagnostic utilities and it showed different refresh rates for different resolutions on my laptop's LCD, all the way from 53.xxHz to 60.xxHz, although I think that was an error, possibly due to WinXP.

Obviously I too am convinced PC LCDs do have truly fixed refresh rate, at 60Hz. However, my conclusion is rather based on the lack of information than anything else. Most LCDs are being sold without any specification given for their refresh rate as if there is some unspoken rule or is somehow self-implied, that they all run at fixed 60Hz. But then, I do not see any practical reason why they could not vary their refresh rate, so I am going to get another LCD and test it all again but this time from both Windows and DOS, and Linux if I can find any such diagnostic tools.


Anyway, in that case LCDs could only do authentic vertical refresh rate if the game's refresh rate is also 60Hz exactly, or they could force games to have 60Hz updates by slowing them down or speeding them up to 60Hz, which is the only good looking and proper way to do away with it. Anyhow else trying to fix this situation is just as artificial and ugly hack as digitally interpolating/extrapolating frames, i.e. making non-existing frames out of thin air or deleting existing ones and trying to arrange what's left evenly over time.

http://en.wikipedia.org/wiki/Telecine

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #172 on: April 08, 2011, 12:24:50 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #173 on: April 08, 2011, 12:26:00 pm »
Bitbytebit, and to whomever it may concern,


Rather than trying to "fix" MAME, would you be interested to fork off another project, something like AdvanceMAME + SmoothMAME + FastMAME, only better, faster and simpler?

I already started the project and reached interesting point. I took MAME 0.88, for various reasons, and completely stripped it from EVERYTHING but core engine. I think around 70% went out yet it still can play games, and about 15% faster. Then I went and simplified drawgfx.c with intention to convert all the graphics data structures (sprites and tiles) into OpenGL textures and actually re-write the core drawing engine to support hardware acceleration and 3D in the very heart of graphics emulation.
 
However, at this point I realized that my empty Windows application, either OpenGL or DirectX, can not reach over 2000fps with nothing going on there but printing the fps on the screen, while VAntAGE emulator for DOS can run Galaga at 6000fps!!!!

I can not explain it, I barely believe myself, why and how can Windows application, or any of those APIs, come with such monstrous overhead, but that's how it is. So, I am now wondering should I go 15 years back in time and instead of using modern video hardware capabilities just do MAME re-write for VESA standard and actually make it several orders of magnitude FASTER. Unbelievable!


Anyway, would you be interested in such project, either OpenGL (SDL) or VESA based? My real goal is to make it really compact and simple so to be portable to mobile platforms, but beside speed and size my main concerned is smooth animation and authentic gameplay, so this should be something you would want to put in both, your arcade cabinet (with cheap old computer) and your shiny new mobile phone. How about it?



bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #174 on: April 08, 2011, 12:43:22 pm »
Bitbytebit, and to whomever it may concern,


Rather than trying to "fix" MAME, would you be interested to fork off another project, something like AdvanceMAME + SmoothMAME + FastMAME, only better, faster and simpler?

I already started the project and reached interesting point. I took MAME 0.88, for various reasons, and completely stripped it from EVERYTHING but core engine. I think around 70% went out yet it still can play games, and about 15% faster. Then I went and simplified drawgfx.c with intention to convert all the graphics data structures (sprites and tiles) into OpenGL textures and actually re-write the core drawing engine to support hardware acceleration and 3D in the very heart of graphics emulation.
 
However, at this point I realized that my empty Windows application, either OpenGL or DirectX, can not reach over 2000fps with nothing going on there but printing the fps on the screen, while VAntAGE emulator for DOS can run Galaga at 6000fps!!!!

I can not explain it, I barely believe myself, why and how can Windows application, or any of those APIs, come with such monstrous overhead, but that's how it is. So, I am now wondering should I go 15 years back in time and instead of using modern video hardware capabilities just do MAME re-write for VESA standard and actually make it several orders of magnitude FASTER. Unbelievable!


Anyway, would you be interested in such project, either OpenGL (SDL) or VESA based? My real goal is to make it really compact and simple so to be portable to mobile platforms, but beside speed and size my main concerned is smooth animation and authentic gameplay, so this should be something you would want to put in both, your arcade cabinet (with cheap old computer) and your shiny new mobile phone. How about it?




I'd definitely be interested in porting the changes to resolution switching/calculation into such a project, including it in the Groovy Arcade Linux as an alternative to the current groovymame.  Not tons of time to branch off into more than what I'm currently undertaking, but sounds like if you have your project in a git repository available I'd be poking around at it and trying to create patches to submit to you adding in any extra arcade monitor functionality or other modeline/resolution improvements.  I'd say open it up and see where it goes, I'd definitely feel like things like the smoothmame patch would be nicer to work into something like that.  After looking at the smoothmame patch, it does look like less of something I want to put into my patches to current mame since it makes some core changes to defines that would be hard to keep current to a moving target, so more suited to something like this that was forked permanently.  I like groovymame for keeping current, and so something like this sounds interesting to have for everything else to go that can't be kept current without constantly re-factoring patches each release.  I have all the code mostly in separate files in groovymame, so it's concise and simple in how it's modified mame, but with major changes in resolution configuration/setup too.  That way I hopefully won't have to spend a ton of time in future releases adapting it, and also that separate code could easily be put into a project like yours or other emulators in the future.  I actually would like to sometime make it into more of a library for modeline switching and generation to link into other applications with an API to use it.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #175 on: April 08, 2011, 12:48:16 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

How do you know what refresh rate your LCD is running? Does that monitor have on screen display showing that information or you trust some software? 

I believe no one was even talking about it around here, and from what I can find via Google LCDs do have truly fixed rates, so even if they can accept some range they would end up updating their screen at their internal refresh rate, or so it would seem.

Ironically then my own tests show otherwise too, and of course if I was so sure about any of it I would not test it any more, but then, not all tests are to be believed and surely such LCD, with varying refresh rate, would come with some manual and specification sheet that says so, right? But where is it?

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #176 on: April 08, 2011, 12:51:38 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

How do you know what refresh rate your LCD is running? Does that monitor have on screen display showing that information or you trust some software? 

I believe no one was even talking about it around here, and from what I can find via Google LCDs do have truly fixed rates, so even if they can accept some range they would end up updating their screen at their internal refresh rate, or so it would seem.

Ironically then my own tests show otherwise too, and of course if I was so sure about any of it I would not test it any more, but then, not all tests are to be believed and surely such LCD, with varying refresh rate, would come with some manual and specification sheet that says so, right? But where is it?

Basically in Linux running with an ATI card using vsync and no throttle, xrandr modelines and looking at the mame speed percent.  I am pretty sure I can get 100% speed running on the card/monitor vsync to the LCD, and not all 60Hz games.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #177 on: April 08, 2011, 01:01:58 pm »
I'd definitely be interested in porting the changes to resolution switching/calculation into such a project, including it in the Groovy Arcade Linux as an alternative to the current groovymame.  Not tons of time to branch off into more than what I'm currently undertaking, but sounds like if you have your project in a git repository available I'd be poking around at it and trying to create patches to submit to you adding in any extra arcade monitor functionality or other modeline/resolution improvements.  I'd say open it up and see where it goes, I'd definitely feel like things like the smoothmame patch would be nicer to work into something like that.  After looking at the smoothmame patch, it does look like less of something I want to put into my patches to current mame since it makes some core changes to defines that would be hard to keep current to a moving target, so more suited to something like this that was forked permanently.  I like groovymame for keeping current, and so something like this sounds interesting to have for everything else to go that can't be kept current without constantly re-factoring patches each release.  I have all the code mostly in separate files in groovymame, so it's concise and simple in how it's modified mame, but with major changes in resolution configuration/setup too.  That way I hopefully won't have to spend a ton of time in future releases adapting it, and also that separate code could easily be put into a project like yours or other emulators in the future.  I actually would like to sometime make it into more of a library for modeline switching and generation to link into other applications with an API to use it.

Great, in worst case we can share some code and in best case scenario we might end up with some cool project, so all the chicks would scream our names in their wild arcade dreams. Anyway, I have to log off now, let me get back to that later.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #178 on: April 08, 2011, 01:11:07 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

How do you know what refresh rate your LCD is running? Does that monitor have on screen display showing that information or you trust some software?  

I believe no one was even talking about it around here, and from what I can find via Google LCDs do have truly fixed rates, so even if they can accept some range they would end up updating their screen at their internal refresh rate, or so it would seem.

Ironically then my own tests show otherwise too, and of course if I was so sure about any of it I would not test it any more, but then, not all tests are to be believed and surely such LCD, with varying refresh rate, would come with some manual and specification sheet that says so, right? But where is it?

Basically in Linux running with an ATI card using vsync and no throttle, xrandr modelines and looking at the mame speed percent.  I am pretty sure I can get 100% speed running on the card/monitor vsync to the LCD, and not all 60Hz games.

MAME?! If they knew anything about it there would not be things like SmoothMAME or AdvanceMAME, or CabMAME, or people like you and me trying to fix all that rubbish. MAME does crazy things with timers and is probably the worst software to tell you anything about your monitor.


Find some LCD with OSD that shows refresh rates like PC CRTs used to have, if there is any such LCD?
Find the manual or whatever specification of whatever LCD on the Internet that confirms it black on white?

Until then, I am not trusting even any software that was made to tell those things, let alone MAME's gibberish.

« Last Edit: April 08, 2011, 01:12:58 pm by torino »

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #179 on: April 08, 2011, 11:08:25 pm »
Do you know if your build fixes this issue?  I'm still setting up my Windows 7 + ArcadeVGA system, so I can't test it yet.

This sucks because it limits my front-end to 640x288   :(


http://www.ultimarc.com/avgainst.html
Quote
Important note about Windows 7

There is currently a known issue with Windows 7 switching between resolutions.

If the desktop is running at an interlaced resolution (eg 640 x 480 on a standard-res monitor), When any game which uses a non-interlaced res is started (which is pretty much any Mame game), an error resuts "Unable to initialize directdraw".

Note this only happens if the desktop is running at an interlaced res, which is the case when using a standard res monitor (not a multi-frequency monitor).

There is a workaround for this: Run the desktop at a non-interlaced res such as 640 x 288. This might mean using a front end which has a 640 x 288 mode such as Mamewah.

The resolution can be switched using the Quickres icon.

Note to Mame devs: This issue does not arise if D3D is selected. But owing to not being able to disable stretching in D3D in Mame this results in a poor quality picture.
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

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #180 on: April 08, 2011, 11:27:46 pm »
Do you know if your build fixes this issue?  I'm still setting up my Windows 7 + ArcadeVGA system, so I can't test it yet.

This sucks because it limits my front-end to 640x288   :(


http://www.ultimarc.com/avgainst.html
Quote
Important note about Windows 7

There is currently a known issue with Windows 7 switching between resolutions.

If the desktop is running at an interlaced resolution (eg 640 x 480 on a standard-res monitor), When any game which uses a non-interlaced res is started (which is pretty much any Mame game), an error resuts "Unable to initialize directdraw".

Note this only happens if the desktop is running at an interlaced res, which is the case when using a standard res monitor (not a multi-frequency monitor).

There is a workaround for this: Run the desktop at a non-interlaced res such as 640 x 288. This might mean using a front end which has a 640 x 288 mode such as Mamewah.

The resolution can be switched using the Quickres icon.

Note to Mame devs: This issue does not arise if D3D is selected. But owing to not being able to disable stretching in D3D in Mame this results in a poor quality picture.

Interesting, I had no clue that this happened with the arcadeVGA card and Windows 7.  The method of using custom modelines for the non-ArcadeVGA ATI drivers we use doesn't work in Windows 7 though.  It may have more todo with Windows 7 and directdraw being depreciated, possibly they are causing interlaced modelines to be not able to switch back and forth.  I remember seeing something, where the whole interlaced flag I think is changing there.  Actually in the powerstrip forums they were talking about how you can't jump from interlaced to progressive modes, I think that's what I'm thinking of.  So it may be an ATI + Windows 7 interaction I guess, not sure if it's fixable without just dropping back to XP64 or XP32.  Not the best answer, but newer versions of Windows aren't exactly trying to be flexible with arcade monitors, quite the opposite actually.  I guess that the ArcadeVGA in Windows 7 does have a few drawbacks, just less than other solutions in Windows 7, yet sounds like quite an irritation to not be able to utilize an interlaced desktop for the frontend.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #181 on: April 09, 2011, 01:33:56 pm »
I'd definitely be interested in porting the changes to resolution switching/calculation into such a project...

Ok, so I organized my files and I can upload everything together with Mingw environment, all set up for easy compile. It compiles in about 15 seconds, it's a tiny build supporting just three games - Galaga, Scramble and Moon Patrol.

I'm not sure if there is anything interesting for you to see at this point, but I think it's common interest to find some basic performance numbers, so if you would be keen to test VAntAGE DOS emulator (it works under Windows just as good, without sound that is) and compare fps with what you get in empty OpenGL or DirectX application on your system, that would great, and I can upload all those files as well and make it easy for you to test. Are you interested?


And also, are we going to settle on LCD refresh rates, truly fixed or not?
« Last Edit: April 09, 2011, 01:35:34 pm by torino »

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #182 on: April 09, 2011, 02:49:30 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).
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

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #183 on: April 09, 2011, 06:00:51 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).

I can't imagine using a monitor with less than nineteen inches of viewable area.
-Banned-

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #184 on: April 09, 2011, 07:12:05 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).

I can't imagine using a monitor with less than nineteen inches of viewable area.

I don't plan on using this in a cabinet.  I was just citing it as an example of an LCD that supposedly supports multiple refresh rates.
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

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #185 on: April 09, 2011, 08:48:09 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).

Thank you. That helped a lot, I think I figured it all out now.


"MultiSync LCD", that makes sense as much as "square wheel", but I'm sure it helped increase the sales, it sure sounds good, whatever it is, even if it's nothing, nothing but scam. So, there was a time when decision was made for LCDs are to replace CRTs. And as always in computer industry, when old standards get replaced with new, there was a question of backward compatibility. LCDs simply had to be able to accept the same signal as CRTs they're trying to overthrow, and they managed to achieve this. However, what they did not want you to know is that even though input could stay the same, the output would be something very different. Very, very different, but they called it "better", and we believed. 


Anyhow, what you really want to know is what is the 'response time' of that LCD and that will tell you its ACTUAL refresh rate - the number that defines how many different whole screens it can display over one second interval. For that specific monitor it's ~17ms, which means maximum of 60fps. And that's sufficient, it's adequate and good compared to how it was just several years ago, but still, it's all very misleading, as you can see.


- "NEC ’s Rapid Response technology provides for
uninterrupted display of full-motion video with
response times of 30ms or less.

Rapid Response delivers streaming video without
noticeable ghosting or blur-ring, while achieving
as many as 40 frames per second (fps).

This remarkably quick motion makes these models
better than ever for gaming and video... "


http://www.monitorgalaxy.com/pdf/2351.pdf


Can you believe it? 40fps!? Why did no one ever read those manuals? It was only yesterday when we still had CRTs and we knew the higher the fps the better animation and precision of movement control, yet when LCDs invaded we were happily degraded to believe 40fps is "remarkably quick motion" and BETTER THAN EVER for GAMING!?!

How did that happen? Well, in retrospect, it seems much of it has to do with simply calling things differently, so there was no more 60Hz refresh rate, now we have 17ms response time. I mean, would you really buy any of those LCDs if you knew they can do maximum of 40fps? Of course not, but 30ms response time, well that sounded much better, add there the word "MultiSync" and voila! Who would not want one? Therefore, conclusion is that LCD do have truly fixed refresh rates, and all this confusion, misinformation and lack of information is actually intentional propaganda and false advertisement, as those numbers are (were) such that some might not really wanna know about it at all. 

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #186 on: April 09, 2011, 08:52:09 pm »
I'd definitely be interested in porting the changes to resolution switching/calculation into such a project...

Ok, so I organized my files and I can upload everything together with Mingw environment, all set up for easy compile. It compiles in about 15 seconds, it's a tiny build supporting just three games - Galaga, Scramble and Moon Patrol.

I'm not sure if there is anything interesting for you to see at this point, but I think it's common interest to find some basic performance numbers, so if you would be keen to test VAntAGE DOS emulator (it works under Windows just as good, without sound that is) and compare fps with what you get in empty OpenGL or DirectX application on your system, that would great, and I can upload all those files as well and make it easy for you to test. Are you interested?


And also, are we going to settle on LCD refresh rates, truly fixed or not?


Sounds interesting, I'd definitely when have some extra time take a peek at  it and see how it runs.  

I know that my acer LCD's in the manual state a horizontal range and vertical refresh range they can run in.  I don't know for sure though, I'm guessing any LCD isn't as great at displaying the tear free refresh rate even if it tries to match the rate.   I wonder too about the Wells Gardner and other arcade monitor LCD replacements that are really pricey and are meant to put into place of an original arcade monitor and take direct output from a PCB.  I have no way to test an LCD for true refresh rate, guess just by sight and it's subjective, my d9800 wells gardner arcade monitor has an OSD and I can easily see on it, only if every monitor had such things.

Interesting, yeah I found the wording quite interesting too and now looking at LCD information they all seem sort of sly in how the describe things.  So it's kinda like some technical magic trick to make the display output work with the input refresh rate, but it's not like an old CRT arcade monitor where it's really what the screen is doing in the end.  I figured it was something like this actually, I still wonder though about the high end wells gardner LCD's, but suspect they are doing similar "make it work to a persons eyes" technology but not really running output in the same Hz as you are sending it, but digitally I guess you can do a lot of tricks like that and a majority of people don't even notice.  Just like they have the 16:9 TV's with 4:3 pictures on stretch, and they don't notice that everybody is really fatter than they should be.
« Last Edit: April 09, 2011, 08:59:13 pm by bitbytebit »

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #187 on: April 10, 2011, 05:40:43 pm »
Sounds interesting, I'd definitely when have some extra time take a peek at  it and see how it runs.  

* MobileMAME v0.01 + MinGW + TEST(VAntAGE & Empty App) [19mb]

http://www.4shared.com/account/file/W7B1C4X-/MobileMAME_001.html



!RunMe.bat - will produce "tiny.exe", then it will compile "empty.exe" and then it will execute all:



1.) tiny mpatrol

You should see fps counter and garbled OpenGL texture but you will still be able recognize it's Moon Patrol running in it. There is nothing much to see here other than to go through source code and see what is _missing, as what is left is still pretty much MAME 0.88, bit cleared up and simplified at some parts, but overall is quite a mess.
 


And more importantly...

2.) empty.exe

You should see black screen and fps counter, on my laptop, which is 1.7GHz with lousy integrated ATI Xpress GPU, I get 2500fps



3.) vantage galaga -ror

You need to press F11 to see fps counter. I get 6200fps and when I "insert coin" it goes to 7500fps. All tested on WinXP.



Curious, isn't it? What kind of super-duper graphic card we need, how many gigahertz and gigabytes does it take to beat 15 years old VESA and dead old DOS?



Quote
I know that my acer LCD's in the manual state a horizontal range and vertical refresh range they can run in.  I don't know for sure though, I'm guessing any LCD isn't as great at displaying the tear free refresh rate even if it tries to match the rate.   I wonder too about the Wells Gardner and other arcade monitor LCD replacements that are really pricey and are meant to put into place of an original arcade monitor and take direct output from a PCB.  I have no way to test an LCD for true refresh rate, guess just by sight and it's subjective, my d9800 wells gardner arcade monitor has an OSD and I can easily see on it, only if every monitor had such things.

Yeah, and so rather unexpectedly I actually found the software meant for this purpose exactly.

The program is called "JudderTest" and it needs Powerstrip:

http://www.kuratorn.se/011/software/JudderTest11.zip

http://www.entechtaiwan.com/files/pstrip.exe


It can tell you "missed frames". That is, the programs presumes to know, somehow, what is the ACTUAL (internal) rate of the display, but it also has good visual test. I also found some "Judder test" for Linux, but this first one seem good enough so I didn't bother to try or look for more of these tests.


Quote
Interesting, yeah I found the wording quite interesting too and now looking at LCD information they all seem sort of sly in how the describe things.  So it's kinda like some technical magic trick to make the display output work with the input refresh rate, but it's not like an old CRT arcade monitor where it's really what the screen is doing in the end.  I figured it was something like this actually, I still wonder though about the high end wells gardner LCD's, but suspect they are doing similar "make it work to a persons eyes" technology but not really running output in the same Hz as you are sending it, but digitally I guess you can do a lot of tricks like that and a majority of people don't even notice.  Just like they have the 16:9 TV's with 4:3 pictures on stretch, and they don't notice that everybody is really fatter than they should be.

From what I know now, I'd say there is no such thing as Arcade LCD meant to work with multiple arcade PCBs. I'd say LCDs at most support two internal refresh rates, like 50 and 60fps, but it does not seem it is easy or possible for them to vary refresh rate from predefined and built-in one(s).

They use telecine or pulldown, or interpolation/extrapolation aka sampling, or some combination, which is why you see ghosting and/or blurring when you feed frames in different temporal resolution than LCD internal refresh rate.


Those 40fps LCDs from 2003, I'm pretty sure many continued to play their first person shooters at 75Hz or 85Hz like they did with CRTs, giving the GPU quite a workload just so the LCD would degrade it down to 40fps and even make it worse on the way with blurring and ghosting, and so our unfortunate gamers would have been much better off if they were running their game at 40fps to start with, or even better if they never switched to LCD at all.
« Last Edit: April 10, 2011, 05:52:34 pm by torino »

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #188 on: April 11, 2011, 11:55:01 am »
Wells-Gardner Electronics Corporation

http://www.wellsgardner.com/products/details.asp?iCat=1&iSubCat=5

- "The 9000 series LCD comes standard with an A/D scaler controller. This controller features an integrated DVI receiver operating up to 135 MHZ, high quality scaling for all VESA modes that fit the screen and direct connect to all DVI compliant transmitters."


There it is, that Analog-Digital controller they are talking about is not only resolution scaler, but it also does frequency re-sampling, which they do not mention, nor imply anyhow. And just like we get bogus image in regards to pixels due to stretching, so do we also get non-authentic visual tempo which comes together with its own visual artifact due to frame rate conversion. Ergo, both spatial and temporal resolution gets skewed and distorted which can hardly help you break any world record, and I don't think Twin Galaxies would/should even accept such record due to terrible non-authenticity that comes with LCD displays, even if it actually makes the games harder.


However, that's only top of an iceberg. Having a temporal scaler means once frames get to A/D controller they need to go into buffer first, then they go through digital manipulation process and only then get sent to display, all of which takes time, so we get the beautiful lag, aka latency. And here comes the best part. You can't use the same mechanism to convert whatever arbitrary mismatch in frame rates, and the difference directly determines the amount of time, or better to say number of frames that need to go into buffer and be worked on as a sequence.

Why? Well, if you need to convert between 50/60fps (PAL/NTSC) you have 10 frames to play with each second, so the latency can be under two seconds, or under one second depending on desired quality, but consider what happens when you need to convert 60.606 -> 60 fps. In such case there is only one extra frame every two seconds, approximately, so what do you do? Do you simply drop that extra frame and get a jerk every now and then, or do you feed two seconds into buffer first and try to smooth 121 frames for each such sequence, and then somehow re-arrange it all over upcoming time?

The closer the input/output frame rates the harder it becomes to actually smooth them, and it takes more time as the relevant sequence gets wider, more sparse, until there is a perfect match, then it becomes perfect, as it should be, and that's what CRTs do.



Anyhow, they say it's always best to ask, so that's what I did.

Quote
frossini@wellsgardner.com

Hello,

I'm looking at this monitor: WGF1979-SDSS39J
7900 Series 19" LCD W/SAMSUNG PANEL (TN)


Can you please tell me what is its internal refresh rate, how many
frames per second?

Can it vary refresh rate like CRTs can, or is it fixed at say 60fps,
or maybe fixed 120fps?

What happens when PCB is feeding different frequency like 60.606fps or
57fps? CRTs can adjust refresh rate to match that of the game, but as
far as I know LCDs must do some kind of conversion and re-sampling to
to match their internal refresh rate, so can you please explain what
kind of conversion/scaling happens when there is such mismatch?


Thank you.


Hopefully we will soon have all the answers, and with some luck maybe it turns out I was completely wrong all along, but as my mum always says - that's not very likely. And, should we move this discussion to some other thread, or new one, I did not mean to interrupt or plan to get so much off the topic, although all this is related at some level, so maybe it does fit here as it is.



bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #189 on: April 11, 2011, 12:09:42 pm »
Wells-Gardner Electronics Corporation

http://www.wellsgardner.com/products/details.asp?iCat=1&iSubCat=5

- "The 9000 series LCD comes standard with an A/D scaler controller. This controller features an integrated DVI receiver operating up to 135 MHZ, high quality scaling for all VESA modes that fit the screen and direct connect to all DVI compliant transmitters."


There it is, that Analog-Digital controller they are talking about is not only resolution scaler, but it also does frequency re-sampling, which they do not mention, nor imply anyhow. And just like we get bogus image in regards to pixels due to stretching, so do we also get non-authentic visual tempo which comes together with its own visual artifact due to frame rate conversion. Ergo, both spatial and temporal resolution gets skewed and distorted which can hardly help you break any world record, and I don't think Twin Galaxies would/should even accept such record due to terrible non-authenticity that comes with LCD displays, even if it actually makes the games harder.


However, that's only top of an iceberg. Having a temporal scaler means once frames get to A/D controller they need to go into buffer first, then they go through digital manipulation process and only then get sent to display, all of which takes time, so we get the beautiful lag, aka latency. And here comes the best part. You can't use the same mechanism to convert whatever arbitrary mismatch in frame rates, and the difference directly determines the amount of time, or better to say number of frames that need to go into buffer and be worked on as a sequence.

Why? Well, if you need to convert between 50/60fps (PAL/NTSC) you have 10 frames to play with each second, so the latency can be under two seconds, or under one second depending on desired quality, but consider what happens when you need to convert 60.606 -> 60 fps. In such case there is only one extra frame every two seconds, approximately, so what do you do? Do you simply drop that extra frame and get a jerk every now and then, or do you feed two seconds into buffer first and try to smooth 121 frames for each such sequence, and then somehow re-arrange it all over upcoming time?

The closer the input/output frame rates the harder it becomes to actually smooth them, and it takes more time as the relevant sequence gets wider, more sparse, until there is a perfect match, then it becomes perfect, as it should be, and that's what CRTs do.



Anyhow, they say it's always best to ask, so that's what I did.

Quote
frossini@wellsgardner.com

Hello,

I'm looking at this monitor: WGF1979-SDSS39J
7900 Series 19" LCD W/SAMSUNG PANEL (TN)


Can you please tell me what is its internal refresh rate, how many
frames per second?

Can it vary refresh rate like CRTs can, or is it fixed at say 60fps,
or maybe fixed 120fps?

What happens when PCB is feeding different frequency like 60.606fps or
57fps? CRTs can adjust refresh rate to match that of the game, but as
far as I know LCDs must do some kind of conversion and re-sampling to
to match their internal refresh rate, so can you please explain what
kind of conversion/scaling happens when there is such mismatch?


Thank you.


Hopefully we will soon have all the answers, and with some luck maybe it turns out I was completely wrong all along, but as my mum always says - that's not very likely. And, should we move this discussion to some other thread, or new one, I did not mean to interrupt or plan to get so much off the topic, although all this is related at some level, so maybe it does fit here as it is.




It's making sense to me, now it all kind of makes sense about what LCD's have done to the idea of different framerates or vertical frequency of analog video input.  I've never liked what LCD's and digital displays have done to video, unless of course it's new HD or digitally created video that was meant to be tightly set to the 50 or 60 fps/Hz.  Now it's really sounding quite sad about what the truth is, how the blurring happens because of it pretty much being a bunch of smoke and mirrors to make it seem like the original refresh rates would even be kept.

Here's the things I read that were interesting, about how they keep on increasing the Hz to somehow mask the issues...
http://www.lcdtvbuyingguide.com/lcdtv/lcdtv-responsetime.shtml
http://www.lcdtvbuyingguide.com/lcdtv/120hz-240hz-60hz.html

Well it seems to fit this cabmame thread somewhat, probably more of the monitor forum topic, but either way it's definitely more in depth details about LCD's than I've seen before in how they actually are working.  I am interested to hear what Wells Gardner reports back about your question to them.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #190 on: April 11, 2011, 05:43:48 pm »
<FRossini@wellsgardner.com> Hi John,
Please see email below and respond back to this customer.

Thank you, Fran

<jpruski@wellsgardner.com> Hello.
I am attaching the spec. sheet with all of the modes that this LCD can handle so all that is means is that if your game falls into any of these frequencies it will either auto search it or you can manually depress the AUTO SEARCH.

John W.G. TECH. SUPPORT
wgf1979 modes.PDF (see below)




So, I'm asking about this LCD they say is meant for classics like Pac-Man, Galaga and Space Invaders and they send me some specification sheet that describes some VGA and VESA modes. It looks like description for analog CRT signal and in no way seem to be related to what I was asking, nor do I see 60.606Hz that MAME claims Galaga is running at. Anyway, this was my reply...

Quote
Hi,

I understand it can "handle" different input, but I want to know what
is the output.

What is the internal refresh rate of that LCD, how many frames per second?

Thank you.

It's getting interesting, I wonder if I'll get any more replies. Perhaps someone who actually bought this thing would have the right to DEMAND this information and/or get them to court for false advertising. Well, I have no further comment, I'm kind of speechless at the moment, I expected far better response, though I can't quite say I'm surprised either. But really, what now, what if they simply refuse to say? Fascinating!

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #191 on: April 11, 2011, 06:10:12 pm »
I agree, this is pretty much off topic at this point.
Maybe one of the board moderators can figure out how to split this thread into two threads.

BUT since I'm here, I'll throw some more wood on the fire.

My guess is that the hardware on the input side of an LCD acts somewhat like a Time Base Corrector...

Quote
Time base correction counteracts errors by buffering the video signal and releasing it at a steady rate. "TBC"s also allow a variable delay in the video stream. By adjusting the rate and delay using a waveform monitor and a vectorscope, the corrected signal can now match the timing of the other devices in the system. If all of the devices in a system are adjusted so their signals meet the video switcher at the same time and at the same rate, the signals can be mixed together. A single master clock or "sync generator" provides the reference for all of the devices' clocks.

I'm willing to bet that input to one of these "arcade replacement" LCD monitors suffers from a small amount of input lag, possibly a frame or two because of the buffering that goes on.

If the people in the thread below are correct, the same sort of input lag can happen when you use triple buffering in PC games...
http://hardforum.com/showthread.php?t=1436949
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

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #192 on: April 11, 2011, 06:27:06 pm »
I agree, this is pretty much off topic at this point.
Maybe one of the board moderators can figure out how to split this thread into two threads.

BUT since I'm here, I'll throw some more wood on the fire.

My guess is that the hardware on the input side of an LCD acts somewhat like a Time Base Corrector...

Quote
Time base correction counteracts errors by buffering the video signal and releasing it at a steady rate. "TBC"s also allow a variable delay in the video stream. By adjusting the rate and delay using a waveform monitor and a vectorscope, the corrected signal can now match the timing of the other devices in the system. If all of the devices in a system are adjusted so their signals meet the video switcher at the same time and at the same rate, the signals can be mixed together. A single master clock or "sync generator" provides the reference for all of the devices' clocks.

I'm willing to bet that input to one of these "arcade replacement" LCD monitors suffers from a small amount of input lag, possibly a frame or two because of the buffering that goes on.

If the people in the thread below are correct, the same sort of input lag can happen when you use triple buffering in PC games...
http://hardforum.com/showthread.php?t=1436949

Sounds like basically the same process as you use when encoding video, like input is 29.97 fps and you output 15 fps, dropping frames there, things smooth out and timing is redone for the output.  So these LCD's most likely are re-encoding the input to the output digital display and so the whole concept of 'frame rate' as preserved for the output  is no longer relevant at all.  It makes a lot of sense, but they of course never actually explain it in this way, and of course many people don't even understand that about encoders of digital video and how that truly works with input/output frame rates.   Then you have things like WMV which are time based instead of frame based, so MPEG2 to WMV totally loses any concept of actual framerate, WMV just makes things up essentially in a timeline with smoothing and drops frames here and there, unlike MPEG2 which has to strictly keep the same frame rate you ask it to have for the output.  So these LCD's are just encoders, with different input capabilities and the Arcade ones have a larger range of input possible framerates.  Then they all just encode it and plop it out at the 50 or 60fps, or whatever the flat output capability is, but it's nothing like a CRT and the input framerate means nothing really to what your seeing as output.  I'm very familiar with encoding video, feeding raw video frames to an encoder, changing framerates of the output and timestamps on frames.  So it just really sounds like the same thing to me, and I'm surprised I didn't think of what the LCD was doing actually since it now hits very close to what I've done a ton of with video encoding.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #193 on: April 12, 2011, 05:48:15 am »
I agree, this is pretty much off topic at this point.
Maybe one of the board moderators can figure out how to split this thread into two threads.

BUT since I'm here, I'll throw some more wood on the fire.

My guess is that the hardware on the input side of an LCD acts somewhat like a Time Base Corrector...

What we are talking about here is generally known as "telecine". There is no win-win situation with frame rate conversion, except when the difference gives exact double, and it's only thanks to our lazy eyes we are not more aware, or better to say - upset, about any of it.


http://en.wikipedia.org/wiki/Telecine


a.) if too many: drop extra frames, but produce hiccups

b.) if not enough: repeat some frames, but produce judder

c.) or adjust the speed, but produce funny audio pitch

When the difference in frame rate is small the best thing to do is simply speed up or slow down the whole thing. Only that's not something monitors can do, for that you need direct control over timing of the output signal, so that's done in production (together with sound pitch correction), or you can build it in video players, or software such as SmoothMAME.



...independent extra:
d.) interpolate motion, but produce blurring and ghosting



http://en.wikipedia.org/wiki/Motion_interpolation

- "Motion interpolation... aimed at alleviating the video artifacts introduced by framerate conversions in fixed-framerate displays such as LCD TVs... "


Quote
I'm willing to bet that input to one of these "arcade replacement" LCD monitors suffers from a small amount of input lag, possibly a frame or two because of the buffering that goes on.

It does spatial scaling to fill the screen in any case, that means minimum lag in duration of 'one frame', and so your bet wins. But that still leaves us with whatever that LCD does with frame rate scaling, and that we can only know once we know what is actually going on in-there, but we don't know the first thing - its actual output refresh rate, so we really know nothing, yet.


Classic arcade games, that's where every pixel and every frame counts. If you wanna be the King of Kong, then you better stay away from LCDs, that's what I think about it.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #194 on: April 12, 2011, 06:13:04 am »
Sounds like basically the same process as you use when encoding video, like input is 29.97 fps and you output 15 fps, dropping frames there, things smooth out and timing is redone for the output.  So these LCD's most likely are re-encoding the input to the output digital display and so the whole concept of 'frame rate' as preserved for the output  is no longer relevant at all. 

Yes, exactly, but nothing smooths out when you drop frames, unless you drop exactly half of them. What do you mean "no longer relevant"?

Frame rate is all that matters, that's what animation is. We are talking about "moving pictures", and they are moving in time, so beside the time we also must have those pictures, and that means WHOLE pictures, aka frames. If there are fractions, then we have tearing. In any case, the distribution of those frames over time will define our frame rate and this effectively produces what we call "animation".

Frame by frame, there is no other way to depict motion. Except for vector monitors I suppose, or even LCDs could save some energy by only updating those pixels that changed since last frame, and by doing that completely skew the meaning of "frames per second", but when the camera pans and when the screen scrolls then often all the pixels change every frame, so it really all must come down to same old thing - "frame by frame".


Unless you're talking about compression, but that's "internal" to 'format',  and the video stream still has to come out on the display as a sequence of frames, where again the "time spacing" between them defines the quality of the illusion of motion. Interestingly enough, thanks to our lazy eyes, for motion to be perceived as "smooth" the sheer number of frames is less important than its distribution, so constant and evenly spaced 25fps is more fluid to eye than uneven 100fps, which is ugly judder and should be prohibited by international law.


.    .    .    .    .    .    .    .    .    .    .    .

..... ................... .................... .........



Quote
It makes a lot of sense, but they of course never actually explain it in this way, and of course many people don't even understand that about encoders of digital video and how that truly works with input/output frame rates.   Then you have things like WMV which are time based instead of frame based, so MPEG2 to WMV totally loses any concept of actual framerate, WMV just makes things up essentially in a timeline with smoothing and drops frames here and there, unlike MPEG2 which has to strictly keep the same frame rate you ask it to have for the output. 

Perhaps, but I think you are talking about compression. The end result, the actual output, still must manifest via frames changing through the time, frame by frame, and that's foremostly the property of the display itself, so it should be up to software to do the best it can with a given display. It's only that LCDs make such cooperation impossible as they are impostors pretending to be CRTs. And they are also your second video card, the one you don't wanna have as it will override and downgrade what your actual video card was working on so hard.


All this is actually about the 'whole numbers', there simply can't be any fractions, we must have those frames complete. If there are fractions, then we have tearing, like top half of one frame and bottom half of the next frame, but that's not the way to do animation, that's visual artifact, it's ugly and it should be prohibited by international law.


Quote
So these LCD's are just encoders, with different input capabilities and the Arcade ones have a larger range of input possible framerates.  Then they all just encode it and plop it out at the 50 or 60fps, or whatever the flat output capability is, but it's nothing like a CRT and the input framerate means nothing really to what your seeing as output.  I'm very familiar with encoding video, feeding raw video frames to an encoder, changing framerates of the output and timestamps on frames.  So it just really sounds like the same thing to me, and I'm surprised I didn't think of what the LCD was doing actually since it now hits very close to what I've done a ton of with video encoding.

I know exactly what you mean. So, what happed there? We are naive, that's what happened. LCDs did seem adequate replacement for CRTs, they could "handle" all the usual input, we just never got to the point to question its output. Windows would say 60Hz and that was pretty usual, so from that point on we all assumed everything else was "usual" too, or at least adequate replacement, and that was it. For the rest we can blame our lazy eyes and cunning advertisement.
 

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #195 on: April 12, 2011, 06:37:07 am »
Sounds like basically the same process as you use when encoding video, like input is 29.97 fps and you output 15 fps, dropping frames there, things smooth out and timing is redone for the output.  So these LCD's most likely are re-encoding the input to the output digital display and so the whole concept of 'frame rate' as preserved for the output  is no longer relevant at all. 

Yes, exactly, but nothing smooths out when you drop frames, unless you drop exactly half of them. What do you mean "no longer relevant"?

 
Just that it's changing the frame rate with multiple tricks to achieve the output, and so the output frame rate isn't even correlating to what the input frame rate was.  In fact the output with the blurring and other LCD issues is a lot like compressed video and what the non-frame rate temporal types of compression tend to do.   So it can fudge and change around the output framerate to make it work, put an extra frame here and there to make it fit and smooth it out between frames to avoid tearing, instead it's sort of blurry.

I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

So how does the smooth mame patch then have the ability to change the original framerate?  I've always thought about it like sampling analog, or the actual video camera, and at the mame emulation end feeding the frames, the source basically, can alter this in multiple ways just like feeding an encoder or monitor/LCD.  I'm not sure how correct I am in assuming that, I do know in cases like the redraw patch of cabmame it is exactly like that in doubling the framerate through repeating each frame twice.  I've just never fully known if it really is at the ROM/machine level that we could have the ability to alter this much at all or that any changes like in smooth mame are going to be doing some loss/add to what the ROM/machine is giving out.  I guess in smoothmame it's changing the machine, at least I am guessing, to run at a different pace, and is it really true that the ROM can just alter if the machine is altered like that, in what the output framerate is?  I guess since smoothmame works well on an LCD, it must be doing something right, just wondering what the technical reasons are for that, how it really is allowed to alter the fps or Hz, and yet the LCD can't do it right at that later stage in the pipeline.

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #196 on: April 12, 2011, 12:49:53 pm »
My understanding is that SmoothMAME slows down (or speeds up) emulation to make the output exactly 60Hz.

This is not without consequences.  It will change the pitch of sound output as well.  But usually the amount adjusted is small enough that it's not noticeable.

Some smoothmame links...
http://www.zophar.net/mame/smoothmame.html
http://forum.arcadecontrols.com/index.php?topic=9195.0
http://forum.arcadecontrols.com/index.php?topic=18260.0
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=58007
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

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #197 on: April 12, 2011, 08:08:20 pm »
Just that it's changing the frame rate with multiple tricks to achieve the output, and so the output frame rate isn't even correlating to what the input frame rate was.  In fact the output with the blurring and other LCD issues is a lot like compressed video and what the non-frame rate temporal types of compression tend to do.   So it can fudge and change around the output framerate to make it work, put an extra frame here and there to make it fit and smooth it out between frames to avoid tearing, instead it's sort of blurry.

Not really. There is no "between frames". If your LCD is fixed at 60fps then that's how many unique frames it can show in one second. Those are your allotted time slots, and while you can fiddle with what you're going to put in each one, you can't put anything between or around them. In other words, the time dimension or time granularity is locked, you only have 2 space dimensions left to work with.

So, if you want to apply this extra step, you first need to realize it will only affect the space, not time dimension. "Motion interpolation" effect comes 'on top' of whatever you have done with frame rate conversion first, and to implement it you will need to double display refresh rate (or triple, or quadruple), i.e. increase the number of alloted time slots so you can put those extra frames in.


There are two problems with it:

1.) This is intended for TVs where standard frame rate conversion produces hiccups and judder which is closely spaced in time, but the choppiness produced with small mismatch in frame rates, like Galaga +0.606 or Moon Patrol -3 frames per second, produce choppiness that is just too sparse, it falls out of the limit where it can be smoothed, not even if you insert 100x more frames in between.

Once you drop a frame you practically change the speed of all the objects in the scene for that instant in time. Interpolation can't quite "fix" that, it can only make the animation of it all more "pleasing" to the eye, but even if it's all "blurry" you will still notice all the objects increased their speed and then suddenly slowed down back to normal for no apparent reason, your brain will know that's not what actually happened, but it's only ugly visual artifact known as "telecine judder".


2.) It takes time to do this interpolation, it produces latency aka lag. By the way that example from above looks too good, I don't see how can image algorithm possibly make it look so perfect. In reality it's more like this:




In any case that explains "ghosting" a bit more clearly. So, we did our frame rate conversion and we now have exactly 60 frames to match with our fixed 60fps LCD, all together with hiccups and judder. Now we press the "smooth" button and this doubles our display refresh rate to 120fps. In ever 'even' numbered time slot we place original frame and in every 'odd' time slot we place our intermediate frame. But, to produce this extra frame we need to have the next frame as well, since we need to combine these two to make our "transition frame". This means the display must be in the past, lagging behind the real time for at least one frame, which is still at least ~17ms even though we now operate at internal 120Hz.


If you really wanted to "smooth" sparse judder where there is a small mismatch in refresh rate, you will need to combine not two frames, but as many frames as there is in between each hiccup. Galaga's 60.606fps would produce hiccup only once every two seconds, so you will really need to buffer and interpolate 121 frames, which means 2 second latency, and that's just out of the question. In more practical view, the problem here is that this does not seem to scale so that we are be able to compensate latency for quality, so I think choosing the tearing over judder and "smoothing" that artifact instead might be easier and more effective than smoothing judder, but I don't think anyone is actually doing this in practice.


Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.


Quote
So how does the smooth mame patch then have the ability to change the original framerate?  I've always thought about it like sampling analog, or the actual video camera, and at the mame emulation end feeding the frames, the source basically, can alter this in multiple ways just like feeding an encoder or monitor/LCD.  I'm not sure how correct I am in assuming that, I do know in cases like the redraw patch of cabmame it is exactly like that in doubling the framerate through repeating each frame twice.  I've just never fully known if it really is at the ROM/machine level that we could have the ability to alter this much at all or that any changes like in smooth mame are going to be doing some loss/add to what the ROM/machine is giving out.  I guess in smoothmame it's changing the machine, at least I am guessing, to run at a different pace, and is it really true that the ROM can just alter if the machine is altered like that, in what the output framerate is?  I guess since smoothmame works well on an LCD, it must be doing something right, just wondering what the technical reasons are for that, how it really is allowed to alter the fps or Hz, and yet the LCD can't do it right at that later stage in the pipeline.


As kirck said. Imagine there is no emulation and you already have all the frames ready, say recorded and saved as a collection of images: frame_001.bmp, frame_002.bmp, frame_003.bmp... and so on. Imagine you recorded Moon Patrol at 57fps, and now if you play-back those images at 60fps it will perfectly sync with the 60fps display refresh rate, but everything will be slightly faster. Speeding up or slowing down is regularly done as a part of "telecine" process, not only on its own but also in combination with "pulldown" techniques aka skipping/repeating frames. Changing speed, that is the only one of these telecine methods that leaves the frames as they were, the only good looking one.



newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #198 on: April 12, 2011, 08:58:52 pm »
The whole attempt at trying to get LCDs to run at any arbitrary refresh rate seems like it will never work consistently enough to be any sort of releasable system. I would imagine that there is a vast amount of variability between different LCD driver in as far as what frame rates they actually display. I would also imagine that the rate at which it attempts to display frames, and the rate at which the actual liquid crystals can change is variable, as was suggested previously. Since monitor speeds are generally stated as 'gray to gray' i would also be lead to believe that there is variability in the speed at which different colours change to one another, again independent of what rate they are being instructed to change.

The 'ghosting' effect that's traditionally described in LCDs is more a result of of this rate of change of the individual cells, rather than any sort of intentional interframe-interpolation.

I doubt there is any technical reason why an LCD could not be updated at a fully arbitrary frame rate. In face I imagine there are probably ones on the market right now that would happily be fed a random refresh speed and display it just fine. However, I would assume that most are going to simply ASSUME they will be run at ~60hz and happily drop frames that don't line up since 99.9% of the consumers will not only not care, but not even notice.

In traditional CRTs the actual speed of the electron gun was being driven by the sync signal, which is why arbitrary rates were a non-issue.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #199 on: April 12, 2011, 11:23:44 pm »

Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.



Actually the d9800 has an OSD and it does show my in 2 decimal places the hfreq and vertical refresh, and they are spot on.  There's never any tearing at all on my d9800, it's a real arcade CRT and ranges from 15.1khz -> 38khz horizontal and 40Hz -> 100Hz vertical.  It's able to play galaxian, galaga, super mario, moon patrol, and every game pretty much at the exact vertical refresh without any tearing at all.  I worked actually for quite a while to get this to work in Linux, with xrandr and vsync using the ATI cards.  I saw tearing, was very familiar with it, and finally after a lot of work totally eradicated every bit of it I saw.  I just do small tests for the groovymame changes on my LCD, which are cheap Acers, and also a samsung HDTV too, and they definitely are terrible and show tearing compared to my d9800.  Even when they are supposed to be running at the correct refresh rate.  They do say they are running at that rate though, they just don't seem to be able to hold it steady, it varies and I don't even trust they are as accurate as they are claiming with the numbers from the ATI PLL clocks and xrandr reporting compared to what the LCD is actually performing.  So the d9800 has no question at all about it, that's as perfect as you can possibly get, even more accurate with overall games refresh rates compared to a standard straight 15khz generic arcade monitor (since it has the large range there of khz and Hz, yet a real CRT, and on screen OSD display verifying it besides the visual proof).