10 replies to this topic

[Veil]

I know that in Allegro it's

BITMAP* tex[10];
int& pixel(BITMAP* bmp, int x, int y)
{
    return ((int**)(bmp->line))[y][x];
}

but what's the syntax for this in DirectX?

[jamby]

You need to call Map() on the texture to get access to the texture data. Don't forget to call Unmap() afterwards. You will have had to create the texture with the proper flags to be able to write to the texture.

ID3D10Texture2D

[Veil]

You need to call Map() on the texture to get access to the texture data. Don't forget to call Unmap() afterwards. You will have had to create the texture with the proper flags to be able to write to the texture.

ID3D10Texture2D

wait will this work on directx 9?

edit:IDirect3DTexture9 has LockRect() method,but I'm not sure exactly how to use it,could someone explain it's arguments:

[in]   UINT Level,
  [out]  D3DLOCKED_RECT *pLockedRect,
  [in]   const RECT *pRect,
  [in]   DWORD Flags

Edited by Bogomil, 31 May 2012 - 04:08 PM.

[mhagain]

Map/Unmap are only present in D3D10 and 11, and - yes - the OP did tag the question as [D3D9].

For LockRect you should look at the documentation in the SDK - also available here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205913%28v=vs.85%29.aspx

If you have any specific questions about it's usage (which can differ depending on what exactly you're trying to achieve), it would be best to ask them after reading the documentation and experimenting a little with it.

[jamby]

the OP did tag the question as [D3D9].

Hmm...sorry. Never saw any tag because they don't show on the "Interesting Topics" list on the home page where I saw the thread.

[hupsilardee]

Also be wary that it won't let you LockRect on textures that were created in the default pool, or created - D3D9 is full of these little special cases and corner cases and vendor-specific features and the nightmare that is D3DCAPS9, thank goodness for D3D10+ restoring sanity to the API

[InvalidPointer]

Since this hasn't been asked yet, I'll go ahead and bite the bullet: What Are You Doing, Really? Any time the subject of CPU readbacks come up, there's like a 90% chance a better way to do what you're trying to accomplish exists.

Edited by InvalidPointer, 31 May 2012 - 08:10 PM.

[Veil]

Since this hasn't been asked yet, I'll go ahead and bite the bullet: What Are You Doing, Really? Any time the subject of CPU readbacks come up, there's like a 90% chance a better way to do what you're trying to accomplish exists.

Well,I have a server program that sends to the client a data struct with info for the current terrain piece.The info is generated randomly by the server and sent to the client,so I want the client to draw a terrain blendmap with the info from the received struct and then use the blendmap in the shader.This only happens when the client receives a new terrain piece(the player walks into a new zone)or when he burns the ground or something.Still it's not every frame,so I suppose it shouldn't cause a noticeable slowdown?

[Bacterius]

Since this hasn't been asked yet, I'll go ahead and bite the bullet: What Are You Doing, Really? Any time the subject of CPU readbacks come up, there's like a 90% chance a better way to do what you're trying to accomplish exists.

Well,I have a server program that sends to the client a data struct with info for the current terrain piece.The info is generated randomly by the server and sent to the client,so I want the client to draw a terrain blendmap with the info from the received struct and then use the blendmap in the shader.This only happens when the client receives a new terrain piece(the player walks into a new zone)or when he burns the ground or something.Still it's not every frame,so I suppose it shouldn't cause a noticeable slowdown?

The client really should be the one generating this stuff, sending actual assets over the network isn't the best use of bandwidth (of course, maybe you have something different in mind, but from what you said it sounds like an overly complicated method to do things)

[Veil]

The client really should be the one generating this stuff, sending actual assets over the network isn't the best use of bandwidth (of course, maybe you have something different in mind, but from what you said it sounds like an overly complicated method to do things)

The thing is,the terrain must be persistent and stay on the server and during the game players can affect and change it from time to time,but it's not really a problem - each zone has a tileset and each tileset has 8 different terrain types,so that's 0-7(3 bits for the tile type) and same for the tileset - 8 tileset types.

The point is I have to get the client to turn this received info into a blendmap pixel by pixel when receiving the terrain chunk data.

Edited by Bogomil, 31 May 2012 - 09:54 PM.

[InvalidPointer]

Dumb idea, but you could try drawing a point list for all updated tiles. This won't introduce any pipeline bubbles but could conceivably do the scattered write you want.

(I assume the blendmap is a 1:1 texel:tile map)

Edited by InvalidPointer, 01 June 2012 - 08:47 PM.