Is there an emulator that can do fullscreen without tearing?

[Zepper]

RockNES has support for video triple buffering.

[Luke]

I see periodic "stuttering" in Nestopia (and some other emulators). It's not quite a Vsync issue from what I can tell, and it's very very hard to describe. It's fucking annoying and is one of the literal hundreds of reasons why I stick with XP.

I ran into a similar problem with my emulator and screensaver: it seemed like Windows 7 was automatically dropping video frames; games would play back at the proper speed, sound was fine, for all intents and purposes the game was running full speed but the video was definitely not showing 60 FPS.

To solve this problem, I implemented a Direct2D renderer - previously I only supported GDI and DirectDraw, both of which exhibited this frame dropping problem under Win7. Somehow, someway, Direct2D works a lot better - I guess the driver code utilized by Direct2D (for my GPU) must somehow be different/better then whatever was running underneath DirectDraw + GDI.

I was able to do this in a way that does not force any hard dependencies on the emulator binary and DirectX, meaning the emulator can run fine on XP with an ancient version of DirectX; Direct2D is just not available in that case. If anyone is interested in knowing more I'll elaborate.

[kuja killer]

I myself also experience exactly koitsu and luke said. And i hate it to pure death
precisly 100% what luke said, no problems, no slowdown, nothing at all like that. JUST stutter

My best friend recently wanted me to try out a top of the line gaming PC he built, to replace this old outdated laptop im currently using.

