No-buffering display mode with zero screen tearing, the next step?

[Dr.Venom]

Hi Toni,

I've been doing some additional testing with the floating point frequency support in the latest beta (2.3.2 beta 5). Since this topic is deviating from the original topic (whether or not WinUAE is optimized for lowest possible input lag, see http://eab.abime.net/showthread.php?t=58495), I'm posting this as a seperate topic.

Given my findings and some new ideas I hope that we can possibly take the floating point frequency support one step further. The goal would be to make the feature robust enough for users to enjoy the "no buffering" display mode (fastest mouse/joypad input response) in combination with zero screen tearing. With robust I mean that it would take a one time calibration by the user and after that no "tricks" or anything to get screen-tearing to zero.

I need to explain my findings a bit to hopefully make it clear where my suggestion comes from and why it could be a step forward in making this a robust and unique feature (not to forget the Dream of every Amiga purists action gamer! ). To be honest, if this is going to work, then I'll keep my real Amiga A1200/060 for reference, but WinUAE will take over in all aspects.

Below is a short guide which I'll write as a guide to anyone interested. Why might it be of interest? The benefit of the chipset_refreshrate option is that it makes it possible to very closely match your monitor's refresh rate with the screen refresh rate of WinUAE, thus minimizing screen tearing in the no-buffering mode (which gives the fastest input response / lowest input delay on your mouse and joystick.) An additional benefit is that it makes it possible to match the WinUAE refresh exactly with PC screenmodes that line up exactly with the Amiga Agnus PAL display specifications (for example created with soft15khz).

To be very clear about it, this guide is meant for experienced users. If you never worried about input lag, smooth scrolling and/or screen-tearing, then you're already fine. For others, who did worry at one time or another about these topics, then you might want to explore this.

Short 'how to' guide: calibrating the chipset_refreshrate variable
Assumption: your monitor is capable of running a screenmode that has a refresh of approximately 50hz (100hz most probably also applies).

Step 1: get to know the exact refresh rate of your monitor.
You can do this by running the tool FrequencyTest, which you can get here: http://www..com/?lycrjcm55j37n

For this example let's say the tool returned an average of 49,918221. Now only take the number with the first two decimals (so 49,91) and take this as the starting value for the 'chipset_refreshrate' in the config file.

Step 2: set your WinUAE configuration:

• CPU&Chipset
  o configure it such that it closely matches A500 specs: 68000, OCS/ECS and chipset set to cycle exact.
• display
  o select a 50hz (or close to) screenmode as fullscreen native
  o select no-buffering
  o do not enable vsync)
• sound
  o disable 'automatic switching' (my guess is this resets the synchronization buffer, which in turn shifts the position of the screen tearing. We don't want that in this case).
• filter setting
  o for now do not use any filter setting.

Step 3: find out at which sound buffer setting the buffer is most stable.
You can do this by enabling 'native on-screen display' in the miscellaneous options. The game to use is Jim Power, as its title screen has lots of sideway scrolling parts and it continuously loops (this will come in handy later). So load up the title screen and change the sound buffer setting until it's most stable with the average around zero. For me this is a buffer setting of 3.

Step 4: find the right 'chipset_refreshrate' by iteration
For this you'll need some time and patience, be prepared. It will take time because you'll be going through an iterative process where you 1) start winuae and load up the game, 2) do testing , 3) close winuae, 4) adjust the chipset_refreshrate in the config file, 5) go back to 1), just as long until the screen-tearing is stabilized/fixed to a few horizontal lines that do not roll-up or down the screen, but instead stay in the same place 'jittering' back and forth a little bit.

Doing the actual refreshrate calibration.
Start by loading up the title screen of Jim Power. You'll see a big logo 'Jim Power' and lots of background horizontal scrolling looping continually. Watch the screen, you'll notice screen-tearing because of the no-buffering option. Run through the following just as long until the line tearing doesnt roll-up or down the screen anymore.

