Jump to content

  • Log In with Google      Sign In   
  • Create Account


Read render picture from another application


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 rongshuxiacy   Members   -  Reputation: 122

Like
0Likes
Like

Posted 15 November 2012 - 09:50 AM

does anybody know there are apis about reading the rendering picture from a game application like War3 in windows?I want to make an application which is just like a video recording software record the game screen to a file.are there any apis?

Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8178

Like
2Likes
Like

Posted 15 November 2012 - 11:58 PM

The traditional way of doing it is to literally hook your own code into the rendering code for the game application in question. Basically, immediately before the game draws the final image to the screen, insert some code which'll allow your own application to access it easily (like initialize some shared memory and store the frame there, or something like that). This is how FRAPS does it. It is not trivial, but it's doable. See "directx hooking" on Google.

Other than that, no, I do not believe there are any ready-made API's that'll do what you want. There are window capture functions in GDI, but DirectX/OpenGL windows typically evade those (you only get a black screen) and they are not very efficient.

The crux of the problem being that if you want to get a reasonable recording framerate, you need to capture the game's backbuffer, not the global frontbuffer (which is subject to locks and stalls, and is just generally sucky). Of course you can just bitblt the hell out of it, but don't expect the performance to be up to far with software like FRAPS, or to even work properly at all.

Edited by Bacterius, 16 November 2012 - 12:00 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS