Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    217348

Untitled

Sign in to follow this  
Mushu

104 views

Getting back to code, I'm still on the same GUI-ish problem - optimizing a GUI renderer since a lot of the GUI is almost static (ie, reacts based on events) but is not static.

The problem I've been having is with textures - nothing is guarenteed about what textures will be needed, so we can't create a GUI texture palette. Which ultimately means state changes. Which means we can't just draw everything in a single draw call.

I think at this point I'm just going to use a strict immediate mode approach. I mean, yeah. It will be pretty nasty. But you know, it is just a GUI, after all. Though important, it isn't a vital part of the graphics pipeline. If, later on, it does bottleneck the system then I'll fix it. But at this point, anything needing an insanely complex GUI probably won't be doing any hardcore rendering, so the GUI can hog all the GPU bandwidth it needs.

I know basically everyone here has written their own GUI system - has anyone made a nice system that uses vertexbuffers to reduce the number of draw calls?
Sign in to follow this  


4 Comments


Recommended Comments

My old system used A single vertex buffer for the entire GUI manager.

Each control had two vertex methods:

int RequestVertexCount();
Vertex* GetVertices();


Then I just looped through and copied each set of vertices onto a vertex buffer.
Can't say it was amazingly fast though. A single vertex buffer doesn't necessarily mean more speed.

I'm rendering each of my containers separately and I don't get any performance issues at all.

Share this comment


Link to comment
I use a dynamic texture palette in my system. I create a huge texture (Size is determined by the amount of avilable texture memory and maximum supported texture sizes - Ends up usually as 2048x2048 or 4096x4096), and copy textures into that as they're loaded. It's actually a lot faster than I expected.

All my GUI code goes through my sprite manager, which is essentially one large dynamic VB which gets filled each frame with sprites in the scene.

I can draw every single object on the screen - all the GUI elements and the backhground image (4x3 tiles of 256x256) in 2 draw calls and 2 texture switches - One for my sprites, one for ID3DXFont (It uses an ID3DXSprite which batches all the text into one draw call).

Share this comment


Link to comment
I use a dynamic texture palette in my system. I create a huge texture (Size is determined by the amount of avilable texture memory and maximum supported texture sizes - Ends up usually as 2048x2048 or 4096x4096), and copy textures into that as they're loaded. It's actually a lot faster than I expected.

All my GUI code goes through my sprite manager, which is essentially one large dynamic VB which gets filled each frame with sprites in the scene.

I can draw every single object on the screen - all the GUI elements and the backhground image (4x3 tiles of 256x256) in 2 draw calls and 2 texture switches - One for my sprites, one for ID3DXFont (It uses an ID3DXSprite which batches all the text into one draw call).

Share this comment


Link to comment
Quote:
Original post by Programmer16
My old system used A single vertex buffer for the entire GUI manager.

Each control had two vertex methods:

int RequestVertexCount();
Vertex* GetVertices();


Then I just looped through and copied each set of vertices onto a vertex buffer.
Can't say it was amazingly fast though. A single vertex buffer doesn't necessarily mean more speed.

I'm rendering each of my containers separately and I don't get any performance issues at all.


Wow, after removing the other part of my last sentence, it comes off really rude. Sorry.

Share this comment


Link to comment

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