bsnes v0.039 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
FirebrandX
Trooper
Posts: 376
Joined: Tue Apr 19, 2005 11:08 pm
Location: DFW area, TX USA
Contact:

Post by FirebrandX »

Panzer88 wrote:Wow that's great, thanks a lot, FirebrandX
No problem. I should clarify though, that you can do virtical as well on LCDs, but if you use scanlines like I do, They lose their effect and just become messy. So whenever I do custom resolutions for emulators on my LCD, I always make sure to use the native virtical res and only customize the horizontal.

Also, I don't try to correct the Genesis/Megadrive main resolution mode of 320x224 because its already close enough to square that it doesn't bother me. For Nestopia however, using 1440x1050 perfectly pulls the display into a 4:3 aspect on my 1680x1050 LCD. Same with bsnes since they both are playing games at 256x224. The difference is Nestopia allows you to select the mode from it's polling of the video card, while bsnes does not since it uses a maxed window. You end up having to set your desktop to the custom res before running bsnes. I suppose that's one thing Nestopia has over bsnes is a better fullscreen system. But then again, nestopia doesn't run snes games ;-)
byuu

Post by byuu »

Neat, found this in my referral logs:
http://code.google.com/p/bsnesnetplay/

A major license violation, but I honestly don't mind. I think it's pretty cool actually.

Nach / JMA or the authors of the GPL'ed socket library they're using might mind, though. And no e-mail, would like to warn them that the ui/hiro port they're working off of is now deprecated for Qt. It'll be gone after v041 or so.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Wouldn't it just be easier to come here and ask? On a scale of 1 to 10, how difficult is it to make a custom netplay client? I notice a lot of emulators just use kaillera middleware, never used it myself, but haven't heard great things about it.

By the way, the next version allows you to reconsider something that could save us all a lot of typing:

This future:

0.040 (official release)
0.040.01 (wip)
0.040.02 (wip)
0.040a (official release)
0.040.03 (wip)
0.040.04 (wip)
0.040.05 (wip)
0.040.06 (wip)
0.041 (official release)
...

vs this future:

0.04 (official release)
0.04a (wip)
0.04b (wip)(official release)
0.04c (wip)
0.04d (wip)
0.04e (wip)
0.04f (wip)
0.05 (official release)
...

Besides taking up less characters, the other good thing about scheme #2 is emergency update naming makes more sense when it happens. It's just a wip version made public, so why differentiate their naming?
wertigon
Rookie
Posts: 46
Joined: Sat Aug 07, 2004 7:20 pm

Post by wertigon »

That second scheme is kinda good except for one thing, I do believe v 0.04 was released years and years ago. ;)
byuu wrote:Neat, found this in my referral logs:
http://code.google.com/p/bsnesnetplay/

A major license violation, but I honestly don't mind. I think it's pretty cool actually.

Nach / JMA or the authors of the GPL'ed socket library they're using might mind, though. And no e-mail, would like to warn them that the ui/hiro port they're working off of is now deprecated for Qt. It'll be gone after v041 or so.
You might even want to tell them that Netplay is a wanted feature and that they're welcome to collaborate with you. Also, a separate fork for Netplay might be a good idea for now - it'll take time to develop i properly, so...
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

wertigon wrote:That second scheme is kinda good except for one thing, I do believe v 0.04 was released years and years ago. ;)
You're thinking of 0.004.
wertigon
Rookie
Posts: 46
Joined: Sat Aug 07, 2004 7:20 pm

Post by wertigon »

FitzRoy wrote:You're thinking of 0.004.
Depends on how one view the version numbers, I suppose, but for me, a version number isn't a decimal number, it's a series of numbers. Usually (major . minor . point), though bsnes do away with the point releases alltogether. So, any prefixed zero is simply there for clarification and little more. Therefore 0.4, 0.04 and 0.004 are all the same thing for me...

I still think Ubuntu ultimately got that right though; Version number is (year released) . (month released). So the first Ubuntu was 4.10 and was released October, 2004. The next one, 5.04, was released April the year after. 5.10 was released October 2005, and so on. This means that one can easily know how old any given Ubuntu release is, though I suppose in a fast-moving project like bsnes where releases occur on average once a month (atleast it does now) and sometimes even twice a month, that model is a bit *too* coarse...

