Screen capture
Jens Pedersen
I have an windowed application with static vertexes and changing texture data.
The application runs on one specific known hardware platform with a shared
memory GPU
The textures are updated with a rate from 5 to 40 times a second.
A render thread updates the textures with uniform interval and calls Present.
It is important that the images updated with uniform intervals.
The image size is appr. 800 * 800 pixels.
At the same time I want to capture part of the screen including the window
with the application image and some more.
The capture area is appr 1000 * 800 pixels
The capture should be done with a rate of at least 15 Hz.
I have seen a couple of different methods for screen capture.
One is to use the DirectX method GetFrontBufferData. Stated as slow in the
documentation!
The other is to use GDI methods and BitBlt screen data to a MemDC and then
get the data with GetDIBits.
I guess both ways of reading the screen memory in some way disturbs the
rendering in the GPU.
Now come the questions.
Which method will disturb the least? Give smooth rendering
Will it be best to set the DirectX PresentationInterval to
D3DPRESENT_INTERVAL_IMMEDIATE
or D3DPRESENT_INTERVAL_ONE to get a uniform display of the images?
Should the screen capture be synchroneous to the rendering - done in the
render thread -
or can it just as well be done in a separate capture thread?
--
Jens
BK Medical
Richard [Microsoft Direct3D MVP]
=?Utf-8?B?SmVucyBQZWRlcnNlbg==?= <JensPe...@newsgroup.nospam> spake the secret code
<5D54E2C5-F2E2-42B5...@microsoft.com> thusly:
>I have seen a couple of different methods for screen capture.
>One is to use the DirectX method GetFrontBufferData. Stated as slow in the
>documentation!
>The other is to use GDI methods and BitBlt screen data to a MemDC and then
>get the data with GetDIBits.
>I guess both ways of reading the screen memory in some way disturbs the
>rendering in the GPU.
The way to read back data from the graphics card is to use
GetRenderTargetData on the back buffer before calling Present.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Jens Pedersen
area I render with
my windowed DirectX application. And I want the cursor to be captured also.
So GetRenderTargetData is not enough.
--
Jens
BK Medical
Paul Roussin
an hour so what I write here is not vigorous and is very empirical. However
it may take you where you wish to go. I suspect (using weak words on
purpose) that you can capture anything on the screen including movies etc.
If all you wish to do is capture then look into using DirectX 7's DirectDraw
(not the D3d stuff). That does not mean you have to change your other D3d
device. I am assuming your capture can be independent of your render code.
Perhaps you can use both devices from the same program (that is what I would
try).
While playing around with my stuff I discovered that in DirectDraw I could
read or write any place on the screen and even write over other windows. In
other words I was drawing outside of the Window I thought I was supposed to
stay within. I was not interested in that use of DirectDraw. I was
investigating a screen camera and was only interested in capturing what it
was drawing into my own software. I wanted to detect pigeons on my roof :).
Writing outside of that window was discovered accidently for my errant code
was painting on to a Visual Studio window. When I moved Visual studio it
carried my paint along with it :).
It may work for you. There are some free screen capture utilities that can
capture your activities and I suspect they may be using DirectDraw. I would
avoid them because I want to control the bits that I capture and place them
where I want them. However if you only want a movie then they may work well
for you.
Keep in mind you can't call DirectDraw with interfaces from DX9 but I assume
you are already aware of that. That does not mean direct draw can't read
what you are actually placing on the screen from a higher version of
DirectX.
I am not certain of what I write here, but if I wished to read any place I
wished on the screen then I would investigate DirectDraw further. I am
confident I can do it, but don't know how to tell you to do it at this
point.
Directdraw is very fast (on very fast cards:)), the slow downs will come
from what you do with the data.
I have not played with the Microsoft screen capture stuff.
Paul
"Jens Pedersen" <JensPe...@newsgroup.nospam> wrote in message
news:5D54E2C5-F2E2-42B5...@microsoft.com...
Richard [Microsoft Direct3D MVP]
=?Utf-8?B?SmVucyBQZWRlcnNlbg==?= <JensPe...@newsgroup.nospam> spake the secret code
<88CD8747-0D58-4B8D...@microsoft.com> thusly:
>Fine, but the problem is that I have to capture more of the screen, than the
>area I render with
>my windowed DirectX application. And I want the cursor to be captured also.
>So GetRenderTargetData is not enough.
If you operate windowed, then just use Win32 to grab the desktop
contents after you call Present. I don't know if that includes the
cursor, but you can probably overlay that yourself without much trouble.
Jens Pedersen
Could you be a little more specific about where I can find something about
DirectDraw as it is in DirectX7
I have tried to look at Mircosoft library but could not find anything.
What interface procedures did you use?
--
Jens
BK Medical
Paul Roussin
still uses DirectX 7:).
DX7 is great for 2D work. It takes many steps to get up but once there you
would like it.
You may be able to find it in an old book CD.
Take a look here: http://www.gamedev.net/reference/articles/article608.asp
You get an IDirectDraw interface.
Use that to create a surface and get its interface.
You can use the surface functions to draw on that surface.
Then there are several functions to present that surface onto the screen.
Blt, or Flip. One is for full screen and the other is for windows.
I don't remember how I got the screen data. Perhaps I had an hDC to a screen
window. I may have used an hDC from the Blt call and it may have been the
screen ??????. I suppose it has to be an hdc to the screen that is where
the surface is blitted to.
I remember locking the surface and was able to read and write the screen.
Also if you get an hdc using GDI and an hdc using a directX surface, then
you can move data that way. You may wish to play with that while you are in
DX9. I've never written of read the front buffer. That would be a really
fast test. Perhaps I will do that with my movie grabber and tell you what
the results are. I am throwing out too many options. I am not an
encyclopedia nor an expert. When I work I list out areas of investigation
and go exploring. That has its rewards and pitfalls the pitfalls being that
empirical data can lead to misunderstanding or imprecise knowledge.
The problem with my memory was that I was capturing calls and using someone
else's interface so I am a little unsure of exactly what I was handed. It
was a while ago.
I think you can find samples and tutorials that will take you 99% of the way
there and you can discover how to read the screen.
I can install a screen grabber movie maker type of program and then use my
movie grabber to capture the calls it makes if it uses DX7. I am kind of
busy at the moment.
Search Google for "DirectDraw", "DirectDraw Help", "DirectDraw tutorial"
etc.
As to the sdk any advice other than finding an old CD is inappropriate for
this newsgroup.
"Jens Pedersen" <JensPe...@newsgroup.nospam> wrote in message
news:D87BD4D6-CF89-4311...@microsoft.com...
Paul Roussin
a compliant DX7 help file.
I have other thoughts using DX9 but they are too questionable or
experimental to post here. I would have you zigging like a laser beam in a
jewelery store. I will try one of them myself and if I succeed I will post
back.
Best to you,
Paul
WenJun Zhang[msft]
Just wonder if you have any further question on this issue?
Have a nice week.
Sincerely,
WenJun Zhang
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.