Jump to content

  • Log In with Google      Sign In   
  • Create Account

NightCreature83

Member Since 21 Feb 2008
Offline Last Active Today, 03:11 AM

Posts I've Made

In Topic: D3D11 - Bitmap Font Rendering

19 July 2016 - 10:00 AM

A thanks for the recommendations. Looks like I'm off to implement nice batching then. I thought so, I was just befuddled at what a difference it makes, the little bit of text would cause such tremendous slowdowns.

@NightCreature83: I was creating a buffer for every quad. So that's quite a few reuses per frame for a few lines of text :)

Its the number of buffers here that are the problem, you are usually better of creating a fewer vertex buffers and having a few large ones than really small ones, the CPU overhead will cost more on the small buffers than on the large ones.


In Topic: Maximum Size Of Vertex Buffer

18 July 2016 - 08:29 AM

https://msdn.microsoft.com/en-us/library/windows/desktop/ff819065(v=vs.85).aspx

D3D11 only guarentees a buffer size of 128 MB that is usuable, on hardware that supports more it will allow the allocation to happen but since this wil fail on other hardware its better to not do this. But if you have a 128MB vertex buffer I dont think your performance will be super anyway.


In Topic: D3D11 - Bitmap Font Rendering

18 July 2016 - 07:28 AM

Do you create a buffer for each quad or are you using a buffer to hold multiple quads? (the text you wrote to me indicates that you create a buffer for each quad so just want to clear that up)

 

You should discard the content of the old buffer when you are filling it again with new data, you could create a quad data that contains all of the transformed vertex data and then just copy that into the vertex buffer for rendering. You would need a new VB if you change font or scaling size offcourse, and even that is fixable with instanced rendering.


In Topic: Loading Models With Assimp Directx 11

18 July 2016 - 05:50 AM

or seeing this is a DX11 app try DXTK which is a replacement for D3DX functions. It will load textures straight into SRVs so that you can use them in pixelshaders. https://directxtk.codeplex.com/


In Topic: Does Object Pooling with a Vector in C++ have problems with memory?

08 July 2016 - 03:44 AM

In your constructor for the BulletPool class, you're really overcomplicating this.

         {

           Bullet *bullet = new Bullet[11];
           for(int j = 0; j < mCounter; j++)
           {
             mBullets.push_back(&bullet[j]);
           }

         }

This here is completely unnecessary. A quick dive into the STL's documentation about Vector will inform you that Vector has a resize function that will initialize a size for you to start of with.

 

http://www.cplusplus.com/reference/vector/vector/resize/

 

This will save you the trouble of managing pointers. You've also made a dire error which will later cause you problems with memory leaks.

 

 

 

Bullet bullet* = new Bullet[11]

The pointer will be allocated to the function's stack. However the data that the pointer points to is not guaranteed to be on the stack. In fact,it will be on the heap. When the pointer dies, the array of bullets that it points to will still be alive, and you will have no way to remove it. Please remember to call delete[] on arrays, or delete() on any data type that had been allocated from a function, and is not going to be used later after the function exits.

 

The Return bullet is absolutely unnecessary.  And the way Get and Return is set up is absolutely error prone if not implemented correctly. You're trying to implement a stack, which is not what a pool is.

I don't know what Flash tutorial you're looking at, because there are several other things that could go poorly. 

This line "Bullet *bullet = new Bullet[11];" hides the member variable from the BulletPool, this leads to really strange bugs because bullet* has no valid address in the class. I would just allocate my bullets in a std::vector<Bullet*> and then copy the unused bullet pointers into a std::deque<Bullet*> m_freeList; and give out and return pointers to the deque.


PARTNERS