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???
Why is my ID3DXSprite::Draw so slow???
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?
try surrounding your code in source tags to make it easier to read
[/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?
[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?
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
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
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.
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.
Author
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.
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.
Are you using a HAL or REF device? Are you using any shaders? What graphics card do you have? How are you measuring FPS?
Author
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();
I measures fps by using
t1 = clock();
render();
t2 = clock();
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?
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
