Jump to content

  • Log In with Google      Sign In   
  • Create Account


Too many draw calls


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
29 replies to this topic

#21 0r0d   Members   -  Reputation: 817

Like
0Likes
Like

Posted 24 June 2013 - 02:11 AM

You should probably find a good tutorial on how rendering works.  Trying to do graphics without properly understanding how the render pipeline and the gpu works is bound to go very badly for you.



Sponsor:

#22 superman3275   Crossbones+   -  Reputation: 2011

Like
0Likes
Like

Posted 24 June 2013 - 01:23 PM

Why redraw every frame when you only need to redraw if a cube is removed or placed? Doesn't make sense.

Do you not know what a game-loop is? This isn't even low-level stuff. Every library I've ever worked with involving gamedev (around three) all require a game loop.


Edited by superman3275, 24 June 2013 - 01:23 PM.

I'm a game programmer and computer science ninja ph34r.png!

Here's my 2D RPG-Ish Platformer Programmed in Python + Pygame, with a Custom Level Editor and Rendering System!

 

Here's my Custom IDE / Debugger Programmed in Pure Python and Designed from the Ground Up for Programming Education!

Want to ask about Python, Flask, wxPython, Pygame, C++, HTML5, CSS3, Javascript, jQuery, C++, Vimscript, SFML 1.6 / 2.0, or anything else? Recruiting for a game development team and need a passionate programmer? Just want to talk about programming? Email me here:

hobohm.business@gmail.com

or Personal-Message me on here smile.png!


#23 0r0d   Members   -  Reputation: 817

Like
0Likes
Like

Posted 24 June 2013 - 03:52 PM

What I gathered from my hours of googling is that I'd only need to redraw the buffer when something in it changes, but something in my head didn't click and I didn't realize I had 40,000 single buffers being drawn for 40,000 different cubes with over 300,000 vertices lol. It makes sense to me now though. I just thought all the drawing could be done at Initialization and I wouldn't have to deal with redrawing until input is recieved 

Normally you want to have the render loop running at some rate along with the update loop.  In most cases these happen in sync, but they can happen at different rates like for example if the drawing is slow but you want to keep a faster update frequency for physics or whatever.  If the scene is truly static, then technically you can just draw it once to the backbuffer and swap and then leave it there, but on at least some hardware it will choke if it doesnt get swaps every so often.

 

You might also have situations where a scene is static but only rendered as part of the bigger scene on screen... like if you have a monitor showing what's going on in another part of the level.  The image on that monitor can be a texture into which you drew that part of the level, but if that doesnt change then you dont have to update the texture... until something does happen.



#24 burnt_casadilla   Members   -  Reputation: 440

Like
0Likes
Like

Posted 24 June 2013 - 09:46 PM

 

What I gathered from my hours of googling is that I'd only need to redraw the buffer when something in it changes, but something in my head didn't click and I didn't realize I had 40,000 single buffers being drawn for 40,000 different cubes with over 300,000 vertices lol. It makes sense to me now though. I just thought all the drawing could be done at Initialization and I wouldn't have to deal with redrawing until input is recieved 

Normally you want to have the render loop running at some rate along with the update loop.  In most cases these happen in sync, but they can happen at different rates like for example if the drawing is slow but you want to keep a faster update frequency for physics or whatever.  If the scene is truly static, then technically you can just draw it once to the backbuffer and swap and then leave it there, but on at least some hardware it will choke if it doesnt get swaps every so often.

 

You might also have situations where a scene is static but only rendered as part of the bigger scene on screen... like if you have a monitor showing what's going on in another part of the level.  The image on that monitor can be a texture into which you drew that part of the level, but if that doesnt change then you dont have to update the texture... until something does happen.

 

My map isn't that complicated though. It's pretty static, except for some destroying and building of blocks. I see what you're saying and it makes sense, but for now I just need to get the map drawn on the screen in game time. Physics don't apply here yet


If you see a post from me, you can safely assume its C# and XNA :)


