Jump to content
  • Advertisement
Sign in to follow this  
Josheir

Slow 2D Game using DirectX 2010

This topic is 511 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

 
This is sort of an addendum but not really.
 
I bought an acer laptop to develop a 2d graphics game so I would be using windows 10 and the 
new visual studio for c++.  The problem is the graphics is integrated (built in.)  Am I doing something 
wrong because these are the frame rates from the program:
 
 
 
Dell            : 6.3 frames/sec
Emachine   : 4.2 frames/sec
Acer           : 3.8 frames/sec
 
 
 
///////////
 
Acer data:
 
Aspire E 15 E5-575-72L3
 
Adaptor:  Intel hd graphics 520 up to 4160 MB Dynamic Video Memory
 
8GB ddr4 memory
 
graphics memory 4160 mb
dedicated memory 128 mb
system video memory : 0 mb  ?
shared system memory: 4032
 
Intel core i7 6500u 2.5 ghz with turbo boost up to 3.1 ghz
 
1000 gb hdd
 
//////////
 
 
I was wishing that it was the virtual drive slowing it down but I don't think so.
 
 
Someone said that built in integrated graphics support would be sufficient for any 2D game so I 
didn't buy the discreet card.  I wish I had.
 
 
I am looking at code that is very old and not that great.  I was writing to the hard drive which 
was slowing it down to debug and I am hoping that I am doing something else wrong to slow it down.  
 
 
Does anyone know of a program/feature I can use to see the time spent on each line of code or even 
a function so I can analyse what is going on?  Something easy to use maybe stepping through it and 
displaying?
 
 
I put some test statements in the program and blitted 3 more of the same image in the loop onto the 
screen to see the affect and there really wasn't any.  So I don't know whats going on here either.  
Changes don't really seem to affect the games speed?  
 
 
The program waits for a key press blits a few times presents the display than goes through a 
hundred or so if then statements with minimal usage and then does the whole thing over again and again.  
I am using directx SDK from 2010.
 
 
I am also confused that when I play the game Blackhawk Striker 2 there must be 100 images on the 
screen with all the bullets and so forth and it is running fine as a windowed application.  This 
seems to be about as complicated or more so with all the movement and collisions and comparable
enough (blits 2D and  if then else )!  IF THEY CAN DO IT THAN WHY CAN'T I ?  Did they use assembly or
something?  However I do have about the same speed with however I change it, so maybe I can keep
adding to it and the way it works is it keeps a constant rate?  That's what it seems like?!?!?
 
 
Or I was thinking it is using three D graphics library instead of the deprecated ddraw library and 
its quicker.  However it's an old game though.  In my opinion if this displays fine so should mine 
right?  What is going on?  Is there a way I can reprogram the display/graphics for better speed?  
I'm using directX from 2010.
 
 
Another example is half life is running fine on an old windows 2000 computer without any gpu and it 
has got to be more complicated than my simple adventure game and it runs fine too?  I know its not 
a 2d adventure game but isn't it even more so?
 
 
I am pretty angry about the frame rate of my game hopefully I am doing something wrong.
 
 
Another thing is that I noticed is that there is no difference when running the game using a 
display of 32 or 16 bit color depth (the images have all been changed to 8 bit.)  This seems odd to 
me.  I tried to change the color bit depth to 8 for the display but there were problems for the 
computers that supported it, however I don't want to reprogram the loading and displaying if it is 
not going to make a difference.
 
 
The one good point is that for people playing my game if their using an integrated card I know what 
they can expect.  It is barely adequate and I was hoping I would have some leeway with a gettime 
function and some sleeping in the loop.  
 
 
Which leads me to my last question : how do I determine the required processor to run the game?
Like I said the Acer is barely adequate.  On the other hand I'm hoping that the Acer is about as slow as
it will get (in a way)  so that all the computers out there would not have problems with the speed.  How would
the other computers stack up?
 
 
 
Angry.  Thank you,
 
Josheir
Edited by Josheir

Share this post


Link to post
Share on other sites
Advertisement
Does anyone know of a program/feature I can use to see the time spent on each line of code or even a function so I can analyse what is going on? Something easy to use maybe stepping through it and displaying?

The term you're looking for is "profiling".

Basically, you compile the code with profiling enabled, which injects code into the program so it knows where it is. When you run the program, it generates a profiling log, basically a dump of sample points in the program, taken at some fixed rate.

Afterwards, you convert that dump to a readable list of functions, so you can see the general call patterns between functions, and the (approximate) amount spend in each function.

 

That should give you some idea where to start looking for the problem. I don't use it often, but from experience, I can say, the problem is not where you expect it, and it's often something very stupid and easy to fix. (I hope the latter is true for you as well.)

 

Good luck!

Edited by Alberth

Share this post


Link to post
Share on other sites

Well I wonder if an if than else statement is say 1000th of a second and there are more than 100 that would add up.  I guess I need to contain them better in other if than else statements (3 sections) really which should be an estimated double performance.

 

For some reason I had 35 fps in my head as being normal.  Which I guess is not normal for adventure games.

 

It is amazing that a graphics card does all this work and gets the frame rate of 35 - 60 for much more complex displays and my processor is having trouble keeping up with if then else statements.

 

That's what I think for now (does this sound right?),

 

Josheir

 

 

Maybe there are some optimizations that could also be done with the compiler?

Edited by Josheir

Share this post


Link to post
Share on other sites

100 if statements will execute very quickly. its HIGHLY unlikely that is your issue.

 

