Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 23 Feb 2005
Offline Last Active Sep 12 2012 07:21 PM

Posts I've Made

In Topic: Rendertargets + viewports and device caps in Direct3D11?

11 September 2012 - 02:16 AM

thanks for your fast answer. Very helpful links. Helps a lot to know I can stop looking for device caps. Most of our "design" for that part consisted of pretty much copying the device caps structure from D3D9 and renaming it, so I guess I'll finally go over that again and try to find some compromise between the two.

I currently don't have any idea for what I'd use the "different viewports for different primitives" feature, but it's definitely good to know. One thing we're looking forward to is getting to play around with geometry, domain and hull shaders and all the new stuff in D3D 10 and 11, so perhaps I stumble upon a use for that feature then.

In Topic: [solved] output gets "corrupted" when window size changes

19 June 2009 - 02:13 AM

Once again, a stupid oversight ruins the day.
I forgot to change the depth stencil buffer's size accordingly. My initial problem is solved, I guess, so I'm renaming the thread, too.

However, I have a new problem.
At startup, I'm back to getting the results I want, i.e. something like this:

But, as soon as I resize the window, this happens:

Sorry, I seem unable to get any kind of image posted :(
This is the exact same problem I had with my previous implementation that created a backbuffer with the size of the client window. It seems that some portions of the window are just not updated. The portions that aren't updated change when changing the window's size and remain constant between size changes.

Any clues?

Edit: Again, stupid oversight. I set the Z-value to clear to in the Clear call, but forgot to add the D3DCLEAR_ZBUFFER flag... Feel free to delete this thread entirely, as it just comes down to being blind due to hours of programming.

[Edited by - matches81 on June 19, 2009 8:13:38 AM]

In Topic: Short question about quadtree frustum culling

10 January 2009 - 06:25 AM

Setting y to 0 in the plane equation basically changes the plane you're representing. For example the plane represented by 1/sqrt(3)A + 1/sqrt(3)B + 1/sqrt(3)C + 1 = 0 is a completely different plane as 1/sqrt(2)A + 0 + 1/sqrt(2) + 1 = 0. Both have a distance to the origin of 1, but that's it.

My guess is that you would have to project your frustum to 2D and use that for your culling purposes, but I also think that thias isn't exactly worth it. I'd set the min and max Y values for the AABBs in your quadtree to the min and max values of your terrain and continue to use the 3D test.

In Topic: HLSL if-statement

07 January 2009 - 09:08 PM


The Error is/are in my program:

...\phong.fx(76): error X3500: asymetric returns from if statements not yet implemented
...\phong.fx(85): ID3DXEffectCompiler::CompileEffect: There was an error compiling expression
ID3DXEffectCompiler: Compilation failed

I can't do anything with this description.
I compile the Shader with the (managed) function Effect.FromFile ( Shaderflags.Debug)

My guess would be that the compiler doesn't like it if your "if" branch returns something and your "else" branch does not.
Simple test for that would be to put an "else" before your final return statement.
I'm just guessing what could be meant by "asymmetrical returns from if statements", though.
If that isn't a solution at all or not for your case, I'd just go with Viik's solution.

In Topic: rasterising a line

01 January 2009 - 10:26 PM

Original post by luca-deltodescowhen converting from float to int, it simply removes the fractional part of the number; for positive numbers this acts as taking the floor, for negative numbers this acts as taking the ceil.

True, sorry for the inaccuracy.

Btw, I got it working, although I still use floats.
The problem was that I calculate 'restStepX' / 'restStepY' before I adjust the direction's length, leading to bigger values than expected. So, simply swapping these two lines:

float restStepY = errorX*dir.y;
dir /= dir.x;


dir /= dir.x;
float restStepY = errorX*dir.y;
(same for the slope > 1 case, of course)
fixed the problem.