Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    421981

TLM : The Falling out with D3D follow up

Sign in to follow this  
_the_phantom_

67 views

Hmmm, maybe I should goto town on D3D more, I seem to get more comments that way [grin]

Anyways, the comments about using PIX has been taken onboard and I'll be looking into that in a bit, but I figured before I do I'd make an entry to reply to a few points from the comments [smile]

@FReY
Last place I'll blame things on is a driver bug, the fact that ATI's R2VB samples work fine also kinda rule this out and point to me doing something wrong.

@jollyjeffers
The problem is that I'm NOT doing any sampling in the PS at all. The only thing being passed down is interpolated values which are then written out to the framebuffer.

The values themselves are coming from textures but these textures have been bound to vertex streams (1&2) to act as VBs.

Hmm, although you do have to bind 'fake' VBs to the streams as well to make sure D3D doesn't cry and I'm reusing the same one for all 3 sources (because I know it'll be big enuff to avoid the debug runtime yelling at me), I wonder if that'll effect things....

As for the RT stuff, it's not that it isn't simple it's just that it's annoyingly verbose to use and you have to execute the same series of function each time.
Let me compare for you (as I have it setup)
D3D:
Setup :
- Create textures at some point
Rendering:
- save old view port
- save old colour target
- get surface from texture
- bind to colour buffer
- set new view port based on surface size
- render
- bind back old colour target
- restore viewport
- safe release surface
- safe release old colour buffer surface

OGL:
Setup :
- Create texture
- Create FBO
- (optional) create render target for depth
- (optional) bind to FBO
- bind texture to FBO
- unbind FBO
Rendering:
- save old viewport
- set new viewport
- bind FBO
- render
- unbind FBO
- restore viewport

Two steps less over all and alot less in the rendering loop. FBOs also remember render target state so if you setup up say a 4 target RT in setup it'll automagically be configured when you bind the FBO. Give me something like this in D3D and I'd be happy [smile]

I'm sure that decls are fine with a decent FX system, however they just seem to cause pain when you are just knocking up a proof of concept and fiddling with things and don't have/want/need an FX system.

@Mars_999
JCD's GUI is nice and I've looked at it before, however like all GUIs it suffers from the 'zomg, use my classes, kk!' problem. Being forced to use someone elses texture and tuple classes when they could have just inforced an interface instead and let me use my own makes me twitch. I'm all for code reuse but not when it bloats out of control because you have 4 texture classes for 4 different libs all in different namespaces.

Worse comes to worse I'll just end up hacking it apart and re-engineering the bugger for interface instead of instances of classes. (Templates a-go-go).

The other thing which I couldn't work out was runtime binding of events, it all seemed somewhat XML hardcoded, which again made me twitch.

Anyways, I'm done, hopefully later tonight I'll have success to report... it's that or I'll be wacking D3D about the head until it's laying bleeding on the floor... [wink]
Sign in to follow this  


1 Comment


Recommended Comments

Quote:
Two steps less over all and alot less in the rendering loop. FBOs also remember render target state so if you setup up say a 4 target RT in setup it'll automagically be configured when you bind the FBO. Give me something like this in D3D and I'd be happy
Yeah, the verbosity of RtT in D3D is a pain. I wrote myself a wrapper class that handles all of it though such that code looked something like:


{
RENDER_TO_TEXTURE( pNewRenderTarget, pNewDepthStencil );

// Do render to texture stuff here
}


The RENDER_TO_TEXTURE() was just a macro to a class on the stack that did all of the defensive copying and state blocks in the constructor and then undid the changes in the destructor (the explicit scope block forces the stack object to be destroyed at the right time).

I did mean to post the above code in my journal, but it appears I never got around to it. I've got a whole bunch of these things kicking around on my HDD [rolleyes]

Quote:
I'm sure that decls are fine with a decent FX system, however they just seem to cause pain when you are just knocking up a proof of concept and fiddling with things and don't have/want/need an FX system.
Yup, can't disagree with you there. Now that D3D10 creates all its objects from struct's the code is getting more verbose unless you abstract it all away with some sort of caching/manager system - which is a bit of a bugger for PoC and simple apps [headshake]

Quote:
it's that or I'll be wacking D3D about the head until it's laying bleeding on the floor...
I know where you live... [evil]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now