Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Gyannea

Rapid frame rate within a Window

This topic is 5476 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need to "continuously" display small sections of two sound waves at a maximum of 100 times per second in two different windows. However, the regions (nice and rectangular) being updated will not occupy the entire screen but appear in an otherwise normal window. I was looking to Direct X to give me these update rates but am not sure what the most efficient means of implimentation would be. Can one define a backbuffer the size of the rectangle, use the "drawprimitive" function to draw the wave and then "present" the backbuffer into the appropriate region of the normal window? What is driving me nuts is handling WM_PAINT messages in this case. Normally I create a compatible bitmap and do all drawing into the bitmap and "blt" on WM_PAINT messages. One solution would be to create the entire windows on backplanes and refresh the entire windows every soundwave update, but that seems like a lot of waste. The goal is to minimize CPU graphics overhead as it will be occupied with some heavy duty DSP work. Not exactly gaming, but if gamers can''t do this, no one can. Any suggestions? Thanks Brian Reinhold

Share this post


Link to post
Share on other sites
Advertisement
For standard gdi operations when you only need to update some parts of the window, just call InvalidateRect with only the wanted rect. Call it several times for several rects. When you receive a WM_PAINT, just update the wanted rects (or simple repaint all, Windows will only update those rects - unless someone somewhere specifies to update the whole window).

Share this post


Link to post
Share on other sites
For standard GDI operations I use the compatible bitmap and update using blts on a WM_PAINT message. But this would be too slow and out of time if I used this method to update the section of the window that had the soundwave displayed in it.

The sound wave would be drawn by GDI "LineTo" function that does a whole series of points (forgot what it is called) after erasing the rectangle containing the current wave. This would be done every refresh (up to 100 frames per second). Then that would need to be copied to the screen. All of this seems heavy on the CPU. However, using DirectDraw3d I would like to use hardware for the graphics primitive Line draw on the backbuffer and then copy that onto the screen (also using hardware). The rest of the Window could use GDI stuff as that would be infrequent. Uing the video hardware for this sound wave redraw would free up lots of CPU for DSP work.

I would like to avoid doing the entire window update every 10 milliseconds...it seems an unnessecary overload. I am just not sure how to mix these two (GDI and Direct3D) or if they even can be mixed in this fashion.

Brian Reinhold

Share this post


Link to post
Share on other sites
You would want to look into GDI+. It comes with double buffering stuff and could optionally use directx interfaces if you intend. But that''s what I''ve heard, I''m not sure.

Share this post


Link to post
Share on other sites
UdayK,

I have not heard of GDI+ but it sounds like something that would only be available in the latest versions of Windows (XP perhaps?). On the other hand, if somehow GDI can be made to use Direct X features and device Dependent bitmaps that would be great. I don''t want to use the host CPU to draw the rectangle, draw the sine wave by connecting all the dots, and then copying the entire region to the screen 100 times per second (if I can avoid it)! That''s a lot of horsepower that could be used for DSP work.

Brian Reinhold

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
my suggestion would be to use child windows for your DX presentation. a static for instance could be used. the only thing you need to do differently would be to specify the top-level parent window as the focus window in the CreateDevice call. during rendering you could then use the Prseent call''s device window override parameter to switch between which child window gets the current rendering. there''s also source and dest rect parms on that call which could be used if necessary.

there''s SDK samples that show how to do this using one child window for an MFC application.

Share this post


Link to post
Share on other sites
The SDK does have an example of this? Good to know, I am looking, but there are MANY examples and its hard to tell from the names which one that might be. I hope there will be one NOT in MFC as that hides everything and I don''t want to use it (MFC).

Is this only possible in a child window, not directly to the parent?

Maybe parent Window as compatible bitmap using GDI and API for user interaction and WM_PAINT but

Backbuffer Direct3D for rectangular region needed updates that is then ''presented'' into the main Window?

Not so sure that can be done. All Windowed examples I have seen so far concern entire Windows blitted onto the display, not just a section of them (the hardware takes care of it).



Brian Reinhold

Share this post


Link to post
Share on other sites
Metus: I''m not sure, but I successfully compiled and ran a GDI+ application on w2000 and I didn''t care about w9x. May be I had certain GDI+ components installed that I was not aware of.

Gyannea: If you plan to achieve 100 fps without bothering your CPU too much, you will have delve into some really good optimizations.

I would therefore recommend that you use your GPU as much as you can. And that too a good one . You don''t have enough control if you''re on a fixed-function pipeline. So there have to be some additional areas where you should look for optimizations.

You could for example, keep your viewport area small. Additionally you can perform checksums on your dsp data to check if something has changed, and only perform the drawing-process if you see a difference, further, some minute changes may be ignored all together. But still, you have to perform profiling to know that it''s actually helping the process instead of just uselessly eating up cycles.

Goodluck
UdayK

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Gyannea
The SDK does have an example of this? Good to know, I am looking, but there are MANY examples and its hard to tell from the names which one that might be. I hope there will be one NOT in MFC as that hides everything and I don''t want to use it (MFC).

i''m pretty sure that all of the samples that have a DX window within a parent GDI window are all coded with MFC. look for the MFC Fog or Effect Edit samples if you''re still interested. (btw, i''m assuming DX9 SDK here?)
quote:
Is this only possible in a child window, not directly to the parent?

you can do this directly to the parent as well if you want. it''s just normally easier to use a child window since that helps keep things separate, especially if you want to use OO window wrappers.
quote:
Maybe parent Window as compatible bitmap using GDI and API for user interaction and WM_PAINT but

Backbuffer Direct3D for rectangular region needed updates that is then ''presented'' into the main Window?

Not so sure that can be done. All Windowed examples I have seen so far concern entire Windows blitted onto the display, not just a section of them (the hardware takes care of it).


here''s a quick bit of code to try out. first, assuming you have VC++ and have installed the SDK properly, you should be able to generate a new VC++ project using the DirectX App Wizard. just keep selecting Next until it''s greyed out then select Finish. assuming you are able to do so, go to the
 CD3DApplication::Render3DEnvironment() 
function and replace the "hr = m_pd3dDevice->Present( NULL, NULL, NULL, NULL )" line with the following code:

{
#include <math.h>
const int numRC = 3;
const int numVP = numRC*numRC;
static int curVP = 0;
RECT cRect;
GetClientRect(m_hWnd, &cRect);
int widthVP = (cRect.right - cRect.left)/numRC;
int heightVP = (cRect.bottom - cRect.top) /numRC;
int curCol = curVP % numRC;
int curRow = curVP / numRC;
RECT dRect = { widthVP * curCol, heightVP*curRow,
widthVP *(curCol+1), heightVP*(curRow+1) };
hr = m_pd3dDevice->Present(NULL, &dRect, NULL, NULL);
if( ++curVP == numVP )
curVP = 0;
Sleep(1);
}

what this will do is present numRC^2 viewports of the same render, with each new frame drawn to the "next" viewport. if you play around with the code you should be able to have some of the viewports not drawn, which would then expose any underlying GDI paint processing.

HTH.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!