Quote:Original post by BlueMonkQuote:Original post by TodoI downloaded the DirectX 10 SDK, and it came with redist components. Also, I don't expect the people using my software to be running Vista. (Not that I'm ruling it out, I just expect the majority to be using Windows XP.)
DirectX10 is AFAIK an essential part of Vista, and doesn't work with any previous version of the OS (because of its model), so you shouldn't have to bundle any part of DirectX with your game/application. In fact, I'm not sure it's possible (e.a. will there be anything like an end-user runtime distro?)
You don't have a choice in that regard: D3D10 is available exclusively for Windows Vista, because of underlying changes in the hardware driver model. You can run D3D9 apps on Windows Vista, but not D3D10 apps on Windows XP. Or has this changed yet again recently? Mind you, this has nothing to do with the availability of the SDK (although I didn't know of the bundled redist, thanks for that info).
Quote:Original post by BlueMonkQuote:Original post by TodoYes, I anticipated compatibility issues with different systems supporting different display modes. But DirectX is much more complicated to scale than other things because there are so many variables to check. So I tried only to deal with scalability only at the simplest level (I don't have the resources to go into it too deeply with this being a project I'm working on alone in my free time), but I'm having unexpected problems (I'm sure you know, not every issue can be anticipated). So now I'm trying to work out just what requirements/variables there are that I didn't catch. The strange thing is that this is just a new version of a product I've already made (albeit a rewrite in a new language with a new version of DirectX) and I didn't have these kinds of problems with the first version. I think I just went about enumerating display modes wrong, so I'm working on fixing that, and hopefully that will eliminate some of my problems.
Incidentally, that's how developers take care of things. You anticipate compatibility issues (amongst others) and handle them accordingly (=> scalability). How far you wish to go ultimately determines how many people you will amount to.
Nobody expects you to anticipate all problems :-). Plus, you're an indie, so it's cool. I know very well of the problems that can arise during play testing on different machinery, as it happened to us more than once during college projects.
Quote:Original post by BlueMonkQuote:Original post by TodoWell, I use ScissorRectangle to clip some pieces of the output, but depending on what type of output it is, I might want to clip it before the transformation instead of after, and I doubt scissor testing supports that. Maybe I should be using something else for 2D clipping, but this is the best/only thing I found that works.
I don't know what ScissorRectangle is in this context, but if you mean the scissor test, then no, it won't. Both operate on independent primitives. Unless you mean that the result of a transformation may place the scene outside the scissor rectangle, but that's trivial.
The scissor test rejects pixels at one of the last stages in the fragment pipeline, thus after any transformation on vertices. If you want clipping to happen earlier on, you should use clipping planes or play with the frustum.
Cheers.
