Is 1000+ Game-Objects in Vector too slow? What is my mistake?

Question

I am currently working on a game where you need to track a lot of objects.

I have a game object class that contains all the necessary information about the object and processes AI () on update ();

I decided that only objects with the brain would need to update each frame. Therefore, I have selected vectors to save time. However, I cannot find a similar solution when drawing objects. Therefore i got

std::vector<cOBJECT*> LivingObjects; 

and

 std::vector<cOBJECT*> WorldObjects; 

When drawing all the objects, I first put all the objects in a RenderList:

 //Add World and Living Objects into one list of RenderObjects RenderObjects = WorldObjects; RenderObjects.insert(RenderObjects.end(), LivingObjects.begin(), LivingObjects.end()); 

Then I sort them by Y:

 //Sort all Objects by Y (bottom) Coordiante sort(RenderObjects.begin(), RenderObjects.end(), cmd); 

Here is the code for this (maybe this is slow too ?:

 //Sorts by Y-Coordinaté bool cmd(cOBJECT* obj1, cOBJECT* obj2) { return obj1->getrect().y + obj1->getrect().h < obj2->getrect().y + obj2->getrect().h; } 

Then I draw them. The drawing function checks if they are turned on on the screen! Therefore, I draw only visible objects:

 //DRAW OBJECTS and for (std::vector<cOBJECT*>::size_type i = 0; i != RenderObjects.size(); i++) { RenderObjects[i]->render(Renderer, CameraX, CameraY, SCREEN_WIDTH, SCREEN_HEIGHT); } 

Here is the real draw function:

 int cTEXTURES::renderAnimation(int targetX, int targetY, double angle, SDL_Point* center, SDL_RendererFlip flip, SDL_Renderer* Renderer, int row, int speed, int offX, int offY, int SCREEN_HEIGHT, int SCREEN_WIDTH) { //Draw if part of it shown on screen if (targetX - offX >= -FrameWidth && targetX - offX <= SCREEN_WIDTH + FrameWidth && targetY - offY >= -FrameHeight && targetY - offY <= SCREEN_HEIGHT + FrameHeight) { SDL_Rect SourceRect; SDL_Rect TargetRect; TargetRect = { targetX - offX, targetY - offY, FrameWidth, FrameHeight }; SourceRect.x = (CurrentFrame - 1) * FrameWidth; SourceRect.y = (row - 1) * FrameHeight; SourceRect.w = FrameWidth; SourceRect.h = FrameHeight; if (OldTime + speed > SDL_GetTicks()) { SDL_RenderCopyEx(Renderer, TheTextureManager::Instance()->TextureList[TexturePath], &SourceRect, &TargetRect, angle, center, flip); return 0; } OldTime = SDL_GetTicks(); //SDL_RenderCopyEx(Renderer, TheTextureManager::Instance()->TextureList[TexturePath], &SourceRect, &TargetRect, angle, center, flip); TheTextureManager::Instance()->draw(TexturePath, Renderer, &SourceRect, &TargetRect, angle, center, flip); CurrentFrame++; if (CurrentFrame == (Frames + 1)) { CurrentFrame = 1; return 1; // returns 1 if one row is finished } return 0; // returns 0 if animation is not finished } return 0; } 

Now I have 1000+ objects, maybe even 2000+ later. Just running a for loop to check if you need to draw objects is very time consuming, right?

What am I missing? How can I track 1000 objects and know if they should be drawn without such a large amount of work for the CPU? Especially since I need a lot of space for a lot of AI

Thanks, it drives me crazy.

Answer 1

To speed up stl container iterators in debug builds (and compilation time due to header parsing) include the following lines in the first header (or precompiled header) before anything else is included (for example, the "Windows.h" header):

 #ifdef _WIN32 # define _CRT_SECURE_NO_WARNINGS // disable the Microsoft specific warnings about _s buffer underrun security issues for ISO methods (fopen, strcpy etc..) # define VC_EXTRALEAN // cut down includes # define WIN32_LEAN_AND_MEAN // cut down includes # undef _SECURE_SCL // iterators generate less overhead code in debug # if _ITERATOR_DEBUG_LEVEL > 0 # define _SECURE_SCL 1 # else # define _SECURE_SCL 0 # endif #endif 

The _iterator_debug_level parameter can be a bit complicated if you reference other libraries that have different iterator_debug_levels parameters.

This will make your debug builds run much faster, but if performance is required, often using containers that require a second look, and finally deploying your own containers is a last resort if your operations are complex or specific.