And finally, while on the topic of version numbers, here is some useless trivia; Emacs is the application to have skipped the most version numbers ever. It went from v1.13 to v14. :)
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

It might cause new users to think this is only the fourth release instead of the 40th.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
_willow_
Hazed
Posts: 51
Joined: Mon Dec 24, 2007 2:03 am
Location: Russia
Contact:

Post by _willow_ »

Looks like it is the right moment to ask about video mode scales.

Is it any real needs in scales for fullscreen? Is'nt the fullscreen are virtually always supposed to fill up the entire screen space except menu\debug\out-of-ratio bars?
[url=http://quake2xp.quakedev.com]quake2xp[/url] audio engineer
h4tred

Post by h4tred »

A major license violation, but I honestly don't mind. I think it's pretty cool actually.
Not to flame, but whats the deal?

So basically, if a end user wants to make some code, they have to send it all through you, get it ripped to shreds by you (so it fits your "clean code" standards), and only then it has the potential of being accepted? Seriously, people could just redist the code patches, not the binaries. Or is that non allowed to?

Reason is: I want also to do something, but I can't because of damn licensing. And frankly, the only way I could do it is by making my own SNES emu since:

* ZSNES 2.0 is still in devel
* Snes9X is iffy at best for what I want to do.
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

Kaillera is outdated right? I don't even uses that anymore.
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
h4tred

Post by h4tred »

Yes Kaillera is outdated and a hunk of crap.
FirebrandX
Trooper
Posts: 376
Joined: Tue Apr 19, 2005 11:08 pm
Location: DFW area, TX USA
Contact:

Post by FirebrandX »

_willow_ wrote:Looks like it is the right moment to ask about video mode scales.

Is it any real needs in scales for fullscreen? Is'nt the fullscreen are virtually always supposed to fill up the entire screen space except menu\debug\out-of-ratio bars?
Some people might want to play in doublescale on fullscreen or perhaps some other scale besides max. There are plenty of reasons to leave them in, while there is only one reason to leave them out.
byuu

Post by byuu »

h4tred wrote:So basically, if a end user wants to make some code, they have to send it all through you, get it ripped to shreds by you (so it fits your "clean code" standards), and only then it has the potential of being accepted?
If they want the code in my project, then yes I will choose how I want it incorporated. If they want to make their own project fork and want it to be legal, then they have to ask me first, yes.
Seriously, people could just redist the code patches, not the binaries. Or is that non allowed to?
Not allowed without approval.
Reason is: I want also to do something, but I can't because of damn licensing.
You could always violate it like everyone else :P
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

wertigon wrote:Depends on how one view the version numbers, I suppose, but for me, a version number isn't a decimal number, it's a series of numbers. Usually (major . minor . point), though bsnes do away with the point releases alltogether. So, any prefixed zero is simply there for clarification and little more. Therefore 0.4, 0.04 and 0.004 are all the same thing for me...
You're confusing me. 0.04 is the same thing as 0.040. One is showing thousandths, the other isn't. It's mathematically compatible with old versions to drop it. Yet another reason decimal systems suck, people can't even understand this. They never get followed, either. For some reason, people like trying to proportion progress and make integer jumps rare and radiant events to usher in big new changes.

YYYYMMDD is a good system for marking progress in private. Then I like revisions by integer for public, because it guarantees the least amount of characters: r0 (first public release), r1, r2, r3... r278...
h4tred

Post by h4tred »

If they want the code in my project, then yes I will choose how I want it incorporated. If they want to make their own project fork and want it to be legal, then they have to ask me first, yes.
Fair enough. :) I can agree with that.
Not allowed without approval.
Darn. Oh well, guess I could keep whatever I concoct to myself. :P
You could always violate it like everyone else :P
Dude, I am not that cruel :P
byuu

Post by byuu »

New WIP, looking for feedback on these changes.

First, I switched from a standard QWidget to a more semantically-correct QMainWindow. Not much difference, except it adds an automatic menubar and statusbar, no need to make my own. One advantage was free status hint support without having to catch the event. So I took that and redesigned the status system.

First, the game name on the status bar ate up too much space for nothing. I moved it to the titlebar: bsnes v0.nnn - Game Title (U)