#25 0r0d   Members   -  Reputation: 817

Like
0Likes
Like

Posted 24 June 2013 - 10:14 PM

 

 

What I gathered from my hours of googling is that I'd only need to redraw the buffer when something in it changes, but something in my head didn't click and I didn't realize I had 40,000 single buffers being drawn for 40,000 different cubes with over 300,000 vertices lol. It makes sense to me now though. I just thought all the drawing could be done at Initialization and I wouldn't have to deal with redrawing until input is recieved 

Normally you want to have the render loop running at some rate along with the update loop.  In most cases these happen in sync, but they can happen at different rates like for example if the drawing is slow but you want to keep a faster update frequency for physics or whatever.  If the scene is truly static, then technically you can just draw it once to the backbuffer and swap and then leave it there, but on at least some hardware it will choke if it doesnt get swaps every so often.

 

You might also have situations where a scene is static but only rendered as part of the bigger scene on screen... like if you have a monitor showing what's going on in another part of the level.  The image on that monitor can be a texture into which you drew that part of the level, but if that doesnt change then you dont have to update the texture... until something does happen.

 

My map isn't that complicated though. It's pretty static, except for some destroying and building of blocks. I see what you're saying and it makes sense, but for now I just need to get the map drawn on the screen in game time. Physics don't apply here yet

 

 

Just have a game loop that updates and renders the scene based on the current camera.  That's the simplest setup and all you need.



#26 burnt_casadilla   Members   -  Reputation: 440

Like
0Likes
Like

Posted 25 June 2013 - 12:17 PM

Ok so if I'm going to start simple, I'm going to only draw the sides of the cube that I can see. Can anyone point me to a tutorial on how to do that or give an example?


If you see a post from me, you can safely assume its C# and XNA :)


#27 Alpha_ProgDes   Crossbones+   -  Reputation: 4688

Like
0Likes
Like

Posted 25 June 2013 - 12:41 PM

Why don't you start with this tutorial (it's XNA 3.1) or this website (should work with XNA 4.0).


Beginner in Game Development? Read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler

#28 phil_t   Crossbones+   -  Reputation: 3318

Like
1Likes
Like

Posted 25 June 2013 - 12:51 PM

That's not starting simple. That's a more advanced optimization... which sides of a cube are visible depend on where it is in relation to the camera, and evaluating that for each cube individually isn't going to get you any perf win (unless you have an orthographic projection from a fixed angle...). In your current implementation, your performance is almost certainly CPU-bound, not GPU-bound.

 

The simplest thing is, like I explained befored, just to put all your cubes in a single vertex buffer at startup and draw that. That will get you interactive frame rates. (Yes, if you need to add/remove cubes at runtime and still have that be fast, then that will be more work... but you said "I'm going to start simple").

 

The next simplest thing is to use instancing. You have one cube model, and a separate dynamic vertex buffer with instance data in it. There is a tutorial on the XNA site here: http://xbox.create.msdn.com/en-US/education/catalog/sample/mesh_instancing. It will require you write your own shader, because your vertex shader needs to compute the position from the cube vertex base position plus the instance position. This won't be any faster, but it will use less memory, and it will be slightly faster to add/remove cubes.



#29 burnt_casadilla   Members   -  Reputation: 440

Like
0Likes
Like

Posted 25 June 2013 - 04:07 PM

Thanks. I'd rather start with instancing if I can remove blocks. It wouldn't make sense to draw a big chunk and not be able to change the blocks in it

If you see a post from me, you can safely assume its C# and XNA :)


#30 Alpha_ProgDes   Crossbones+   -  Reputation: 4688

Like
1Likes
Like

Posted 25 June 2013 - 06:21 PM

Thanks. I'd rather start with instancing if I can remove blocks. It wouldn't make sense to draw a big chunk and not be able to change the blocks in it

 

I think you should do some searching for a good tutorial or book and start from the beginning. Other than that, I don't think anyone here is going to say anything that hasn't already been said.


Beginner in Game Development? Read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS