Okay, this one's pretty simple. I'm going to reduce this example to a very minor part of my project.

In my game I have a bullet struct followed by a vector with that struct as it's elements. (See code below) The problem occurs after I push_back around 8,000 elements of this vector. Things run great until then, but at somewhere around this point in the application it hangs up (only graphically it would seem.) Once the bullets hit something and tell the vector to remove themselves, everything resumes.

Not sure if this is a code problem or I just don't understand something about vectors. Here's the code I have for this problem:

Add your timer and screen buffering to the code you provided. There could be a problem there.

Also, something to keep in mind here is that vectors are not efficient for deleting elements in the middle of them, only for pushing and popping. I recommend you change your bullet.erase() line with the following:

if(collided_with_object) {
  if (i == bullet.size() - 1)
    bullet.pop_back();
  else {
    memcpy(&bullet<i>,&bullet.back(),sizeof(bullets));
    bullet.pop_back();
}

Granted, this is not an OOP compliant solution, but if you want to keep using vector objects, it's a fast way to speed up the erasing of your bullets.

When you have 8000 objects in your vector and you delete, say, the 5th one, there's about 7994 reallocations of memory which must occur. (If I understand how vectors work.)

It's a lot more efficient to set a limit, allocate the memory ahead of time, then work within that limit so you're not constantly allocating and deallocating memory.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Okay thanks a lot, guys. This is helping a lot.

I have a question concerning Kris's snippet. Were you declaring i as an int or vector<bullets*>::iterator?

if(collided_with_object) {
  if (i == bullet.size() - 1)

Is there a better way? I'm definitely up to changing my code completely at this point. Is it better to go with a predelcared size so that you're not resizing a ton every game cycle?

Here's the code for my timer, though it's not easily readable and I can't imagine it being very helpful.

[edit] Gosh I edit a lot

Get vsync() out of the area between acquire and release!

That could be the source of all your problems. Calling vsync() while a video bitmap is locked with the acquire commands can cause bad things to happen!

On my computer, that action would cause a program lock-up within the first split second of operation.

I also noticed I forgot a } in the code I posted, and I also noticed a way to improve it:

if(collided_with_object) {
  if (i < bullet.size() - 1)
    memcpy(&bullet<i>,&bullet.back(),sizeof(bullets));
  bullet.pop_back();
}

--- Kris Asick (Gemini)
--- http://www.pixelships.com

I'd draw mouse to buffer, not to screen.
Also, have you tried to drop the aquire_screen and/or vsync completely?

I haven't done any windows development for quite a few years but I don't remember not having any problems when not using them.

[edit]

Doh, you are using stretching. You might want to ignore this post. I haven't got enough sleep

Ok, I think we can assume something here...

Your code was working fine before, up until about 8,000 bullets, then died.

Now it works up to about 40,000 then dies.

Either way, it still dies, but improving the bullet removing code improved how many you could handle.

This suggests that the problem is in the way you are handling framerates below the target framerate. I would look at how you handle lower than normal framerates and see if that's the problem.

EDIT: I figured the problem out. If your timer increments while the game logic is still being processed, it never runs the drawing code.

Try this...

--- Kris Asick (Gemini)
--- http://www.pixelships.com

You're right, the code I provided doesn't work... the problem is almost the same with it.

Here's what's happening with your original code. Your variable "speed_counter" is incremented by your 60 FPS timer, right? And you've designed your second while loop to run while speed_counter is greater than 0.

So what happens when you're processing so much data that speed_counter increments while in the middle of processing logic? The while loop continues for another logic pass, which again takes so long that speed_counter increments, so it processes even more logic, and this whole time, ends up skipping your drawing routine which is outside the while loop.

My code, which I thought would work, doesn't because each time it processes the logic, it ends up with more of it to process each new frame and just stockpiles exponentially when the framerate drops.

I don't actually understand proper frame dropping techniques because I switched to doing realtime programming before I learned any, but that's what you need to look up because your frame dropping technique is where the problem is. Though frame dropping is usually for handling when rendering takes too long. If it's the game logic that's taking too long, you need to do something to decrease how much logic is processed.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Yes, Kris is right frame dropping only works if the logic loop runs fast enough that the computer can keep up with logic alone. Since rendering takes a long time (especially with Allegro games), usually this assumption is that the logic is much less demanding than graphics.

If the logic loop can't keep up then you have problems because if rendering takes a lot more effort, then your game is going to run too slow.

The only solution if your game is fixed-rate logic is to have a maximum frame skip and run your game slower than real-time -- the computer just can't keep up with your game.

What HardTranceFan showed does something similar except that it isn't predictable. What will happen is that the frames will get farther and farther spaced out because every time it runs, speed_counter and therefore speed_counter_copy will get higher.

I've published on here and also mentioned in several posts something to deal with it if you have dynamic rate logic, that had several ranges (dt being the logic frame duration for a single step)

1. If dt > maxDt, dt = maxDt (run less than real-time)

2. If dt > frameSkipDt (frame skipping)

3. If dt > minDt (1:1 frame drawing, dynamic dt rate)

4. else, dt is < minDt (1:1 frame drawing, fixed dt rate, CPU sleeping to reduce CPU usage

EDIT: BTW, having code to run less than real-time is especially important even for fast computers and fast games -- if your process is temporarily suspended because your user switched away from your app (alt-tab), suspended/slept/hibernated PC, a process like virus scan or firewall paused your PC, or a heavy disk app like defrag paused you, you don't want the game to go into super-fast zoom mode when it returns from the pause... you want it to stop, pause, and resume where it left off. If it's a network game, you can't do this, though.

Well, it helped!