Jump to content
  • Advertisement
Sign in to follow this  
FutureCode

Why is my ID3DXSprite::Draw so slow???

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

The IDirect3DSurface9 is very fast, but it doesn't support transparency so I gave it up.
Now it's said that ID3DXSprite is fast as well, and I had a try.
But it turns to be unsatisfactory.

My code is as follows:
render function :
pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 0), 1.0, 0);
pd3dDevice->Clear(0,0,D3DCLEAR_TARGET,0xff000000,1.0f,0);
pd3dDevice->BeginScene();
spriteNote->Begin(D3DXSPRITE_ALPHABLEND);
for(i = 0; i < n; i++)
{
spriteNote->Draw(textNote, &spriteStruct.srcRect, NULL, &D3DXVECTOR3(spriteStruct.posX, spriteStruct.posY, 0), 0xFFFFFFFF);
}
spriteNote->End();
pd3dDevice->EndScene();
pd3dDevice->Present(NULL, NULL, NULL, NULL);
main loop :
while(msg.message != WM_QUIT)
{
if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
render();
}
}

Now the problem is, when n is less than 50 it's all right, but if n == 100, then I can feel fps decreases a lot.
My sprite is only 7 * 28. It's not supposed to act like this;

What's wrong with it???

Share this post


Link to post
Share on other sites
Advertisement
Not sure if this would be the cause, but I've noticed you've made two calls to Clear(). Surely one call would be enough?

Share this post


Link to post
Share on other sites
try surrounding your code in source tags to make it easier to read

[SOURCE]
[/SOURCE]

[/source]

what hardware are you using? what is your actual fps and time per frame? Is that the exact code, how are you loading the sprites? Are you setting any renderstates?

Share this post


Link to post
Share on other sites
When you say the FPS decreases a lot, how much is that? Though, it would be better to measure speed in terms of the milliseconds taken to render a frame as opposed to frames per second:

If fps drops from 2000 to 1950, that means it only took ~0.000013 seconds.
If fps drops from 60 to 10, that means it took ~0.083333 seconds

-Jeff

Share this post


Link to post
Share on other sites
Frame rate is not a meaningful way to measure performance, if that is what you're doing. The reason for this is the amount in which the frame rate decreases will not make sense if you look at the numbers literally. For example, if I draw one cube, I might go from 2000 fps to 1200fps. That's 800fps for one cube! Drawing another cube might take me down from 1200 to 1000... That's 200fps for the exact same cube.

If you're starting from a blank screen and comparing the results of the frame rate after you drew your sprites, the numbers aren't really going to mean much unless your framerate is dropping to choppy levels like under 60.

Share this post


Link to post
Share on other sites
The Clear() is a mistake and I'm sorry, but it's not the cause.
The fps is dropping seriously because when n is up to 40, the fps is exactly 60.
What I can't understand is, such little work takes so much time, for I'm just performing some simple 2D drawing, and when the size of sprite is 128 * 128, I can't even put 5 sprites.

Share this post


Link to post
Share on other sites
Are you using a HAL or REF device? Are you using any shaders? What graphics card do you have? How are you measuring FPS?

Share this post


Link to post
Share on other sites
I create the device using D3DDEVTYPE_REF, for HAL seems to be worse, and SW fails.

I measures fps by using
t1 = clock();
render();
t2 = clock();

Share this post


Link to post
Share on other sites
Quote:
Original post by FutureCode
I create the device using D3DDEVTYPE_REF, for HAL seems to be worse, and SW fails.

I measures fps by using
t1 = clock();
render();
t2 = clock();


try using query performance counter for timming, or just run FRAPS for an even easier solution. REF is probably just faster because most your work is being done on your cpu so there is no need to swap memory back and forth. Once you start doing heavy stuff though, you'll see the refrence rasterizer slow down.

What GPU do you have?

Share this post


Link to post
Share on other sites
Quote:
Original post by FutureCode
I create the device using D3DDEVTYPE_REF, for HAL seems to be worse, and SW fails.


When you create the device with D3DDEVTYPE_HAL, are you using D3DCREATE_HARDWARE_VERTEXPROCESSING for the fourth parameter? Example:
d3d->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, window.handle(), D3DCREATE_HARDWARE_VERTEXPROCESSING, &pp, &device);

Reference mode is going to be slow since it uses software rendering to emulate the Direct3D standard for whatever version you're using. SW is a different story.

Also, what are you doing with t2 and t1? Those alone won't give you the FPS, but subtracting t1 from t2 gives you the preferred "how much time did it take to render this frame." clock() alone may not be what you're looking for, due to varying platform implementations. It doesn't return seconds; if you want those you'll need to divide the result by CLOCKS_PER_SEC.

Quote:
Original post by FutureCode
Now the problem is, when n is less than 50 it's all right, but if n == 100, then I can feel fps decreases a lot.
My sprite is only 7 * 28. It's not supposed to act like this;

What's wrong with it???

You will "feel" the choppiness if you don't interpolate moving objects using the delta time. I can't tell if you're moving your sprites at all from the code you've posted, but it's just another thing to look into if you are.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!