Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Aug 2009
Offline Last Active Oct 28 2014 03:02 PM

Topics I've Started

Blting DX9 textures to GDI, editing, and blting back

06 July 2014 - 07:31 PM

I'm looking for info on directly editing height and splat map data. My initial thought was that GDI with it's premade brushes would be an asset. So I set about learning what i needed from GDI to get the DXTexture into an HDC for use in a window.I've used BltBit which copies the entire Pixels RGB data from the dx surface into the HDC of my window.


I would prefer to copy a single SRC channel ( R,G,B,or A for the splat layers(1-4)), leaving the rest of the DST bitmap black. After a brush has affected the bitmap, I intend to copy the single channel back to the initial DXTexture, which is used as a splat map in my terrain viewer(hopefully editor)


Another thought was skipping GDI directly, and and implementing brushes in DX(unless they exist in an area i'm not familiar with) using pixel shaders, and modifying textures directly that way.


I'd appreciate a nudge in the right direction, if anyone has a spare moment.

Alan Turing

10 June 2014 - 07:57 AM



Anyone else catch this in their news feeds today?

Siggraph 2014 Vancouver

30 May 2014 - 06:11 PM

Anyone attending? I just noticed this was in Vancouver, and though it's about 600 mi away, or 1000km for we metric folk, the thought crossed my mind about going, as I will have a steady income this summer and will not need to slave away at a 9-5 position for a few months. I've never attended an event like this and would like to know if it is worth the trip.



DX9 with MRT, access violation

01 May 2014 - 11:12 AM

So I'm attempting to work with deferred rendering for the first time, and I'm having issues with access violations. I am currently trying to distill the problem down to a short example, so I don't have much code to show at the moment.


1) I create 4 textures using device->createTexture() all using the same width, height, mips,  format, and usage(d3dusage_rendertarget);

everything seems to work ok on that front.


2)  I bind the 4 targets to slots 1-4, and render a simple cube.


3) after rendering the gbuffer, i set RT0 to the backbuffer of my swapchain, and render a quad for the light.


4) when i call present it fails.


so I scrap that, and try to figure out if something is wrong pass by pass, so after step 2, I try and write out each texture surface to a bmp file and check the results. on the second pass it crashes when trying to save the surfaces. looking at the rts from the first pass, my object is not being drawn to any of the targets. If i don't save the surfaces, I can render a few frames before I end up with an access violation while rendering the cube(right after locking the dynamic VB), which has me even more confused, as I've never had an issue with my object cache before.


EDIT: if i don't render anything(just clear buffers) everything seems to be ok, I can save the buffers which have been cleared to pink, and I can see the backbuffer, which i clear to a time dependent color, working as intended.


Does anyone have any ideas I can run with at this point? Helpful would be a short example, or insight as to why i would get an access violation, that seems to shift around in the code.


As I said above, i'm trying to distill the code down to a simple example without any of my framework code in that may be causing the issue(though it works fine in all other demo projects I've used it in). d3d9 tutorials with multiple render targets are few and far between(I've yet to find one that is c++, to be honest) and MSDN doesn't yield much else.

HLSL postion only semantic, no color

25 April 2014 - 05:11 PM

I'm encountering a weird issue that I'm having trouble understanding.


I'm using DX9, and am attempting to render a position only vertex. in the vertex shader. In the vertex shader stage I add a COLOR0 semantic to the output, which I fill in with float4(y,y,y,1) where y is the world space position of the vertex. In the pixel shader I just output that color. I am getting only white, no matter what height of the vertex.


However if i set the color to (1,0,0,y) I end up with the vertices colored properly, with variation between  Black -> Grey -> White with a world space y of <0 -> 0..1 -> >1. I'm perplexed, as this is the output I'd expect from shader described in the previous paragraph, while i would expect the range from black to red with this.


So I'm pretty sure the vertex shader is working, but the pixel shader is not getting, or not using the correct value. Is this due to the vertices' declaration as a position only vertex? If so, can anyone explain why?


I know I can add the COLOR0 semantic to the vertices vertex declaration, and bring it through the shader stages if necessary, I just can't comprehend why I should need to in this situation.