Second, I merged the FPS counter with the system state and put it on the right-hand side of the status bar. It shows "No cartridge loaded", "Power off", "Paused" and the framerate. This is persistent and always visible. FPS doesn't show ideal FPS next to it anymore. That just wastes space.

Third, the new left-hand stuff. It uses the native QStatusBar support for timed messages. I use that to pump power state changes ("System was reset.", "Loaded Star Ocean (J), and applied UPS patch.", etc.) They go away after ~3 seconds. Unsupported special chip warnings now pop up a modal dialog box instead of showing in the status bar.

Fourth, we can now set special menu group / item descriptions that appear when the items are hovered. For instance, mouse over settings->video mode->ntsc and it explains that the setting affects the perceived video output size, rather than the core emulator mode. The descriptions there now suck, but it shows off the concept. We'll leave them off for all the obvious items.

With all of that, I was able to kill off the "Status" class, ~4kb of nasty code that polled the time constantly and maintained an internal string queue for statusbar messages.

Also new to this WIP ... it's apparently not trivial to set a fixed window size with Qt on Xlib. My MinimizeWindowHint that worked on Windows was making the window top-most on Xfce, and breaking fullscreen mode.

So, I tried again to write code that could properly switch between windowed and fullscreen mode. For some reason, this always causes tons of problems. Window managers like to take their sweet ass time updating internal states, so rapid geometry changes often fail, leaving the window in odd positions and sizes.

It took quite a while, but I have it working, hopefully, 100% on Windows. I even account for the desk area (ignoring the taskbar and such) and the window decorations. Centering should be truly perfect, and scale max should be a pixel-perfect fit to all available screen size, while maintaining the ratio.

Linux support is still kind of flaky, though. Long shot, but any knowledgeable help here would be appreciated.

Code: Select all

void Utility::updateFullscreenState() {
  if(config.video.isFullscreen == false) {
    config.video.context = &config.video.windowed;
    winMain->window->showNormal();
    application.processEvents();
  } else {
    config.video.context = &config.video.fullscreen;
    winMain->window->showFullScreen();
    application.processEvents();
  }

  //refresh options that are unique to each video context
  for(unsigned i = 0; i < 2; i++) resizeMainWindow();  //call twice as Xlib drops window messages sometimes
  updateHardwareFilter();
  updateSoftwareFilter();
}

//if max exceeds x: x is set to max, and y is scaled down to keep proportion to x
void Utility::constrainSize(unsigned &x, unsigned &y, unsigned max) {
  if(x > max) {
    double scalar = (double)max / (double)x;
    y = (unsigned)((double)y * (double)scalar);
    x = max;
  }
}

//0 = use config file value, 1+ = override with new multiplier
void Utility::resizeMainWindow(unsigned multiplier /* = 0 */) {
  if(multiplier != 0) config.video.context->multiplier = multiplier;
  else multiplier = config.video.context->multiplier;

  unsigned width  = 256 * config.video.context->multiplier;
  unsigned height = (config.video.context->region == 0 ? 224 : 239) * config.video.context->multiplier;

  if(config.video.context->correctAspectRatio) {
    if(config.video.context->region == 0) {
      width = (double)width * 54.0 / 47.0 + 0.5;  //NTSC adjust
    } else {
      width = (double)width * 32.0 / 23.0 + 0.5;  //PAL adjust
    }
  }

  QDesktopWidget *desktop = QApplication::desktop();

  if(config.video.isFullscreen == false) {
    //get effective desktop work area region (ignore Windows taskbar, OS X doc, etc.)
    QRect deskRect = desktop->availableGeometry();
    unsigned deskWidth  = (deskRect.right() - deskRect.left() + 1);
    unsigned deskHeight = (deskRect.bottom() - deskRect.top() + 1);

    //place window offscreen so resize events do not cause flickering
    winMain->window->move(desktop->width(), desktop->height());
    application.processEvents();

    //shrink window as much as possible to compute frame + menubar + statusbar size
    winMain->canvas->setFixedSize(0, 0);
    winMain->canvasContainer->resize(0, 0);
    application.processEvents();
    winMain->window->resize(0, 0);
    application.processEvents();
    QRect frameRect = winMain->window->frameGeometry();

    //constrain window so that it will fit inside desktop work area
    constrainSize(height, width, deskHeight - (frameRect.bottom() - frameRect.top() + 1));
    constrainSize(width, height, deskWidth  - (frameRect.right() - frameRect.left() + 1));

    //resize canvas to desired size
    winMain->canvas->setFixedSize(width, height);
    application.processEvents();

    //shrink window so that it contains all of canvas, but is no larger
    winMain->window->resize(width, height);

    //allow canvas to be resized along with window by user
    winMain->canvas->setMinimumSize(256, config.video.context->region == 0 ? 224 : 239);
    winMain->canvas->setMaximumSize(desktop->width(), desktop->height());
    winMain->canvas->setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Expanding);
    application.processEvents();

    //force window size change to take effect
    winMain->window->resize(width, height);
    application.processEvents();

    //center window onscreen:
    //take desktop work area and window frame decorations into account
    QRect windowRect = winMain->window->frameGeometry();
    unsigned windowWidth  = (windowRect.right() - windowRect.left() + 1);
    unsigned windowHeight = (windowRect.bottom() - windowRect.top() + 1);

    winMain->window->move(
      deskRect.left() + (deskWidth  - windowWidth ) / 2,
      deskRect.top () + (deskHeight - windowHeight) / 2
    );
  } else {
    constrainSize(height, width, winMain->canvasContainer->size().height());
    constrainSize(width, height, winMain->canvasContainer->size().width());
    winMain->canvas->setFixedSize(width, height);
  }
}
If anyone wanted to get stupid, a style for QWidget.backdrop { background: url(border.png); } when designed for a specific resolution + scaling mode would allow Super Gameboy-style borders :P