It has Win 7, ATI Radeon 7970 Graphics Card (i think that's the lastest model released currently right now by AMD ??), im not sure what the CPU is, but AMD Phoenon 6-core something something. sorry i dont know exactly what it was called.

And when i go to test all my emulators and games. I notice this incredibly annoying as hell "micro stutter" happen in every single little thing i ever try.
NES emu's, snes, genesis, gameboy..
PC games like Rosenkreustillete, Megamari... just about anything.

It made me so mad cause it's impossible for me to really "enjoy" playing anything.

But on this really old outdated laptop im using. -
Win XP, Intel Core 2 Duo CPU, a dumb "integrated" video card. not dedicated

Everything performs so much "better" on here, stuff just "screen tears" until using vblank in programs/emu's. It's much more comfortable than that ridiculous micro-stuttering on the new comp.
I dont understand why the better comp performs so much worse compared to this laptop in my opinion.
I dont even use that comp because that stutter is so headache-inducing to me.
And then i read a wikipedia article that states, radeon 7970 supposedly is the MOST affected graphics card to date with the problem... dahhh

I just want a PC that doesn't do either stuttering or screen tearing period ever. It matters to me alot, just to be completely honest.

[snarfblam]

I just want a PC that doesn't do either stuttering or screen tearing period ever. It matters to me alot, just to be completely honest.

You would think it would matter to hardware/OS companies. Gaming is a big part of computing, and this stuff bugs a lot of people. I know it bugs me. Especially since these problems were ironed out in the DOS days. Why should it be so difficult now? VSync should be an easily accessible feature in any OS/software environment that might be used to make a game, and it shouldn't cause unnecessary stutter.

[Sik]

DOS wasn't multitasking. You could get away with just polling the vblank flag (VGA got rid of the vblank interrupt) and you would still be guaranteed that the moment it went from 0 to 1 vblank had just started.

Even then I find it weird, because I'm pretty sure vblank should work... Stuttering comes from the fact programs don't get a vblank-based timer anymore (and if you're doing fixed framerate, there isn't much use for it since the refresh rate can be anything), the closest you can get is the rendering thread stalling when it swaps the buffers with vsync on... and only when it never misses a vblank period.

Also reminds me, vsync doesn't work on multimonitor systems at all, because the OS insists on treating them like a single huge monitor, and the monitors aren't in sync (they may not even have the same refresh rate!). Kind of stupid, it'd make more sense to treat each monitor as a completely separate display... I guess we're stuck with this because when multimonitor support was added in Windows the concept of multiple workspaces was uncommon (also probably because programs were never made for multiple displays and there could have been something misbehaving horribly - remember Windows' backwards compatibility history).

[rainwarrior]

Why should it be so difficult now? VSync should be an easily accessible feature in any OS/software environment that might be used to make a game, and it shouldn't cause unnecessary stutter.

On every platform I've ever developed for, modern or old, vsync has never been difficult at all for fullscreen applications.

Windowed applications are the opposite-- there is still no consistent solution for Windows. I am not certain if the situation is equally hopeless on other platforms (I've had conflicting reports-- also some people claim to be able to do it in Windows, but I have yet to see such an implementation that works for more than that one person).

As for getting rid of stutter, aside from generic issues like synchronizing audio and video, on Windows it is important to set your game's thread priority higher than default if you want it to run smoothly without stutter. If you fail to do this, it will be in competition with other running programs, because the OS is never given the hint that this game should be running more smoothly than the rest of the things you have running.

There is a corollary that it is also important to lower the thread priority when it is not needed (e.g. game minimized or paused) or at least have very low CPU usage during these times so that the user can get back their CPU when they want to run other programs temporarily.

[Sik]

Windowed applications are the opposite-- there is still no consistent solution for Windows. I am not certain if the situation is equally hopeless on other platforms (I've had conflicting reports-- also some people claim to be able to do it in Windows, but I have yet to see such an implementation that works for more than that one person).

I think this completely depends on the driver. If you're stuck with only copy on present (as opposed to swap on present), forget it.

[rainwarrior]

It probably could be solved at the driver level, but that's completely outside the game programmer's control. Nobody wants to distribute thousands of hacked drivers with their game, and who would trust them enough to install them over the ones made by the manufacturer?

That said, on the driver side, I doubt it's as simple as swap vs copy when you're dealing with a windowed environment (and a copy can be vsynced just fine by the hardware if done properly). There's a lot of ways to skin that cat.

[Sik]

(and a copy can be vsynced just fine by the hardware if done properly)

The problem is how much you can copy, especially being a standard blit instead of something that'd go through the usual rasterizer, and especially considering other programs may want to do exactly the same (I guess this is also why Direct2D fares better in this sense, it only uses the rasterizer, for pretty much everything).

[WedNESday]

WedNESday (hopefully to be released later this year) can do fullscreen AND windowed with no tearing.

[koitsu]

That said, on the driver side, I doubt it's as simple as swap vs copy when you're dealing with a windowed environment (and a copy can be vsynced just fine by the hardware if done properly). There's a lot of ways to skin that cat.

I see different methodologies/implementations in every emulator, and use different settings in every emulator, to try and minimise (or completely subvert) tearing in windowed mode. Because I don't like being ambiguous, I'll give details. Again (because all of this data matters), I'm using Windows XP with an nVidia GTX 760 card, driver set 335.23, stock settings. CPU is an Intel i7-2600K.

Data point: Nestopia is the one emulator which rarely stutters or tears (maybe 1-2% of the time), so for playing actual games, it's what I use. And since I run in windowed mode, I tend to focus on 2x (linear) scaling because it adds to the "pixel" look and makes it easier on the eyes. I hate scalines and post-effect crap. Anyway, this is what I use:

Code: Select all

* Nestopia unofficial
  - Options / Video
    - Monitor Frequency "Auto": checked (never been sure if this applied to full-screen or windowed or both)
  - Options / Timing
    - VSync: checked
    - Use high-precision timer: checked
    - Enable triple buffering: unchecked
  - View
    - Screen Size: 2x

* VirtuaNES
  - Option / Emulator
    - Auto frame skip: checked
    - Throttle use: checked, set to 600 fps (not a typo)
  - Option / Graphics
    - Double size rendering: checked (this allows for linear 2x resizing, but without this checked, stuttering happens)
    - SystemMemory surface: unchecked
    - Sync drawing(Window): unchecked
    - use HEL: checked
    - Using Sleep: unchecked (but if you wanna save 1-2% CPU, check this)
  - Option
    - Zoom: 2x
  - See footnotes.

* FCEUX (2.2.3-interim svn3071)
  - Config / Video
    - Windowed Settings
      - Size Multiplier: 2.0 for X, 2.0 for Y
      - Force integral scaling factors: checked
      - Sync method: Lazy wait for VBlank
      - DirectDraw: No hardware acceleration
  - See footnotes.

* Nintendulator
  - See footnotes.

Footnotes:

- VirtuaNES: I know -- the options I choose seem confusing, and there's a crapload of combinations of course.
  The combination of the two settings above seem important; if one is set without the other, stuttering will
  occur for me.
- VirtuaNES: toggling any of the graphics options seems to cause the emulator to "lose its shit" briefly, re:
  timing synchronisation, so you may need to play for 5-6 seconds to see if things settle down after.

- FCEUX: I've never gotten this thing to do windowed sync correctly.  There is always some form of intermittent
  tearing no matter what combination of options I use (including "Wait for VBlank" instead of "lazy wait").  I
  mainly use FCEUX for debugging/RE'ing, but for me I use it like a combo of Nestopia and Nintendulator.
- FCEUX: Tearing actually goes away if I set DirectDraw: Create Surface in RAM, however for whatever reason
  that starts causing audio-related problems (difficult to explain, sounds like clicks or buffer/timing problems).
  Adjusting audio-related settings doesn't relieve the problem.  Also, in this mode occasionally the emulator will
  randomly drop to like 30-40fps (with audio stuttering crazily) for 4-5 full seconds then fix itself.
- FCEUX: Oddly enough, if I set DirectDraw: Hardware acceleration, the audio-related problems I mentioned
  above happen, tearing + slowdown issue happens, *and* (as expected) I get bilinear filtering/blurry results.
- FCEUX: So I hope this explains why I pick the options I do.  Oh, and don't go blaming my audio card (Audigy SE)
  because the same problem happened with an on-board Realtek ALC887.  My gut feeling is that there's just some
  major desync between the video and audio layers when certain options are checked so someone should probably
  revamp that code.  Issue is 100% reproducible.

- Nintendulator: I mention it because it's an emulator I use but not for playing games -- I use it solely for
  debugging/RE'ing thus tearing/sync aren't a focus.  Quietust <3

There you go. I'd really recommend someone look into what VirtuaNES is doing with those two options checked...

[rainwarrior]

I don't think it's even worth trying to get a vsync in windowed mode (there are lots of solutions that appear to work under the right conditions on a specific machine, but it really can't be done in a consistent/robust manner- there just has never been an API for it), but I'm certainly disappointed by emulators which fail to provide vsync in fullscreen mode. Every emulator should be able to do that; the ones that can't are simply doing it wrong, except in the case where the user's hardware settings have globally disabled vsync. It's a bit sad that you have to try so many permutations to get it working in a lot of emulators, but at least it can be done eventually most of the time.

I also get awful audio stuttering in FCEUX unless vsync is disabled. I use FCEUX for debugging/testing and making videos though, not for playing, so it's not a significant issue for me (maybe one of us should submit a bug report, though). Also, it seems like the audio buffer settings apply unless you restart, so that might explain why they seem to do nothing sometimes.

I've always found Nestopia to be the nicest one for just playing games. It always just worked properly for me in terms of setup/vsync/options. Lately I've become a fan of puNES as well, though it's in a less complete state.

[WedNESday]

I don't think it's even worth trying to get a vsync in windowed mode (there are lots of solutions that appear to work under the right conditions on a specific machine, but it really can't be done in a consistent/robust manner- there just has never been an API for it), but I'm certainly disappointed by emulators which fail to provide vsync in fullscreen mode. Every emulator should be able to do that; the ones that can't are simply doing it wrong, except in the case where the user's hardware settings have globally disabled vsync. It's a bit sad that you have to try so many permutations to get it working in a lot of emulators, but at least it can be done eventually most of the time.

I also get awful audio stuttering in FCEUX unless vsync is disabled. I use FCEUX for debugging/testing and making videos though, not for playing, so it's not a significant issue for me (maybe one of us should submit a bug report, though). Also, it seems like the audio buffer settings apply unless you restart, so that might explain why they seem to do nothing sometimes.

I've always found Nestopia to be the nicest one for just playing games. It always just worked properly for me in terms of setup/vsync/options. Lately I've become a fan of puNES as well, though it's in a less complete state.

Seeing as windowed VSYNC is nothing more than a short piece of code its definitely worth trying. Is using Present not consistent across machines?

I couldn't agree more with emulators that don't provide fullscreen VSYNC seeing as that is guaranteed.

[koitsu]

BTW, I forgot of another emulator that seems to get windowed vsync correct (on XP) -- Fusion. No "special settings", just enable "Vsync" in the Video pulldown and that's it. Though that emulator does take up 15% CPU of my i7-2600K (pretty much one core maxed out at all times, even with Sleep-while-waiting enabled), still...

The README had this to say about it:

Code: Select all

Please note that VSync in Windowed mode may be quite slow. This is because
the only way to do VSync in windowed mode is to physically sit there and
wait until the VSync happens. Obviously that can be a huge waste of CPU
time, especially if, at the point you start waiting, you've only just
missed the last VSync...

[rainwarrior]

Yes, a wait loop should max out one core, by design.

That's one of many problems of trying to do windowed vsync that way:
1. wasting CPU polling the vsync
2. various factors may contribute to a fixed delay between vsync and your actual video update (causes a consistent tear)
3. windows may interrupt your program at a critical time anyway (causing an occasional tear)
4. the timing of your window's actual video update can be buffered/rescheduled by the operating system (making the vsync irrelevant)
5. vsync may not actually correspond to a real hardware state (in some cases it is just a dummy timer)
6. vsync may not signal at all, causing program to fail (rare)

All that said, sometimes you are getting a real vsync signal, and the conditions for timing are right, and you get a tear-free window. It's generally a matter of luck. Issue 1 you just have to live with if you want to use this method (and a good reason to make it optional). Issue 2 can be mitigated with a user configurable timer of some sort that inserts a delay between vsync and the video update, but this tends to be really fiddly. 3 is usually infrequent, occasionally very frequent. 4 and 5 are conditions that will make the effort entirely useless on that system. 6 is another reason it needs to be an option.

Actually, sometimes under lucky conditions the standard DirectX/OpenGL/Windows APIs for double buffering will appear to work in a window, and you'll get no tearing without the wasted CPU cycles. This is not guaranteed or even specified behaviour, but in some situations it does produce a consistent/stable timing with a tear-free result.


I've never liked the vsync poll method, because it's an out-of-spec solution that fails to work in a lot of cases (and the CPU load is a significant problem in itself). It's possible though that the hardware/driver situation is better than it used to be and maybe it works on more systems now? My own experience is certainly not a comprehensive survey.