You said it works if you create a single particle instance, but not if you spawn a single particle instance from the emitter. Correct?

If so, create a single particle instance manually, and spawn a single particle instance from the emitter. Using breakpoints and/or debug printing, compare the states of the one you created manually vs the one that was spawned from the emitter.

Indeed, most programmers would write "i < N" for loops that should run N times, rather than i <= N - 1. It would be a good idea to do this consistently from now on, to prevent such bugs.

Now, it sounds like you've discovered something very interesting from a debugging perspective, which is you have two versions of the program, one of which behaves as expected and another which does not.

As Lactose says, you can start running the two versions and comparing the various variables involved. Keep the number of particles small and it might be easier to debug.

Excellent observation, that is indeed the sequence of IDs that you might expect, that you see a deviation is significant. 3452816845 is an interesting number, not by itself but rather because many of your variables seem to have this value.

Googling it gives me https://stackoverflow.com/questions/18673913/why-variables-are-initialized-with-max-value-instead-of-zero, which reveals that the value has a special meaning:

3452816845 = 0xcdcdcdcd, the value used to initialize memory allocated from the heap.

(I knew about this already, but this shows how you might investigate yourself).

So what is happening? This example program might illustrate:

#include <iostream>
#include <vector>
 
struct Foo {
 
  Foo() {
    std::cout << "Constructor for " << this << std::endl;
  }
 
  ~Foo() {
    std::cout << "Destructor for " << this << std::endl;
  }
 
  Foo(const Foo &other) {
    std::cout << "Copying " << &other << " into " << this << std::endl;
  }
 
  Foo &operator=(const Foo &other) {
    std::cout << "Assigning " << &other << " to " << this << std::endl;
    return *this;
  }
 
};
 
int main() {
  std::vector<Foo> v;
  std::cout << "Before insertion" << std::endl;
  v.push_back(Foo());
  std::cout << "End of main" << std::endl;
}

If you run this, you'll see something like:

Before insertion

Constructor for 0x7fff8957a718

Copying 0x7fff8957a718 into 0xfdd030

Destructor for 0x7fff8957a718

End of main

Destructor for 0xfdd030

Note that a Foo object was created, copied and destroyed during the "push_back". This is the lifecycle of the temporary Foo() instance. The copy lives on in the vector, and is destroyed after the last line of main().

It looks like your Particle class is more complex than it seems at first, it has complex inner types. The question is really whether these complex inner types can be copied and / or assigned. Remember the rule of three, which is that any class that has a destructor should probably have a copy constructor and assignment operator (leaving aside move for the moment), or be "non-copyable", which can be done (in modern C++) by deleting the problematic functions (to prevent them being automatically generated), or simulated in older C++ by declaring the functions private and leaving them unimplemented.

Generally you do not want to implement copying semantics for external resources, such as textures that reside on the graphics card. Not only is it tricky, but also it is likely to have performance issues. You don't generally want to have lots of distinct copies of the same texture on the GPU, that is just wasting memory and wasting time switching between textures. I'd recommend changing your Texture, Vbo and Ebo classes to be non-copyable.

Once you do this, code that attempts to insert Particles into the container should stop compiling. I was never much of a graphics programmer, and it has been a long while since I've dabbled, but my guess would be to think about managing the textures and related objects at a higher level than the particles, for example the emitter could manage these resources. Particles should be as lightweight as possible, managing GPU resources is the opposite of this.