To give some background information, I'm currently working on a Java coded pinball game. I'm keeping it in an MVC design model. It has a fairly realistic physics system that allows it to work collisions, gravity, friction etc. The system runs on a 20 FPS system right now.
The problem I'm having is that the physics loop that checks for collisions in the system works by running a method that using the current velocity of the ball calculates the time until the next collision. The most effective way for this to work would obviously be to keep running the check to account for the movement of the ball between checks to get it as accurate as possible, and if the time until collision is less than the time until the next check, then carry out the collision.
However, right now the system I am working with can only run the loop 20 times per second, which does not provide as accurate results as I would like, particularly during times of high acceleration, such as at ball launch.
The timer loop that I use is in the controller section of the MVC, and places a call to the physics section, located within the model. I can pass in the time remaining at the time the method is called in the controller, which the physics system can use, however I don't know how to run the loop multiple times while still tracking the remaining time before the next screen refresh?
Ideally I would like to run this at least 10 times per screen refresh. If anybody needs any more information please just ask.
Thanks for any help.
So the actual problem is that you do not know when the the collision will happen and when the next frame update is?
Shouldnt these be seperate running tasks? One thread that manages the collision detection and one that does the updating? each thread can run on its own interval (Timer.addTask(...)) and they should propebly be synchronized so colission/location updates are not performed when the render thread is executed.
Hope this answers your question.
Regards, Rob.
Related
With the languages and libraries I've worked so far, there was always an option to sync the main loop of the program (a game or anything with an always changing context) to the current display's refresh rate. So I had the option to either switch on VSYNC or just let the loop execute as many times per second as it could. I'm referring to SDL2, OpenGL 3.0 with GLFW, the HTML5 canvas etc.
I'm looking for something similar on Android now in OpenGL ES 2.0, but so far all the example code I can find simply uses a variation of sleep and set the framerate to 60 or 30. So they basically count the amount of time passed since the last iteration, and only advance further and call the requestRender() function if a given amount of time has passed (0.016 ms in case of 60 frames per second etc.).
I'm simply wondering if there's a better option than this or not. I'm just concerned that not every phone has the same screen refresh rate, so hard coding any amount doesn't seem to be a desired method. As far as I understand it is not that simple to figure out the given phone's refresh rate, or at least it is not possible with "pure" Java and OpenGL.
What you need to do is match the display's frame rate, and advance game state according to how much time has elapsed since the previous frame. There are two ways to go about this:
Stuff the BufferQueue full and rely on the "swap buffers" back-pressure.
This is very easy to implement: just swap buffers as fast as you can. In early versions of Android this could actually result in a penalty where SurfaceView#lockCanvas() would put you to sleep for 100ms. Now it's paced by the BufferQueue, and the BufferQueue is emptied as quickly as SurfaceFlinger is able.
Use Choreographer.
Choreographer allows you to set a callback that fires on the next VSYNC. The actual VSYNC time is passed in as an argument. So even if your app doesn't wake up right away, you still have an accurate picture of when the display refresh period began. Using this value, rather than the current time, yields a consistent time source for your game state update logic.
source: https://source.android.com/devices/graphics/arch-gameloops
I have studied a lot in SO to find an answer for this but non of the documents can explain the performance phenomena I measure in my app. The standard answer is to log the time at the beginning and end of the onDraw method and then the delta is the time consumed. Of course I have done this but it does not explain the entire time consumed by the application before the screen is refreshed. So I wonder whether there is an element of activity on system level which I am not aware of.
Now more details:
The app works on a Nexus 7 with Android Version 5.1.1.
Purpose of the app is to show graphically the layout of a golf course while the player moves over the fairway. The player position is retrieved by GPS signals (onLocationChange). Whenever the position of the player has changed (which is happening almost every second when he is walking), the graphical layout of the area has to be redrawn since distances, orientation etc. have now changed with the new view point.
(I think it would not help to copy the code here because it would be too much to study. Furthermore this is more a principle question about understanding the architecture correctly.)
To simplify it we can say that the app has two main tasks:
A) retrieving new location information via GPS in a short interval of 1 or 2 seconds (depending on the movement).
B) Drawing the golf course's hole layout again based on the new position as
given from A.
The phenomena I measure from my logging over a period of 15 minutes in which many redraws happen naturally is that there is obviously a third big unknown time consumer beside the computations of A) and B). Lets call it X). The expected sequence in my logs would be like:
A
B
A
B
...
What I notice is this:
A
B
A
X
B
...
A
B
X
A
A
A
A
B
It means the duration of X which can grow to 5 seconds (while B performs in an average of 200ms) is so big that once it is done, obviously a number of queued events of A (new GPS positions) arrive in an interval of milliseconds.
Furthermore I notice that the duration of X grows with the time the app runs so that at the end the app cannot respond anymore.
I have read about the rendering thread and wonder whether this is the candidate for X. But what I understood from those documents is that the rendering thread time is covered by the time consumed in onDraw (B in my example). The impression I get however is that the program updates the canvas (B) and that then the device (or the OS ?) needs some considerable time to make it visible. However I could not find any documentation or SO case giving such an indication. So, if somebody could explain how the system mechanism works conceptually and (ideally) how this explains the phenomena measured above, it would be highly appreciated.
Last remark: Of course I have read a lot about how to keep the UI thread responsive, using Asynctask etc. I also intend to implement this but I cannot expect based on the measured phenomena above that this will cure my problem. It might reduce the time slice for B on the main thread but as long as I cannot identify the main consumer of X, it is unlikely Asynctask can reduce the overall performance of the program.
Systrace will allow you to profile your app and see what is taking up the time. https://developer.android.com/studio/profile/systrace.html
I was wondering how I would use multiple threads in an applet at the same time. I'm creating a game like Space Invaders and I wrote all the code for the enemies to move and shoot but I can't add the player in to move around using the keyboard at the same time as the enemies. So I was thinking I needed to have 2 different threads running. I would upload the code but there is a lot of different classes and code.
If someone could help me out quick I would appreciate it a lot.
Yes they are independant of each other i got my single thread that moves the enemies in the run() method that i overloaded and all my movements are in the paint method.
should they be somewhere else?
You can do this with one thread, or with two.
Either way you have to work with the GUI Event Thread to do all the screen updates.
There is a lot of reference on the web discussing how to do this. If you google java space invaders you get 1.5 million hits and usually the first page of such a search has more than what you need.
I think the enemies are independent and have particular movements, if that's the case, you will need several threads enemy, and for each player, but taking into account the resources of the computer you should deal with a manager thread or task managers.
These are links that maybe help you.
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/CyclicBarrier.html
So i'm writing an app for android where you play a game similar to Dutch Blitz. Its a pretty simple game, and I have it basically finished, I'm mostly looking for advice for how to handle my AI opponents, right now they win the game in about 2 seconds, I was wondering what i should do to get them to "pause" mid loop or how to slow them down some how so that the user has a chance to actually win.
I just don't want my way to slow them down dependent on the processor speed of the phone used...
I'm not familiar with the game Dutch Blitz, but this logic should apply. You can create your turn functionality triggered by a Count Down Timer. That function repeated (think of this as a turn) will eventually equate to a win condition. Causing your AI to prevale eventually, but not right away. You can then set the rate of how often a turn happens, thus controlling the rate at which your AI will win. Also this makes it easy to set difficulty levels by increasing the time it takes your AI to complete a turn.
Your game may work with different rules, but some kind of interval per turn would probably be the simple way to control the speed of your AI.
I've been working on a little proof of concept game that has a rolling environment in the background (2D). I have a custom class object called roadTile, which basically is a 200px tall block with a picture to paint on and some physics. I'm storing the tiles in a LinkedList 5 at a time. I have a main loop that is responsible for moving everything and checking for collisions. The loop is supposed to be performed every 50ms (controlled by a timer) and it keeps the rate fixed by measuring the length of the last run and then taking deducting it from the sleep-time.
This usually runs fine and the loops run in less than a millisecond, but when I start the program, it "chokes" after the first 2-7 times. I removed the old tile and put a new one on the bottom of the list. On calling the add (new roadTile()), the program halts for 20-400ms which is a millenium in computer time, and to top this off, the behavior isn't consistent. Sometimes it works fine some times not.
I'm pretty clueless how to eliminate this, any thoughts?
Make sure that you cache everything before you start working with graphics. This might be the cause of your delay.