Support for 100Hz/120Hz lightboost strobe

[mdrejhon]

Originally Posted by Toni Wilen

WinUAE has always supported this.
It isn't that simple to implement but should be possible, at least in some modes..
As I said above, winuae "low latency" mode is not like traditional vsync.

Very interesting explanations, and it does make sense. Having programmed machine language on 6502 CPU on the Commodore 64, worked with raster interrupts, and written a 100% assembly language video game, and achieved sprite multiplication, I can appreciate the challenges that emulator authors go through for accurate graphics emulation, while also at the same time trying to synchronize the emulator to the real machine...

d) it is not possible to get real time state information (current "scanline" position, which frame is being displayed, if I send next frame for displaying now, does it stall because internal frame buffer(s) are full).

I'm able to read it using Microsoft Direct3D API "RasterStatus.ScanLine". I did some tests and it works on AMD and nVidia cards. This isn't perfect because it is not guaranteed to work on all graphics cards, and it is a polled API -- no raster interrupts or events! Don't know if this will help in synchronizing your frame-delivery to the graphics card, to make sure your frame is delivered to a back buffer before it's flipped during the next refresh, if you're trying to avoid buffer latency. (If you're rendering high-resolution images in RAM, there's a frame transfer latency for transferring over the bus to graphics card, amongst other latencies caused by the driver, so if you eventually plan to use RasterStatus.ScanLine to improve frame delivery accuracy, you probably want a safety margin; to deliver the frame to the graphics card about 2ms before the scanline hits the blanking interval) Also, it appears fairly "expensive" to read RasterStatus.ScanLine (very slow operation, I can only read it a mere half million times per second or so) so you definitely don't want to poll it excessively frequently, like every clock cycle....

Without looking at your code, you probably use a high-precision multimedia timer presently? Running off when the previous frame-flip returns, as a guesstimate of when the next frame flips?

Either way, I'll leave it to you to decide the best way to handle black-frame insertion. Sounds quite tricky with your architecture at the moment.

[mdrejhon]

Originally Posted by Toni Wilen

c) there is no way to tell the driver that "yes, I probably missed this frame by 1ms or so, but I do have new frame ready, please show it immediately without waiting for next frame. (possible tearing is much better than missing whole frame which also mess all other timings temporarily)

I guess you're thinking of a behaviour very similiar to a newer graphics card's "Adaptive VSYNC" feature? It essentially does what you describe; it enables VSYNC at fps=Hz, but tearing shows up at fps<Hz. Two comments come to my mind:

1. This will be difficult to reconcile with black frame insertion, since you'll have nasty moments of flicker when perfect sync isn't maintained. One method is to occasionally swap a black frame with the frame, to give you another 8.33ms of time to finish processing, instead of causing a tearing issue. This will still cause a noticeable flicker issue, though less objectionable than double-black-frames.:
#=a visible frame / 0=black frame
1,0 | 2,0 | 3,0 | 0,4 | 5,0

But most computers that use a 120Hz monitors are fast computers anyway, so you might not want to bother.

2. Couldn't you use RasterStatus.ScanLine to guesstimate whether or not you missed the frame flip opportunity or not? It might not provide perfect guesstimating, though.

3. What about the idea of simply decoupling the black frame insertion from emulator frame delivery?
e.g. let emulator framerepeat and frameskip if it doesn't have a frame ready?
Basically, you'll always have black frame insertion always at every odd-numbered refreshes, regardless of how fast or how slow your emulator is running.
Example:
#=a visible frame / 0=black frame

1,0 | 2,0 | 3,0 | 3,0 | 4,0

or

1,0 | 3,0 | 5,0 | 7,0 | 9,0

This actually looks MUCH better in other varible-framerate software (based on my testing). The emulator would just simply run at whatever speed it does, and your frame flipping logic would execute on the clock (e.g. 2 milliseconds before blanking interval), alternately flipping to a visible frame or flipping to a black frame (instead of flipping to the currently held frame). This may require modifying your emulator logic to always execute the frame flipper always a certain amount of time before the computer's blanking interval. Make sure you have a backup method instead of RasterStatus.ScanLine, though (unless you've already used it and confirmed it doesn't work)...

Although I'm not sure if anyone really wants to run the black frame insertion trick for any framerate other than framerates synchronized with the emulator (e.g. 60fps@120Hz). That's the only time where the benefits of black frame insertion really shines. Thus, it is probably best to leave black frame insertion disabled for emulator rates other than situations where Hz is a multiple of fps. So the above method may not be worthwhile.

