I have this issue with Box2D physics where objects will tunnel through walls if the lag in the game is high enough. The game lag is something I'm working on but I think its kinda inevitable that something is eventually going to cause the game to lag and the last thing I want is for the player to walk through a wall when the lag spikes just enough.
Yes I've turned on continuous collision detection and enabled the objects I want to have bullet physics but the problem persists. Any advice? I thought maybe if I slowed the world down proportional to the FPS but I'm not sure how to implement this cleanly or if cocos2d/box2d had a simple fix for this type of issue.
Try using a fixed timestep. Variable timesteps are generally disadvantegous for physics simulation.
Related
I guess I have some explaining to do:
I'm fairly new to game programming, so please don't get mad if I don't understand a concept immediately
The game makes use of DirectX 10 and is written in C++
It's very simple 2D game
The situation: Despite of being very simple in both game logic and graphics, it still takes my CPU and GPU load to 100%. Even the menu is displayed with more than 2000 frames per second.
My problem is not that the game runs too fast. I already timed sprite animations and game logic using the QueryPerformanceCounter function.
The actual problem is that the game calculates the same code numerous times without anything happening on the screen, therefore putting a massive load on my hardware.
In what ways can I decrease the hardware load of my game? I feel like using Sleep is "cheating".
Thank to Damon for pointing me in the right direction, I looked into the present function. (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174576(v=vs.85).aspx)
All it took to solve both CPU and GPU load problems was changing
swapChain->Present(0, 0);
to
swapChain->Present(1, 0);
Just a quick suggestion:
Everytime you enter the game loop calculate the time passed since the last time you entered.
If this time is below a given threshold just return without processing anything.
I'm working on a game where you have to watch out for a ball that bounces around the screen (bounces at the edges of the screen). I am using cocos2d together with chipmunk. In chipmunk I have defined 0 gravity and 0 friction, so that the bouncing ball keeps it's original speed after every bounce.
However, I want to introduce a special type of bouncing ball that gets a temporary speed boost for a couple of seconds and then return to it's original speed.
Is there a nice chipmunk way of doing this, a sort of temporary impulse that one can add? Or do I have to do it the long way manually, by storing the original speed and keeping track of how long (how many cycles) the boosted speed has been running and resetting the original speed at the end of the "boost" period?
Chipmunk doesn't provide timers and such like that, but Cocos2D does.
I am making a game similar to bust-a-move for the iphone. I am using cocos2d. I am encountering lag sometimes during the game. I have 6 different types of balls. I am creating 30 instances of each type and I reuse them. The problem comes when I shoot the ball and the ball does not collide with either the wall on the sides or the balls on the screen. I believe it may be due to a lag. When the ball is shot I initialize a scheduler to run every 0.01s to check if it collides with any of the other balls. In each interval I create a rect for the ball that was shot and create a rect for all other balls and check for intersection.
I was wondering what the reason for the lag could be. I am also trying to figure out if there is any bottle neck by using the Instruments. Could having a lot of images loaded cause lag? or could a lot of numerical computation be the reason?
It would be helpful if you can share any similar experiences or if you can suggest some possible reasons for lag and how to avoid them.
Thanks
Abhinav
a 100Hz (0.01sec) timer is going to slow your game right down. Most PC's can't even handle a scheduler with that frequency (mainly, the OS overhead, but I digress).
Highly recommend that you use the CCLayer update method instead of a Scheduler or NSTimer.
OK,So i've figured out the problem :)
The thing is, in my game I am loading 100 balls. 20 of each of the 5 types. Besides that I am also loading some explosion animation and some other animated creatures. So the problem comes because each texture was loaded individually even though most of them are using the same texture. So each frame 120 odd textures were loaded.
The solution is to use Batchnode. So instead of 20, now I load only 1 texture. So in total instead of 120 I am now loading only 6 or 7 :) Now all the lag and lag related bugs are gone.
[[CCTextureCache sharedTextureCache] addImage:#"ball-black.png"];
SpriteSheet1 = [CCSpriteBatchNode batchNodeWithFile:#"ball-black.png"];
[self addChild:SpriteSheet1 z:4];
//---------FIRE BALLS---------
for (int i = 0; i<20; i++)
{
f[i] = [[Fire alloc]init];
//[f[i] getball] = [CCSprite spriteWithFile:#"ball-black.png"];
[SpriteSheet1 addChild:[f[i] getball]];
[[f[i] getball] setPosition:ccp(220,-200)];
f[i].isBallMoving = FALSE;
}
Hope it helps someone with the same problem.
Thanks Stephen for your replies :)
I'm planning to build a basic rebound iOS game in Cocos2D. Will Box2D be best suited for the following scenario?
The layout will consist of a target at the top of the screen, with obsticles in the middle of the screen, blocking direct view of the target from the bottom. The user will shoot a ball from the bottom of the screen by rebounding it of the sides and around the obsticles, aspiring to hit the target. Similar to a breakout style of game.
As the game levels progress, the obsticles will be moving dynamically, left to right and back, up and down etc..
I understand that the collision detection can be achieved using Cocos2D alone. Can the rebounding and trajectory of the ball off obsticles and walls also be achieved without using a physics engine?
I will have no need for gravity in the game scenario. A reduction in the velocity/speed of the ball will be essential.
Please note, I am new to iOS dev, coming from a background in front-end web dev.
Advise and help much appreciated.
Thanks
You certainly can do all that without using an existing physics engine. Once you start doing collisions with moving objects and objects of different shapes, though, it starts to become advantageous to use an out of the box solution.
It's easy to setup box2d without gravity and it will give you all of the collision calculations and velocity stuff
I want to make a 2D game that is basically a physics driven sandbox / activity game. There is something I really do not understand though. From research, it seems like updates from the server should only be about every 100ms. I can see how this works for a player since they can just concurrently simulate physics and do lag compensation through interpolation.
What I do not understand is how this works for updates from other players. If clients only get notified of player positions every 100ms, I do not see how that works because a lot can happen in 100ms. The player could have changed direction twice or so in that time. I was wondering if anyone would have some insight on this issue.
Basically how does this work for shooting and stuff like that?
Thanks
Typically, what will happen is that the player will view the game 100ms behind how it actually is. That, and you have to accept that some game designs just require faster server updates. Typically, games that need faster server updates use client/server model where the server computes all the physics, not the client. You've seen the traditional RTS model- peer2peer, slow updates. But the traditional model for FPS games is client/server, fast updates, for this exact reason.
There is a forum entry and a whole multiplayer/network FAQ on GameDev on this topic that might be a good first read.
You have to design your game to take his into account. For example if you're shooting a target that could move out of the way suddenly, just have shells with proximity fuses and make lots of noise and pretty colours for a while, hiding the fact neither your nor your player actually knows yet if they hit the target.
In fact this is pretty close to real physics: it takes time for the consequences of actions to be observed.