Best Video Setup when playing games at 1280x1024???

[byuu]

I don't know what the ATI / nVidia drivers do. I implement it in software (with video scaling done in hardware), so it can be toggled within the emulator. ZSNES does the same. Triple buffering or vsync when you're not running at 50/60hz (e.g. in windowed mode) looks hideous and should be easy to turn on and off on demand.

Now, scanlines: fun stuff. On the TV, the SNES has scanlines. Every other line is drawn. In non-interlace (pseudo-progressive) mode, only the even scanlines (0, 2, 4) are drawn. In interlace mode, it draws even scanlines on one field, odd on the next, to double resolution.

The reason 50% scanlines look too dark is because on a TV, the scanlines bleed into each other slightly, this is called the kell effect. Between two scanlines, 70% of the luminance comes from the currently drawn scanline, 30% from the previously drawn scanline. This even causes flickering to occur when you enable interlace at 256x224 mode. No SNES emulator gets this right.

The scanline effect applies to both non-interlace and interlace modes as well, no emulator handles this with interlaced mode.

Basically, when you turn off interlace, since the odd lines are no longer drawn, they fade away over the course of 2-3 frames.

For an example, assume these three lines make up two TV scanlines.

For even frames, your two scanlines would look like this:
color 0 --->
color 0 --->
color 1 --->

color 0 --->
color 0 --->
color 1 --->

For odd frames, it becomes
color 0 --->
color 1 --->
color 1 --->

color 0 --->
color 1 --->
color 1 --->

That's the closest, simple approximation I can come up with thus far.

You could also blend the non-active scanlines by 40%, and get something similar.
e.g. (31*7)/10 = (31+(31*.4))/2
SNES9x' TV mode uses 70% luminance for odd scanlines, which is completely wrong.

[Deathlike2]

