Jump to content
  • Advertisement
Sign in to follow this  
tristan1333

Handling Projectiles in SDL C++

This topic is 510 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm making a game currently, it's a 2d platformer. I've got characters working and recently implemented a projectile system for archers. However, when there's about 50-100 projectiles on screen, the performance is majorly hit. I tried it on my home computer, and it isn't really playable at all. On other computers it's fine and works mostly perfectly, but my friend said his fan got louder so uhh... There's obviously a few minor optimization issues. The way it currently works is, (this is not a particularly good way to do it I know but it's temporary) check against the players rectangle and the projectile in questions rectangle (This is a for loop against a vector containing all of the projectiles). If there's a collision, hit the player and delete the projectile. I've thought about making it that it only checks when a certain x value away, however, that would lead to the issue of nuking the persons fps when they come close to the projectiles. Is there a proper way to handle these projectiles, or is my pc just terribly, terribly awful?

Edited by tristan1333

Share this post


Link to post
Share on other sites
Advertisement

I should mention this is sloppy BUT wip so ehhh yeah.

void handle_projectiles()

{
	for(int i = 0;i < P_List.size();i++)
	{
		if(P_List[i].x > cam.x + 1000 || P_List[i].x < cam.x - 1000)
		{
			P_List.erase(P_List.begin() + i);
			i--;
			continue;		
		}
		P_List[i].travel();
		int renderx,rendery;
		if(P_List[i].x  > cam.x)
		{
			renderx = SCREEN_WIDTH/2 + (P_List[i].x - cam.x); 
		}
		else
		{
			renderx = SCREEN_WIDTH/2 - (cam.x - P_List[i].x);
		}
		if(P_List[i].y  > cam.y)
		{
			rendery = SCREEN_HEIGHT/2 + (P_List[i].y  - cam.y);
		}
		else
		{
			rendery = SCREEN_HEIGHT/2 - (cam.y - P_List[i].y);
		}
		SDL_Rect position_rect;
		P_List[i].collbox.x = renderx;
		P_List[i].collbox.y = rendery;
		P_List[i].collbox.w = P_List[i].w;
		P_List[i].collbox.h = P_List[i].h;
		SDL_RenderCopyEx(mainren,P_List[i].display,NULL,&P_List[i].collbox, 0,NULL,P_List[i].flip);
		//renderTexture(P_List[i].display,mainren,renderx,rendery);
	}
}
		for(int a = 0; a < P_List.size();a++)
		{
			if(SDL_HasIntersection(&P_List[a].collbox,&mainchar.pos_rect))
			{
				if(mainchar.last_hit + mainchar.hit_timer > SDL_GetTicks())
				{
					continue;
				}
				int x_pw = 2;
				int y_pw = -2;
				if(P_List[a].velocity < 0)
				{
					x_pw = -x_pw;
				}
				mainchar.set_knockback(x_pw,y_pw,50,20);
				P_List.erase(P_List.begin() + a);
				a--;
				continue;
			}
		} //Checks the intersection between projectiles.

There's alot to sort through, but I think that's the most relevant. 

Share this post


Link to post
Share on other sites

Put the timer vs. ticks check outside of the loop. There's no point iterating through all of P_List and running SDL_HasIntersection checks if you're just going to ignore the result anyway.

 

You're not showing what type P_List is (vector?) and erasing things from the middle of vectors can be slow, but it happens infrequently enough that it shouldn't be your problem.

 

Most likely the problem isn't directly in the code you've posted. Comment bits out and see how the performance changes. Perhaps make a test case where you don't actually render anything. And another test case where you don't bother with the intersection test. Better still, run it through an actual profiler if you can.

 

The fan getting louder isn't unusual. A game is usually asking a computer to do more than a browser or word processor is, so the CPU gets hotter and the fan works harder. No big deal. You might want to make sure your main loop is either waiting for vsync or otherwise pausing, if you don't think you need 100% CPU.

Share this post


Link to post
Share on other sites

If you feel your computer is terribly slow then I'll bet there are a lot of people in this world that are in your same situation.  So checking your code against a slow computer is a good thing because then you find places your algorithms really hamper your game.

If your running into calculation issues on 50-100 projectiles then it is time to really optimize your code.  But there are many solutions to this problem and without knowing a little more about the game mechanics it will be difficult to provide you a decent answer.  Is this a top down tank shooting type game? Or is this a side scroller game where your projectiles have a limited direction of flight.

Either way one thing you might look into doing is breaking your collision tests into groups so that your not testing every collider in the game world against every projectile.  For example if there is a collider located in the opposite direction the projectile is flying then there is no reason you should every test those two colliders.  Many physics engines will break their collision system into groups of close objects.  This way an object that is on the far lower right of the game field isn't being tested against an object in the upper left corner.  You may need to use a different type of data structure that help you sort through all your colliders and collect objects within a certain amount of distance for each other.

It sounds like you are rolling your own physics system.  If this is the case then maybe look at Box2D since all the code is open source you can see how they handle collisions in their system and also the different types of data structures they use to manage the physics world.  You may also want to look at a couple of books that discuss these concepts.  I've read "Game Physics Engine Development: How to Build a Robust Commercial-Grade Physics Engine for your Game" and he goes into great detail about handling the physics world.

Edited by lede

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!