The NEW Build Your Own Arcade Controls
Software Support => GroovyMAME => Topic started by: cpharlok on February 26, 2013, 10:32:10 am
-
Hi all,
With newer 120Hz TFTs ghosting have become something of the past, it is incredible to see like CRT movement with zero motion blur on them. However, that is only achieved with 120Hz screen refresh. I need MAME to output at that refresh without loosing game timing. Now, if I start MAME with -speed 2 option it shows perfectly (in a forced 60Hz Mame source) but obviously with double game speed. What I need, and I think a lot of 120Hz TFTs users will benefit also, is to keep 60Hz timing but output at 120Hz refresh. Maybe duplicating last frame, but I do not know what to change in sources to achieve that or configure groovymame to do it. Any help will be very appreciated. I have configured also groovymame to output to 1920x1080 at 120hz but it doubles games speed, if i try to triplebuffer the effect is gone (motion blur again). Played also with refreshspeed/wait vsync/speedsync with no results (in fullscreen and windowed modes). I am using lightboost trick if you want to know:
http://www.techngaming.com/home/guide/tips/updated-eliminate-motion-blur-while-gaming-with-nvidia-lightboost-r485 (http://www.techngaming.com/home/guide/tips/updated-eliminate-motion-blur-while-gaming-with-nvidia-lightboost-r485)
Thanks!!
-
Hi cpharlok,
If you have a working 1920x1080@120 video mode already available in the system, try setting GM like this:
monitor lcd
lcd_range 120-120
syncrefresh 1
frame_delay 5
This should force GM to scale the frequency properly. Let me know if it works.
-
Yep, that's what I did except for the frame delay. I added it with no luck however, still blurring image, fullscreen and windowed. Switchres successfully goes to 1920x1080 at 120Hz but blur occurs. But, if I take a simple new default config and I add in command-line -speed 2 (that is I double the speed) all magically goes perfect, fullscreen and windowed (some tearing appear but it is normal due to syncs/triplebuffer switched off by default)
The problem is I do not know why the blur, if it is MAME not delivering the 120 screens update per second or it is that MAME is successfully doubling the frame to adjust to the doubled frequency and that makes the blur effect on the monitor. Is there a way I can check it? Maybe adding some line at code to log it. I am doing the tests using Black Tiger, which is 60Hz and have a nice background scroll easy to check blur on it. At 120Hz is impressive, like a normal CRT.
BTW, Calamity, I take this opportunity to congratulate you for the fantastic, state of the art work you have done for all us arcade community. THANK YOU MATE ! :cheers:
Gracias!
-
Well this is actually a very interesting subject.
You know what? I also get a blurry picture when running scrolling games at 120 Hz but on a *CRT* monitor. I do this to get native hardware modelines at 31 kHz. It's not too bad but it's definitely there. The problem dissapears when I run the game at 200% (no frame doubling). My theory on this was that because we're drawing each frame twice, combined with the phosphorus persistance, the animation is not perceived as fluent, as the consecutive frames blend with each other in the eye, so a blank frame should be added in the middle instead of drawing each one twice.
So as this seems to be the principle behid the trick you're using I'm wondering if the stroboscopic effect you're trying to enable with the lightboost trick is actually working. Can you confirm that?
I'm thinking that I might implement a blank frame between active frames by software on frequency scaling, this could be an interesting feature.
-
Yes, definitively lightboost is correctly working, as I can run GM in a window and entire desktop is at 120Hz with backlights strobe. Strobe occurs every 2ms-1.4ms (depens on how much bright you want, lesser is darker) and it clears pixels persistency. You can easily measure ghosting of CRTs and LCDs with this tool: http://www.prad.de/download/pixperan_english.zip (http://www.prad.de/download/pixperan_english.zip), although CRTs with low phospor persistence will look just perfect, as always.
Adding a blank frame before duplicating the frame may do the trick, but may add some flickering. If I am correct, when you duplicate a frame and play it at double speed nothing changes, it should appear as the original (I have done some 25fps to 50fps in video and was just a matter of doubling frames, if you have to ie convert a film to ntsc, 24 to 29.97, you can't simply double the frames and you have to spread along the frames the increase). Even more, in modern TVs with 100-200-400Hz they add some interpolation to achieve the artificial "motionflow" and add some extra frames not by just duplicating (which will do nothing). Interpolation and morphing add smoothness (and some weirdness).
Is really MAME duplicating the frame correctly when output is 120Hz if we have a original 60Hz timing? Perhaps adding some kind of logging at source would help. What is clear is when you speed up all system with the speed command it does the output correctly.
-
Adding a blank frame makes sense for NOT duplicating frames, so you're not shown the same frame twice, which ruins motion smoothness, but still update the screen twice as fast. Indeed, it will produce hardcore flicker for sure.
Yes, I'm familiar with the interpolation features of modern TVs, soap opera effect, etc. I mean that duplicating frames at double speed *does* change the animation perception to some extent, it's definitely not the same thing, that's why 100 Hz PAL TVs do interpolation and don't just duplicate frames, even if the PAL source is 50 Hz (I always turn off this feature anyway).
Well, actually GM does NOT duplicate frames now, that was the old implementation and it was causing some issues, as well as a waste of system resources, so it was sorted by just missing one out of two vertical retraces and updating the video memory at 60 Hz, even if the video card is outputting 120 Hz. The video card is the one that duplicates the frame for us by reading the same memory buffer twice.
But now I'm wondering if this Nvidia Lightboost feature actually needs an explicit DirectX screen update on our part in order to trigger the strobe. That would be quite silly but to be honest I don't have a real understanding of how it works, apart from what I have read. You can find if this is the case by trying CabMAME, which actually *redraws* the screen twice if required. Just force it to run at 120 Hz as usual and use these options:
-triplebuffer 1
-redraw 2
CabMAME: http://www.arcadeinfo.de/showthread.php?9555-ENGLISH-Overview (http://www.arcadeinfo.de/showthread.php?9555-ENGLISH-Overview)
If this was the case then I'll consider re-implementing the redraw patch.
-
That is what happens:
- In windowed mode: Seems that redraw does nothing.
- In fullscreen mode: Overall speed decreases when triplebuffer activated, with redraw 2 it runs at 34.81%. If I want to go fullspeed I have to leave redraw at 0, which of course it just do as the regular MAME, that is with motion blur showing. If I deactivate triplebuffer game goes well with redraw 1,2,3 but blur occurs as usually, with redraw 4 it slows to 64%.
- In fullscreen mode, with syncrefresh activated and redraw 2 speeds goes down to 34%, with redraw 1 speed goes to 50%, with redraw 0 it goes ok but again blur occurs.
I have seen something interesting however. When I close cabmame, for about 1 second when I return to windows from fullscreen, screen flickers. Maybe this is hint.
Also, If I check in monitor menu the resolution when in fullscreen it shows correctly 1920x1080 at 120Hz with lightboost on.
I have tried several indie 2d games to check. For example this one:
http://www.gog.com/gamecard/treasure_adventure_game (http://www.gog.com/gamecard/treasure_adventure_game)
It runs smooth, windowed or fullscreen mode, vsync off or on, with no blur.
-
Probably it was -redraw 1, actually.
Are you using -video ddraw or -video d3d?
EDIT: Try:
-video d3d
-redraw 1
-syncrefresh 1
-triplebuffer 0
-throttle 0
-
I have tried both, d3d and ddraw in every try, with ddraw syncrefresh does nothing, if I use redraw it slows but blur appears. With the settings you provided it goes at 50% speed and blur occurs. If I change redraw to 0 it goes ok but again with blurring. As a side effect, it goes perfectly synced without skips or stutter, and this is the first modified mame that achieved that without recompiling, before I had to recompile source forcing it to go 60Hz always to get a perfect smooth game emulation (although I know speed it is different from original but I was using it in a fixed 60Hz monitor). In all mame versions throttle go fullspeed whatever options I switch, but this cabmame does it ok (only in fullscreen, windowed goes fullspeed without throttle).
One of the thing I also tried is to change source to force 120hz update with no luck:
in screen.c
screen.m_refresh = HZ_TO_ATTOSECONDS(pixclock) * htotal * vtotal;
to
screen.m_refresh = HZ_TO_ATTOSECONDS(120);
Does strange things. I did that with 60Hz for perfect scrolls although since I found that cabmame does it ok without throttle I think I wont need to change that code again.
Seems that everytime speed goes below 200% blur appears.
EDIT: With the options you provided in a freshly created config it goes ok but with blur in windowed mode, fullscreen goes 50% speed with blur also.
-
Ok, but there's something I still don't get...
If you use my settings above, but set -redraw 0, don't you get 200% speed?
Try either with -syncrefresh 1 / -triplebuffer 0 and -syncrefresh 0 / -triplebuffer 1
What I'm trying to determine is if your machine is actually capable of rendering 1920 x 1080 at 120 Hz with MAME.
-
With your settings above with redraw 0:
- Windowed mode: 200% speed. Perfect with no blur. If I enable redraw 1 goes 100% speed with blur.
- Fullscreen mode: 100% speed. Blur happens.
With triplebuffer 1 and syncrefresh 1 redraw 0:
- Windowed mode: 200% speed. Perfect with no blur. If I enable redraw 1 goes 100% speed with blur.
- Fullscreen mode: 100% speed. Blur happens
With triplebuffer 1 and syncrefresh 0 redraw 0:
- Windowed mode: Goes top speed (2407%)
- Fullscreen mode: 100% speed. Blur happens
EDIT : I found why on fullscreen it goes 100%r. It was due to nvidia driver launching 3D for MAME. Swithching inside MAME to 2D (CTRL+T) makes it goes to 200% smooth, as in windowed mode (logically).
-
Ok, let's see...
You don't have 120 Hz in full screen MAME, that's clear to me. You have 60 Hz for some reason.
In windowed mode you do have 120 Hz, but if enabling redraw 1 makes the picture blurry then chances are it will be the same if you achieved 120 Hz while in full screen.
I'm sorry I don't have much experience with NVidia. BTW is that W7?
EDIT: Before you complain, probably you do have 120 Hz in full screen but DirectX just reports 60 retraces per second... that could be the reason.
-
Just edited my post before reading yours, yes you are right, it was with due to 3D enabled on fullscreen. Disabling it (CTRL+T) makes fullscreen do as windowed. System is windows 7 64 bits, latest nvidia driver with force 3D activated always (thats why in fullscreen driver tried to make it 3d). However, as in windowed mode, 100% speed goes with motion blur.
-
Ok that makes more sense, so -redraw 1 fullscreen is 100% and blurry too?
-
Yes. I am missing something :dizzy:
I am looking for some kind of 60fps 2D test to check, or perhaps a game, or perhaps modify an old shootem'up i coded some time ago
-
Well, at least now we know that CabMAME is indeed updating the screen twice per frame and that doesn't help, so it must be that lightboost and MAME (probably DirectX 9) don't work well together. Is there anything special in the non-MAME games you tested which run smooth which might give us some clue??
-
Here you have an example of perfect synced, zero blur simple game:
http://xout.blackened-interactive.com/Prototype2/Prototype2.html (http://xout.blackened-interactive.com/Prototype2/Prototype2.html)
It shows the fps onscreen (120fps in my machine) and seems it have been done using SDL (which means it outputs to directdraw if I am right).
BUT
I have tried also Zsnes and... bingo! It does the same thing as MAME. If I run the game normally (I test it with Actraiser as it is easy to see blurring in grass and trees due to pattern) it blurs, but at double speed it runs perfect, no blur at all.
I can't think of a proper explanation to that. Maybe it is related on how program updates screen.
Can you try Zsnes on your 120Hz CRT and check it? Just to be sure it is related to lightboost or not
-
I've tried the Prototype II game and interestingly it's running at more than 900 fps here, even with v-sync on. The game action looks absolutely normal however. But this has very slow scroll, so I don't think it's a good test case. You need a background that actually moves one pixel per frame to drive conclusions. It doesn't seem a 2D game either, even if the action is 2D (I might be wrong).
Yes, I'll test Zsnes, but I won't be able to test this till Friday probably.
-
I found this in zsnes config files:
; Force Refresh Rate (0 = NO, 1 = Yes)
; Enable this if you are experiencing visual tearing
; WARNING: Setting a refresh rate that your monitor cannot handle will have consequences!
; The DX Refresh Rate Override in dxdiag must be set to default in order for this to work!
; The refresh rate is only valid if it is supported by your system!
; This option is only useful in fullscreen modes.
ForceRefreshRate=0
SetRefreshRate=120
; Enable KitchenSync/KitchenSyncPAL (0 = NO, 1 = Yes)
; When enabled, ZSNES will use double the refresh rate of the game and use half of it to
; sync with the game to reduce/prevent visual tearing.
; You can enable this if your video card/monitor AND current ZSNES resolution supports
; 100Hz (for PAL games) and 120Hz (for NTSC games)
; KitchenSyncPAL applies to PAL games only, use KitchenSync for PAL+NTSC games.
; WARNING: The DX Refresh Rate Override in dxdiag must be set to default in order for this to work!
; This option is completely useless in a non-fullscreen mode.
KitchenSync=1
KitchenSyncPAL=0
And that is what the docs say:
KitchenSync (Win port only)
This makes NTSC games (60Hz) run at 120Hz, and PAL games (50Hz) run at 100Hz. To enable it, just start ZSNESw with the -ks switch. Alternatively, you can create a shortcut to ZSNESw that starts with this switch enabled, every time. First create a shortcut to ZSNESw in Windows. Next, right-click on the shortcut and choose Properties. Then, put the cursor right after the quotation marks in the Target box, press the space bar, and type -ks. Finally, click OK. If ZSNESw crashes or refuses to start after enabling this, your monitor does not support the 100/120 Hz refresh rate.
If your monitor supports 100Hz and not 120Hz, you can instead use the -kp switch for PAL only. This way, you will not have to disable the -ks switch every time you wish to play an NTSC game.
Seems the problem is not new. Later will take a look at the code to try to figure out what this "KitchenSync" actually do. With those settings emulator does nothing, it is still at 60Hz, but maybe I am doing something wrong.
And this is part of the screen update code (winlink.cpp):
void DrawScreen()
{
if (FullScreen == 1)
{
if (TripleBufferWin == 1 || KitchenSync == 1 || (KitchenSyncPAL == 1 && totlines == 314))
{
if (DD_BackBuffer->Blt(&rcWindow, DD_CFB, &BlitArea, DDBLT_WAIT, NULL) == DDERR_SURFACELOST)
DD_Primary->Restore();
if (DD_Primary->Flip(NULL, DDFLIP_WAIT) == DDERR_SURFACELOST)
DD_Primary->Restore();
if (KitchenSync == 1 || (KitchenSyncPAL == 1 && totlines == 314))
{
if (DD_BackBuffer->Blt(&rcWindow, DD_CFB, &BlitArea, DDBLT_WAIT, NULL) == DDERR_SURFACELOST)
DD_Primary->Restore();
if (DD_Primary->Flip(NULL, DDFLIP_WAIT) == DDERR_SURFACELOST)
DD_Primary->Restore();
}
}
else
{
if (vsyncon == 1 && curblank != 0x40)
{
if (lpDD->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, NULL) != DD_OK)
{
DDrawError();
}
}
DD_Primary->Blt(&rcWindow, DD_CFB, &BlitArea, DDBLT_WAIT, NULL);
DD_Primary->Restore();
}
}
else
{
if (vsyncon == 1)
{
if (lpDD->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, NULL) != DD_OK)
{
DDrawError();
}
}
DD_Primary->Blt(&rcWindow, AltSurface == 0 ? DD_CFB : DD_CFB16, &BlitArea, DDBLT_WAIT, NULL);
}
}
extern "C" {
void MultiMouseInit();
void MultiMouseShutdown();
extern BYTE device1,device2;
extern BYTE GUIOn;
extern BYTE GUIOn2;
DWORD InputEn=0;
}
-
No luck with zSnes... seems they never implemented properly that KitchenSync thing or it does not work now. I will try to find more information about.
-
Unfortunately, got the answer on what is happening. Basically, what I get it is not blurring, but double frame. It is evident on plasma/crt as blurring in lcds "disguise" it, but when you double the frame you can see this effect, image juddering, specially in fast moving parts (scroll). This is the thread I found where people talks about it:
http://www.avsforum.com/t/1107325/30fps-gaming-at-60hz-and-the-effects-of-frame-doubling (http://www.avsforum.com/t/1107325/30fps-gaming-at-60hz-and-the-effects-of-frame-doubling)
That's why a 120Hz source always looks good (basically, every game that is coded to support multiple screen refresh or it is not fps limited, does not matter if it is 3D or 2D, although 2D games usually are fps locked) and a 60fps source looks "blurry" actually not exactly blurry, more judder.
I fear that the only real solution for MAME to display properly in a 120Hz lightboost display would be:
1. Make MAME add one interpolated frame (as smooth motion TVs do to convert all to soap operas) . This will introduce a whole new world of undesired artifacts and seems unrealistic
2. Hack the lightboost thing to work on 60Hz. This will add flickering for sure as backlight strobe will be slower, but I think that flicker would be similar to CRTs usual flicker.
3. Play MAME at 2x speed for great awesomeness :afro:
4. Forget about all and stick with old CRTs (mine died some weeks ago, thats why I am trying this)
So seems that the only realistic option for CRT mame gaming with TFTs is to wait for a new technology (oled, tvs with strobe at ntsc refresh, new tvs with scanning backlight at 60hz i think there are at least one model around) or hack the lightboost thing to work on 60Hz.
Related video of the undesired judder:
Fallout New Vegas fps Ghosting example on Plasma TV (http://www.youtube.com/watch?v=X113cl9K_Oo#)
-
Ok, that's definitely it.
And it confirms my suspicions, it's the same artifact I'm seeing in my CRT at 120 Hz.
Well you're not mentioning the other feasible possibility: adding a black frame in the middle instead of duplicating frames, to create the strobe by software. I wonder how much flicker you'd get with this method on a 120 Hz display.
-
And you were right from the beggining, yes. Adding a blank frame between may help. How can I test it? I have some trouble understanding mame code (mainly that schedule thing).
-
If you take the CabMAME patch, the -redraw patch is applied to src/emu/video.c, but to do a quick test you could edit /osd/windows/window.c, the winwindow_video_window_update function is where the screen update is ordered, you could add a static boolean there that switches from true to false on each call, then if false, set the primlist to null, I'm not sure if it would work but...
-
Mmmm I see. I will test it and check what it does.
-
Finally, thanks to Calamity, got it working. It simply astonishing to see how it performs!
PROS:
- No noticeable flicker (at least for my eyes) if you are using 120Hz+Lightboost hack
- Absolutely cristal clear, CRT like scrolls and sprites. No more blur!
CONS:
- Brightness halved due to black frame insertion. You need to max your brightness and tweak a bit gamma, but at least in my monitor 2411T Benq, it looks superb after adjusting.
- You need to be Lightboost enabled, so you need a special monitor and do the lightboost hack: http://www.blurbusters.com/zero-motion-blur/lightboost/ (http://www.blurbusters.com/zero-motion-blur/lightboost/)
- Code must be manually altered for this to work on 60Hz sources. That includes emulators, locked fps games...
I am now a very very happy man, getting back to that Break Thru, now it is very playable on LCD :cheers:
Thanks Calamity for your help and advices!
-
Congratulations for getting Black Frame Insertion working with MAME 120 Hz.
I think we've got the world's first Zero Motion Blur LCD MAME!
I'm the one who encouraged cpharlock to look into this, from the HardForum thread.
My BlurBusters.com Blog (http://www.blurbusters.com) is covering the LightBoost LCD's -- strobe backlight LCD's -- with media coverage (http://www.blurbusters.com/zero-motion-blur/media/), the high-speed video of an LCD display successfully bypassing pixel persistence (http://www.blurbusters.com/zero-motion-blur/), and the instructions in the LightBoost HOWTO (http://www.blurbusters.com/zero-motion-blur/lightboost/).
FYI: My blog measured a LightBoost LCD monitor to have a whopping 92% less motion blur than a standard 60 Hz LCD, because of the LightBoost strobe backlight.
60 Hz CRT = 1 to 2 millisecond phosphor decay flicker
60 Hz LCD = 16.7ms LCD sample and hold
120 Hz LCD = 8.3ms LCD sample and hold (50% less blur)
120 Hz LCD with LightBoost = 1.4ms to 2.4ms strobe flash (85% to 92% less motion blur)
1.4ms strobe is 92% shorter than a 16.7ms refresh (60 Hz), and finally makes LCD equal to CRT in motion blur.
Unfortunately, LightBoost strobes only works at 120 Hz, so I was the one who suggested black frame insertion and encouraged the source code modification. This eliminates the frame repeat, and eliminates the double frame image, gaining the full 60 Hz effect on a 120 Hz LCD with each MAME frame strobed only once, like a CRT.
___________
This new MAME black frame insertion feature would lead to:
50% less motion blur on regular 120 Hz LCD's -- 8.33ms frame samples instead of 16.7ms frame samples
85% less motion blur on LightBoost 120 Hz LCD's (with LightBoost OSD setting configured to 100%) -- 2.4ms strobe backlight
92% less motion blur on LightBoost 120 Hz LCD's (with LightBoost OSD setting configured to 10%, not "OFF") -- 1.4ms strobe backlight
So all 120Hz monitors will benefit, but LightBoost LCD's will benefit the most.
It should also work for European framerates (50fps @ 100 Hz LightBoost, which LightBoost also supports).
Thanks,
Mark Rejhon
BlurBusters.com Blog -- Eliminating Motion Blur On LCD's
-
It's so great that it works!
The first place I read about the idea of black frame insertion in MAME and an actual SDL implementation of it was in this thread by Pulsewidth:
http://shmups.system11.org/viewtopic.php?f=1&t=34212 (http://shmups.system11.org/viewtopic.php?f=1&t=34212)
The good news for us are that this trick is not specific of the LCD technollogy, it actually solves an old issue we had with frame doubling on 31 kHz CRT monitors. We use this to create real hardware scanlines for low resolution video modes at 31 kHz by doubling the vertical refresh to 120 Hz. The problem was this technique leads to some degree of perceived judder, that is absent when running those games at their native 60 Hz refresh.
One interesting case was Super Zaxxon. This game has a fast diagonal scroll. Well, when running this game duplicating frames at 120 Hz, you could see how scanlines nearly disappeared as soon as the scroll started. Of course it was a visual effect, because the scanlines where obviously there. Then I was pointed to your text about eye tracking induced blur and I understood the problem.
Inserting a black frame makes the scroll perfectly smooth again for 120 Hz CRT screens too, and adds zero flicker, at least on my monitor.
-
Excellent to know that this BFI technique works so successfully for all known 120 Hz use cases (not just LCD)
120 Hz LCD benefits massively from it because LCD motion blur is so terrible to begin, that suddenly turning LCD motion into a CRT motion is an amazing sight to behold. This black frame insertion trick needs to be part of all MAME codebases if possible, and other emulators too (NES, SNES, etc).
I do have one request: Please insert "www.blurbusters.com/mame/" into the MAME documentation, ChangeLog or some other information in MAME, because I'm going to expand this page with instructions, a technical explanation how it works & also a download link. Both your names have been added as credit.
-
Hi mdrejhon,
Thanks for spreading this. I just want to clarify I'm not one of the MAME devs, so I can't add anything into MAME documentation. Of course I will add your link for reference on the new GroovyMAME update when this feature is included.
The new version is a bit delayed as there are some bulk changes to the source that need to be done, probably not so exciting stuff but defintely required.
The -strobe patch (or "-black_frame_insertion" if we rename it finally), as it is now, is just too hacky for MAME devs to consider, however a reworked version of it might have some chance some day, especially when there's general awareness (i.e: mameworld forums) of the improved visual experience (it might be early for this yet, as most of us still use 60 Hz panels). If you think about it, HLSL is definitely much more baroque and managed to get its way into baseline MAME.
Just thought I'd copy the patch here so people following this thread understand what we're talking about. This is to be applied to baseline MAME v0.148, NOT GroovyMAME. It adds a new option named -strobe, so create a new mame.ini (mame -cc). This is for 120 Hz LCD only.
For proper operation, these parameters are *required*: -strobe -video d3d -syncrefresh -nothrottle -nomultithreading
diff -rupN ./src/osd/windows/drawd3d.c ./src/osd/windows/drawd3d.c
--- ./src/osd/windows/drawd3d.c 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/drawd3d.c 2013-03-01 22:34:18.000000000 +0100
@@ -545,6 +545,7 @@ static int drawd3d_window_draw(win_windo
{
d3d_info *d3d = (d3d_info *)window->drawdata;
render_primitive *prim;
+ static bool blank_frame;
HRESULT result;
// if we're in the middle of resizing, leave things alone
@@ -581,6 +582,9 @@ mtlog_add("drawd3d_window_draw: begin");
d3d->hlsl->record_texture();
+ blank_frame = !blank_frame;
+ if (!video_config.strobe || !blank_frame){
+
// first update any textures
window->primlist->acquire_lock();
for (prim = window->primlist->first(); prim != NULL; prim = prim->next())
@@ -629,7 +633,7 @@ mtlog_add("drawd3d_window_draw: primitiv
}
mtlog_add("drawd3d_window_draw: primitive loop end");
window->primlist->release_lock();
-
+}
// flush any pending polygons
mtlog_add("drawd3d_window_draw: flush_pending begin");
primitive_flush_pending(d3d);
diff -rupN ./src/osd/windows/video.c ./src/osd/windows/video.c
--- ./src/osd/windows/video.c 2011-12-15 15:10:46.000000000 +0100
+++ ./src/osd/windows/video.c 2013-03-01 21:57:39.000000000 +0100
@@ -427,6 +427,7 @@ static void extract_video_config(running
video_config.syncrefresh = options.sync_refresh();
video_config.triplebuf = options.triple_buffer();
video_config.switchres = options.switch_res();
+ video_config.strobe = options.strobe();
// ddraw options: extract the data
video_config.hwstretch = options.hwstretch();
diff -rupN ./src/osd/windows/video.h ./src/osd/windows/video.h
--- ./src/osd/windows/video.h 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/video.h 2013-03-01 21:56:26.000000000 +0100
@@ -100,6 +100,7 @@ struct win_video_config
int syncrefresh; // sync only to refresh rate
int triplebuf; // triple buffer
int switchres; // switch resolutions
+ int strobe; // strobe to reduce motion blur
// ddraw options
int hwstretch; // stretch using the hardware
diff -rupN ./src/osd/windows/window.c ./src/osd/windows/window.c
--- ./src/osd/windows/window.c 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/window.c 2013-03-01 22:57:29.000000000 +0100
@@ -817,7 +817,11 @@ void winwindow_video_window_update(win_w
if (multithreading_enabled)
PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
else
+ {
SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ if (video_config.strobe)
+ SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ }
mtlog_add("winwindow_video_window_update: PostMessage end");
}
}
diff -rupN ./src/osd/windows/winmain.c ./src/osd/windows/winmain.c
--- ./src/osd/windows/winmain.c 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/winmain.c 2013-03-01 21:53:05.000000000 +0100
@@ -422,6 +422,7 @@ const options_entry windows_options::s_o
{ WINOPTION_FULLSCREENBRIGHTNESS ";fsb(0.1-2.0)", "1.0", OPTION_FLOAT, "brightness value in full screen mode" },
{ WINOPTION_FULLSCREENCONTRAST ";fsc(0.1-2.0)", "1.0", OPTION_FLOAT, "contrast value in full screen mode" },
{ WINOPTION_FULLSCREENGAMMA ";fsg(0.1-3.0)", "1.0", OPTION_FLOAT, "gamma value in full screen mode" },
+ { WINOPTION_STROBE ";st", "0", OPTION_BOOLEAN, "alternate a normal and a blank frame, intended to remove motion blur on 120
Hz monitors" },
// sound options
{ NULL, NULL, OPTION_HEADER, "WINDOWS SOUND OPTIONS" },
diff -rupN ./src/osd/windows/winmain.h ./src/osd/windows/winmain.h
--- ./src/osd/windows/winmain.h 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/winmain.h 2013-03-01 21:29:57.000000000 +0100
@@ -143,6 +143,7 @@
#define WINOPTION_FULLSCREENBRIGHTNESS "full_screen_brightness"
#define WINOPTION_FULLSCREENCONTRAST "full_screen_contrast"
#define WINOPTION_FULLSCREENGAMMA "full_screen_gamma"
+#define WINOPTION_STROBE "strobe"
// sound options
#define WINOPTION_AUDIO_LATENCY "audio_latency"
@@ -262,6 +263,7 @@ public:
float full_screen_brightness() const { return float_value(WINOPTION_FULLSCREENBRIGHTNESS); }
float full_screen_contrast() const { return float_value(WINOPTION_FULLSCREENCONTRAST); }
float full_screen_gamma() const { return float_value(WINOPTION_FULLSCREENGAMMA); }
+ bool strobe() const { return bool_value(WINOPTION_STROBE); }
// sound options
int audio_latency() const { return int_value(WINOPTION_AUDIO_LATENCY); }
-
Also, precompiled binaries are here if you do not want to do the patch and compile work:
http://free-game.es/mame0148_strobe_modded.zip (http://free-game.es/mame0148_strobe_modded.zi)
The ini file included is the one I am currently using in my system, so you may have to tweak it a bit to suit yours, but probably it will go as is. HLSL is enabled and configured my taste, hope you like it :D
IMPORTANT: If you are using lightboost, remember to hit CTRL+T when game loads to disable 3D otherwise it will stutter
-
I've posted a thread at the Mameworld forum to publicize this change.
Mameworld Thread -- Eliminate motion blur on 120 Hz LCD's with MAME software black frame insertion (http://www.mameworld.info/ubbthreads/showflat.php?Number=305674)
-
The good news for us are that this trick is not specific of the LCD technollogy, it actually solves an old issue we had with frame doubling on 31 kHz CRT monitors. We use this to create real hardware scanlines for low resolution video modes at 31 kHz by doubling the vertical refresh to 120 Hz. The problem was this technique leads to some degree of perceived judder, that is absent when running those games at their native 60 Hz refresh.
Even more good news!
120Hz has less input lag! It half a frame less input lag, a big win for Street Fighter and other fast-reaction button-mash games! Doing the black frame insertion masks the second repeat of a refresh, giving the proper 60fps effect, while keeping the reduced input lag of 120Hz! This actually partially makes up for the mandatory input lag of the MAME framebuffer!
240p @ 120Hz has less input lag than 480p @ 60Hz
(And this black frame insertion fixes the double-image motion artifacts, so it looks exactly like 480p with the black scanlines tweak)
-
I tried the same modelines given to me in Linux and tried to apply it in Windows XP. I changed crt_range to monitor_specs and it switches to 120Hz but it also doubles the resolution of the screen. So it displays 120Hz at 480P instead of 240. I've tried turning off the double_scan option in mame.ini but it has no effect. Also tried using the modeline in VmMaker but it doesn't make a difference. If I try to change the desktop to low res @ 120Hz it chops the display in half and still displays at 480p.
Can I get switchres to keep native res or is this a limitation in Windows?
-
I tried the same modelines given to me in Linux and tried to apply it in Windows XP. I changed crt_range to monitor_specs and it switches to 120Hz but it also doubles the resolution of the screen. So it displays 120Hz at 480P instead of 240. I've tried turning off the double_scan option in mame.ini but it has no effect. Also tried using the modeline in VmMaker but it doesn't make a difference. If I try to change the desktop to low res @ 120Hz it chops the display in half and still displays at 480p.
Can I get switchres to keep native res or is this a limitation in Windows?
Hi mamenewb100,
You can't use old VMMaker for frequency scaling, this is part of the new Switchres engine and I'm currently porting it to VMMaker. It's not required however, GroovyMAME will convert the normal 60 Hz resolutions to 120 Hz for you on the fly, based on its crt_range settings.
However the strobing is not implemented yet in currently available GroovyMAME so the scrolls will be blurry.
-
I got it to work in Windows now. There was something wrong with my mame ini. Scrolling is just like it was in 31K now. Something else I'm surprised that didn't get mentioned is games are flickering properly again, right? The timing should be the same. Instead of 120FPS@120Hz with each frame duplicated like before. It is now 60FPS@120Hz with a blank frame every other frame, which should be the same as 60FPS@60Hz right? My camera is picking up flicker in low refresh games when it wasn't before.
If true, than the only thing that would be off now is the brighter desktop but there could be a way to create a modeline with the same effect? Probably not but the desktop usually needs more brightness anyway. The only downside would be games that run at 31 Khz would need a seperate MAME build unless an option is made to toggle frame insertion on and off. Also the brightness would have to be re-adjusted when switching between both. Other than that I think it should be almost no difference between 31K and 15K monitor, depending only on the dot pitch of your display.
-
I got it to work in Windows now.
Great! How does it look? What display are you using -- I'm assuming you're using a 31K CRT? Although this modification benefits LCD far more greatly than CRT's, it has great benefit for 31K CRT's. However, CRT's benefits from the reduced input lag of 120 Hz; great for fighter games.
There was something wrong with my mame ini.
Mind if you elaborate; so that we can warn others?
Scrolling is just like it was in 31K now. Something else I'm surprised that didn't get mentioned is games are flickering properly again, right? The timing should be the same. Instead of 120FPS@120Hz with each frame duplicated like before. It is now 60FPS@120Hz with a blank frame every other frame, which should be the same as 60FPS@60Hz right? My camera is picking up flicker in low refresh games when it wasn't before.
That's correct. For CRT's, it should visually look exactly the same as 60 Hz. Black-frame insertion allows 120 Hz behave like 60 Hz, without changing the refresh rate from 120 Hz. You are still running 31K, just 240p@120Hz instead of 480p@60Hz.
You also get the reduced input lag due to the quicker display of frames -- your refreshes are finished 8 milliseconds more quickly (1/120sec refreshes are displayed in half the time period of 1/60sec refreshes).
If true, than the only thing that would be off now is the brighter desktop but there could be a way to create a modeline with the same effect? Probably not but the desktop usually needs more brightness anyway. The only downside would be games that run at 31 Khz would need a seperate MAME build unless an option is made to toggle frame insertion on and off. Also the brightness would have to be re-adjusted when switching between both. Other than that I think it should be almost no difference between 31K and 15K monitor, depending only on the dot pitch of your display.
Except input lag. You will get less input lag at 120 Hz + black frame insertion.
So that makes 31K CRT's superior for input lag, using the 240p+120Hz+BFI trick.
There is no modeline way to fix the brighter desktop -- unless you do BFI (Black Frame Insertion / strobing) on the desktop -- except some other modifications to compensate for this, such as using a darker MAME desktop.
Either way, hopefully future MAME modifications will include useful changes that will do exactly what you say -- toggle BFI on/off, etc. Also, you do not necessarily need two builds -- you can also use two separate commandlines (instead of using a configuration file). One that launches without BFI (strobing), and another that launches with BFI.
-
@Mark, mamenewb100 is beta-testing a strobing-enabled GroovyMAME based build, instead of the vanilla MAME based that we released. That's probably why he needed specific ini options.
He's using a Makvision 2929D, 31 kHz arcade monitor, check his thread:
http://forum.arcadecontrols.com/index.php/topic,130215.0.html (http://forum.arcadecontrols.com/index.php/topic,130215.0.html)
Although its picture will be sharper than the old-school arcade monitor, I believe its dot pitch can't be very different from the typical 15/25/31 kHz multisync monitor, so this Makvision working low res at 120Hz/31kHz/BFI will look as good as any multisync working at 60Hz/15kHz.
-
You know I thought maybe I was just getting better at timing the combos in street fighter but I guess if you think about it, your given an extra frame to pull off a move. Which I guess is kind of cheating.. but I'm not playing competitively or anything. And it evens the score against the cheap CPU. ;)
So it's not really input lag but extra input time.
-
Hi, just an important request (and a bump) for the original compiler..
If you can get the sources for 0.139 version, is it possible to compile and upload that version somewhere, for the strobe frame insertion?
The reason I ask is, versions of mame from 0.145+ have broken savestates in many of the Atari System 1 games (All the gauntlet and Gauntlet 2 games, at minimum), while saves work perfectly in 0.139.
And yes they are broken in 0.148.
So if it's possible to make a 0.139 compile, would you be able to kindly do it for me (and any other sporadic Gauntlet fans)
Thank you.
(btw this feature really should be put in as an official option in MAME, since MAME is supposed to preserve the original experience, and 60 hz blurry LCDs are only used in much newer games (Street fighter 4, Virtua Fighter/Tekken 6, etc, etc)
-
You know I thought maybe I was just getting better at timing the combos in street fighter but I guess if you think about it, your given an extra frame to pull off a move. Which I guess is kind of cheating.. but I'm not playing competitively or anything. And it evens the score against the cheap CPU. ;)
So it's not really input lag but extra input time.
It's still input lag.
1. This is because original arcade games didn't have a buffer. They scanned out the graphics in real-time to a CRT.
2. Emulated MAME adds input lag, compared to the original machine, because MAME uses a framebuffer where none originally existed.
3. Using 120Hz reduces this MAME framebuffer lag.
So you're actually getting closer to original manufactured videogame responsiveness, by reducing the MAME framebuffer lag.
-
Mind re-uploading the source patch or binaries since free-game.es fell off the face of the earth?
Edit: Saw you posted the diff on the previous page, got it to compile and it works great even on my old Samsung 2233RZ. Thanks for all your hard work on this!
-
Mind re-uploading the source patch or binaries since free-game.es fell off the face of the earth?
Edit: Saw you posted the diff on the previous page, got it to compile and it works great even on my old Samsung 2233RZ. Thanks for all your hard work on this!
Can someone please make this an official part of one of the public MAME releases?
Sincerely,
Mark Rejhon
-
Hi, sorry for being offline for some time. I saw that freegame went offline, tomorrow I will upload it to another place and update it.
-
Here you are, the updated links:
DIFF:
http://db.tt/linhVuTQ (http://db.tt/linhVuTQ)
COMPILED:
http://db.tt/jOknzHEU (http://db.tt/jOknzHEU)
And soon Openmsx also :D . Just trying to fix some sound sync issues. BTW Openmsx do not use Directx and I thought it is mandatory to do the trick, but seems that SDLGL when going fullscreen it uses the same desktop resolution and refresh rate so in fact is 3D enabled already, so black frame trick works perfectly.
-
Hi mdrejhon,
Thanks for spreading this. I just want to clarify I'm not one of the MAME devs, so I can't add anything into MAME documentation. Of course I will add your link for reference on the new GroovyMAME update when this feature is included.
The new version is a bit delayed as there are some bulk changes to the source that need to be done, probably not so exciting stuff but defintely required.
The -strobe patch (or "-black_frame_insertion" if we rename it finally), as it is now, is just too hacky for MAME devs to consider, however a reworked version of it might have some chance some day, especially when there's general awareness (i.e: mameworld forums) of the improved visual experience (it might be early for this yet, as most of us still use 60 Hz panels). If you think about it, HLSL is definitely much more baroque and managed to get its way into baseline MAME.
Just thought I'd copy the patch here so people following this thread understand what we're talking about. This is to be applied to baseline MAME v0.148, NOT GroovyMAME. It adds a new option named -strobe, so create a new mame.ini (mame -cc). This is for 120 Hz LCD only.
For proper operation, these parameters are *required*: -strobe -video d3d -syncrefresh -nothrottle -nomultithreading
diff -rupN ./src/osd/windows/drawd3d.c ./src/osd/windows/drawd3d.c
--- ./src/osd/windows/drawd3d.c 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/drawd3d.c 2013-03-01 22:34:18.000000000 +0100
@@ -545,6 +545,7 @@ static int drawd3d_window_draw(win_windo
{
d3d_info *d3d = (d3d_info *)window->drawdata;
render_primitive *prim;
+ static bool blank_frame;
HRESULT result;
// if we're in the middle of resizing, leave things alone
@@ -581,6 +582,9 @@ mtlog_add("drawd3d_window_draw: begin");
d3d->hlsl->record_texture();
+ blank_frame = !blank_frame;
+ if (!video_config.strobe || !blank_frame){
+
// first update any textures
window->primlist->acquire_lock();
for (prim = window->primlist->first(); prim != NULL; prim = prim->next())
@@ -629,7 +633,7 @@ mtlog_add("drawd3d_window_draw: primitiv
}
mtlog_add("drawd3d_window_draw: primitive loop end");
window->primlist->release_lock();
-
+}
// flush any pending polygons
mtlog_add("drawd3d_window_draw: flush_pending begin");
primitive_flush_pending(d3d);
diff -rupN ./src/osd/windows/video.c ./src/osd/windows/video.c
--- ./src/osd/windows/video.c 2011-12-15 15:10:46.000000000 +0100
+++ ./src/osd/windows/video.c 2013-03-01 21:57:39.000000000 +0100
@@ -427,6 +427,7 @@ static void extract_video_config(running
video_config.syncrefresh = options.sync_refresh();
video_config.triplebuf = options.triple_buffer();
video_config.switchres = options.switch_res();
+ video_config.strobe = options.strobe();
// ddraw options: extract the data
video_config.hwstretch = options.hwstretch();
diff -rupN ./src/osd/windows/video.h ./src/osd/windows/video.h
--- ./src/osd/windows/video.h 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/video.h 2013-03-01 21:56:26.000000000 +0100
@@ -100,6 +100,7 @@ struct win_video_config
int syncrefresh; // sync only to refresh rate
int triplebuf; // triple buffer
int switchres; // switch resolutions
+ int strobe; // strobe to reduce motion blur
// ddraw options
int hwstretch; // stretch using the hardware
diff -rupN ./src/osd/windows/window.c ./src/osd/windows/window.c
--- ./src/osd/windows/window.c 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/window.c 2013-03-01 22:57:29.000000000 +0100
@@ -817,7 +817,11 @@ void winwindow_video_window_update(win_w
if (multithreading_enabled)
PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
else
+ {
SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ if (video_config.strobe)
+ SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ }
mtlog_add("winwindow_video_window_update: PostMessage end");
}
}
diff -rupN ./src/osd/windows/winmain.c ./src/osd/windows/winmain.c
--- ./src/osd/windows/winmain.c 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/winmain.c 2013-03-01 21:53:05.000000000 +0100
@@ -422,6 +422,7 @@ const options_entry windows_options::s_o
{ WINOPTION_FULLSCREENBRIGHTNESS ";fsb(0.1-2.0)", "1.0", OPTION_FLOAT, "brightness value in full screen mode" },
{ WINOPTION_FULLSCREENCONTRAST ";fsc(0.1-2.0)", "1.0", OPTION_FLOAT, "contrast value in full screen mode" },
{ WINOPTION_FULLSCREENGAMMA ";fsg(0.1-3.0)", "1.0", OPTION_FLOAT, "gamma value in full screen mode" },
+ { WINOPTION_STROBE ";st", "0", OPTION_BOOLEAN, "alternate a normal and a blank frame, intended to remove motion blur on 120
Hz monitors" },
// sound options
{ NULL, NULL, OPTION_HEADER, "WINDOWS SOUND OPTIONS" },
diff -rupN ./src/osd/windows/winmain.h ./src/osd/windows/winmain.h
--- ./src/osd/windows/winmain.h 2013-01-11 08:32:46.000000000 +0100
+++ ./src/osd/windows/winmain.h 2013-03-01 21:29:57.000000000 +0100
@@ -143,6 +143,7 @@
#define WINOPTION_FULLSCREENBRIGHTNESS "full_screen_brightness"
#define WINOPTION_FULLSCREENCONTRAST "full_screen_contrast"
#define WINOPTION_FULLSCREENGAMMA "full_screen_gamma"
+#define WINOPTION_STROBE "strobe"
// sound options
#define WINOPTION_AUDIO_LATENCY "audio_latency"
@@ -262,6 +263,7 @@ public:
float full_screen_brightness() const { return float_value(WINOPTION_FULLSCREENBRIGHTNESS); }
float full_screen_contrast() const { return float_value(WINOPTION_FULLSCREENCONTRAST); }
float full_screen_gamma() const { return float_value(WINOPTION_FULLSCREENGAMMA); }
+ bool strobe() const { return bool_value(WINOPTION_STROBE); }
// sound options
int audio_latency() const { return int_value(WINOPTION_AUDIO_LATENCY); }
Do you have a setting for 120hz CRT, with the black frame insertion?
-
Hi, I posted a request on the last page but no one replied :(:(
Can you guys kindly make a strobed version of the older 0.139 version (64 bit) if possible? I mentioned that the 0.148 version has problems with save states in the Atari system 1 games (Gauntlet and others).
Just a request.... please?
-
MAME developers and others:
Here's a web animation of software-based black-frame insertion (http://www.testufo.com/#test=blackframes).
(Blur Busters Motion Test website, requires Chrome, IE 10+ or FireFox 24+; quit all apps and browser tabs for smooth operation)
http://www.testufo.com/#test=blackframes (http://www.testufo.com/#test=blackframes)
If you run at 60Hz, it will demonstrate 30fps + black frames insertion.
If you run at 120Hz, it will demonstrate 60fps + black frames insertion.
-
Hi, I posted a request on the last page but no one replied :(:(
Can you guys kindly make a strobed version of the older 0.139 version (64 bit) if possible? I mentioned that the 0.148 version has problems with save states in the Atari system 1 games (Gauntlet and others).
Just a request.... please?
Hi Falkentyne, sorry but I don't have the time atm to make custom builds. However the patch is available and it should be possible to backport it to v0.139. I think you should consider reporting this problem with Gauntlet save states to MAMEdevs so it can get fixed in the main line project.
-
I'm looking to improve display lag and blur.
Are the ideas above still relevant / state of the art ?
Are the necessary options in groovymame now ? or what's the most up to date patch/diff?
What are some good screens to use? eg 24" 120fps
-
This thread is obsolete. GroovyMAME supports black frame insertion since long. The relevant options now are:
-monitor lcd
-black_frame_insertion
-syncrefresh
-lcd_range 60-120 ->this one is required for 120Hz lcds
This will work as long as your desktop is configured with a 120 Hz video mode.
Be warned that the result won't probably be as nice as you may expect.
-
Be warned that the result won't probably be as nice as you may expect.
I don't have a 120fps capable monitor at the moment. From the above comment I don't think I want to pursue this method.
(If I end up with a high frame rate monitor I run the above to see the result).