• screen tearing rolling down? This means winuae refresh is lower than your real monitor --> raise the value in the config file
• or screen tearing rolling up? This means winuae refresh is higher than your real monitor --> lower the value in the config file.

An example
As an example: your whole iterative process could be such that it starts with a value of 49,91 --> screen tear rolls down --> raise value to 49,92 --> screen tear rolls up --> lower value to 49,915 --> tear still rolls up --> lower value to 49,912 --> tear rolls (slowly) downward --> raise value to 49, 9125 --> tear still rolls slowly downward --> raise value slightly to 49,9127 --> tear still rolls slowly downward --> raise value slightly to 49,9130 --> tear moves very slowy upward --> lower value to 49,9129 --> etc... until you've gotten to 5 decimals at least. Getting to the last digit iteration, takes time (!), as you'll have to leave the title screen running for half an hour to see whether the tear is moving upward or downward... Finally you might come up for example with a value of 49.912920.

DO NOTE: various settings in WINUAE can/probably influence how stable you're going to get the tearing. for example the priority settings, how powerful your PC is and whether your using Direct3D or DirectDraw. Do experiment with some of the settings to see if they deteriorate or improve the minimization of screen tearing.

DO NOTE 2: In WinUAE 2.3.2 beta 5 there's a small bug, where the chipset_refreshrate setting is reset back to the default 50.00hz if you bring up the Setting window (F12) during emulation and click on 'Display' panel and OK. So if you experience rolling screen tearing again all of a sudden, then probably you've gone through that menu, which made the refreshrate being reset to the default value again.

If you've done things right:
Then you've probably ended up with minimal screen tearing: in this case only about 2-3 lines shift back and forth, but most importantly these 'jittery' lines stay in the same place on the screen.

Now for the interesting part. If you load up a game with these settings then you have a certain chance that the screen tearing isn't visible at all. That is when the tearing lines end up in the border and blanking area of the screen. My guess is that there's approximately an 8% chance of this happening. Simply because there are 287 lines displayed out of a total of 313. So you have 26 lines of border+blanking on 313 total, which makes it about an 8% chance of having no screen tearing at all!

The other way round is that you have a 92% chance that the jittery lines WILL be visible... But, another interesting finding leads to a way to mitigate this. If you press F12 and OK, somehow the draw position from the display buffer gets shifted a number of lines, which also makes the jittery lines shift position and then again stay put. If you try this a few times, you have about a 1 in 10 chance that the jittery lines get shifted to the border area, where you'll not see them anymore. This makes it possible to enjoy ZERO screen tearing in no-buffering mode and thus enjoy the best of all worlds: no screen tearing AND very fast input response.

As an indication, with my current calibrated settings if I press F12 and OK a few times at the start of a game, until there's no visible tearing/jittering anymore, I've been playing a long way through Jim Power (wel until level three until I get killed ) with NO screen tearing at all. The same holds for games as Hybris and Pinball Dreams. It's simply *bliss* for the Amiga purist with a love for action games, as it's so remarkably close to the real thing.

Toni, now for the suggestion

Calibrating the chipset_refreshrate value leads to a stable positioning of a few jittery lines on the screen. Already a major advancement from the 'rolling' screen tearing that default no-buffering modes lead to. There's still a drawback unfortunately, as these jittery lines may still be in sight and distract from the real smooth Amiga experience. (And unfortunately chances of these lines being invisible in the border area by itself are small.)

Now instead of pressing F12 and returning to the screen a number of times until the jittery lines are positioned in the border (which as said is a bit of a game of chance), it would be much more sensible if we could have WinUAE create the correct alignment. I do have an idea, which I hope is feasible (and works).

What if WinUAE would do a vertical sync only on the first frame after the display buffer is activated, and then return the display back to the chipset_refreshrate timing. Would filling and displaying the buffer then not be aligned correctly, thus having the jittery lines per configuration out of the visible screen area? WinUAE would probably also have to do this alignment after a user returns from the settings menu (F12) to the screen, as currenly that shifts the position of the 'jittery lines'.