a using profiler, or profiling your code with high resolution timers will tell you where your code is slow.

 

1. profile to find the slowest part.

2. figure out whats wrong with it (if anything)

3. fix it (if it needs fixing)

4. check you FPS. if its not fast enough, profile to find the next slowest part, and repeat the process until you're fast enough, or you've fixed everything you can.

Share this post


Link to post
Share on other sites

Well I wonder if an if than else statement is say 1000th of a second and there are more than 100 that would add up. I guess I need to contain them better in other if than else statements (3 sections) really which should be an estimated double performance.
How did you arrive at this conclusion?

 

You profiled, or are you guessing?

In the latter case, you're wrong.

 

When I must find a performance problem, I always first make a guess where the problem would be for fun. Then I properly profile it, and check the data.

In the past 35 years, I have been consistently wrong with my guess.

 

A running program is just too complicated to guestimate. Instead, measure by profiling, then you know.

Share this post


Link to post
Share on other sites

I agree with the advice to profile, but I will also add why don't you post how you are going about putting graphics on the screen?  So if something obvious is wrong or could be a problem area someone can point it out.

 

Or I was thinking it is using three D graphics library instead of the deprecated ddraw library and  its quicker.  However it's an old game though.  In my opinion if this displays fine so should mine  right?  What is going on?  Is there a way I can reprogram the display/graphics for better speed?   I'm using directX from 2010.

 

 

So are you using ddraw or d3d?  Which version?  As to what is going on, again profile... it might be your technique as in how exactly you are going about drawing things.  In other words if you want more help post more details as to what you're doing.  If you're using d3d how many draw calls are you throwing at the API?

Share this post


Link to post
Share on other sites

Intel 520 graphics are capable of running Doom 3 Ultra quality at over 60 fps at 1920x1080.  Source for this claim: I've done it.

 

Yes, you're doing something wrong.

 

As the others have said, profile.

Share this post


Link to post
Share on other sites

In the past 35 years, I have been consistently wrong with my guess.

i usually average 80-90% correct when i guess.    but i write EVERYTHING with speed in mind, and dx9 is the only 3rd party code i use, so i tend to know whats slow and whats not to begin with - cause i put it in there - or made use of the slow API (in the case of dx fonts).

Share this post


Link to post
Share on other sites

Well hello, the lack of speed was the getdc and releasedc for a text drawing function to the surface.  It's very quick without it but...

 

 HRESULT CSurface::DrawText( HFONT hFont, TCHAR* strText, 

                            DWORD dwOriginX, DWORD dwOriginY,
                            COLORREF crBackground, COLORREF crForeground )
{
 
 
    HDC     hDC = NULL;
    //loveHRESULT hr;
 
    if( m_pdds == NULL || strText == NULL )
        return E_INVALIDARG;
 
    // Make sure this surface is restored.
    if( FAILED( hr = m_pdds->Restore() ) )
        return hr;
 
    if( FAILED( hr = m_pdds->GetDC( &hDC ) ) )
        return hr;
 
    // Set the background and foreground color
    SetBkColor(hDC, crBackground );
    SetTextColor(hDC, crForeground );
 
    //if( hFont )
    //    SelectObject( hDC, hFont );
 
    // Use GDI to draw the text on the surface
    TextOut(hDC, dwOriginX, dwOriginY, strText, _tcslen(strText) );
 
    if( FAILED( hr = m_pdds->ReleaseDC(hDC) ) )
        return hr;
 
    return S_OK;
}
 
 
This is the function that's slowing it down.  I tried real hard to get it working it just won't work.  
 
I tried two or three different ways.  It was interesting changing the above textout parameter to a global hdc and it flickered.
 
I tried double buffer using a bitblit.  I also tried drawtext, textout, all to no avail.
 
Is there a simple way to do this I'm still using DirectX 7/8 2010. 
 
I haven't tried invalidation yet that's next I guess. 
 
Thank you,
 
Josheir
Edited by Josheir

Share this post


Link to post
Share on other sites
// Use GDI

 

my guess is this is the bottle neck.

does dx8 have dxfonts? i don't recall.  dxfonts are pretty fast.  for even faster,  just make a set of font textures and use dxsprites.

this assumes those api's are in dx8 as well as dx9.

write a test routine that writes a line of text 20 or 30 times to the screen, then try it with GDI, dxfonts, and dxsprites, and use a high resolution timer (QueryPerformanceCounter based) to time them, calling it say 1000 or 10000 times.   i think you'll be surprised at the differences. i know GDI is slower than dx fonts, and Dxfonts was slower than dx sprites, especially with overdrawn drop shadow text. with sprites you can include the drop shadow in the font texture.

i had to go from dxfonts to dxsprites because a whole screen of debugging HUD info with 3-5x dropshadow overdraw was causing a noticeable FPS drop on low end PC's.

 

And yes, GDi is known to be slow.    At least speed freaks like me consider it so. <g>.

PS: if you want to go fast, QueryPerformaceCounter (or its equivalents) is you best friend. 

And when considering any API for use, be skeptical. assume it runs slow unless it claims otherwise, or you've heard other wise, or you've tried it for yourself.   Most software is not designed with realtime games in mind - GDI being one example. in fact, as i recall, they came out with a GDI+ api to address that issue.  

Also never discount brute force as a first option.  With hardware these days, more and more things are becoming doable by brute force means - things that used to require fancy algos to accomplish on slower PCs.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!