Let's see ... properly subclassed the generic input binding pools for clarity, and added user interface key binding support again. So far only for exit emu + toggle fullscreen, but the rest should be easy now.

I can't reduce the space for the QFrameWidgets. Only setMargin works, but it reduces margins on all sides where only the top is bad. I may have to revert it back to a section label + horizontal separator between each area. Probably a good idea, QGtkStyle doesn't support QFrameWidget's decoration anyway. Looks terrible on GNOME.

Finally, fixed ui_hiro for Windows. Still need to fix up the Linux target. They share the same Makefile, so additional targets should be easy, eg a pure SDL port or whatever.
Darn. Oh well, guess I could keep whatever I concoct to myself.
Or tell me what you want to do, as I probably won't mind :P
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

blargg wrote:
FitzRoy wrote:
Gil_Hamilton wrote:But.... the Genesis doesn't have square pixels either..
The 320x224 mode was close enough that you could port the game to a modern device without having to redo all of the original artwork. Even if Nintendo couldn't foresee the portable market in 1983, they should have at least wanted to make it easier for artists by having as close to square pixels as possible. The Master System had 256x192, why couldn't Nintendo?
You're ignoring the fact that 256x192 almost definitely had black borders on the top and bottom, rather than vertically scaling the image. TVs are not multisync displays; the number of scanlines is fixed, and the game system is what determines how much of the width those 256 columns fill. Having more than 256 pixels across would have complicated the hardware register interface, and vertical resampling is out of the question. They could have shrunk the image horizontally so that pixels came out square, but then there would have been black borders on the sides, and a more color fringing.
Hmmm...
I'll have to hoook my 99/4a up and test that. I thought it used square pixels, though I admit to not having launched an exhaustive study.
Relevance is that it used the TMS9914A that the SG1000 used.

Stick TI LOGO in and start TELL TURTLE-ing some test images or something. :P
Maybe get unlazy and actually code a test in Extended BASIC.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

FirebrandX wrote:
_willow_ wrote:Looks like it is the right moment to ask about video mode scales.

Is it any real needs in scales for fullscreen? Is'nt the fullscreen are virtually always supposed to fill up the entire screen space except menu\debug\out-of-ratio bars?
Some people might want to play in doublescale on fullscreen or perhaps some other scale besides max. There are plenty of reasons to leave them in, while there is only one reason to leave them out.
Actually, willow is right. Using window scales in fullscreen mode is an oxymoron. There aren't plenty of reasons to leave them in, which is why you didn't state them. I think the behavior should change to max scale at all times. This was actually part of my proposal to overhaul the video settings, I was intending to choose a more dormant time, but I want to defend willow's logic. I'd like to see them moved back into the configuration area and have settings be universal for both modes, excepting scale of course.

Image

Image

