Posts Tagged ‘direct3d sucks’


famous last words…confirmed

January 8, 2009

So I’m REALLY starting to freak out that maybe won’t get in to college.  Because while I’m certainly eligible, I got this crappy email that tells me: “yeah, you want a student loan?  this is your student ID, which you’ve had since before you were even sudo admitted.”  thanks for being clear, assholes.  I only have ONE WEEKEND to register for classes and get my fukken act together if I’m even in, which I don’t know, because they AREN’T BEING CLEAR.

Okay, thank you for your cooperation in terms of listening to a rant.  WAIT!  IT’S NOT OVER!  Some drunk fucker wandered in to our garage and started knocking things over!  Full story here.

But anyway.  Those it-should-be-easy-to-get-depth-targets-to-work-in-Direct3D last words?  Yeah.  Apparently, it can’t handle rendering to a depth texture, so you have to create a depth stencil render target.  But you can’t just use that.  Ohhh, no.  Apparently depth components can’t be reinterpreted without shaders.  This makes no sense, as OpenGL has had this capability FOREVER.  So it actually takes a simple pixel shader to copy from the depth target to a usable texture, a red only format texture.  Talk about clumsy and stupid.

So the long and short of it is that I now have to have two classes of rendertarget, (yes, even for OpenGL as I can’t break unified API,) one for color and the other for depth.  In OpenGL, it’s actually the same class with two settings.  In Direct3D, it’s two seperate classes.  pfft.  I don’t like it, but I’m pleased to say that the actual API needs only ONE outwardly apparent change.  The CreateRenderTargetTexture() method now has a new argument: targetmode, which can be RAVEN_RENDER_TARGET_COLOR or RAVEN_RENDER_TARGET_DEPTH.  The rest is transparent.

Sooo… yeah.  Workin’ on it.


big post + act finished + more 3D materials

January 3, 2009


I haven’t posted in forever!  This is because of the following:

  • One of my best friends is in a rather nasty jam, and I am helping him.
  • I’ve been a bit more depressed than usual.
  • I’ve been studying for the ACT.
  • I’ve been working hardcore on an elusive problem with getting text to work in Direct3D.  It is a pixel data problem.  More on that later.
  • I’ve been spending time with *sigh* family on the holidays.
  • Reading Isaac Asimov’s Foundation and Empire.  VERY GOOD SCI-FI YOU MUST READ.
  • Sleep disorders are worse than ever.

But hey, you know, life’s still good!  I keep telling myself that anyway.  So really.

I just took the ACT.  It was pretty non-descript, mostly because I didn’t have enough caffiene in my system.  I hope I was still well off enough to do a good job.  My initial response to that was “meh…I’ll pass.”  I don’t really care, as long as it gets me in to college where the real learning begins.

In RAVEN, I’ve gotten a few more material/lighting things working, and I fixed the lighting inconsistencies, at least I believe so.  Per vertex alpha and material alpha both work, depending on whether the UseVertexColor flag is on.  Textures are great.  Here’s a problem for you though, text doesn’t work in Direct3D.  I’ve narrowed it down to the part where I copy the pixel data to the Direct3D textures.  The texture mapping works fine, the textures are valid, and I’ve done some printouts / diagnostics to check to see if the data is actually there when I copy it to the textures, and the answer is yes, it is there.  So everything works… but the copy.  It’s even D3DFMT_A8, just like the text data I copy to it.  One byte per pixel, that byte is an alpha value, am I mistaken?  Lock…memcpy…Release…Index…Render…FAIL!  Just blank quads.  T_T  I don’t know what the problem is, but I do need to slaughter right now!

And yes, I can’t sleep!  This is pissing me off!  I’m an insomniac, but I’ve barely slept at all this past week, and it can’t have helped my performance on the ACT today.  Ah well… life goes on.

Umm… that’s just about it.  Anyway.  I’m resuming normal posting now.


new article wip Direct3D 9 on the fly geometry

December 22, 2008

I’m commencing work on a cool article regarding on-the-fly geometry code. In OpenGL it’s really a snap (glBegin(), glEnd(), glVertex(), glNormal(), etc.) but in Direct3D it’s fucking impossible. You cannot do any of it on the fly. You consolidate everything down to a single call, (a few complex ones for vertex buffers) that requires all this pain-in-the-ass setup, and it’s STILL less efficient. I don’t get you fucking people at M$. ARB can do it, so you definitely can.

But anyway… I created a little class called GeometryInterfaceD3D9. It takes OpenGL style on-the-fly commands, then does the work for you. It’s not really fully optimized to the extent you can with D3D, but it works, and emulates OpenGL very well. Just avoid quads at all costs, because while I technically added emulation for them (quad primitives not available in D3D9 wtf?) they are DEADLY SLOW. I could fix this with a bit more preprocessing, but for now it just does multiple calls to RenderPrimitiveUP(), so it is, as I said, ridiculously slow. THIS IS NOT THE FINAL ITERATION, I WILL FIX IT KAY ZOMG.

The reason was that the main Renderer class and children RendererOpenGL and RendererD3D9 were initially designed for these calls. Then I eventually realized that this is not how you do it at all with Direct3D. But I firmly believe that these on-the-fly geometry instructions are the clean way of doing the API. So, I accepted a less efficient implementation on RendererD3D9. Don’t worry about the lack of efficiency there. Just as VertexBuffer and VertexBufferVBO are efficiency optimized for OpenGL, VertexBufferD3D9 will be optimized for Direct3D. And of course, all the specific implementations are invisible to the user of the library, so it is important to add layers that unify the API. So far this is going well.

Anyway. I will add most of this above text to the article page, and also the code. Please check it out when it is complete.