Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 28 Feb 2012
Offline Last Active Jan 06 2014 04:51 AM

Posts I've Made

In Topic: Face Instancing: Dividing Draw Calls?

08 August 2012 - 06:38 PM

The `Index Buffer` will need updating every frame based on what the camera can see.

The `Vertex Buffer` will only need updating every time a block is destroyed.This may only happen once every 1.5 seconds, based on the rate you can destroy blocks.

Notice the index buffer is made up of 4 byte integers. If you had 150,000 faces in your vertex buffer, you will need 900,000 indices to draw every face.

Add frustum culling, which will take it down to ~33% (Based on what the camera can see), 297,000 indices is now required to draw all the faces that the camera can see.

297,000 indices * 4 bytes = 1.13MB

That amount of data should have no proplem being sent down to the grapihcs card every frame.

In Topic: Face Instancing: Dividing Draw Calls?

08 August 2012 - 03:47 AM

Yes it will, the less draw calls the better in most situlations.

You may be going around the problem in the wrong way. The graphics card is made to have huge amounts of vertices and indices deleted and loaded every frame.

Heres how I got around this same problem with a very good frame rate.

For every chunk, calculate which cube faces are visible, then store the vertices and indices for the faces in memory.

Create 1 very large static vertex buffer and fill it with all vertices from all the chunks.

Create 1 very large dynamic index buffer.

Every frame use frustum culling to find with chunks are visible to the camera, fill the index buffer with the indices from the visible chunks and draw.

If a cube is destoryed, you will need to reload the visible faces for that chunk and refill the whole vertex buffer. Don't worry like I said, graphics cards are built to do this!

In Topic: Null pointer exception during primitives draw call.

06 June 2012 - 06:09 PM

You know what the problem is. The `device` variable is NULL and you are calling draw on it. Step through your code to find why the device is NULL. If you use visual studio, use the call stack.

In Topic: Class Function Overloading Method Question

11 May 2012 - 03:10 AM

This is more of a `Is this the correct way of doing it` question. But I have added functionality if it helps.

class CModel
	 void Draw(CRenderer& _rRenderer)

class CPlayerModel : public CModel
	 void Draw(CRenderer& _rRenderer, const CVector3& _krPlayerPosition)


So the user adds a CPlayerModel to their game. They need to call Draw on the CPlayerModel.

They have the choice of either CModel::Draw or CPlayerModel::Draw. Both are available to be called even though CPlayerModel::Draw should be the only function that used be for drawing this object type.

What stops the user from calling the CModel::Draw? Or should the user just have the "Smarts" or do the research before choosing which draw function to use?

In Topic: Visual Studio C++ Release Build Issue

06 May 2012 - 08:00 PM

Without seeing the code there is only so much other people can do to help you. Such as pointing out common causes to this issue.

- not defining default values for variables
- putting functions into debug only macros, such as asserts
- memory trampling