Jump to content


Member Since 28 Oct 2007
Offline Last Active Apr 25 2013 09:16 PM

#4955550 Help me understand how to hook DX application, to copy screen buffer

Posted by Shuun on 04 July 2012 - 01:31 AM

I also would question why your trying to do this? Typically this is the type of thing game hacks do, which I am willing to guess is exactly what your trying to do.

But a quick google search produced the following: http://spazzarama.co...ct3d-api-hooks/

Copying screen buffer is not a hack, it does not change or automate any of the behaviour of the software, if doing that would be considered hack, then using things like fraps or any other screen recording software would be bannable offense.

I know about that spazzarma api hook, but its overly bloated with extra threads, and probably even changes running application by running CLR runtime host on it, and i dont want that. Also requires your assembly to be installed in GAC.

#4955533 Help me understand how to hook DX application, to copy screen buffer

Posted by Shuun on 03 July 2012 - 11:33 PM

Why don't you simply use detours.

Why would i use complete library only to install a hook to 2 functions? Its also not free for commercial and limited in express edition, lets not be ridicilous here.

#4955005 Help me understand how to hook DX application, to copy screen buffer

Posted by Shuun on 02 July 2012 - 01:17 PM

I'm developing application in C#, and i'm currently strugling in finding the general correct steps required to sucessfully hook DX function in order to send screen buffer to my main application for some processing.

Here is a list of what i think i should be doing so far:

1. Attach a custom C++ dll into target application, from my main application (written in C#)
2. DLL hooks some (Device Present and Reset) functions in d3d9.dll that is loaded in target application.
3. After even occurs, i need to send a callback event from the custom dll to my main application, containing the screen data

Can someone please correct me where i could have gone wrong and help me with point 3? I'm not expirerenced in dll callbacks, let alone not a C++ interop guru and im having a trouble understanding how i could possibly have a callback to my main application from a C++ dll loaded in another application.

#4886201 Client position and the unreliable nature of networking

Posted by Shuun on 21 November 2011 - 08:16 AM

Client: I started moving from X, to direction Y at time Z
Server: OK, as your speed is S and time passed from Z is T, your position X0 is now X+Y*T*S
Client: As you say.

Dont accept or deny anything from client, just take the input and update client according to game server rules.

#4873024 Tile based forward rendering?

Posted by Shuun on 15 October 2011 - 08:20 PM

Hi! I would like ask opinion on idea, because i don't want to waste my time implementing something that is stupid right from the start.

Story is i don't want to do deferred because i love and need transparency, max amount of possible materials and anti-aliasing plus dont have time to implement sophisticated systems to get that kind of things to work well with deferred.

Im using DX 11 only.

So im thinking about this:

1. Render all scene depth only
2. Calculate view-space minZ-maxZ value for each tile (one tile could be about 16x16 pixels) in compute shader
3. In compute shader- calculate for each light what tiles it intersects and add light index to that tile
4. Render scene normally and light like this:
4.1 Determine what tile this pixel lies withing
4.2 For each light index in tile light list -> lookup it from the global light table and calculate lights

I know there is this: http://visual-comput...rred_rendering/ but it still uses G-Buffers.

#4786565 Effect vs Fixed Function Pipeline, Massive Performance Drop

Posted by Shuun on 16 March 2011 - 09:29 AM

Well, without seeing what you're doing here are a few suggestions:
1. Batch
2. Make sure you're using the handle functions for your variables, and not the ones that take the name. Cache the handle as well.

Dont batch. Live EVER. Unless you have like 5000 draw calls or 20000 SetX.. Calls or that batch is very trivial. Just write simple nice code, thats not to fanatic about "not giving a damn" and have nice balance.

How many objects are you drawing? Whats your GPU? Have you updated drivers? Can i see your draw code? That may give you correct answer.It may also be your shader, as i could guess, if you are writing from fixed fuction to shader then your hlsl and general shader usage knowledge probably is not of high levels, so you could make some small mistake or skip some very obvious optimization here and there and that could give you that performance difference versus fixed function.

#4786562 What should I be looking for if there's a resource leak in PIX while debu...

Posted by Shuun on 16 March 2011 - 09:25 AM

Look at destruction time, if it says "Never" then you did not release object.

#4767944 Batching and minimizing DIP's and state changes

Posted by Shuun on 01 February 2011 - 08:03 AM

It have come to my attention that although general rendering performance guidelines suggest minimizing draw call count and render state changes, most big AAA tiles do only very minimal optimizations on this or no optimizations at all, for example i PIX'ed few popular games to see whats up:

Mass effect - ~1000 draw calls per frame, 20000(!) render state changes and ~1000 draw primitive UP calls per frame
Civilization V (DX11) - 3000+ draw calls, thousand or so set pixel/vertex shader, 500+ set texture, etc per frame on average

Whats up with this nonsense? Why none even bother to do some optimizations on this matter?

#4586244 How does WoW's terrain generation work?

Posted by Shuun on 11 January 2010 - 06:44 AM

I have made exact copy of WoW like terrain renderer that can also display WoW terrain in past. Basically you have chunks of 9x9 vertices arranged in vertex buffer like VertexBuffer contains (chunk1Vertices, chunk2Vertices, etc) and have variations of index buffers for each type of transition so you can display lower triangle counts using same vertex buffers. Note the X pattern.

Each chunk have maximum of 4 textures assigned for it - they are using for splat mapping (multitexturing).

Also i can suggest that you store all the information you need in just one single Vector3 Position like this:

CPU - main memory will have information for each chunk like:
4 textures (ID, hash or similar lookup)
Vector3 base position - this will be position where X and Z coordinates (left handed system) are your chunk top left corner in game world and Y coordinate is average vertex Y position in chunk

GPU - video memory will have information like this:
VertexBuffer - only one Position (Vector3) is needed - you store your Vertice Y position RELATIVE TO BASE Y in X component and have texture coodrdinates, ranging from 0 to 1 stored in Y and Z components of your position so in vertex shader you can construct your position like this:

float3 outPos;
Pos.Y = shaderInputBasePos.Y + inPos.X; //relative height stored in X of Position
Pos.X = shaderInputBasePos.X + inPos.Y * CHUNK_SCALE; //Texcoord component used to offset vertex position X
Pos.Z = shaderInputBasePos.Z + inPos.Z * CHUNK_SCALE; //Texcoord component used to offset vertex position Z

float2 outTexcoodrd;
outTexcoodrd.X = inPos.Y * TEXTURE_SCALE;
outTexcoodrd.Y = inPos.Z * TEXTURE_SCALE;

For loading/unloading you group say 8x8 chunks together and load/unload them when you are in range. DONT create or destroy vertex buffers in runtime, you will have say, 2x2 or 3x3 groups in sight range at once so you will only need to replace old data in vertex buffer (only X value of your position if you use technique i told) with new one when old disappears and new appears. Also you replace your old splat texture with new one for texturing so the rendering of stuff comes together like this:

foreach visible chunkGroup
set splat texture to chunkGroup splat texture

foreach visible chunk in current chunkGroup
set basePosition for vertex shader
set 4 diffuse textures for pixel shader

RenderCHUNK(): vertexBuffer = chunkGroup vertexBuffer,
indexBuffer = calculated LOD for current chunk,
vertexOffset = current chunk vertex offset,
vertex & tris count = chunk vertex & tris counts (constant)