Tearing may actually be better, but is a bit too complicated to reconcile with black frame insertion, so you may need to enforce non-tearing modes with black frame insertion...

[Toni Wilen]

Yes, I use D3D/DD scanline reporting and QueryPerformanceCounter() in low latency mode to predict when next vblank is going to happen.

It is not that simple to decouple black frame insertion because display is "shared" (both real display and black screen use same context), you must be careful not to block normal rendering and/or render it in wrong order. Time to emulate one frame can't be predicted (one frame may take 1ms, next frame may take 15ms!). This needs extra syncronization.

[CFou!]

Originally Posted by cpharlok

New 120Hz lightboost enabled monitors can deliver perfect CRT images without blur, ghosting, coronas... I have a Benq 2411T and believe me, it can do perfect CRT animations. The problem? You need 100-120Hz sources in order to get the effect done. More info:

http://www.blurbusters.com/zero-motion-blur/lightboost/

We all know old school is 50Hz/60HZ. If we try on those monitors frames just get doubled to match monitor speed, and if you simply double the frame a juddering/doubling effect appears in moving parts of image. So you solve blur, but introduce a new artifact.

Solution: simple. Adding a black frame after every frame delivers perfect image, CRT like animation. Because we are at 120Hz the screen updates so fast that flickering is not noticeable (at least I cant see it) and you avoid the double frame effect.

What we need? : Just an option in WinUAE to enable this. At 100/120Hz instead of doubling the frame of the 50/60Hz source, we just put a black frame. Simple.

I have done it in MAME with 100% success. Believe me, it's astonishing seen perfect scroll games without the damn ghosting/blurs.

Also, any help is appreciated to recompile source and modify it to support it, however will be better to be an option for future releases.

Thanks!

i had same problem & scrolling wasz smooth only using 3d vision glasses see:
http://eab.abime.net/showthread.php?t=66975
http://eab.abime.net/showthread.php?...light=3dvision

i had tryed to intercalate black screen between 2 frames for test in amig demo running on winuae with refresh rates to 120 htz with success but not perfect....

ps:

i use ASUS VG278HE

[CFou!]

Originally Posted by cpharlok

I have done it in MAME with 100% success. Believe me, it's astonishing seen perfect scroll games without the damn ghosting/blurs.

Thanks!

with mine i must have 3D vision glasses for smooth scrolling as crt monitor

i will test mame 148 i hope mame plus will be support it

[CFou!]

Originally Posted by Toni Wilen

Quick test version: http://www.winuae.net/files/b/winuae.zip

Restrictions:
- CPU speed must be cycle exact or approximate. Fastest possible not supported.
- Low latency vsync mode only.
- Direct3D only.
- Double or triple buffer mode. No buffer not supported.

It looks "different".. Image is not as bright as normally but "ghosting" effect is gone. (ViewSonic V3D241WM)

i will test it!!

[CFou!]

Originally Posted by Toni Wilen

Quick test version: http://www.winuae.net/files/b/winuae.zip

Restrictions:
- CPU speed must be cycle exact or approximate. Fastest possible not supported.
- Low latency vsync mode only.
- Direct3D only.
- Double or triple buffer mode. No buffer not supported.

It looks "different".. Image is not as bright as normally but "ghosting" effect is gone. (ViewSonic V3D241WM)

i am just testing with my monitor VG278HE

without change in my configuration (3d vision activated) i'am just testing:
- BC kid
- turrican
- my GNG intro

of course i must press Crtl+T to remove 3d vision mode

and it's smooth using exact cycle (tested with foollowing refresh rate 100, 120 144 hz)

just 2 bugs:
- sometimes i can see a back screen (as desynchronised)
- i can see a black trame (on pixel on 2) but not visible on screenshot

[cpharlok]

I have tested BC Kid and Turrican and I get no black screen ever except one of the BC Kid pirate intros, that it pops sometimes (about every 10-20 secs), but none in games.

I tested them at 120Hz, low latency vsync, cycle exact, 1920x1080 with triple buffering and null filter with scanlines and bilinear activated.

[CFou!]

Originally Posted by cpharlok

I have tested BC Kid and Turrican and I get no black screen ever except one of the BC Kid pirate intros, that it pops sometimes (about every 10-20 secs), but none in games.

