Printable View
If you render a face in Direct3D and look at it from a close distance, it is very pixelated. How do you render it more smoothly (interpolated colors, or something)? Is it some render state you set?
Here is a screen of it (hopefully the JPG compression won't smooth it too much ^^):
Look up the IDirect3DDevice9::SetSamplerState() method/function in your DX 9.0 SDK.
Code:Device->SetSamplerState(0,D3DSAMP_MAGFILTER,D3DTEXF_LINEAR);
Device->SetSamplerState(0,D3DSAMP_MINFILTER,D3DTEXF_LINEAR);
This turns on linear texture filtering for stage 0 and uses the linear filter for both the minification filter and the magnification filter.
Exactly what I was looking for, thanks!
(here is the result :) )
I'll just to add on to what has already been said. Lots of times when people are making a demo or whatever it is only ever intended to run on their machine and this is fine. However, lots of times you want to give people your demos and let them see how cool it is. You don't want any problems when they try to run your demo on their machine do you? Well if you don't you should really start checking out the CAPS stuff for Direct3D. This will let you know the capabilities ( CAPS ) of their video card. Most cards support bi-linear filtering as per Bubba's suggestion. However, there are better ways to filter textures such as Anisotropic. When you use these you need to check to see if the video card will support it first. It is common in your initialization code to check for the best type of filtering for min, max and mip and then keep track of that.
I post this because far too many people blantantly disregard the caps stuff nowadays and wonder why they get crashes on different machines. It's not always because they didn't check caps but often it is. Enjoy.
Well I didn't go into that explanation because I'm sure he's in the beginning stages of his project.
I'm adding the CAPS stuff now and I will tell you it does add quite a bit of code as well as quite a bit of variable testing - but of course I'm doing this outside of the render loop like a good graphics programmer or the engine would be slower than slow.
It is a good bet though that nearly every card that supports DirectX 9.0 will support bi-linear filtering (actually it is two linear filters combined on x and y which creates a bi-linear). So you will probably be safe in assuming this. I know of no modern games that even support nearest point sampling simply because it is so outdated. Most assume that your card will support bilinear filtering if it supports DX 9.0...and if it doesn't then you definitely bought the wrong video card. :D
But Mr. Wizard does have a very good point albeit a bit mute on bi-linear filtering. You should test the CAPS of your devices prior to using advanced features (bilinear filtering is no longer advanced). This is true with all components of DirectX (DirectInput, DirectShow, DirectMusic, etc.).
Another important area this relates to is point sprites. Most video cards suprisingly DO NOT support the D3DFVF_PSIZE flexible vertex format flag. If you use this on a video card that does not support it....you will render absolutely nothing to the screen which can be extremely misleading. You might think its your code that is causing the problem when in actuality your code is perfect...the hardware simply does not support it. This is one of the few areas of Direct3D that DOES NOT pass this call on to the HEL if the HAL does not support it. In other words it will only be controlled in software if you specifically tell DirectX to do so otherwise it will assume hardware.
Point sprites as they are IMO are quite useless because their size is clamped to 64x64 pixels (not very big on a 1024x768 or higher res video mode). I'm not sure why this limitation exists but it is extremely annoying (even the newer cards only support 128x128 point sprites). So I dumped the point sprites for everything except very small particles because they are useless for anything else. Billboarding is still a much better solution.
If you do not want to test for CAPS every time you implement something new during development...simply create a dummy DirectX init class that holds all possible values in it. It's really not hard to test for caps and if you make it a (global) structure or public class....it should work well for you.
I've also found that in game coding do not be afraid to use globals in your main module. This is an easy way to get everything up and running w/o worrying about all that inheritance stuff.
For instance:
I've found this to work quite well...you are still obeying the rules of OOP in your classes and objects so it is still very encapsulated...it just makes access easier in the main module.Code://in SomeThing.h
class SomeThing
{
};
//In AnotherThing.h
class AnotherThing
{
};
//Main module
#include "SomeThing.h"
#include "AnotherThing.h"
SomeThing MyObject;
AnotherThing AnotherObject;
Of course if you are going to do this you should avoid passing parameters to constructors and this, too, I find to be a very good practice. Use constructors to zero everything....but don't initialize anything. Use and Init() function to do that and return false on failure. This way if the initialization fails you simply test the return value and then throw and exception and/or destroy the object. You could throw from the constructor of your objects but this creates some rather ugly constructors.
I think of constructors as empty buildings. They have been constructed but nothing has been initialized - no furniture..no lights...etc, etc. The init() function 'installs' all of that.
Of course I could be full o crap here too...but it works for me.
:D