Jump to content
  • Advertisement
Sign in to follow this  
SiS-Shadowman

DX9 Effect Interface - Performance questions

This topic is 4148 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 have several questions about the Effect Interface within directX. I'm currently working on a GUI for my game and have encountered some performance issues, especially when I was rendering "much" font ( about 500 letters ) the framerate dropped down to 6 fps ( from 60 ). My GUI is based on a simple tree ( with a variable number of branches ) that is then rendered in a back to front order ( due to transparency in some objects ). Since windows, frames and buttons somehow need to be scaled, I render 9 different textures onto quads, that then shape the desired object. But I'm not shure how I can speed up this system. When rendering one string, I once set up all the parameters, that do not change during the rendering step ( the character bitmap, the color, etc... ), then I call SetTechnique(), after that Begin() and BeginPass(). Once this is done, I loop through the string and calculate offset coordinates for the bitmap and the quad, setting up these parameters and then calling CommitChanges() to update the data for the shader. A Draw() Call for the quad finished one character. After this is done, I call EndPass() and End(). ( Then the GUI moves on to the next object, etc... ) But performance just drops down as hell, when I draw a little text ( from 60 fps to 30 fps for 100 or 200 characters ). If you want to see the code for my Font rendering step, I can paste it in. But it's pretty unordered and screwed :-/. Do you have any tipps how I can speed this process up?

Share this post


Link to post
Share on other sites
Advertisement
This doesn't sound like the effect interface is slowing you down.

You say you have a Draw call made for each character in a string? That will kill performance. You should keep the draw calls for your entire frame bellow 100 for decent performance. Going over that will start causing performance issues very very quickly.

To compare, the GUI renderer I will start working on soon will probably render the entire UI in 1-2 Draw calls. You should aim for a system that works with as little Draw calls as possible.

Share this post


Link to post
Share on other sites
Okay, that could propably be the problem.
But how do you manage to draw the entire GUI with 1 or 2 Draw...() calls?
How is that possible?

*edit* One thing came into my mind. I could create on large "construct" for the entire interface, updating the vertices when needed. This would result in writing into the vertex and possible index buffers every frame. If this is, what you meant, how can I then solve the Z-Rendering problem? If the entire guy is inside one vertexbuffer, I would have to shift their y coordinates, so they would be rendered in the "right order", but this would result in size problems: the forward objects would appear bigger, than the backward, wich is not desired. Apart from that, how could I manage the different textures, needed for the different objects?
If I'm totally wrong, please let me know how you would do this :)

[Edited by - SiS-Shadowman on May 13, 2007 8:04:14 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by SiS-Shadowman
If the entire guy is inside one vertexbuffer, I would have to shift their y coordinates, so they would be rendered in the "right order", but this would result in size problems: the forward objects would appear bigger, than the backward, wich is not desired.


If you setup the projection matrix to be orthagonal this wouldn't happen.

Quote:
Original post by SiS-ShadowmanApart from that, how could I manage the different textures, needed for the different objects?


Create a vertex + index buffer for each type of your objects (button, textbox background etc) - I would use a single texture and use texture coordinates (rather than separate textures for each of the 9 sections). Then render it in each of the positions needed (batching them maybe?).


|----|-------|----|
| /| _/| /|
| / | _/ | / | (each separate triangles because the UV
| / | _/ | / | coordinates are going to be different)
|/___|/______|/___|
| /| _/| /|
| / | _/ | / |
| / | _/ | / |
|/___|/______|/___|
| /| _/| /|
| / | _/ | / |
| / | _/ | / |
|/___|/______|/___|


Share this post


Link to post
Share on other sites
I rewrote the GUI, it works now as you proposed. Even more. All the elements are drawn in one Draw() Call, because they all share the same texture (apart from the font). I also store some costum data in the vertices, such as opacity, color, etc.
For the Font, the Pixelshader differs from the one for "standard" elements, that's why I also store an additional flag inside the font's vertices. The routine for the pixelshader changes, when rendering font. This works well, BUT only in release mode. When I compile the programm under debug, the framerate drops from 60 fps (without font) to 30 fps (with font). Although this is much better than 6 fps, I'm not shure why this happens. I'm using some stl containers for texture coordinates, and for the vertices (the container holds every vertex, until the elements have updated theirs, so that the vertexbuffer can be updated again).
The GUI is composed of 50 vertices and with the font, it's about 150. I can't believe that the container will slow down because of that vertex count.
Could this be the reason?

Share this post


Link to post
Share on other sites
Profiling your app in debug mode is a moot point. Debug wasn't designed for speed, and it's speed is unpredictable by you. All that matters is how it runs in release.

Share this post


Link to post
Share on other sites
Or it just doesn't run better. Awful day.
When rendering 300 letters, the framerate doesn'n drop a bit, however with about 2000, it drops down to 3. I really don't get it. Should I post my rendering code?

[Edited by - SiS-Shadowman on May 17, 2007 10:48:30 AM]

Share this post


Link to post
Share on other sites
If you're still having trouble with it, yeah, it couldn't hurt to have some more sets of eyes go through it.

Share this post


Link to post
Share on other sites
I think I figured it out. I was using the std::deque container for the vertexarray. The elements added their vertices to this array, until the GUI is finished "drawing". Then I create the vertexbuffer and fill it with the array. I did a loop with std::deque<myvertexstructure>::iterator.
After the GUI was rendered. I cleared the container with Clear(). I am not shure why. But when I use std::vector, the framerate doesn't drop a bit, although I'm drawing very much characters.

Recently, I read an article, that explained the difference between std::deque and std::vector. What I noticed, deque was faster when it's coming to element insertion, but much slower than vector, if it has to free all elements. It seems I underestimated the time to free de deque container ( it had about 6000 elements ). The article did not explain exactly, how the container managed the elements inside, it just showed diagrams, that showed the performance differences between vector and deque. I'm just guessing, but vector seems to be an plain array, that reserves some size, and when more is needed, it reserves more, copies the old data, inserts new and deletes the old. Deque seems to be behaving like a "chain" tree. At least I got the impression. Please correct me if I'm guessing wrong ;)

I'll just try to remember to use std::vector if I frequently whipe an array and insert again :)

Share this post


Link to post
Share on other sites
If you're serious about speed, get rid of STL. You have to work with a worst case memory footprint anyway, so allocate a fixed, maximum size array upfront. Better still, use write-only vertex/index buffers.

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!