I am developing an Android game using Unity and in my game I am instantiating objects which move in x direction visible to camera and when they leave camera view they are destroyed, to stop slowing the processing and taking memory. It works fine, but when my player moves in vertical direction there are objects which are instantiated but they are out of camera view, and then they are not destroyed. Therefore, when my objects are out of camera view I want to stop invokeRepeating. Here is the code which works only when objects are in view.
public GameObject colorbar;
public Vector2 velocity = new Vector2(-3, 0);
void Start () {
GetComponent<Rigidbody2D>().velocity = velocity;
transform.position = new Vector3(transform.position.x, transform.position.y, 0);
InvokeRepeating("CreateObstacle", 1f, 1.8f);
}
// Update is called once per frame
void Update () {
}
public void OnBecameInvisible()
{
Destroy(colorbar);
Debug.Log ("Color bar is Destroyed");
}
void CreateObstacle()
{
Instantiate(colorbar);
Debug.Log ("Color bar instantiating");
}
}
You can check if the renderer is visible when you create the object:
http://docs.unity3d.com/ScriptReference/Renderer-isVisible.html
void Awake(){
if(GetComponent<Renderer>().isVisible == false){
Destroy(this.gameObject);
}
}
But best would be to avoid creation if not needed, so you could get the point where you object should be created, then convert to screen point:
http://docs.unity3d.com/ScriptReference/Camera.WorldToScreenPoint.html
if the value is within the boundaries of the screen, then you good. You could also linecast from position to camera and if there is nothing stopping the cast, you are double good to create.
Vector3 pos = ObjectPos;
Vector3 screenPos = Camera.main.WorldToScreenPoint(pos);
if(screenPos.x > 0 && screenPos.x < Camera.main.pixelWidth &&
screenPos.y > 0 && screenPos.y < Camera.main.pixelHeight && screenPos.z > 0)
{
if (Physics.Linecast(pos, Camera.main.transform.position) == false){
// Create object
}
}
Keep in mind this is using the position of the object. If your object is large, then the position may be outside while some edges would be inside. The best would be to check for each vertex of the mesh. But if you have a complex mesh, that might get expensive, if you deal with a cube then maybe.
Related
I implemented input for my mobile game like so:
I have some buttons and I have anywhere else on the screen.
Basically when the player touches the screen and not a button ingame, the character jumps. Now, It is implemented by using OnPointerDown and OnPointerUp that sets a bool:
public class JumpInput : MonoBehaviour
{
public static bool JUMP;
public void PointerDown()
{
JUMP = true;
}
public void PointerUp()
{
JUMP = false;
}
}
If the player is jumping, it is checked by a FixedUpdate method:
if (!movementDisabled && grounded && JumpInput.JUMP)
{
//then we can jump
currentImageIndex = 0;
animState = CharAnimStates.jumpStart;
//added again from here
//zeroing out the Y axis velocity if we had one
rb2d.velocity = new Vector2(rb2d.velocity.x, 0.0f);
//until here
jump = true;
}
As I get decent frame rates even when using post-processing, I have no clue why the input is so delayed. I require assistance to verify if my solution for "anywhere on the screen input" is viable performancewise and it not, how to improve it.
I am making a game in which my player is a UFO, and when the player collides with other game objects, I need the game objects to be attached or floated in the air below the player (UFO), like original UFO. I tried to attach them as a child, but it didn't worked.
I made one script as below:
if (coll) {
distance = Vector2.Distance (this.transform.position, player.transform.position);
if (distance < 2) {
this.transform.parent = encaixe.transform;
this.transform.localPosition = new Vector2 (0f, 1.2f);
this.transform.localRotation = Quaternion.identity;
encaixe.rigidbody2D.gravityScale=0;
}
}
In using this script, the gameobject is attaching, but the player is not moving as like original. The game object is pulling down or up forcefully.
Please suggest to me how to do this.
I know that this Thread is rather old, but maybe someone might come across this question and is in need of an answer.
You can actively set the Object's Position and Rotation to the UFO's on Collision.
Something like the following (pseudocode):
private bool hasCollided = false;
void OnCollisionEnter()
{
hasCollided = true;
}
void LateUpdate()
{
if (hasCollided)
{
followPlayer();
}
}
void followPlayer()
{
//update position and rotation
}
I'm trying to implement a MiniMax algorithm in a Reversi/Othello game, and I'm pretty stuck, since the function I wrote looks perfectly normal, and yet I get some strange moves, and a crash after a few. Here's the function finding an optimum move:
public Field findBestMove(GameBoard gb, int depth, int player)
{
if(depth >= max_depth) return null;
ArrayList <Field> moves = findAllPossibleMoves(gb, player);
Field best_move = null;
/** iterating over all possible moves, to find the best one */
for (int i=0; i<moves.size(); i++)
{
/* board to simulate moves */
GameBoard temp_board = new GameBoard(gb);
Field move = moves.get(i);
game.move(move, temp_board, player);
int opposite_player = player == GameBoard.WHITE ? GameBoard.BLACK : GameBoard.WHITE;
Field best_deep_move = findBestMove (temp_board, depth + 1, opposite_player);
/** if the maximum depth is reached, we have a null, so we evaluate */
if (best_deep_move == null)
{
/** we rate it according to the evaluation table */
move.setRating(evaluate (temp_board, player));
}
else
{
move.setRating(best_deep_move.getRating());
}
if(best_move == null)
{
best_move = move;
}
else
{
if (depth%2==0)
{
/** for us, we look for the maximum */
if (best_move.getRating() < move.getRating()) best_move = move;
}
else
{
/** for the opponent, we look for the minimum */
if (best_move.getRating() > move.getRating()) best_move = move;
}
}
}
return best_move;
}
After each move, the active player is changed. In the onTouchEvent method of the GameView, first the player makes his move, and then the player is changed to the WHITE one, which is the AI, and it makes a move. It should search for the best move in his tree, and then perform ONE move, instead he does several weird moves. I've no idea why, for each branch I create a new copy of a board, so I have no idea why the main game board gets modified.
Any ideas?
If changing a copy of an object affects the original. Then it is a "shallow copy". That means that somewhere in data structure objects are shared. You want a "deep copy".
Show us the code for new GameBoard(gb)
Some optinos: you can implement clone for your Gameboard and all of the objects it contains (and that they contain). Or, implement an undo() function in your game board. As long as you undo every move in your gameboard you can perform moves on it. That would save memory and object creation overhead when doing test moves during evaluation..
Please see the below images.
In the first image you can see that there is box collider.
The second image is when I run the code on Android device
Here is the code which is attached to Play Game (its a 3D Text)
using UnityEngine;
using System.Collections;
public class PlayButton : MonoBehaviour {
public string levelToLoad;
public AudioClip soundhover ;
public AudioClip beep;
public bool QuitButton;
public Transform mButton;
BoxCollider boxCollider;
void Start () {
boxCollider = mButton.collider as BoxCollider;
}
void Update () {
foreach (Touch touch in Input.touches) {
if (touch.phase == TouchPhase.Began) {
if (boxCollider.bounds.Contains (touch.position)) {
Application.LoadLevel (levelToLoad);
}
}
}
}
}
I want to see if touch point is inside the collider or not. I want to do this because right now if I click any where on the scene
Application.LoadLevel(levelToLoad); is called.
I want it to be called if I click on PLAY GAME text only. Can any one help me with this piece of code or can give me another solution to my problem??
Recent Code by following Heisenbug's Logic
void Update () {
foreach( Touch touch in Input.touches ) {
if( touch.phase == TouchPhase.Began ) {
Ray ray = camera.ScreenPointToRay(new Vector3(touch.position.x, touch.position.y, 0));
RaycastHit hit;
if (Physics.Raycast(ray, out hit, Mathf.Infinity, 10)) {
Application.LoadLevel(levelToLoad);
}
}
}
}
Touch's position is expressed in screen space coordinate system (a Vector2). You need to convert that position in the world space coordinate system before trying to compare it against other 3D locations of objects in the scene.
Unity3D provides facility to do that. Since you are using a BoundingBox surrounding your text, you can do the following:
Create a Ray which origin is in the touch point position and which direction is parallel to the camera forward axis (Camera.ScreenPointToRay).
Check if that ray intersect the BoundingBox of your GameObject (Physic.RayCast).
the code may look something like that:
Ray ray = camera.ScreenPointToRay(new Vector3(touch.position.x, touch.position.y, 0));
RaycastHit hit;
if (Physics.Raycast(ray, out hit, Mathf.Infinity, layerOfYourGameObject))
{
//enter here if the object has been hit. The first hit object belongin to the layer "layerOfYourGameObject" is returned.
}
It's convenient to add a specific layer to your "Play Game" GameObject, in order to make the ray colliding only with it.
EDIT
Code and explanation above is fine. If you don't get a proper collision maybe you have not used the right layer. I haven't a touch device at the moment. The following code will work with mouse (without using layers).
using UnityEngine;
using System.Collections;
public class TestRay : MonoBehaviour {
void Update () {
if (Input.GetMouseButton(0))
{
Vector3 pos = Input.mousePosition;
Debug.Log("Mouse pressed " + pos);
Ray ray = Camera.mainCamera.ScreenPointToRay(pos);
if(Physics.Raycast(ray))
{
Debug.Log("Something hit");
}
}
}
}
It's just an example to put you in the right direction. Try to figure out what's going wrong in your case or post an SSCCE.
I based my game off of the lunar lander demo, although heavily modified, and I can get around 40-50fps but the problem is it fluctuates between 40-50fps so much that it causes the moving graphics to jitter! Its very annoying and makes my game look really shitty when in fact its running at a good frame rate.
I tried setting the thread priority higher but that just made it worse... now it will fluctuate between 40-60fps...
I was thinking of limiting the FPS to about 30 so that it will be constant. Is this a good idea and does anyone else have experience or a different solution?
Thanks!
This is my run loop
#Override
public void run() {
while (mRun) {
Canvas c = null;
try {
c = mSurfaceHolder.lockCanvas(null);
synchronized (mSurfaceHolder) {
if(mMode == STATE_RUNNING){
updatePhysics();
}
doDraw(c);
}
} finally {
// do this in a finally so that if an exception is thrown
// during the above, we don't leave the Surface in an
// inconsistent state
if (c != null) {
mSurfaceHolder.unlockCanvasAndPost(c);
}
}
}
}
private void updatePhysics() {
now = android.os.SystemClock.uptimeMillis();
elapsed = (now - mLastTime) / 1000.0;
posistionY += elapsed * speed;
mLastTime = now;
}
Don't base your game's logic (object movement, etc.) updating rate on the framerate. In other words, put your drawing and logic updating code in two separate components/threads. This way your game logic is completely independent from your framerate.
Logic updating should be based on how much time has passed since the last update (let's call it delta). Therefore, if you have an object moving at 1px/millisecond, then during each update your object should do something like this:
public void update(int delta) {
this.x += this.speed * delta;
}
So now even if your FPS lags, it won't affect your object's movement speed, since the delta will just be larger, making the object move farther to compensate (there are complications in some cases, but that's the gist of it).
And this is one way of calculating delta within your logic updating object (running in some thread loop):
private long lastUpdateTime;
private long currentTime;
public void update() {
currentTime = System.currentTimeMillis();
int delta = (int) (currentTime - lastUpdateTime);
lastUpdateTime = currentTime;
myGameObject.update(delta); // This would call something like the update method above.
}
Hope that helps! Please ask if you have any other questions; I've been making Android games myself. :)
Sample code:
Copy these two snippets (1 activity and 1 view) and run the code. The result should be a white dot smoothly falling down your screen, no matter what your FPS is. The code looks kinda complicated and long, but it's actually quite simple; the comments should explain everything.
This activity class isn't too important. You can ignore most of the code in it.
public class TestActivity extends Activity {
private TestView view;
public void onCreate(Bundle savedInstanceState) {
// These lines just add the view we're using.
super.onCreate(savedInstanceState);
setContentView(R.layout.randomimage);
RelativeLayout rl = (RelativeLayout) findViewById(R.id.relative_layout);
view = new TestView(this);
RelativeLayout.LayoutParams params = new RelativeLayout.LayoutParams(
10000, 10000);
rl.addView(view, params);
// This starts our view's logic thread
view.startMyLogicThread();
}
public void onPause() {
super.onPause();
// When our activity pauses, we want our view to stop updating its logic.
// This prevents your application from running in the background, which eats up the battery.
view.setActive(false);
}
}
This class is where the exciting stuff is!
public class TestView extends View {
// Of course, this stuff should be in its own object, but just for this example..
private float position; // Where our dot is
private float velocity; // How fast the dot's moving
private Paint p; // Used during onDraw()
private boolean active; // If our logic is still active
public TestView(Context context) {
super(context);
// Set some initial arbitrary values
position = 10f;
velocity = .05f;
p = new Paint();
p.setColor(Color.WHITE);
active = true;
}
// We draw everything here. This is by default in its own thread (the UI thread).
// Let's just call this thread THREAD_A.
public void onDraw(Canvas c) {
c.drawCircle(150, position, 1, p);
}
// This just updates our position based on a delta that's given.
public void update(int delta) {
position += delta * velocity;
postInvalidate(); // Tells our view to redraw itself, since our position changed.
}
// The important part!
// This starts another thread (let's call this THREAD_B). THREAD_B will run completely
// independent from THREAD_A (above); therefore, FPS changes will not affect how
// our velocity increases our position.
public void startMyLogicThread() {
new Thread() {
public void run() {
// Store the current time values.
long time1 = System.currentTimeMillis();
long time2;
// Once active is false, this loop (and thread) terminates.
while (active) {
try {
// This is your target delta. 25ms = 40fps
Thread.sleep(25);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
time2 = System.currentTimeMillis(); // Get current time
int delta = (int) (time2 - time1); // Calculate how long it's been since last update
update(delta); // Call update with our delta
time1 = time2; // Update our time variables.
}
}
}.start(); // Start THREAD_B
}
// Method that's called by the activity
public void setActive(boolean active) {
this.active = active;
}
}
I am thinking there might be, not really something wrong with some of the above code, but rather an inefficiency. I am talking about this code...
// The important part!
// This starts another thread (let's call this THREAD_B). THREAD_B will run completely
// independent from THREAD_A (above); therefore, FPS changes will not affect how
// our velocity increases our position.
public void startMyLogicThread() {
new Thread() {
public void run() {
// Store the current time values.
long time1 = System.currentTimeMillis();
long time2;
// Once active is false, this loop (and thread) terminates.
while (active) {
try {
// This is your target delta. 25ms = 40fps
Thread.sleep(25);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
time2 = System.currentTimeMillis(); // Get current time
int delta = (int) (time2 - time1); // Calculate how long it's been since last update
update(delta); // Call update with our delta
time1 = time2; // Update our time variables.
}
}
}.start(); // Start THREAD_B
}
Specifically, I am thinking about the following lines...
// This is your target delta. 25ms = 40fps
Thread.sleep(25);
It seems to me that just having the thread hang out doing nothing is a waste of valuable processing time, when in fact what you want to be doing is performing the updates, then, if the updates have taken less time than the 25 millis, then sleep the thread for the difference of what was used during the update and 25 millis (or whatever your chosen frame rate is). In this way the update will happen while the current frame is being rendered, and will be completed so the next frame update uses the updated values.
The only problem I can think of here is that some kind of syncronization will need to occur so that the current frame render does not use partially updated values. Perhaps update into a new instance of your set of values, and then make the new instance the current instance just before rendering.
I think I remember reading something in a graphics book about the goal being to perform as many updates as you can while staying within your desired frame rate, then, and only them, perform a screen update.
This of course will require one thread to drive the updates - if you use a SurfaceView, the render is controlled by this thread when you lock the canvas (in theory, according to my understanding anyway).
So, in code, it would be more like...
// Calculate next render time
nextRender = System.currentTimeInMillis() + 25;
while (System.currentTimeInMillis() < nextRender)
{
// All objects must be updated here
update();
// I could see maintaining a pointer to the next object to be updated,
// such that you update as many objects as you can before the next render, and
// then continue the update from where you left off in the next render...
}
// Perform a render (if using a surface view)
c = lockCanvas() blah, blah...
// Paint and unlock
// If using a standard view
postInvalidate();
Good luck and any feedback from anyone using this would surely help us all learn something...
rpbarbati
I think it's about Garbage collector
I would use SurfaceView instead of View if your game is action heavy. If you don't need to update the GUI rapidly then View is fine but for 2D games it's always better to use SurfaceView.
I have a similar issue, the jitter makes large object moves look uneven. Even though the "speed" is the same, different lengths of steps make the movements look jumpy.
Broody - You say a SurfaceView is beter, however, this is not true after Android 3.0 as the View is HW accelerated but the canvas returned by .lockCanvas is not.
Steven - Yes, this is likely causing poroblems, but is easy to detect.
/Jacob