Moderator: ZSNES Mods
Um, that's exactly what I've been saying the problem is. ZSNES does NOT automatically switch to 60Hz fullscreen when playing an NTSC ROM. It just uses whatever the monitor refresh rate was set to for your Windows desktop. Odds are that's a slightly higher refresh rate than 60 Hz, such as 70Hz, 75Hz, or 85Hz. The mismatch between the game's 30fps and the display's refresh rate means it's impossible for ZSNES to deliver a smooth frame rate, because some subset of frames must be skipped.Squall_Leonhart wrote:Stuttering can be caused elsewhere..... for example if the internal FPS(snes gfx core) doesn't match the External(video output) and the emulator has to use Frame skipping
c0d3h4x0r wrote:Actually, that's EXACTLY what you said:Squall_Leonhart wrote:btw, i never said it automatically switches to 60Hz, learn to read.
Squall_Leonhart wrote:When the menu is open it runs at 85FPS, when a Game is open it dials back to 60 or 50Fps respective of the rom region
Hz and Fps mean the same thing. You're being very immature.Squall_Leonhart wrote:c0d3h4x0r wrote:Actually, that's EXACTLY what you said:Squall_Leonhart wrote:btw, i never said it automatically switches to 60Hz, learn to read.
Squall_Leonhart wrote:When the menu is open it runs at 85FPS, when a Game is open it dials back to 60 or 50Fps respective of the rom region
LEARN TO READ here, i bolded the difference for you.
...People, we are dealin with a moron here.
Nothing to see here, move along, Taking screenshots for /B/ lolz is permitted.
Thank you. It would have saved a lot of hassle if the first reply to my original post had simply said as much.odditude wrote:c0d3h4x0r, yes, it would be nice if the option was in the gui, but it's not. deal with it until the next version comes out; i have a feeling nach/grin/dl2 wouldn't object to it being on the plate for a gui addition.
read the entire thread, and stfu.odditude wrote:jesus christ, you two are acting like preschoolers. do i need to turn this car around and go home?
squall, reread your last few posts - you're becoming the pot calling the kettle black. also, if your refresh rate isn't an integral multiple of your frame rate, there will be duplicated frames - you're just not noticing it for whatever reason, be it your eyes or monitor's response.
c0d3h4x0r, yes, it would be nice if the option was in the gui, but it's not. deal with it until the next version comes out
Stop feeling, you'll turn the devs gay or something.i have a feeling nach/grin/dl2 wouldn't object to it being on the plate for a gui addition.
Triple buffering attempts to provide a speed improvement over double buffering. In real life applications, this often involves trying to abstract the graphics drawing operations from being synchronized with the monitor's refresh rate. Typically this involves frames being drawn at a rate lower than or higher than the monitor's frame rate (a variable frame rate) without the usual effects this would cause (namely flickering, shearing and tearing).
Due to the software algorithm not having to poll the graphics hardware for monitor refresh events, the algorithm is free to run as fast as possible. This is not the only method of triple buffering available, but is the most prevalent on the PC architecture where the speed of the target machine is highly variable.
Another method of triple buffering involves synchronizing with the monitor frame rate, and simply using the third buffer as a method of providing breathing room for changing demands in the amount of graphics drawn. This is the use of a buffer in the true sense whereby the buffer acts as a reservoir. Such a method requires a higher minimum specification of the target hardware but provides a consistent (vs. variable) frame rate. This is the case when using triple buffering in DirectX, where a chain of 3 buffers are rendered and always displayed.
Actually, it's worse/better than that. A lot of bleeding-edge high-res laptops (including mine, 1920x1200 ThinkPad T61p) actually have the EDID on the LCD screen report back as low as a 40 Hz native video mode. A lot of digitally-driven LCD screens no longer have any limitations at all on vertical refresh rate as long as:creaothceann wrote:LCDs/TFTs will have a hard time with PAL games, unless they can go down to 50 Hz.
Why the fuck are you using a non public and leaked Windows build? There goes your testing validity out the window when people can't reproduce your issue.the same laptop when dual-booted into a Windows 7 build
And that just reminded me of a known bug that occurs on Windows Vista, so probably occurs on 7 as well.Verdauga Greeneyes wrote:And just because no one has clarified this yet: tearing occurs when a new frame is presented while the monitor is drawing and the new frame is visibly different from the old one in the region that the electron beam (or the equivalent electronics in the case of LCD) is scanning. This can happen at any frame rate, but if multiple frames are presented during each scan it'll obviously be a lot more visible.
Next, VSync is an annoying problem because while monitors are supposedly capable (according to MSDN documentation) of sending a VBlank IRQ, for some reason these are not handled in any meaningful way and generally the only way to find out when a VBlank occurs is to use polling. On a single core system this means using 100% CPU and potentially spending valuable time waiting around. Using sleep or wait functions is somewhat problematic as user mode timing resolution is usually 10ms. You can lower this to 1ms (at least on Windows - probably on other OSes) although you still have to be careful - VBlank only takes maybe 0.5ms so it's easy to miss.
