DirectX Drives me crazy!!

[techbear]

I've gotten into another situation where my scene doesn't draw right, and I'm fiddling all the SetRenderState() options without knowing what the problem is, and I realize I've been doing this for years.

Obviously I don't grokk the system, and I need help. Is there a book or a tool that will help me understand the totality of D3DTA_TEXTURE, D3DRS_ALPHAFUNC, D3DTSS_MINFILTER, and all those other settings (for dx8, preferably)?

I was thinking of writing one; an app that displays a series of quads and a WHOLE bunch of buttons, to let me fiddle the options and see what I get. But I don't know if that'll be useful.

[ggambett]

So what's the problem?

[vjvj]

The included documentation in the DX SDK should be enough to explain almost everything... It has a lot of material on graphics primers and whatnot.

Which is exactly what a lot of those things you listed are... Alpha functions, for example, are a fundamental graphics concept that is API-agnostic. You'll encounter the same thing using OpenGL, Torque, or PTK even.

DX SDK docs are your friend...

[Jesse Aldridge]

I think the problem is that you're trying to work with DirectX directly. In my opinion DirectX and OpenGL are very low-level libraries that are meant to be used by middleware developers rather than application developers. They are "do anything" libraries. But like with any "do anything" library, the power comes at the expense of ease-of-use. I think there should always be a layer over these do-anything libraries that distills their power into something more usable. In the case of game developers that layer would be a game engine.

I remember having the same thoughts as you, only with OpenGL. I thought, 'if only I knew everything about OpenGL, I wouldn't be having to deal with all these random, obscure issues.' I posted about it here. BadSector replyed with a comment that started with "You don't learn a low-level library like OpenGL inside out." And that got me thinking... and ultimately lead me to the conclusion that I just wrote about in the first paragraph.

To phrase things slightly differently: F*ck DirectX. Crap like D3DTSS_MINFILTER is not meant to be understood by humans. Check out PTK (which I've never used but I get the impression is good). Or, hell, while you're at it f*ck C++ too and move to the Java based Slick game engine (which I am using and highly recommend) (use it with Eclipse, it will change your life ). The bottom line is these are tools that will help you to get things done. Using DirectX directly will have you spend a ton of time running around dealing with technical b.s. that is irrelevant to finishing your game.

Whew. ::takes a deep breath:: Sorry if that isn't really the answer your looking for. Your post just inspired a rant that I suppose has been brewing for a while now

I guess the only dangling question here is whether you should be building the middle layer game engine yourself or letting someone else do it. And I think to answer that question you need to decide whether you want to be a game developer or an engine developer. Trying to be both may simply be impractical for a single developer. And yes, if you use someone else's stuff you'll be restricted by it's capabilities, but as a trade off you'll be able to focus on your game. It's worth it.

[vjvj]

I guess the only dangling question here is whether you should be building the middle layer game engine yourself or letting someone else do it. And I think to answer that question you need to decide whether you want to be a game developer or an engine developer. Trying to be both may simply be impractical for a single developer. And yes, if you use someone else's stuff you'll be restricted by it's capabilities, but as a trade off you'll be able to focus on your game. It's worth it.

Well, the point I was trying to make was that most of those things would be pretty obvious to someone with a background in graphics programming. MINFILTER is a perfect example of something that is a core fundamental concept no matter what API you are using. If MINFILTER is confusing, it's more due to a lack of sense of what is happening with your rendering.

That's why I thought alpha function was a great example; even if you are using something as easy as PTK, you still need to know what they are!

That said, I do generally agree with your above statement and everyone needs to draw the line somewhere.

However, I still stand by my advice to just read the DirectX docs. They explain a lot of fundamental stuff like filtering, blending, transforms, etc. that are all very important core concepts. Remember, we all have a day when art is not showing up correctly in the game, and it's pretty important to be able to have a basic sense of what might be going wrong...

P.S. I have a feeling the bug the OP is encountering has zilch to do with render state. Can you describe the symptoms of the problem?

[bvanevery]

Using DirectX directly will have you spend a ton of time running around dealing with technical b.s. that is irrelevant to finishing your game.

True, but it's also a business model. The only way you're going to make money on your game, is if you sell it and it sells well enough to be profitable for you. Whereas it's pretty darn easy to get hired for your DirectX knowledge, as an employee if you're green, or as a contractor if you've walked through the fire to become an expert.

You have to decide if you actually like mucking around with 3d graphics, C++, and ASM code. Some people do, they're pedal-to-the-metal people. Java doesn't turn them on at all because it's slow and gets used for web servers. Bor-ring! 3d muck will lead you to more 3d muck. If you like it, then that's a way to have a business model while you're trying to get your game off the ground. Web muck will lead to more web muck. If you like it, ditto. But I don't like it. So I don't do it.

As an indie, do not be afraid to pursue the technologies you like, and to dump the technologies you don't like. The only caveat is, you have to consider how your technical investments are going to pay the bills. You go chasing "better" technology that nobody will pay for, you'll end up broke.

RTFM is a good way to get up to speed with DirectX. If you're missing the fundamentals of 3d graphics though, then you need to buy one of those game development books. There's tons of 'em. I can't recommend one specifically, I got my 3d knowledge back when it wasn't even a regular college course offering. Taught myself the rest with a Linux box and reading a bunch of SIGGRAPHs in a math/physics library. Wrote my own software rendering libraries on a 486 before there was any 3d HW on PCs. Nowadays there's a bazillion learning resources all over the internet and tons of people in game developer forums to help you. Us old dogs did it alone, from scratch, with very few resources.

My point is, if we did it, so can you. If you want to. It does take awhile to swallow 3d and it's not for everyone. But there's money in it if you do, if you like the stuff.

[techbear]

The assumptions are getting a bit out of hand. I'm very well versed in DirectX, and I know exactly what MINFILTER is. My post was a simply a whine; sometimes I feel like I understand all the parts, but a holistic understanding escapes me.

Vjvj was right that "we all have a day when art is not showing up correctly in the game"; that's what was happening with me. My problem turned out to be unrelated to SetRenderState(); I wasn't resetting the world matrix to identity, so the skybox was using the position matrix of the last ship I drew, which I misconstrued as a clipping or z-buffer problem. It's fixed.

I also took the opportunity to consolidate a lot of my SetRenderState() calls, to make it easier to keep track of them.

Jesse and others have talked about game coders vs. engine coders, too. I'm a game DESIGNER, but I've always expressed myself in code, and I've always been unimpressed by middleware. I used the popcap framework for a year, good code, but I ultimately felt constricted by its assumptions.

Yes, I've met and worked with plenty of engine coders, and plenty of game coders, and I understand there's a difference. But I'm a strange beast and I'm okay with that. Anyway, thanks for your concern.

[zoombapup]

techbear: I highly HIGHLY recommend you write yourself a class that interfaces renderstate setting for you. Have a bunch of setter methods for setting your common states and then keep a handle on all states setup as you go along so you can trace where state changes happen (and by association you can simply ignore redundant state change code too).

The advantage is that you can take some stats on how often your states are set etc. Gives you the power to add a line like "dumpCurrentState();" to debug current states etc.

Or I guess use the DXDebug runtime to dump out some info too.

[bvanevery]

The assumptions are getting a bit out of hand.

Really I was responding to Jesse, for the benefit of any newbies reading this thread. If a newbie doesn't want to be a DirectX expert, then she should decide what she does want to be an expert at, and how she will get paid for it. If you wanna make money before your own games are profitable, i.e. you're averse to starvation , then you gotta learn the gory grunge of something. "Screw DirectX, learn a 3d engine and use Java!" leads you to web apps, web games, and cell phone games. Make sure those are what you want to work on, because you won't be working on heavy duty 3d anything.

[matibee]

I was thinking of writing one; an app that displays a series of quads and a WHOLE bunch of buttons, to let me fiddle the options and see what I get. But I don't know if that'll be useful.

I did something similar several years ago. I essentially had a player stood on a jigsaw piece and I wanted one texture to represent the piece and another to represent a simplified blob of a shadow. The two textures (eventually) blended together to ensure the shadow only greyed where it should. Held up by naively tweaking renderstates and recompiling I eventually made this tool with the dx8.1 mfc app wizard as a starting point.

Screen shot
Source / Exe

The shadow technique worked really nicely in the end, modifying the size and position of the shadow with uv coords and blending over the pre-made tile texture... screenie. Nobodoy got to see it though as it was yet another canned project

Lot's of experience later and having a go at a producing a viable game engine (that includes renderstate management et al) I've not needed this tool since.

-Matt