It would be awesome if such an option would work, as we could enjoy a calibrated fullscreen no-buffering mode (with blazing fast input response) AND have zero screen tearing by default! It would also be robust enough for use by general users as it would only take a one-time calibration of the chipset_refreshrate by the user. A small effort, especially when in return you're getting a (very close to) real hardware response back for it...

If something like this might work then it would preferably be an additional separate option in the config file, at least for now, so that we could test it with and without this "vsync on first frame" option.

I possibly have omitted some things here and there, but hopefully the findings and story are complete enough for you to think about this suggestion and possibly add this (or something similar?) to a future beta release?

I would appreciate to hear your thoughts on this.

Thanks again. I'm off to playing a few rounds of Hybris and Pinball Dreams!

[Toni Wilen]

What if WinUAE would do a vertical sync only on the first frame after the display buffer is activated, and then return the display back to the chipset_refreshrate timing.

It isn't that simple. You can't switch vsync on/off without partially re-creating DirectX screen setup which takes time.

I am sure these is another way but it may not be reliable.

btw, Display panel refresh rate decimal part can be edited in next beta.

[gary]

Dr Venom,

Its nice to see someone else that appreciates proper smooth scrolling without the associated stutter that often occurs because of the slight differences in timing, but I think that by using this method you're just prolonging the tearing problem and it will occur sooner or later with the tearing effect slowly moving up/down the screen. I tried a similar technique with WinVice (C64 emulator) by recompiling the source code with a very subtle speed adjustment and got almost all games working perfectly ... for about 10 or 20 minutes into a game

Even if you did have the first frame in sync with the vertical refresh, chances are that the value (eg: 49,912) is just not accurate enough after a long time. If you managed to keep it stable for 30 minutes then that is pretty impressive. Also, depending on host processor speed, you may find that this figure needs to be adjusted for each individual game.

