Present() = pixelated

Which is why most people Reset their device with a backbuffer the new size of the client rect. Is there a reason you're leaving the backbuffer at the old size?

I play in a resolution of 640x480 either in fullscreen or windowed.

If I started in window mode and maximized, the game will look similar to if I started in fullscreen. This is why I don't reset() - also because I get much lower FPS in high resolution and I prefer the size of everything when rendered at 640x480.

To keep tight control over the stretching/filtering, you could render your entire scene to a render target and display that on a 'fullscreen' quad at the end of the frame (fullscreen meaning, fitting the client area). When rendering the quad, you'll effectively be re-sampling the scene with whatever filtering you want.

Could you post some example pseudo-code for this?

Look like you don't handle WM_SIZE message, that's why you have stretched display.

Take a look at this sample.

As I said before - I do not desire or need to call Reset().

Stretching via Present() works perfectly except when running with Aero disabled on Vista.

Not desiring to do something, doesn't mean that you are right, only maybe lack of skill/experience to do some tasks, or know certain things.

The first error will show, when you start your program and change desktop resolution with program running, so handling lost devices is kind of essential in this case. That means that you will need to handle reseting of device if you want to have your program running without bugs.

Normally AERO is handled from directx, meaning that when aero is enabled, possibly you have pre-setted the render states of your device, and when the aero is disabled, those render states are different.

Eventually comparing render states when aero is on/off, will show you differences, and what you need to set, to work it properly.

Quote:

Original post by pathon Could you post some example pseudo-code for this?

It's basically the typical post-processing setup, going a bit like this each frame:

1. (begin drawing)
   
2. Set render target on the device
   
3. Render entire scene to the target
   
4. Wrap up rendering to the target, iirc using EndScene
   
5. Set the render target as a texture on the device
   
6. Draw a fullscreen quad with the texture applied and the filtering of your choice
   
7. Present
   
8. (done)
   

I'm not quite sure how various steps need to be implemented in C++/DX, but I think the DX SDK has a few samples (look for post-processing and be sure to check the help on that SetRenderTarget method) and many only tutorials should also provide info on how to set this up.

Rereading pathon's last comment though, if there really are differences in the render states/sampler filter settings you might want to try explicitly setting the differing states to the values that work for you. It sure beats going the long way around with my suggestion, unless you were planning to do some post-processing anyway.

I set different values for samplerstates and it didn't help, I also read the sdk post-processing tutorial and didn't understand it. I followed some tutorials and they didn't work. :(

I was bored, and I couldn't immediately find any concise, readable examples that illustrated the basic concepts of what remigius recommended, so I tried to modify one of the early DX SDK examples to include some of that behavior. It renders to a 640x480 texture, but stretches it onto a 1024x768 backbuffer.

http://gamedev.pastebin.com/m552be2d0

Important things to note:
- No matter what, you are going to need to reset your device. I know it's not what you want to hear, but properly handling resetting your device is important for a lot of reasons, including lost device situations.

- This method allows you to keep rendering your scene at 640x480, and I would think the same performance, BUT: your back buffer will have to match the dimensions of the client area you're rendering to for this trick to do any good. So again, you're going to need to reset your device.

- Of course, pay attention to the handling of resources in the default pool (in this example, the vertex buffers and render target) upon losing the device. This code does not handle that.

Also, this will use simple bilinear filtering. It doesn't delve into the topic of more advanced resampling methods.

Thanks for your help, Neverender

I integrated your code into my game and it now it stretches normal on Vista with Aero disabled...

The game menu now looks perfect - no artifacts (like it should) but when I load a level the graphics go back to the horrible quality like it used to be in menu :(

Edit: nvm, bug on my part :)

[Edited by - pathon on November 16, 2008 1:09:20 AM]

I can't seem to solve some issues after adding the render-to-texture code.

Playing movies now no longer work and neither do fades :/

bump :(

The screen fills with white whenever something transparent is being rendered e.g. fade - so I need a quad that supports transparency?

[Edited by - pathon on November 16, 2008 7:53:43 PM]