Along the same lines, I also think that menu hiding should become standard fullscreen behavior instead of a hotkey for both modes. Think about it: it is a FULL screen setting, not a maximized windowed setting. Plus that, what's the difference between toggling the menu and toggling the mode? There is none, they're both equally fast ways of accessing the menu and returning to fullscreen.

This change would subsequently require fullscreen to be taken out of the menu and made hotkey only. Hotkeys should finally be mentioned in the readme overhaul, so people who are unaware of what bsnes can do should consult it. There's no counter-argument here either, it's just as likely that someone wouldn't know menu hiding exists if we continue present behavior.
byuu

Post by byuu »

Clarifications.

They share the same base Makefile. UI-specific rules in UI-specific Makefiles now.

We can put any widget we want in the statusbar. Checkboxes, buttons, icons, whatever. Can also add docking toolbars and all kinds of crap. Prefer not to bloat things for the hell of it, but if anyone has any good ideas, I'm all ears.

Since the main window can be resized again, the status bar resize grip was re-added, and I stopped setting checkboxes on the scale Nx settings. They act like regular items now, choosing them quickly resizes the window but that's it. It saves your last setting for the next run too, of course.

I'll probably special case in some usleep() calls for Linux fullscreen toggle.

Another major issue I want to address is getting video updates to be really smooth on the canvas area. Ideally the window should use auto-fill mode when no cart is loaded, and use the video blitter + cached buffer to keep a persistent image even when paused if a cart is loaded. For some reason I can't seem to stop auto painting and flickering without totally disabling Qt rendering 100%, but I'll keep working at it.

Not sure if I want to re-add frameskip. The new PPU that I'll be starting on in 30 years from now won't support that by design anyway. Maybe keep it as a key-binding only for now.

Clarifying for Panzer88 -- sorry, I don't want the hassle of dealing with cross-platform resolution changes. Especially not with Xorg. Everything is painful with Xorg. Someone should write a simple launcher tool: you make foo.ext, associate it with FooLauncher. foo.ext contains "1280x1024x32@60hz: c:\bsnes.exe", it will set the res, start bsnes fullscreen, and restore the default upon quitting.
Fair enough. Smile I can agree with that.
Not a huge deal anyway. I'll LGPL it eventually, and I don't think I've denied anyone's request thus far. Keep in mind ZSNES+Snes9X were both closed source until their authors started to move on too :P
Besides taking up less characters, the other good thing about scheme #2 is emergency update naming makes more sense when it happens. It's just a wip version made public, so why differentiate their naming?
I like my numbering system. How many major, non-bugfix versions of bsnes have there been? Okay, how many versions of Ubuntu have there been? How about ZSNES? Linux kernel? Right.

I will make it to 100 releases, and I don't want to exceed v1.0. I consider v1.0 to be special ... either a final release, or perfect emulation. We don't want the former, and we can't have the latter. I know you guys don't mind if we get up to version 13.67, but I do.

-----------------------------------------------
Is it any real needs in scales for fullscreen? Is'nt the fullscreen are virtually always supposed to fill up the entire screen space except menu\debug\out-of-ratio bars?
1) avoid video tearing at the top and bottom by giving more vsync time.
2) maintain an even multiplier of height.
Along the same lines, I also think that menu hiding should become standard fullscreen behavior instead of a hotkey for both modes.
Yeah, that's fine. I still want to allow turning them on via escape. There's nothing stopping you from using the cheat editor / filter change setting when in fullscreen, for instance.
This was actually part of my proposal to overhaul the video settings
We're honestly just in disagreement at this point. I really like having my windowed mode be a tiny 1x non-ARC for quick testing and multi-tasking. Then switch to fullscreen to get 4x ARC + NTSC filter. PAL output is less of an issue in fullscreen mode than it is in windowed mode, so it's fine to leave it on there for the few games that use it. Whereas that black bar in Snes9x 1.43 and SS is kind of tacky in windowed mode.

I also really like having menubar access to these settings. Not mnemonic keyboard bindings, not "go into the video panel" settings. Quick, easy, simple menubar access for resizing.

Really wish you were a programmer :P
I'd be happy to let you maintain the public UI, and I could do my own thing for my needs. I admit my needs may not match general needs all that well, but I'm the one developing it so ... :P
byuu

Post by byuu »

"2) maintain an even multiplier of height. "

