Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Member Since 29 Jun 2010
Offline Last Active Yesterday, 03:46 PM

Posts I've Made

In Topic: How does std::vector<std::list> behave when I add a new item to any o...

21 December 2014 - 05:02 AM

But why? Can you please explain it? It is said that, the vector elements are contiguous in the memory. When I add a new list element, the vector must reallocate in order to preserve its contiguous structure. How do you disprove this?


The vectors memory contains only the lists body. Imagine an implementation like this:

template<typename Type>
class vector
    Type* m_array;
     size_t m_count;

A list is most likely implemented like this:

class list
   Node* m_pFirst; // pointer to the first node

Now if you have a vector<list>, the only thing that is in the memory of the vector is this pointer to the first node. The node itselfs lies elswhere on the heap, and so does every other node you add.

In Topic: Weird particle lag?

12 December 2014 - 06:52 PM

Still get lag not as significant, I just had a thought I havent confirmed that the fps is dropping my camera just slows down a lot after I render it and since my camera uses glTranslatef() could it just be the camera that slows down and not the fps?


How exactly are you rendering the particles? I mean how are they set up in the scene... I've noticed something familiar, that when you eigther have very huge particles covering up the screen with huge textures, or many particles at the exact same position, performance can be really horrible.


You should really run a profiler at this point. There are some good GPU-debugging tools, for DX as well as OpenGL. You could also check profiling the CPU first for the offchance that there is something wrong here.


Can't you instance the particles instead? I don't know too much about opengl but this is how I am handling particles in Direct3D 11 and it works well enough to draw tens of thousands of particles per frame without dropping fps at all.


If updating the positions to the GPU is not the performance bottleneck, as he astablished, instancing is not making a difference.

In Topic: Weird particle lag?

12 December 2014 - 03:47 PM

Thats odd. What happens if you take out all the translation/updating related code and just bind and render this one big vbo each frame (after performing an initialial transform)?

In Topic: Weird particle lag?

12 December 2014 - 03:16 PM

If I see it correctly, you are rendering every particle vertex with a seperate vertex buffer, index buffer, and draw call. Try to put most/all particles in one buffer with a single draw call. That way, you can just update the verticex-positions in the buffer dynamically every frame. Optimally you seperate all animation data in its own buffer, so you won't get overhead for transfering static data like speed for every vertex every frame. This should yield much better performance, since you first of all have way less API-calls. I'm not an expert on legacy-OpenGL, but there should be no performance penalty over updating a buffer VS. calling the glTransf (etc...) functions, in fact it should be way faster.

In Topic: Including namespace on GetTypeDeclaration()

04 November 2014 - 03:23 PM

You're right, of course, but look at how C++ deals with this:


Sure, there is a difference, but I personally don't have any opinion on whats the "correct" or better way here. I just wanted drop in a quick explanation in case there was any technical confusion. If you want me to quess, I'd say c++ purposely dropps the "::" on any global namespace class, because I think internally global or user-defined namespaces are handled somewhat the same.. but thats just quessing. Andreas can surely answer you why it currently is that way and if he decides to change it ;)