Daniel,
thanks for the link, it is VERY informative. Ok I'll separate the code
into two loops.
Until I get that finished are there problems with detecting how long
the drawing/moving takes and then scaling the timeout appropriately?
This won't prevent the frame rate from dropping below 1000/timeout but
it should stabilize things:
FYI I'm not writing a game per-se rather a live wallpaper
---
void loop(){
//android.os.Debug.startMethodTracing("PacDroidTrace");
float dt = android.os.SystemClock.elapsedRealtime();
moveActors();
detectActorCollisions();
detectDotCollisions();
drawFrame();
checkForWin();
dt = android.os.SystemClock.elapsedRealtime()-dt;
mHandler.removeCallbacks(mDrawWallpaper);
if (mVisible) {
mHandler.postDelayed(mDrawWallpaper, timeout-(long)dt);
}
}
On May 24, 11:48 am, Daniel Drozdzewski <[email protected]>
wrote:
> On Tue, May 24, 2011 at 4:25 PM, neuromit <[email protected]> wrote:
> > Thank you both for your suggestions, they are really helpful. I was
> > able to optimise my code quite a bit.
>
> > My collision detection is pretty primitive, so I'll definitely try to
> > improve that.
>
> > public boolean detectCollision(Point target, int dist)
> > {
> > return (Math.abs(this.x - target.x)<=dist && Math.abs(this.y -
> > target.y)<=dist);
> > }
>
> > @Danie, you mentioned that I should split the drawing form the
> > animation code; What are the benefits of doing this? as both drawing
> > and moving are driven by the same loop?
>
> Stuart,
>
> It is true that there must be a main loop for animation (or a game).
>
> However you ought to ensure that the drawing happens every X
> milliseconds, so that the frame-rate is as independent from your state
> computation as possible. Preferably it is a separate thread that
> sleeps X milliseconds, then wakes-up and paints the current state.
>
> State alone is updated constantly based on user input and game AI (in
> your case pressing of the buttons moves PacMan, while ghosts are
> chasing him automatically).
>
> If you do state updates and painting in one loop, then you will notice
> that game will feel differently, depending on how busy given level is
> (plus many more factors impeding the computation performance).
>
> What you will get, when you start optimising the collision detection
> is that you will no longer iterate through all points, and then the
> need to separate painting from state modification will be more
> obvious.
>
> I searched the nets for some tutorials, but found only this [*] which
> explains it to a lesser extent. I am sure you will be able to find
> something more comprehensive. Its for AWT, but the principles hold
> regardless.
>
> [*]http://journals.ecs.soton.ac.uk/java/tutorial/ui/drawing/animLoop.html
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
> > On May 24, 8:33 am, Daniel Drozdzewski <[email protected]>
> > wrote:
> >> Stuart,
>
> >> There are few fixes straight away:
>
> >> - Have a predefined Paint object for your dots and use that instead
> >> of creating new Paint object each time you enter drawDots()
> >> - assign dots.size() to a local variable and keep testing that
> >> variable in the for loop, rather than calling size() method with each
> >> operation
> >> - don't detect collisions in your drawing code
> >> - worth testing whether Canvas.drawBitmap() (cached bitmap of a dot)
> >> could be quicker than Canvas.drawCircle(); first one only copies
> >> memory byte by byte, while second does some computation too
> >> - and finally as String said: profile it
>
> >> Then you have to think:
> >> - how complex is your collision detection? it has to be optimised and
> >> you should not be iterating through all dots testing for potential
> >> collision with PacMan; if you think about it, your dots don't move and
> >> PacMan moves incrementally; there are few clever strategies that you
> >> could use; in general collision detection optimisation strategies are
> >> not trivial, but I am sure you could find something that would work
> >> well for you and would not be too hard to implement;
>
> >> have a look here as an entry to possible
> >> ideas:http://en.wikipedia.org/wiki/Collision_detection
>
> >> On Tue, May 24, 2011 at 12:57 PM, neuromit <[email protected]> wrote:
> >> > I'm writing a pacman style game that has a lot of things to be drawn,
> >> > namely, the dots that pacman likes to eat.
>
> >> > I'm finding that the drawing of the dots is greatly hampering the
> >> > performance of the game. If I turn them off my app consumes much fewer
> >> > cpu cycles than if they are left on.
>
> >> > here is the code i'm using to draw the dots:http://paste2.org/p/1432169
>
> >> > void drawDots(Canvas c) {
> >> > if (!this.drawDots)
> >> > return;
>
> >> > Paint p = new Paint(mPaint);
> >> > p.setColor(this.dotColor);
> >> > for (int i=0; i<dots.size(); i++)
> >> > {
> >> > Dot d = dots.get(i);
> >> > if (this.pacdroid.detectCollision(d))
> >> > d.disableDot();
> >> > if (d.enabled)
> >> > c.drawCircle(d.x, d.y,d.r, p);
> >> > //dots.get(i).draw(c, p);
> >> > }
> >> > }
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Android Developers" group.
> >> > To post to this group, send email to [email protected]
> >> > To unsubscribe from this group, send email to
> >> > [email protected]
> >> > For more options, visit this group at
> >> >http://groups.google.com/group/android-developers?hl=en
>
> >> --
> >> Daniel Drozdzewski
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Daniel Drozdzewski
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