Further, scanline filters only really work well at exact multiples. 2x, 4x, 6x, etc. So if your screen fits 3x, you want to be able to change that. Likewise for clean HQ2x 512x448 with no linear resampling, etc.

Also want to keep the scale stuff in the menubar, and I prefer not to disable menu options when in fullscreen mode.
blargg
Regular
Posts: 327
Joined: Thu Jun 30, 2005 1:54 pm
Location: USA
Contact:

Post by blargg »

Gil_Hamilton wrote:
blargg wrote:256x192 almost definitely had black borders on the top and bottom, rather than vertically scaling the image.
I'll have to hoook my 99/4a up and test that. I thought it used square pixels, though I admit to not having launched an exhaustive study.
Not square (square on top, video capture on bottom). Same size as NES/SNES pixels, BTW.
Image
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

blargg wrote:
Gil_Hamilton wrote:
blargg wrote:256x192 almost definitely had black borders on the top and bottom, rather than vertically scaling the image.
I'll have to hoook my 99/4a up and test that. I thought it used square pixels, though I admit to not having launched an exhaustive study.
Not square (square on top, video capture on bottom). Same size as NES/SNES pixels, BTW.
Image
I salute you, good sir!


Saves me having to fight my half-broken video cables, I suppose.
...
But now I wanna play Parsec.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote:I will make it to 100 releases, and I don't want to exceed v1.0. I consider v1.0 to be special ... either a final release, or perfect emulation. We don't want the former, and we can't have the latter. I know you guys don't mind if we get up to version 13.67, but I do.
I'm not going to try and change your mind on this, but I wanted to note I like CCleaner's versioning system: [major revision].[minor revision].[internal revision] Sure it gets tacky if you ever reach major version 5 or something like that, which is when companies generally make the dubious decision of putting the next year in the title, but I don't think it's a big problem myself.
byuu wrote:1) avoid video tearing at the top and bottom by giving more vsync time.
Is this actually a problem? The only time I ran into this on Windows using Direct3D was when I tried to make a Present() call -after- the first possible instance of GetRasterStatus saying VBlank had started. (and you shouldn't ever run into that with bsnes unless you can do >2000 uncapped frames per second) Even when I told it to copy the backbuffer to the front rather than flipping them I don't think I got any tearing at the top as long as I made it start the moment VBlank is detected.
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Post by tetsuo55 »

Verdauga Greeneyes wrote:
byuu wrote:1) avoid video tearing at the top and bottom by giving more vsync time.
Is this actually a problem? The only time I ran into this on Windows using Direct3D was when I tried to make a Present() call -after- the first possible instance of GetRasterStatus saying VBlank had started. (and you shouldn't ever run into that with bsnes unless you can do >2000 uncapped frames per second) Even when I told it to copy the backbuffer to the front rather than flipping them I don't think I got any tearing at the top as long as I made it start the moment VBlank is detected.
I actually have a LOT of problems with this(not only with bsnes) and a little black bar on the top and the bottom can mean the difference between tearing or no tearing.
Bsnes would have to be capable of moving the sync line into the black part of the screen ofcourse for it to be fully usable
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

tetsuo55 wrote:Bsnes would have to be capable of moving the sync line into the black part of the screen ofcourse for it to be fully usable
Are you saying you have trouble with this in bsnes when using the highest scale setting your monitor can do? Because it could (at least for certain drivers) call Present as soon as the beam reaches the, er, lower black bar. Tracking the beam for the upper black bar is pointless as VBlank happens before then anyway and you'll always be too late if you present after VBlank; the delay is simply too big.

It would be nice if you could keep track of the size of the delay between calling Present and the front buffer actually being updated. Then you could tell it to start drawing at the optimal time, which would avoid the odd duplicate frame. You'd still have to be careful not to start drawing too soon or too late, especially if you might do -either-, as tearing from that would presumably be twice as noticeable.

The only way I can think of to do this would be to encode a time stamp in the back buffer, then poll the front buffer until its time stamp is updated. But that would leave a visual artifact in the frame, not to mention the cost of polling, and might not be feasible if the time spent getting access to the front buffer's data is significant. (i.e. latency in communicating with the graphics card.. unless it's possible to make the GPU go through the process all on its own, i.e. via CUDA) It might be an interesting experiment though.
Locked