[A83] Re: fast clipped sprite routine

[Prev][Next][Index][Thread]

[A83] Re: fast clipped sprite routine



> Joe Pemberton writes:
> > Does anyone have a faster 8xN clipped sprite routine than crashman's?
> > I'm in the process of some serious optomization =)  Check out
> > www.joepnet.com/images/ps/phantom_new10.gif for an idea of what i
> > need it for.
>
> You're not going to get much faster than SpriteClip 3.0.  You need to
change
> your thinking: don't clip.  One way to do this is to use a buffer larger
> than the screen and clip while copying it.  This is much faster than
> clipping for every sprite.
>
> --
> David Phillips <david@acz.org>
> http://david.acz.org/
>
>

I thought of that, but how much is the actual speed gain?  In this case, not
much - the reason being because my game uses a screen that is 64 pixels wide
and 100 pixels high (it scrolls vertically).  Because of this, usually about
1/3 to 1/2 of the sprites that need to be drawn are offscreen, and you
actually lose speed by not clipping them and drawing them to a large buffer.
And the buffer would be large - around about 1500 bytes for a buffer that
would allow me to draw all of my sprites without clipping them (some of them
are around 18 pixels high).

Before I forget, here is another problem that has vexed my mind for a couple
days now.  If you take a look at the screenshot I posted in my earlier
email, you will notice that there are many enemies onscreen and many
bullets.  Collision detection between the two becomes increasingly slow as
more enemies and more bullets are created.  I.E. if there are 30 enemies and
10 bullets, I must loop through the collision detection routine 300 times
(worst case senario, assuming none of the bullets or enemies are destroyed)
This method works, but I think it's rather messy and slow.  So the question
is - how can I speed this up?  How can I reduce the number of times I must
loop through the collision detection?

A friend of mine had the idea of taking all of the object arrays - the enemy
arrays, the bullet arrays etc. and sorting them by their Ycoord's and
Xcoords (respectively)  The reason for this was to speed up several areas of
the game - the collision detection wouldn't have to be an n^2 algorithm
anymore, and there would be a good chance that while drawing the sprites I
could exit the routine early (as soon as I found a sprite that was offscreen
on the Y axis, I could exit the loop)  The problem is that it is possible
that enemies and bullets could get out of order relative to each other's
coordinates, so I would have to manually sort the arrays each time they were
updated.

Any other ideas?

- - Joe P
Follow-Ups: References: