Sign in to follow this  
FlashManiac

[.net] Managed Dx - consuming system performance

Recommended Posts

FlashManiac    122
Hello, I have one question. I try to display simple 3D object(plane) with some 2D sprites.. I have some sample… and it works but problem is with system performance.. It seems it consumes much bigger system resources than should be. On my PC it displays only about 170 2D sprites + 1polygon 3D plane. After that count fps will go low. I think one polygon shouldn’t be so consuming and I don’t understand why is that count of 2D sprites so small. Do somebody know why it is happen? I’ll upload that sample(with source code) on web to download and test it.. http://leteckaposta.cz/646633912 After starting of program you will see only the plane.. To see 2D sprites press “Q” To add 10 another 2D sprites press “A” To remove 10 2D sprites press “S” Number in 3rd row of debug font shall inform you how much 2D sprites you display. (it displays that number *10 sprites) If anybody know if I have some mistakes in source code please help me.. Thank you very much

Share this post


Link to post
Share on other sites
keshtath    146
I Havent had a chance to download and look at your code yet but have you removed the 3d polygon to see if that is what is causing the slowdown. I.E. can you render more sprites with the 3d polygon turned off?


Share this post


Link to post
Share on other sites
FlashManiac    122
well,
I tried remove 3D object and draw 2D sprites only, byt I have draw only 30 sprites more than WITH 3D plane.. without slowing the frame rate..
so 3D plane will not so slow as I think.. but I don't understand why it is so slow when I want draw more 2D sprites..
I thought 2D rendering is much simplier than 3D rendering..

Share this post


Link to post
Share on other sites
kanato    568
Well, I couldn't get it to run on my computer, but I'm guessing the issue is here:


for (i = 0; i < 10; i++)
{
for (j = 0; j < cislo; j++)
{
obrazekPozadi.Begin(SpriteFlags.AlphaBlend);
obrazekPozadi.Draw2D(texturaPozadi, System.Drawing.Rectangle.Empty, new System.Drawing.SizeF(256, 256), new System.Drawing.Point((int)(i * 100), (int)(j * 3)), System.Drawing.Color.White);
obrazekPozadi.End();
}
}



you should try this moving the begin and end calls to outside the loop instead:

obrazekPozadi.Begin(SpriteFlags.AlphaBlend);
for (i = 0; i < 10; i++)
{
for (j = 0; j < cislo; j++)
{
obrazekPozadi.Draw2D(texturaPozadi, System.Drawing.Rectangle.Empty, new System.Drawing.SizeF(256, 256), new System.Drawing.Point((int)(i * 100), (int)(j * 3)), System.Drawing.Color.White);
}
}
obrazekPozadi.End();

Share this post


Link to post
Share on other sites
gharen2    520
Quote:
Original post by FlashManiac
I thought 2D rendering is much simplier than 3D rendering..


Not necessarily. It depends on how you're rendering the sprites. Are you rendering all your sprites in as few batches as possible? Or is each sprite rendered individually (between it's one begin and end calls)?

As a rule, rendering a large number of objects in a single batch is much, much faster than rendering the same number of objects individually. Even if each one is simple.

edit - hah, and kanato beats me by 2 minutes.

Share this post


Link to post
Share on other sites
FlashManiac    122
Quote:
Original post by kanato
Well, I couldn't get it to run on my computer, but I'm guessing the issue is here:

*** Source Snippet Removed ***

you should try this moving the begin and end calls to outside the loop instead:
*** Source Snippet Removed ***


Sorry its old version of code..
I put Draw.Begin and Draw.End outside..
but it don't help fps was same..

Share this post


Link to post
Share on other sites
FlashManiac    122
Quote:
Original post by Dancin_Fool
Draw calls are expensive, you might want to think about batching those sprites together to speed up the framerate.


could you make some sample please?
I heard some info about rendering of ONE big sprite(or more precisely part of big sprite is rendered - and the rest is hide) but I don't find any example...

Share this post


Link to post
Share on other sites
gharen2    520
Batching sprites just means putting all the draw calls between begin and end, which you've already done.

What kind of cpu and video card are you using?

Share this post


Link to post
Share on other sites
Dancin_Fool    785
Yeah, basically what you want to do is move all your individual sprites into one vertex buffer so you can draw them all together. Right now it looks like you're drawing one quad for each sprite.

So one way you could do it is create a vertex buffer big enough to hold all the sprites you would need, then modify the vertices in the vertex buffer so they match up with the positions of your sprites. Then when you make your draw call, just draw the visible sprites.

Another way would be to fill up the vertex buffer with a bunch of 1 unit by 1 unit quads and pass the instancing information to a shader and transform them within a shader.

Either way you try should give you a nice boost to your performance.

Share this post


Link to post
Share on other sites
gharen2    520
Quote:
Original post by Dancin_Fool
Yeah, basically what you want to do is move all your individual sprites into one vertex buffer so you can draw them all together. Right now it looks like you're drawing one quad for each sprite.

So one way you could do it is create a vertex buffer big enough to hold all the sprites you would need, then modify the vertices in the vertex buffer so they match up with the positions of your sprites. Then when you make your draw call, just draw the visible sprites.

Another way would be to fill up the vertex buffer with a bunch of 1 unit by 1 unit quads and pass the instancing information to a shader and transform them within a shader.

Either way you try should give you a nice boost to your performance.


Honestly, that sounds like overkill for what he's doing. If putting all the draw calls between begin and end didn't improve performance at all, my suspicion is that the problem lies elsewhere in his code.

Share this post


Link to post
Share on other sites
gharen2    520
Quote:
Original post by Dancin_Fool
Not necessarily I've found a lot of overhead with draw calls in managed directx.


True, and I've already stated as much in this thread. But the whole point of batching the sprites is to offset that.

Share this post


Link to post
Share on other sites
FlashManiac    122
Quote:
Original post by gharen2
Batching sprites just means putting all the draw calls between begin and end, which you've already done.

What kind of cpu and video card are you using?


Well,
I have
CPU: Athlon64 4000+
GPU: ATi x1600 512MBRAM
RAM: 1,5GB RAM


I wrote that code from the book about Managed DX by Tom Miller(Beginning 3D Game Programming) so I think in that code shouldn't be any unnecessary lines

Share this post


Link to post
Share on other sites
FlashManiac    122
Quote:
Original post by Dancin_Fool
Yeah, basically what you want to do is move all your individual sprites into one vertex buffer so you can draw them all together. Right now it looks like you're drawing one quad for each sprite.

So one way you could do it is create a vertex buffer big enough to hold all the sprites you would need, then modify the vertices in the vertex buffer so they match up with the positions of your sprites. Then when you make your draw call, just draw the visible sprites.

Another way would be to fill up the vertex buffer with a bunch of 1 unit by 1 unit quads and pass the instancing information to a shader and transform them within a shader.

Either way you try should give you a nice boost to your performance.


Could you make some sample?? When I looked on web I found only VertexBuffers for 3D objects.. but I know 3D plane doesn't consume that system resources..

so if you know how, please make some simple sample..
thanks

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this