Interlaced rendering demo

[Xmas]

Starting with a discussion about interlaced rendering modes on consoles, I wondered whether interlaced rendering would be an option for PC games, too. Either for increasing temporal resolution (fps) at the cost of spatial resolution, or for choosing a higher interlaced resolution instead of a lower progressive one.
So I put together a little demo program that allows a comparison of progressive rendering and interlaced rendering with different deinterlacing algorithms. Unfortunately, i didn't have much time to research and implement many algorithms, so the program only contains a very limited choice.

Download

EDIT: fixed the file to include a missing texture

requires:
.NET Framework 1.1
Managed DirectX 9.0c
SM2.0 capable graphics card

In the driver control panel, set AA to application controlled and set vsync to always on.
In the application, make sure that the fps display at the top is identical to your screen refresh rate, or it won't work correctly. You can enable AA in the Change Device screen, but it might not have an effect with older ATI drivers.

If you want to, you can add your own deinterlacing methods to the .fx file. Just add a new technique at the end, it will show up as "User Technique #" in the drop-down boxes.



On my TFT, it doesn't seem to be a worthwile method because the interlaced modes blur the image too much. But maybe it works better on CRTs. Any feedback is appreciated.

 

[991060]

How do I make sure managed DX9.0c is installed?
I have 2005 June SDK, .net framework 2.0 beta installed, and it throws a file not found exception.

 

[Blazkowicz]

I have .NET framework 1.1, don't know either if I have Managed DirectX, but I get this when running the program

and if I click on cancel I get this

(well for that second one I guess the debugger is included in the SDK, I have the runtimes only)


I'm interested in seeing how interlacing looks with what my screen is able for. (I'd try "1024x768i" at 100Hz if I could..)

 

[no-X]

Same problem

 

[Hyp-X]

An exception 'System.IO.FileNotFoundException' has occured in InterlacedRendering.exe

I have .Net framework 1.1 and Managed DX v9.05.132

 

[Xmas]

Hm, I can't reproduce this error on another machine where I freshly installed the .NET Framework and MDX. But I believe it's somehow related to that damned assembly versions. I have both 1.0.900.0 and 1.0.2902.0 versions of the MDX assemblies installed, but VS only lets me choose 1.0.900.0 directly, against which the program won't compile because of some changes between the versions. So I have to manually pick the assemblies, maybe that's why it won't work on other machines.

edit: or maybe I just forgot to include the UI texture...

 

[DudeMiester]

Athlon XP 1800, Geforce 6800GT, 768MB RAM. At 640x480, progressive gets me about 160fps, whereas interlaced is actually slower at 140fps. I think you really need to make it MUCH more pixel shader heavy to see a difference. Throw in relief mapping and HDR and try again.

 

[Xmas]

Athlon XP 1800, Geforce 6800GT, 768MB RAM. At 640x480, progressive gets me about 160fps, whereas interlaced is actually slower at 140fps. I think you really need to make it MUCH more pixel shader heavy to see a difference. Throw in relief mapping and HDR and try again.

Err... the purpose of this demo is not to compare fps, but quality. And you should have vsync enabled.

Interlaced in this demo is slower because it does more work. But this demo is just a feasibility check for doing interlaced rendering in hardware.

 

[sonix666]

Unfortunately it crashes with the same error on my machine too. It is freshly installed with .NET 1.1 and managed DirectX. I installed that last one especially for your demo.

 

[Xmas]

It seems to work for some and not for others, which makes bug tracking extremely difficult. Maybe it requires a certain version of MDX assemblies. If it doesn't work for you, try extracting those to the folder where you put the demo.

 

[Moloch]

It seems to work for some and not for others, which makes bug tracking extremely difficult. Maybe it requires a certain version of MDX assemblies. If it doesn't work for you, try extracting those to the folder where you put the demo.

That fixes it.
But unticking side by side comparison crashes it.

 

[Xmas]

That fixes it.

But unticking side by side comparison crashes it.

Damnit, I really should put more emphasis on exception handling, even when I'm writing code for myself originally.


btw, if you get "interlaced" outputting a very bright image (likely on NVidia cards), you can open the .fx file with a text editor and replace all occurances of "fmod(<anything>, 2)" with "fmod(<anything> + 0.001, 2)". Sometimes precision can make a difference.

 

[Blazkowicz]

still no luck for me

with your libraries I get something now, but it's yet another error messsage (I get the first one after that)

I'm on windows server 2003 with a ti4200 128MB and forceware 61.77, directX 9.0c

 

[Xmas]

Ah, at least I don't have to spend hours to find that bug. Your efforts are appreciated, unfortunately the program requires a PS2.0 capable graphics card to run. I forgot to add this requirement to the initial post at first.

 

[mito]

It seems to work for some and not for others, which makes bug tracking extremely difficult. Maybe it requires a certain version of MDX assemblies. If it doesn't work for you, try extracting those to the folder where you put the demo.

I had the same error reported here first. (Application has generated an expection that could not be handled).

Then I copied your XML and DLL files and now it's working.

 

[Fox5]

Athlon XP 1800, Geforce 6800GT, 768MB RAM. At 640x480, progressive gets me about 160fps, whereas interlaced is actually slower at 140fps. I think you really need to make it MUCH more pixel shader heavy to see a difference. Throw in relief mapping and HDR and try again.

Err... the purpose of this demo is not to compare fps, but quality. And you should have vsync enabled.

Interlaced in this demo is slower because it does more work. But this demo is just a feasibility check for doing interlaced rendering in hardware.

Err, I have several old sega PC games that used like DX5 or something that could run in interlaced output. Looked like crap on a monitor, but looked fine when outputted to a tv. Also, you can force interlaced output in video card drivers, I believe even the standard vga drivers that come with windows.
So what is this then? Using pixel shaders to do interlaced output? Why?

 

[Blazkowicz]

and you can/could set your windows desktop to 43Hz interlaced, at least under windows 9x (I don't have the option here on that PC). looks terrible.

as windows 9x uses desktop refresh for 3d apps (I wish NT 5.x would do that!), I guess you could have interlacing in game (but it would be more interesting with twice or thrice the refresh rate, if it's possible..)

 

[Xmas]

So what is this then? Using pixel shaders to do interlaced output? Why?

To check what it looks like on a high res, high refresh rate PC screen. Especially with yet-to-be-implemented high quality adaptive deinterlacing.

The idea behind this is to dynamically trade temporal with spatial resolution and vice versa, depending on what is required.
E.g. 720p and 1080i require about the same number of pixels per frame. But with good deinterlacing, 1080i offers much better resolution for still images. For moving objects, you either get a bit of blur or mice teeth. But you can't see them sharp anyway.
Alternatively, 720i could be significantly faster with (possibly) only slightly worse quality.

 

[MfA]

E.g. 720p and 1080i require about the same number of pixels per frame. But with good deinterlacing, 1080i offers much better resolution for still images.

Problem is that your monitor doesnt have motion compensated deinterlacing.

If you rely on the eyes to do the deinterlacing then you will get a whole lotta flicker if you actually try to use 1080i without any vertical blur (and once you use vertical blur the advantage of the vertical resolution is a bit academic).

 

[Xmas]

Nah, I want the GPU to do the deinterlacing on output, not the monitor.