Forcing Triple Buffering in either ATI and NVidia (or whatever company) is moot because it is an OpenGL option (which it isn't obvious to an NVidia user) and ZSNES is a DirectX app...

Triple buffering can only be controlled by the app in DirectX...

The other minor detail is that Vsync+Triple buffering are usually separate options in which vsync generally is enabled so triple buffering benefits the most...

Also... triple buffering is not available for windowed modes because of some "limitation" of DirectX... you probably can google the specifics as to why (I'm only recall this from memory).

[byuu]

Also... triple buffering is not available for windowed modes because of some "limitation" of DirectX

Incorrect. You can detect the start of vblank in windowed mode or fullscreen. The difference is that you can't use page flipping in windowed mode because there's other stuff on the screen. The SNES screen size can vary between 256x224 to 512x448. So it makes sense to use hardware to scale the 256x224 to a higher resolution (e.g. 512x448) so that the higher resolutions are the same screen size, and so less RAM -> Video RAM bandwidth is needed in the lower resolution modes.
Plus, sometimes you'd want to stretch a lot more. To 640x480, 1280x1024, etc. for aspect ratio correction.
Thusly, you'd usually update the screen by drawing a stretched rect anyway. While page flipping does work a little better (stretch the image there, and then flip the pointer during vblank), why not draw that stretched rect directly to the display during vblank? With hardware acceleration, you can almost always get the blit finished before the start of the next frame anyway.

[Pasky]

Forcing Triple Buffering in either ATI and NVidia (or whatever company) is moot because it is an OpenGL option (which it isn't obvious to an NVidia user) and ZSNES is a DirectX app...

Triple buffering can only be controlled by the app in DirectX...

The other minor detail is that Vsync+Triple buffering are usually separate options in which vsync generally is enabled so triple buffering benefits the most...

Also... triple buffering is not available for windowed modes because of some "limitation" of DirectX... you probably can google the specifics as to why (I'm only recall this from memory).

Thats odd, then why does enabling it through these driver menu's seem to effect Direct3D games?

[Deathlike2]

Thats odd, then why does enabling it through these driver menu's seem to effect Direct3D games?

Are you sure that's actually occuring? Just google it and you will find out that Triple Buffering in Direct3D is only controllable by the app.

http://www.laptopvideo2go.com/forum/ind ... entry23497
http://www.nvnews.net/vbulletin/showthr ... 04&page=13

Now, there is a tool that lets you force Triple Buffering.. and that's one thing.. but as I said before.. the application has control over Triple Buffering. The drivers only force Triple Buffering in OpenGL.

Incorrect. You can detect the start of vblank in windowed mode or fullscreen. The difference is that you can't use page flipping in windowed mode because there's other stuff on the screen. The SNES screen size can vary between 256x224 to 512x448. So it makes sense to use hardware to scale the 256x224 to a higher resolution (e.g. 512x448) so that the higher resolutions are the same screen size, and so less RAM -> Video RAM bandwidth is needed in the lower resolution modes.
Plus, sometimes you'd want to stretch a lot more. To 640x480, 1280x1024, etc. for aspect ratio correction.
Thusly, you'd usually update the screen by drawing a stretched rect anyway. While page flipping does work a little better (stretch the image there, and then flip the pointer during vblank), why not draw that stretched rect directly to the display during vblank? With hardware acceleration, you can almost always get the blit finished before the start of the next frame anyway.

Well, I'm talking about 3D games (OpenGL and Direct3D) in general.. obviously if this were possible, why isn't it used more? It seems to me that there is something that makes coding this a pain in the ass.

[byuu]

obviously if this were possible, why isn't it used more?

Hell if I know. I guess because it's not quite as good since you have to blit the image, rather than just changing a pointer during vblank. But there's plenty of time for any modern video card to update the window during that vblank time period.
Or perhaps game developers don't want to deal with the horrible choppiness that occurs when the desktop refresh rate doesn't match the game's internal refresh rate.

[blackmyst]

The image quality is superior when both are combined.

To you maybe, but not to anyone else. Scanlines combined with HQxX is ridicilous and it would not "improve" Zsnes. It would merely make Zsnes cater to you more.

Scanlines are for people who want to (somewhat) simulate TV output. It puts each pixel on a horizontal row, detached from the rows above and below. Besides looking more like the actual TV image, this also gives the illusion of smaller pixels, or higher resolution. Having HQxX beneath that defeats the point of having scanlines because it adapts the pixel grid into vectors.

HQxX is for people who want a sharp vectored image for some games even on high resolutions such as 1280x1024. Having scanlines overlaying that defeats the point of HQxX because of what I just described above.


Scanlines emphasise on individual pixels. HQxX tries to make them disappear. Again I repeat, they defeat each other's point.

[Pasky]

Thats odd, then why does enabling it through these driver menu's seem to effect Direct3D games?

Are you sure that's actually occuring? Just google it and you will find out that Triple Buffering in Direct3D is only controllable by the app.

http://www.laptopvideo2go.com/forum/ind ... entry23497
http://www.nvnews.net/vbulletin/showthr ... 04&page=13

Now, there is a tool that lets you force Triple Buffering.. and that's one thing.. but as I said before.. the application has control over Triple Buffering. The drivers only force Triple Buffering in OpenGL.

Incorrect. You can detect the start of vblank in windowed mode or fullscreen. The difference is that you can't use page flipping in windowed mode because there's other stuff on the screen. The SNES screen size can vary between 256x224 to 512x448. So it makes sense to use hardware to scale the 256x224 to a higher resolution (e.g. 512x448) so that the higher resolutions are the same screen size, and so less RAM -> Video RAM bandwidth is needed in the lower resolution modes.
Plus, sometimes you'd want to stretch a lot more. To 640x480, 1280x1024, etc. for aspect ratio correction.
Thusly, you'd usually update the screen by drawing a stretched rect anyway. While page flipping does work a little better (stretch the image there, and then flip the pointer during vblank), why not draw that stretched rect directly to the display during vblank? With hardware acceleration, you can almost always get the blit finished before the start of the next frame anyway.

Well, I'm talking about 3D games (OpenGL and Direct3D) in general.. obviously if this were possible, why isn't it used more? It seems to me that there is something that makes coding this a pain in the ass.

I wasn't sure about triple buffering in particular, not really a way to tell if that is happening but enabling anisotropic x16 through my drivers does in fact effect direct3D games such as half life 2 and even epsxe when run in direct3D mode.