i created a 2D platformer style game in java in which some parts are simualted by a physics-engine that i programmed myself as well. The problem is that the game slows down to around 30 fps from the intended 60 fps at some points. The game loop looks like this:
#Override
public void run() {
init();
long startTime;
long elapsedTime;
long waitTime;
while(running) {
startTime = System.nanoTime();
update();
long updateTime = (System.nanoTime() - startTime) / 1000000;
draw();
long drawTime = (System.nanoTime() - startTime) / 1000000;
drawToScreen();
long drawscreenTime = (System.nanoTime() - startTime) / 1000000;
elapsedTime = System.nanoTime() - startTime;
waitTime = targetTime - elapsedTime / 1000000;
if(waitTime < 0) {
waitTime = 0;
}
try {
Thread.sleep(waitTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
I am measuring the time that is needed to update the game logic with updateTime and the time that is needed to draw with drawTime and drawscreenTime. At all times (during the slowdowns as well!) the updateTime is 0 ms and drawTime + drawscreenTime is around 10 ms, which is below the maximum of 16 ms (for 60 fps).
So far i have found out that changing the setup of potential collisions of my physical objects can reduce the slowdown. At first i wanted to seperate the objects by zones, so that the program doesnt need to check every object with every object. For example instead of 100x100 = 10000 objects only 33x33 + 33x33 + 33x33 = 3267 objects.
Seperating by zones looked like this:
private ArrayList<PhysicalObject> objects;
private ArrayList<ArrayList<PhysicalObject>> zones;
for(int i = 0; i < numberOfZones; i++) {
zones.get(i).clear();
}
for(PhysicalObject object : objects) {
for(int zone : object.getSimulationZones()) {
zones.get(zone).add(object);
}
}
for(ArrayList<PhysicalObject> list : zones) {
for(PhysicalObject object1 : list) {
for(PhysicalObject object2 : list) {
collision stuff happens
}
}
}
}
The "blunt" approach of chekcing every object with every other object looked like this:
private ArrayList<PhysicalObject> objects;
for(PhysicalObject object1 : objects) {
for(PhysicalObject object2 : objects) {
collision stuff happens
}
}
Now as you might expect the blunt approach is slower when looking at updateTime, but when i use this approach the slowdowns are far less significant.
I dont know how this is happening, since the time needed to do one game loop seems to be unrelated to the slowdowns, but when i change code that runs during the game loop, the slowdowns are varying.
At first i thought that Thread.sleep() might be at fault, since i heard that it is sometimes unreliable, so i tried using a Java.util.Timer. But when i use that with a delay of 16 ms (for 60 fps) the fps are jumping up and down around 30 fps.
I would really appreciate if someone could help me with this.
If you need more Code, I can post more, but since the game-code is already pretty big I figured it would be best to start small and not flood my question even more.
EDIT:
It seems that drawing the game-level has an influence on the slowdowns as well. But instead of slowing down when there are more images to draw, it slows down when there are less images. But again: Even though the slowdowns are decreasing, the drawTime is increasing when there are more things to draw. The code for drawing the level looks like this:
public void draw(Graphics2D g2d) {
for(int row = drawStartRow; row < drawStartRow + rowsToDraw; row++) {
if(row >= numRows) {
break;
}
for(int col = drawStartCol; col < drawStartCol + colsToDraw; col++)
{
if(col >= numCols) {
break;
}
//0 stands for no tile to draw
if(map[row][col] == 0) {
continue;
}
int rc = map[row][col];
int r = rc / numTilesAcross;
int c = rc % numTilesAcross;
g2d.drawImage(tiles[r][c].getImage(), (int)x + col * tileSize, (int)y + row * tileSize, null);
}
}
}
The images in the array were generated via BufferedImage.getSubImage() in the constructor.
EDIT 2:
I was finally able to get rid of the slowdowns by changing the drawing method of my level. Instead of iterating over every spot and drawing the corresponding image, i am now iterating over the different images first and then (for every image) over the spots and drawing them if they belong to the spot.
So overall my loop is times numberOfImages longer, but the slowdowns disappeared. The reason seems to be that I am now drawing every image as often as it needs to be drawn and then going on to the next image. But i dont understand how this is affecting my overall framerate so much, even though the time needed to draw is not changing?
As per the specs of drawImage :
https://docs.oracle.com/javase/7/docs/api/java/awt/Graphics2D.html#drawImage(java.awt.Image,%20java.awt.geom.AffineTransform,%20java.awt.image.ImageObserver)
The drawing may be done asynchronously, which means that the image is not rendered when the function returns. By blocking the thread with Thread.sleep, you may be slowing the rendering. You can do a quick test to check if the image is fully rendered by checking the return value.
Related
I ran into a problem, where doing everything on a single thread may lead to some lags. The problem is, when I start to create loads of new objects (like 300 per second), my physics rate drops.
I sort all rendering objects each frame, so I would know which one to draw in which order, this might be the reason why it can handle only so little, but even if that was removed, there still would be like max operations per update, otherwise physics will lag.
Any ideas on how to achieve the correct zOrder, or remove possible physics lags?
Or detach physics from rendering ... ?
My game loop:
while (isRunning) {
currentFrameTime = System.nanoTime();
passedTime = currentFrameTime - lastFrameTime;
lastFrameTime = currentFrameTime;
physicsPassedTime += passedTime;
updatePassedTime += passedTime;
if (physicsPassedTime >= (double) 1_000_000_000 / physicsRate) {
physicsPassedTime = 0;
PhysicsUpdate();
}
if (updatePassedTime >= (double) 1_000_000_000 / refreshRate) {
updatePassedTime = 0;
Update();
Render();
LateUpdate();
}
}
Looks like the best solution (as suggested in comments) will be to run a second loop on a second thread with just physics update, and everything else on the other thread.
That way frame drops should not intervene with the physic updates.
Edit: Implemented this, and works like charm. I'll mark the answer when I'll be able to.
I have many bitmaps I move around on a surfaceview and sometimes the fps drops which makes the bitmap move slow or super fast randomly, I've seen someone post a solution using system time or something like that, but couldn't find it, so I wonder if anyone knows how can I make the speed be the same even if the fps drops.
Edit:
I thought that maybe I can calculate time different using:
int myFPS;
if(gameLoopThread.startTime!=System.currentTimeMillis())
myFPS=(int) (1000 / (gameLoopThread.startTime-System.currentTimeMillis())*-1);
else
myFPS=25;
float new2=1;
new2=25/myFPS;
and then just multiple
currentSpeed.y += speed*new2;
but it didn't work out because the fps showed was wrong, but I think this is the way to do it? or I might be wrong..
Update:
Single threaded loop:
To keep the speed of your game at a constant rate, you will have to skip rendering at some point, should a loop iteration take longer than expected.
while(isRunning){
beginTime = SystemClock.uptimeMillis();
framesSkipped = 0;
//Update game state
update();
render();
//how long we took to update and render
loopTime = SystemClock.uptimeMillis() - beginTime;
//calculate how long to sleep
sleepTime = loopPeriod - timeDiff;
//All work was done on time.
if (sleepTime > 0) {
try {
Thread.sleep(sleepTime);
} catch (InterruptedException e) {}
}
//We were too slow. Update without rendering.
while (sleepTime < 0 && framesSkipped < MAX_FRAME_SKIPS) {
update();
//make sure we don't keep looping here.
sleepTime += loopPeriod;
framesSkipped++;
}
}
}
This loop prioritizes your logic updates, and skips rendering if we are behind. The benefit is, that your game-actors are updated constantly and independently from possible frame rate drops.
Two threads: (original answer)
Another way to ensure steady movement at low FPS, is to do rendering in one thread, and logical stuff in another one.
Example for the game logic thread:
while(isRunning){
startTime = SystemClock.uptimeMillis();
//update game logic, no rendering.
update();
//time it took to update the game state.
loopTime = SystemClock.uptimeMillis() - startTime;
//pausing here to make sure we update the right amount per second.
if(loopTime < updatePeriod){
try {
Thread.sleep(updatePeriod-updateTime);
} catch (InterruptedException e) {
Log.e(TAG,"Interrupted while sleeping");
}
}
}
The update period is the amount of milliseconds a single update iteration is allowed to take.
updatePeriod = 1000 / ups;
ups = updates per second. If your game runs at 60 fps max, use 60 ups.
Note that both loops are very basic, and, without modification, not suitable for advanced applications.
Also, use SystemClock.uptimeMillis(); it's more reliable.
How I kept track of fps 1000milliseconds / 25 = 40 fps
At the start of the while loop make sure you get the time.
long starttime = System.currentTimeMillis();
Then after everything is finished and rendered you get the time again.
long endtime = System.currentTimeMillis();
Subtract start time from end time then divide by 1000 multiply by -1 to get how many times your runnable can loop in a second.
int MyFPS = (int) (1000 / (starttime - endtime) * -1);
If your answer is 75 then you're running at 75fps.
You just need to put the thread to sleep for 35 milliseconds to be at 40fps.
Tracking the low fps I never got around to doing. Hope this helps a little though.
#Override
public void run() {
while (THREAD) {
long starttime = System.currentTimeMillis();
if (!myHolder.getSurface().isValid())
continue;
Update(); <----Running the game.
Main_Render(); <----Rendering graphics.
long endtime = System.currentTimeMillis();
int MyFPS = (int) (1000 / (starttime - endtime) * -1);
if (MyFPS >= 25) {
sleep_length = MyFPS - 25;
try {
Thread.sleep(sleep_length);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
So, I am working on making a 2D game in Java, and I really don't have too much experience with Java. I currently use a very simple loop using a swing timer running every 10ms or so that looks something like:
public void actionPerformed(ActionEvent e) {
update();
repaint();
}
However, I need something more practical for obvious reasons. These reasons include the fact that more lag means less FPS AND slower movement/other updating.
I found the following code in a tutorial for a 3D Java game here. It would begin running when the program starts, and I understand enough to know it would work. However, I do not fully understand it: (tick() is the updater, render() renders the screen)
long currenttime;
long previoustime = System.nanoTime();
long passedtime;
int frames = 0;
double unprocessedseconds = 0;
double secondspertick = 1 / 60.0;
int tickcount = 0;
boolean ticked = false;
while (gameIsRunning) {
currenttime = System.nanoTime();
passedtime = currenttime - previoustime;
previoustime = currenttime;
unprocessedseconds += passedtime / 1000000000.0;
while (unprocessedseconds > secondspertick) {
tick();
unprocessedseconds -= secondspertick;
ticked = true;
tickcount++;
System.out.println(tickcount);
if (tickcount % 60 == 0) {
System.out.println(frames + " FPS");
previoustime += 1000;
frames = 0;
}
}
if (ticked) {
render();
frames++;
}
render();
frames++;
}
This code was not explained in the tutorial I found it in. Could someone please break this down and explain it?
I have also looked here for ideas, and the final piece of code on that page with a render thread and an update thread makes a lot of sense to me.
Which method should I use? One of the above, or something totally different? Also, you can probably tell that this is my first question here on stackoverflow.
Thanks in advance,
Josh
tick() is probably updating the game object's physical properties (position, velocity, etc.) tick() is called multiple times each update because some simulations can't handle too large a timestep without becoming unstable.
There's a popular article online which explains why this is the case, and why using a fixed timestep is the proper procedure. Check it out.
Each update the game is advanced in 1/60th second (so 60 frames a second) increments. This is repeated until there's less than 1/60th a second remaining in the aggregate. Aggregate is just a fancy word for sum.
Then a snapshot of the game's current state is rendered to the screen.
I won't get too deep into it, but really this code should be inerpolating each object's position by the remaining time in the aggregate during render().
long currenttime;
long previoustime = System.nanoTime();
long passedtime;
int frames = 0;
//this is an aggregate, games usually step in fixed units of time.
//this is usually because physics simulations can't handle too large of time steps.
double unprocessedseconds = 0;
double secondspertick = 1 / 60.0;
int tickcount = 0;
boolean ticked = false;
while (gameIsRunning) {
//get elapsed nano seconds from the epoch (january 1st, 1970)
currenttime = System.nanoTime();
//take difference of current time in nanos and previous time in nanos
passedtime = currenttime - previoustime;
previoustime = currenttime;
//divide to get the elapsed time in seconds.
unprocessedseconds += passedtime / 1000000000.0;
while (unprocessedseconds > secondspertick) {
tick();
unprocessedseconds -= secondspertick;
ticked = true;
tickcount++;
System.out.println(tickcount);
if (tickcount % 60 == 0) {
System.out.println(frames + " FPS");
previoustime += 1000;
frames = 0;
}
}
if (ticked) {
render();
frames++;
}
render();
frames++;
}
Good luck Josh.
Edit:
I have no experience with games using one thread for updates, and one for rendering. I can't give advice on those for that reason. If you have little or no experience with multithreading I'd avoid it as only complex games are likely to require this approach, and multithreading will add a multitude of issues you probably don't want to deal with.
Multithreaded game engines will consume more memory between rendering and updating than a single threaded game, or will wind up being depend on one another anyway. This is because the two threads can't manipulate the same data simultaneously. Therefor the only way for the two threads to operate is with synchronization on those data structures, or by the update thread suppling the render thread with immutable data to render.
Writing a multithreaded game engine would be a good introduction to threading. It could teach you quite a lot. Depends on what you want to get out of this.
If you are making a 2D game I feel even more confident that you will not need one thread for updating and one for rendering.
If you really want to pursue this, here's the approach I'd take.
You don't need more than a while loop to control rendering.
The way I do my engines is just as explained before, I multi-thread. Basically, if you split the job of processing and drawing the game into two segments it becomes quicker at the expense of more resources in use. I do a little something like this:
public class Engine implements Runnable {
//Sets classes
Engine tick = new Engine(true);
Engine render = new Engine(false);
Thread tickThread = new Thread(tick);
Thread renderThread = new Thread(render);
boolean job;
boolean isRunning = false;
long sleepTime = 5L;
public Engine(boolean job) {
//Sets what the thread does
this.job = job;
}
public static void startEngine() {
//Starts Engine
isRunning = true;
tickThread.start();
renderThread.start();
}
public void tick() {
//Process things
}
public void render() {
//Draw things
}
public void run() {
//Do engine base things
while(isRunning) {
if(job) {
tick();
} else {
render();
}
Thread.sleep(sleepTime);
}
}
}
This is by no means advanced. This is just an example of what a simple multi-thread game engine would be like. Honestly, I used this exact code when I was starting off making games. This could be used but some adjustments should be made depending on what you use it for. What I mean is that lets say you have an object that's moving and its being rendered at the same time. If the objects position is 50 and increasing and the render method is drawing it then the object could go to 51 then 52 before being rendered again. Normally, the processing is faster than the drawing. Another example: Lets say you have an ArrayList and are constantly removing and adding objects to it. Sometimes you can remove an object just as the render method is about to draw it and cause a null pointer exception because it's trying to draw something that doesn't exist. (I used "if(object.get(i) != null)" and worked around it that way)
I hope this helped at least a little (two years later, lol) and helped you get a basis of what multi-threading is like (if you didn't already).
I'm making a basic 2D game, yet I'm having problems with lag. The character on the game moves fine, yet sometimes slows right down, mainly when near an enemy. The enemy is not causing the lag though, as I've had 50 of them on the screen at once and it runs fine.
I've done the timing almost identically to how it's done in the Killer Game Programming in Java book, yet it doesn't seem to work too well. The FPS also seems to change a lot, which it shouldn't, because it should always take 15ms to complete an update-render-paint-sleep cycle, can anyone explain this?
Also, I think it lags more when my computer is doing things in the background (antivirus scanning, etc.), although I can run the game at about 550FPS while it's running other programs, so I don't think it's my computer.
Here's how I do the timing:
int waitTime = 1000 / 65; //65 being the desired FPS
while(running){
if(!loading){
gameUpdate();
gameRender();
gamePaint();
afterTime = System.nanoTime();
timeDiff = afterTime - beforeTime;
sleepTime = waitTime - (timeDiff / 1000000L);
if(sleepTime > 0){
try{
mainThread.sleep(sleepTime);
} catch(InterruptedException ie){}
}
else{
sleepSkipped++;
if(sleepSkipped == maxSleepSkipped){
Thread.yield();
sleepSkipped = 0;
}
}
fpsTime += (System.nanoTime() - beforeTime) / 1000000;
fps++;
if(fpsTime > 1000){
System.out.println("FPS: " + fps);
fps = 0;
fpsTime = 0;
}
beforeTime = System.nanoTime();
}
}
I think your problem is similar to one very recently Weird behavior in Thread.sleep()
I see that in your loop you add the sleeptime to your timer, meaning it keeps increasing (lowering fps) until it becomes so large that substracting the waittime from it gives a negative number, making your loop go into the one that yields the thread where it adds to the skipcount and yields when the count is high enough.
As arynaq suggested, it was a problem with the enemy collision detection. Every cycle through the loop made each enemy call quite a few methods, however I have now removed and relocated many of the method calls, which has completely fixed the lag problem. Thank you, arynaq.
I'm writing a fairly simple 2D multiplayer-over-network game. Right now, I find it nearly impossible for myself to create a stable loop. By stable I mean such kind of loop inside which certain calculations are done and which is repeated over strict periods of time (let's say, every 25 ms, that's what I'm fighting for right now). I haven't faced many severe hindrances this far except for this one.
In this game, several threads are running, both in server and client applications, assigned to various tasks. Let's take for example engine thread in my server application. In this thread, I try to create game loop using Thread.sleep, trying to take in account time taken by game calculations. Here's my loop, placed within run() method. Tick() function is payload of the loop. It simply contains ordered calls to other methods doing constant game updating.
long engFPS = 40;
long frameDur = 1000 / engFPS;
long lastFrameTime;
long nextFrame;
<...>
while(true)
{
lastFrameTime = System.currentTimeMillis();
nextFrame = lastFrameTime + frameDur;
Tick();
if(nextFrame - System.currentTimeMillis() > 0)
{
try
{
Thread.sleep(nextFrame - System.currentTimeMillis());
}
catch(Exception e)
{
System.err.println("TSEngine :: run :: " + e);
}
}
}
The major problem is that Thread.sleep just loves to betray your expectations about how much it will sleep. It can easily put thread to rest for much longer or much shorter time, especially on some machines with Windows XP (I've tested it myself, WinXP gives really nasty results compared to Win7 and other OS). I've poked around internets quite a lot, and result was disappointing. It seems to be fault of the thread scheduler of the OS we're running on, and its so-called granularity. As far as I understood, this scheduler constantly, over certain amount of time, checks demands of every thread in system, in particular, puts/awakes them from sleep. When re-checking time is low, like 1ms, things may seem smooth. Although, it is said that WinXP has granularity as high as 10 or 15 ms. I've also read that not only Java programmers, but those using other languages face this problem as well.
Knowing this, it seems almost impossible to make a stable, sturdy, reliable game engine. Nevertheless, they're everywhere.
I'm highly wondering by which means this problem can be fought or circumvented. Could someone more experienced give me a hint on this?
Don't rely on the OS or any timer mechanism to wake your thread or invoke some callback at a precise point in time or after a precise delay. It's just not going to happen.
The way to deal with this is instead of setting a sleep/callback/poll interval and then assuming that the interval is kept with a high degree of precision, keep track of the amount of time that has elapsed since the previous iteration and use that to determine what the current state should be. Pass this amount through to anything that updates state based upon the current "frame" (really you should design your engine in a way that the internal components don't know or care about anything as concrete as a frame; so that instead there is just state that moves fluidly through time, and when a new frame needs to be sent for rendering a snapshot of this state is used).
So for example, you might do:
long maxWorkingTimePerFrame = 1000 / FRAMES_PER_SECOND; //this is optional
lastStartTime = System.currentTimeMillis();
while(true)
{
long elapsedTime = System.currentTimeMillis() - lastStartTime;
lastStartTime = System.currentTimeMillis();
Tick(elapsedTime);
//enforcing a maximum framerate here is optional...you don't need to sleep the thread
long processingTimeForCurrentFrame = System.currentTimeMillis() - lastStartTime;
if(processingTimeForCurrentFrame < maxWorkingTimePerFrame)
{
try
{
Thread.sleep(maxWorkingTimePerFrame - processingTimeForCurrentFrame);
}
catch(Exception e)
{
System.err.println("TSEngine :: run :: " + e);
}
}
}
Also note that you can get greater timer granularity by using System.nanoTime() in place of System.currentTimeMillis().
You may getter better results with
LockSupport.parkNanos(long nanos)
altho it complicates the code a bit compared to sleep()
maybe this helps you.
its from david brackeen's bock developing games in java
and calculates average granularity to fake a more fluent framerate:
link
public class TimeSmoothie {
/**
How often to recalc the frame rate
*/
protected static final long FRAME_RATE_RECALC_PERIOD = 500;
/**
Don't allow the elapsed time between frames to be more than 100 ms
*/
protected static final long MAX_ELAPSED_TIME = 100;
/**
Take the average of the last few samples during the last 100ms
*/
protected static final long AVERAGE_PERIOD = 100;
protected static final int NUM_SAMPLES_BITS = 6; // 64 samples
protected static final int NUM_SAMPLES = 1 << NUM_SAMPLES_BITS;
protected static final int NUM_SAMPLES_MASK = NUM_SAMPLES - 1;
protected long[] samples;
protected int numSamples = 0;
protected int firstIndex = 0;
// for calculating frame rate
protected int numFrames = 0;
protected long startTime;
protected float frameRate;
public TimeSmoothie() {
samples = new long[NUM_SAMPLES];
}
/**
Adds the specified time sample and returns the average
of all the recorded time samples.
*/
public long getTime(long elapsedTime) {
addSample(elapsedTime);
return getAverage();
}
/**
Adds a time sample.
*/
public void addSample(long elapsedTime) {
numFrames++;
// cap the time
elapsedTime = Math.min(elapsedTime, MAX_ELAPSED_TIME);
// add the sample to the list
samples[(firstIndex + numSamples) & NUM_SAMPLES_MASK] =
elapsedTime;
if (numSamples == samples.length) {
firstIndex = (firstIndex + 1) & NUM_SAMPLES_MASK;
}
else {
numSamples++;
}
}
/**
Gets the average of the recorded time samples.
*/
public long getAverage() {
long sum = 0;
for (int i=numSamples-1; i>=0; i--) {
sum+=samples[(firstIndex + i) & NUM_SAMPLES_MASK];
// if the average period is already reached, go ahead and return
// the average.
if (sum >= AVERAGE_PERIOD) {
Math.round((double)sum / (numSamples-i));
}
}
return Math.round((double)sum / numSamples);
}
/**
Gets the frame rate (number of calls to getTime() or
addSample() in real time). The frame rate is recalculated
every 500ms.
*/
public float getFrameRate() {
long currTime = System.currentTimeMillis();
// calculate the frame rate every 500 milliseconds
if (currTime > startTime + FRAME_RATE_RECALC_PERIOD) {
frameRate = (float)numFrames * 1000 /
(currTime - startTime);
startTime = currTime;
numFrames = 0;
}
return frameRate;
}
}