I would like to see what could be achieved by having all components of the emulator adjusted according to the video refresh rate (I've seen this hacked into WinVice and the result was practically perfect. Smooth scrolling without sound / input problems. Unfortunately it was just a hack and the changes were not made into the source code therefore WinVice has the same problem as WinUAE: Only the video output can be in sync with the vertical refresh rate, not the rest of the emulator, so there will be problems - especially with sound).

In other words, always sync the video output to the screen but make sure that the chipset & CPU speed is adjusted (or in sync with vsync) to match the video. This would probably result in an Amiga emulator that runs at 0.001 mhz faster/slower than the real thing but the difference would barely be noticable with the result being much closer to a real Amiga.

Toni, is there a chance that WinUAE could have a "sync emulator to vertical refresh" option in the future?

[Mclane]

I don't know if this is related or not but yesterday I was watching one of my fave demo's, Technological death by the Mad Elks, when it got to the screen where it asks you to log in and it scrolls messages up the screen, the scrolling was horrible to look at, it seemed to look like there were bars across the screen that the text passed through and it altered it.

I don't remember this in previous beta's but without grabbing them all I have no way to pin it down to an exact issue.

This was seen on yesterdays beta 6.

I always boot to a standard quicklaunch unaltered config with the slight exception of scanlines added BUT I turned these off and the same result. I tried FS, vysnc etc but no joy.

I'm sure this didn't scroll like this before...

Any idea's ?

[Christian]

I'm really interested in all this. Things definitely feel "snappier" with no screen buffering. I'm sure these kind of issues are partly why people go on about the "feel" of using the real hardware. Combined with the almost zero lag sound possible nowadays, this is almost exactly how my real Amiga is plugged into the same screen.

On my LCD tv however, I can't find a refresh rate that is consistant. I get very close but normally the screen tear moves very slowly up at first and after a while starts to move down the screen (I get direction changes).

Ah well

[Retro-Nerd]

I've tested many games in WinUAE with "No buffering" on a real 50.00 Hz display with Vsync. It's indeed a bit more responsive/smoother, though i can't "feel" any difference in Vsync vs no Vsync.

[Dr.Venom]

Originally Posted by Toni_Wilen

It isn't that simple. You can't switch vsync on/off without partially re-creating DirectX screen setup which takes time.

I am sure these is another way but it may not be reliable.

This sounds hopeful at least . It would be really great if you could think of another way to achieve this.

btw, Display panel refresh rate decimal part can be edited in next beta.

That's cool. A suggestion is to additionally add two hotkeys to respectively raise and lower the value in the smallest possible increments.That way the calibration would become even more easy (or less difficult) and probably also more accurate, as people could do the adjusting in real time without "synchronization interruption" (i.e. by going into the menu/F12). As getting to the fifth digit is a bit of a chore to most people probably, making it easier to do it more accurate will be helpful. For the fifth digit accuracy that would mean bringing the rate a notch up or down through the hotkeys, go away for (another) cup of coffee and reiterate until the calibration has been done to the fullest... Easy, but it only takes time

Originally Posted by gary

Dr Venom,
[...] but I think that by using this method you're just prolonging the tearing problem and it will occur sooner or later with the tearing effect slowly moving up/down the screen. I tried a similar technique with WinVice (C64 emulator) by recompiling the source code with a very subtle speed adjustment and got almost all games working perfectly ... for about 10 or 20 minutes into a game

Even if you did have the first frame in sync with the vertical refresh, chances are that the value (eg: 49,912) is just not accurate enough after a long time. If you managed to keep it stable for 30 minutes then that is pretty impressive. Also, depending on host processor speed, you may find that this figure needs to be adjusted for each individual game.

Hi Gary,

A value of the refresh rate with only three decimals (like eg the 49,912) would indeed definately not be accurate enough. Only in the cases where the real target refresh rate would be 49,912000 it would be enough, but in reality the real monitor refresh rate will almost never be rounded to three decimals (the tool FreqTest will illustrate), not to forget that WinUAE also adds some deviation by synchronizing things to the sound buffer. That was one of the reasons I stressed it necessary to calibrate until at least 5 decimals. It's more of a question what's enough of an alignment for practical purposes. With a short calculation example I'll illustrate that (in theory at least) for practical purposes it can be accurate enough.

For every digit of mismatch in refresh rate one can calculate the time it takes for a line to tear across the screen. As an example suppose you have calibrated to a value of 50,09 (starting simple) while the real value to calibrate to should be 50,00. That would mean a mismatch of 0.09Hz. A small amount of mismatch some would say. Since every Amiga frame (~1/50 of a second) consist of 313 lines, a 0,09 frame per second mismatch would mean 0,09 x 313 = 28 lines (!) tearing up (or down) the screen per second, so within 10 seconds you would have seen tearing going from the one end of the screen to the other end. Very visible screen tearing!

Now your example with three digits. Suppose you've calibrated up until 49,912 while the real value to calibrate to is 49,9129. That would mean a mismatch of 0,0009Hz. An extreme small difference some would say. Well the same calculation example shows differently. A 0,0009 frame per second mismatch would mean 0,0009 x 313 = 0,28 lines per second shift. This would mean 0,28 x 60 = 17 lines per minute. So it would take less than 20 minutes for screen tearing to move from the one end of the visible screen (287 lines) to the other end. Or said differently, since the border+blanking area of an Amiga frame is 26 lines, screen tearing would be invisible for about 1 and a half minute (26/17)!

You probably understand why I stressed that calibration should be done at least to the fifth digit. The lowest to highest possible mismatch in the fifth digit would be 0,00001 to 0,00009Hz. In other words 0,00001 x 313 x 60 to 0,00009 x 313 x 60 equals 0,19 to 1,69 lines per minute. Given that the border+blanking area = 26 lines, it would take (26/1,69) to (26/0,19) = 15 minutes to at most 137 minutes before screen tearing shows its ugly head again. Suppose your calibration ended up anywhere in between than it would lead to approximately 1,25 hour before any screen tearing would occur. For all practical purposes that would already be fine!

Now suppose you would have gone through the process of calibrating up to the sixth digit, as WinUAE currently allows. That would mean a mismatch of either zero (if you're lucky), or a mismatch of 0,000001 to 0,000009Hz. A calculation as the one above shows that such a mismatch would lead to a range of 2,5 hours to 23 hours without any screen tearing. So for all practical purposes I would say that would be accurate enough.

To utilize this in full, maybe it's possible for Toni to come up with a method to reset the position of the tearing lines to the start of the border+blanking area. He at least indicated he might be able to come up with some sort of solution. That would lead to ZERO visible screen tearing for all practical purposes.

And maybe (just maybe) it would even be possible to 'reset' the position at regular intervals to accommodate for possible very slow drift in line tearing, such that we could enjoy the no-buffering mode with no visible screen tearing forever? Here's my vote for at least exploring these possibilities!

P.S. Offtopic: you might want to give Hoxs64 a go instead of WinVice.

Originally Posted by Christian

I'm really interested in all this. Things definitely feel "snappier" with no screen buffering. I'm sure these kind of issues are partly why people go on about the "feel" of using the real hardware. Combined with the almost zero lag sound possible nowadays, this is almost exactly how my real Amiga is plugged into the same screen.

On my LCD tv however, I can't find a refresh rate that is consistant. I get very close but normally the screen tear moves very slowly up at first and after a while starts to move down the screen (I get direction changes).

Ah well

Christian,

Some suggestions. In the current beta the position of the line tearing shifts a number of lines after pressing F12/going into the settings menu and then back to the Amiga screen. Maybe this is what you're experiencing? So it first shifts a number of lines after keying in a new refresh rate and then moves down again? My suggestion would be to wait a little after coming back from the settings screen before drawing conclusions about the tear moving up or down. If after waiting a bit the tear moves down, then you should raise the refreshrate value.

In case you're experiencing constant wide direction changes in the tearing, then you might want to take a look again at step 3 from the short 'how to', i.e. getting to a stable sound buffer usage... As also said in the guide, if you're willing to, do experiment with some of the other settings in WinUAE as they all have impact on the calibration. For me for example, changing to high priority settings and using directdraw made for a more stable result.

[andreas]

Originally Posted by gary

Toni, is there a chance that WinUAE could have a "sync emulator to vertical refresh" option in the future?

Interesting feature request, Gary!
Particularly interesting because this option HAS existed for ages in "competitor" Fellow (DOS). Check in case of doubt.

(Couldn't find that option in WinFellow, though.)

[Christian]

Really?? That's very interesting. I've not used Fellow in ages since PCs got fast enough for UAE. It was awesome in its day though... (DOS)

@Dr.Venom. Cheers for the advice. I'll be looking into that

Edit: Btw, I have my sound (X-Fi) set to use buffer 1, WASAPI, Emulation enabled, 48000 frequency, auto switching off and exclusive mode on. The sound on-screen display pretty much displays 0 all the time, although it does flicker but I can't see what value it changes to.

The screen tear goes mental a bit after exiting the config interface. It then settles down in a position and was very gradually moving one way, then the other. I'm not sure why and need to experiment more. Probably not got the right value yet. TBH I was hanging on a bit to see if Toni came up with something

[Toni Wilen]

I don't think we are not talking about normal vsync.. Please, no assumptions or guesses here.

[Toni Wilen]

Some random stuff..

Problem: there is 2 different rates to sync to and both can drift slowly (or may not be be exactly divisible by reference rate)

Reference rate:
PerformanceCounter

Output rates (known only approximately):
Sound frequency
Video refresh

"Only" problem is to find 2 PerformanceCounter dividers that exactly match with both output rates. I don't think it is possible to have 100% drift free dividers.

Automatic detection is practically impossible because you can't "read" exact display refresh rate "position" or sound buffer position. (there is always some jitter, close enough average is perhaps possible)

Perhaps some kind of "calibration" screen is needed but I am not sure if it is worth the trouble..

[gary]

Toni,

When an Amiga game waits for VBlank, how does WinUAE signal it under emulation? I'm guessing that it uses a calculated value instead of the real (PC monitor) VBlank as it would be too fast in most cases (60hz +)?

If so, would an option to use real VBlank timing for the emulated software help in the case of software that uses that technique for timing?

[Toni Wilen]

Originally Posted by gary

When an Amiga game waits for VBlank, how does WinUAE signal it under emulation? I'm guessing that it uses a calculated value instead of the real (PC monitor) VBlank as it would be too fast in most cases (60hz +)?

If so, would an option to use real VBlank timing for the emulated software help in the case of software that uses that technique for timing?

I don't understand. How does this help when emulator already knows when it trigger vblank interrupt? It does not need to detect any software behavior to know it

Also check earlier posts. Emulated vblank is separate from real vblank. Run one frame of emulated hardware in quick burst, show the frame, wait until enough time has passed, which must also match selected sound output rate, and so on.

If any rate isn't exactly matching during "wait until" part, there will be slow drift and sooner or later things get out of sync. Something needs to fix the drift before it gets too bad and that is not trivial without causing other side-effects.

Sound "out of sync" is the most "visible" problem.

Sound buffer slowly emptying: sound glitch, resync and buffer is again refilled. Sound buffer slowly filling: sound latency increases as buffer fills until emulation starts waiting until sound buffer has free space = video sync gets lost, everything else appears to be fine.

[Dr.Venom]

Problem: there is 2 different rates to sync to and both can drift slowly (or may not be be exactly divisible by reference rate)

Some additional random thoughts from my side also. Maybe some pieces to the puzzle... and some stuff for me to understand things properly.

Basicly what we want to do is synchronize the emulated display with the real display in no-buffering mode, with no audio problems. Since to my mind video stutter is more noticeable then very slight audio pitch changes (or even very slight crackle), I would prefer having the video 'synced' and having the audio follow in lockstep in the best possible way.

Assuming base case of an emulated Amiga 500 running a game in ~49,92Hz. Assume our real world monitor has a refresh of 50,01. This causes quite a big mismatch in refresh rates, which leads to quite visible screen tearing. The (theoretical) solution is: speed up the display of the emulated A500 by a factor 50,01/49,92=1,001803. This is basicly what the chipset_refreshrate variable does: it sets the emulated refresh to 50,01hz.

Making the audio follow in lockstep. I don't know the exact rate at which the audio of real Amiga hardware (and the emulated A500) runs, but lets assume 29Khz or 29000Hz. To keep audio in sync with the video, the audio should get the exact same speed boost. So the emulated Amiga 500 should not play the sound stream at 29000hz, but at 29000*1,001803=29052Hz. At this higher rate the audio will run in sync with video. At least that's my hypothesis, please say so if I'm wrong. To make the picture complete, because we have to deal with soundcards that play (for example) at a rate of 48Khz, the upsampling factor for playing at 48Khz should not be 48/29=1,6552, but should be 48000/29052=1,6522.

All well then wouldn't it? Ehmm, unfortunately not. As the tool Freqtest shows, soundcards aren't completely accurate at delivering the requested refresh rate. For example my soundcard when requested to play a sound at 48000hz, it on average delivers 47998hz, but it also fluctuates by a minimum of 47950hz and and a maximum 48046hz. To compensate for this (on average), the emulator would also need to change the input frequency (now of 29052hz) again by a factor of 'requested rate'/'real rate'. In this case that would be a factor of 48000/47,998=1,000042 * 29052 = 29053hz. Taking the minimum case the factor would be 48000/47950=1,001043. Input rate would then come out at 29082hz.

An important conclusion, to me at least, is that the deviation in requested versus real audio rate, will cause drift of the audio that the emulator will not be aware of. As it's thinking it's getting exact audio rate/timing of 48000hz, but in reality it's getting something close. Most probably the best way to account for that would be to implement a user configurable slider, which enables the user to very slightly adjust the input frequency to mitigate any noticeable audio problems/crackle, because of the drift for example.

So in theory the sound frequency should be set as:

amiga audio rate * [real video refresh/amiga video refresh] * [requested audio rate/real audio rate]

Now ultimately we would be able to set both the chipset_refreshrate (accounting for difference between amiga video refresh and real refresh) AND we would be able to set the 'amiga' audio_inputrate manually, to account for the audio drift that the emulator will not be aware of. I would at least be in favor of a WinUAE beta, where we could experiment with setting both variables.

Now the above would lead to practically zero screen tearing, but I appreciate your point about the dividers possibly not being accurate enough to make them 'drift free'. For me it's more of a question of whether it's fully usable for practical purposes. Thus if running WinUAE for two hours continuously without any noticable 'drift' that would be perfect for 99% of the users I think and a very valuable option as such.

Automatic detection is practically impossible because you can't "read" exact display refresh rate "position" or sound buffer position. (there is always some jitter, close enough average is perhaps possible)

Some additional thoughts. Would it be possible to create a seperate thread that only does polling of the refresh rate and vblank timing? That way this seperate thread could update the main emulation thread regularly of the actual display frame time to use (performancecounter interval) and, given that it can also predict when the vblank comes up, that is also signals the main thread to start displaying the frame at the right time. That would lead to zero visible screen tearing and additionally it would mitigate the need for any manual refresh calibration. Given that you would dynamically know the real monitor refresh rate, it's possible to adjust the audio rate with the same (dynamically adjusted) multiplier, thus keeping video and audio in lockstep.

A manual amiga audio input frequency slider would probably still be very welcome, as it would help in coping with the problem of any drift caused by the real audio rate being different from the requested rate.

Lastly, another thought of a possible remedy came to mind which relates to the traditional vsync. In my experience traditional vsync somehow is problematic in that it seems to lead to noticeably more input lag versus the non-vsynced no-buffering mode. Now, I read on the bsnes forum that the author implemented a manual vsync loop and doesn't use any Wait() instructions, because in his experience even putting in a wait of 1ms sometimes ended up in Windows waiting for 20ms or more, which caused missed vblanks and other unfortunate things to happen. If I remember correctly, internally the WinUAE emulation runs in bursts, and after emulating a frame it waits until "real world" worth of frame time has passed. Does this also account for 'waiting' for vsync in vsync display mode? If so, would it be an idea to test a version without any wait instruction, but active polling for vblank right after the emulation burst?

Perhaps some kind of "calibration" screen is needed but I am not sure if it is worth the trouble..

I'm very much in favor of exploring this (broad) topic further. To my mind, getting the no-buffering mode to work with no screen tearing and robust enough for practical usage, would be a great enhancement and a true joy to use as it so closely mimicks the real thing...

[Dr.Venom]

Hi Toni, I was wondering if you had any new ideas/insights into this topic?

[Toni Wilen]

I thought I replied about a week ago..

Anyway, the most important part was: I'll think about it and experiment with no-buffer vsync after 2.3.2 is out. Of course _If_ D3D vertical refresh position reporting actually works as documented.. (Driver weirdness is always possible when it is about features that are not used by normal applications or games)

[SailorSat]

You can ask a Direct3D Device if it currently is in VBLank via the D3DRASTER_STATUS

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

[Toni Wilen]

Originally Posted by SailorSat

You can ask a Direct3D Device if it currently is in VBLank via the D3DRASTER_STATUS

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

I know. The point was: does it work as documented? Does it return real hardware vblank, not some simulated vblank? Is it accurate? Is it implemented in real world drivers?

[Jgames]

Originally Posted by Toni Wilen

I know. The point was: does it work as documented? Does it return real hardware vblank, not some simulated vblank? Is it accurate? Is it implemented in real world drivers?

If it returns a real hardware vblank, do you think it will be precise enough for a multitasking system like windows, where other application and disk accesses can be disruptive?

[Toni Wilen]

Originally Posted by Jgames

If it returns a real hardware vblank, do you think it will be precise enough for a multitasking system like windows, where other application and disk accesses can be disruptive?

If your hardware and drivers don't suck. I don't support PCs that suck.