I tested them at 120Hz, low latency vsync, cycle exact, 1920x1080 with triple buffering and null filter with scanlines and bilinear activated.

tes again it's working fine now... (i was by error use regedit fix for no 3d glisses users...)

but i have a little bug

with same configuration between previous winaue version and strobe beta version, i can see pixel are badly displayed with stobe version (

indeed there are like a RGB filter and it's not pretty

be example a white pixel are not white as on winuae stable release but i can see RGB pixel!!! as on old pixel zoom on crt monitor....

have you same probleme....

[cpharlok]

Mmm I have it ok but I had some trouble at first to get image right, maybe it is related to beta due to this:

"- Multiple Direct3D shader filters can be enabled simultaneously, optionally
shader can be now run after scaling and filtering."

[CFou!]

Originally Posted by cpharlok

Mmm I have it ok but I had some trouble at first to get image right, maybe it is related to beta due to this:

"- Multiple Direct3D shader filters can be enabled simultaneously, optionally
shader can be now run after scaling and filtering."

it's looks like a RGB filter..

with strobe's winuae version bug dispairs if i don't use double or trible buffer but in this cas no strobe effect and no smooth scrolling of course

[Toni Wilen]

Note that filter adjusments are completely reset if you switch from pre-2.6 to 2.6.

EDIT: and this is useless information without screenshots, logs and config file.

[CFou!]

Originally Posted by Toni Wilen

Note that filter adjusments are completely reset if you switch from pre-2.6 to 2.6.

EDIT: and this is useless information without screenshots, logs and config file.

i'll send you this evening debug files

i noticed also on RTG screen in fullscreen mode (not window) lost of colors and bad color!! after pressing ctrl+ i'll try to send screenshot

for information i am no problem with mame-strobe version=>very smooth without colors problem


ps:
what is high-end rom?
is existing rom for high-end amiga machine supported by winuae?

[CFou!]

Originally Posted by Toni Wilen

Note that filter adjusments are completely reset if you switch from pre-2.6 to 2.6.

EDIT: and this is useless information without screenshots, logs and config file.

here log file and config.

screenshot are black screen or good no visual problem

but real picture in uae have curious colors. white pixel are not white it's grey and i can see RGB pixel!!!! but not on screenshot...

can it caused by nvidia sli (both gtx580 in sli)?

[Toni Wilen]

winuaelog.txt is missing and you really should check when the problem started, I am 99.9% sure it has nothing to do with lightboost and most likely nothing to do with 2.6 betas either.

[CFou!]

Originally Posted by Toni Wilen

winuaelog.txt is missing and you really should check when the problem started, I am 99.9% sure it has nothing to do with lightboost and most likely nothing to do with 2.6 betas either.

you must be right but tonight I'll send you the missing file

Regards,
Bertrand

ps:
thank for your heavy and marvelous works with winuae!!

[CFou!]

Originally Posted by Toni Wilen

winuaelog.txt is missing and you really should check when the problem started, I am 99.9% sure it has nothing to do with lightboost and most likely nothing to do with 2.6 betas either.

HERE MISSING FILES/

[CFou!]

for information several month ago, i have constated than 2D scrolling on winaue or pc game (scrolling in main menu of just cause2/shank) was also smooth than a real amiga on CRT monitor but only in 120hz mode with 3d vision glasses.

so i had coded using winaue in a Vertical Blank interrupt a little code to display 1 frame on 2 in black (see joinded file for test using gng trainer now)

i launched this on winuae on 120hz screen without 3d glasses.

i have product not LCD bad blur effect and scrolling seems smoothes but:
- intro slowdown (1 frame on 2)
- i can see black screen switch

but i knewn it's possible to display smooth scrolling on LCD

now i am happy mame and winaue can do it

thanks a lot for that

[Toni Wilen]

Originally Posted by CFOU!

HERE MISSING FILES/

You didn't say if 100Hz/120Hz worked in older versions? I want 100% confirmation that this is related to strobe, not some generic 100Hz/120Hz vsync issue.

[CFou!]

Originally Posted by Toni Wilen

You didn't say if 100Hz/120Hz worked in older versions? I want 100% confirmation that this is related to strobe, not some generic 100Hz/120Hz vsync issue.

yes

no problem with other no beta version with 100hz/120HZ/

i will try with another Beta version without strobe support
this version by exapme:
http://eab.abime.net/showpost.php?p=870793&postcount=91

i'll confirme to you