Sprites - Rendering or Control?

SDL Development
1

Thinking about what to do next. (While thinking about how to optimize the
overdraw eliminating parallax scroller… :slight_smile:

Probably a sprite example based on code ripped from my upcoming Project
Spitfire port, but do I focus on the rendering or the control system, or
perhaps something else?

I’ve seen a few articles on scrolling, tiles advanced multilayer map
techniques, sprites and all sorts of other things, but very little on how to
get these subsystems to work together in a real game. It’s pretty easy to
hack a program that bounces some sprites around (especially using SDL! :-),
but it gets a lot more complicated when it’s time to get them to interact
with eachother, the map and the player, and even more so when it’s time to
render them on top of (or in the middle of!) a parallax scrolling background.
On this level, everything I’ve seen has been very basic, and there’s usually
no source code demonstrating how the more interesting/complicated problems
are solved. I’ve seen theory on how to implement advanced 3D physics engines,
but no practical example of implemanting the much simpler “physics” of a
Break-Out style game…

In short, 2D games programming seems to be a fogotten art form, known only by
the ones who created it back in the 8 and 16 bit days. Those who know the
basics seem more interested in discussing advanced 3D programming these days,
so there’s no way in for the beginner… The result is slow 2D games using
brute force rendering methods, if there is any result at all!

Oh well, where do I start? What’s the first problem that stops the beginner
from getting sprites to do something useful (ehrm… :wink: on the screen?

I think that it’s more often the spaghetti around the control “system”,
than it is getting the sprites rendered properly. Animation also seems to be
problematic, although that might have to do with the amount of work required
to create the artwork for it.

Collision detection is handled by some libraries, but it might be a good idea
to cover shortcuts that might help games with lots of objects a great deal.
(As an example, Project Spitfire has a special pixel/sprite collision
detection call, as an alternative to the much heavier full sprite/sprite
method. Works fine, and makes the game feel less over sensitive as a bonus
effect.)

Has anyone ever seen the source of something like the contol systems used in
the 8 and 16 bit games? I’m interested in how it was possible to make control
systems feel that accurate and powerful with that limited CPU power - and it
all being written in asm… The C64, for example, couldn’t have had much time
left when doing a scroller and multiple sprite reuse at full frame rate, but
it still did keep track of every single sprite. Look at Armalyte, for
example. How does it keep track of the “reused” sprites [it has >8 sprites on
screen at the same time] when it comes to collisions?

I’d like to answer a few questions that can make the difference between a
playable game and a pure source of frustration;

* How do I check for collisions?

* How do I get objects to react properly to collisions?

* What actually makes a game feel truly *interactive*?

* How do I keep animations in sync with movement, even
  when movement is controlled by "external" events?

* How to chain objects into "dragon necks" and similar
  classical arcade game effects?

* How do I make an object "walk around" the map?

* How to keep helper droids from walking/flying through
  walls and enemies? (Well, they might be *supposed* to
  do the latter sometimes... :-)

* How do I program a homing missile? ;-)

Further, I’d also like to address advanced audio/video integration and other
issues that seem to be totally ignored in anything but commercial top titles.
Why doesn’t anyone play anything more interesting that music + one-shot
sampled sound effects? With the CPU power we have nowadays, there should be
no problem having every single event affect the sound effects dynamically;
space ships should have engine sound that’s directly affected by the movement
of the ship, doppler effect etc.

I’ll probably just hack away on something basic and simple related to this,
but I’m open to suggestions. Of course, the opinions I’m mostly interested in
are those of people who hasn’t already done all of this - that is, the
opinions of those who need the examples! :slight_smile:

As to the rest of us, who have already seen and done everything ;-), I think
this “SDL programing examples” effort could serve as a common ground for more
advanced stuff, such as the things mentioned above. (Some of it applies to 3D
games as well, but it’s usually a lot easier to understand and experiment
with the methods in 2D first.) Something like a cut’n’paste code resource for
serious game projects…

It might turn into a bunch of libs for SDL, but that doesn’t necessarilly
work for everything and everyone - small working examples might be more
useful in some cases.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

2

Here are my bets:

  • How do I check for collisions?
    I’d do it the simple way: I keep a list of all the sprites, and do a bounder
    collision check every frame. If that hits, I’ll do a pixel-accurate one
    (using sge).
    This sucks badly, because if you have to check 10 sprites against each
    other, that’s 100 checks per frame. (it is, isn’t it?)
    But any other method I can think of would be too costly…
  • How do I get objects to react properly to collisions?

I have set up my sprite system object-oriented. So the Sprites recieve a
Hit(Sprite *hitBy)-event.

  • What actually makes a game feel truly interactive?
    h?h?
  • How to keep helper droids from walking/flying through
    walls and enemies? (Well, they might be supposed to
    do the latter sometimes… :slight_smile:
    My system is to have “wall-sprites” (i.e., in my game there are no walls,
    just ceiling and ground, that’s two sprites), but that is impractical for
    everything else. Another system would be to have walls and such as bitmaps
    in memory, cross-checking every move. This would be way too powerful for a
    simple game, though.
  • How do I program a homing missile? :wink:

int ydif=me->y-me->target1->y;
int xdif=me->x-me->target1->x;
angle=(((atan2(ydif,xdif)+PI)*180)/PI)%360;

Me->y is the missiles y coordinate, me->target1->y is the missile’s target’s
y-coordinate.
Simply fly in direction angle all the time :slight_smile:

If you want the missile to home around walls, then you’ll probably really
have to do a wall-bitmap in memory, and use A*.

All those things actually work with 20 fps on a 486, so they can’t suck
too badly, after all. But when I think of those Z80-driven 4,5 Mhz Game
Platforms which did those things almost equally well, I’m getting sick.

3

Here are my bets:

  • How do I check for collisions?
    I’d do it the simple way: I keep a list of all the sprites, and do a bounder
    collision check every frame. If that hits, I’ll do a pixel-accurate one
    (using sge).
    This sucks badly, because if you have to check 10 sprites against each
    other, that’s 100 checks per frame. (it is, isn’t it?)
    But any other method I can think of would be too costly…

You can also divide your map into sectors and only do collision detection
on sprites/objects that are in the same and neighboring sectors. Of course
you have to pick big enough sectors so that no sprite is bigger than a
given sector else this method wont help you much. They should also
be small enough so that you minimize (significantly decrease) the number
of collision detections.

Hope that helps
JoseOn Sat, 24 Feb 2001, Pius II. wrote:

4

Here are my bets:

  • How do I check for collisions?

I’d do it the simple way: I keep a list of all the sprites, and do
a bounder collision check every frame. If that hits, I’ll do a
pixel-accurate one (using sge).
This sucks badly, because if you have to check 10 sprites against
each other, that’s 100 checks per frame. (it is, isn’t it?)
But any other method I can think of would be too costly…

This is where the “sector” approach comes in handy. :slight_smile:

It’s used in 3D games as well as 2D games with lots of objects, and
is based on an arrangement similar to tiled background maps.
References to the objects are stored in an array with suitable
resolution and number of dimensions to allow the objects to be
indexed in world coordinates rather than by checking all of them.
When objects move, they’re responsible for bringing their references
with them around this “objects map”.

  • How do I get objects to react properly to collisions?

I have set up my sprite system object-oriented. So the Sprites
recieve a Hit(Sprite *hitBy)-event.

Yep, that’s what I do as well.

However, what to do in the handler if objects are to be pushed
around, or respond to hits? (Basic game physics, that is.)

  • What actually makes a game feel truly interactive?

h?h?

Well, some games just don’t feel “alive” or sufficiently responsive -
sometimes because the enemies react in ways that are more logical to
the code than to the player. This is probably more a game design
issue than a technical one…

  • How to keep helper droids from walking/flying through
    walls and enemies? (Well, they might be supposed to
    do the latter sometimes… :slight_smile:

My system is to have “wall-sprites” (i.e., in my game there are no
walls, just ceiling and ground, that’s two sprites), but that is
impractical for everything else. Another system would be to have
walls and such as bitmaps in memory, cross-checking every move.
This would be way too powerful for a simple game, though.

Back in the days when I still considered full pixel/pixel collision
detection too heavy, I used a special function to do tile/sprite
collisions, using a tile->collision pattern translation table. Each
tile would have a code to determine what exact method to use; “do
nothing”, “check square”, “check top-left triangle” etc.

The advantage of such a method is that you have more control of
where the actual collision is - but this can be managed with bitmap
based pixel/pixel approaches as well, I think.

  • How do I program a homing missile? :wink:

int ydif=me->y-me->target1->y;
int xdif=me->x-me->target1->x;
angle=(((atan2(ydif,xdif)+PI)*180)/PI)%360;

Me->y is the missiles y coordinate, me->target1->y is the missile’s
target’s y-coordinate.
Simply fly in direction angle all the time :slight_smile:

If you want the missile to home around walls, then you’ll probably
really have to do a wall-bitmap in memory, and use A*.

There are some basic methods to do relatively simple things, like
following a track, following walls, avoiding objects, chasing objects
etc, and it usually works pretty well combining them.

You could use the above approach in combination with a line of sight
check, a “where did I see last him” memory and an adjustment rule no
to hit walls. (Corners in particular - becaues those are what will
cut the line of sight, which in turn determines the chase direction
most of the time.)

There is some article on this stuff somewhere, with working java
applets to demonstrate the methods live. Don’t have the URL here,
however…

All those things actually work with 20 fps on a 486, so they can’t
suck too badly, after all.

I’m using similar methods in the original Project Spitfire, and it
did a rock steady 60 fps on 486 33 MHz, every single bullet being
checked for map collisions. (No one can shoot throug walls.) However,
the gameplay is sufficiently simple that I don’t need to keep objects
alive when they’re off-screen, which keeps the object count down to a
few dozens at most. :slight_smile:

But when I think of those Z80-driven
4,5 Mhz Game Platforms which did those things almost equally well,
I’m getting sick.

…or the 1 MHz 6510 of the C64. hehe

There must be a great deal we can learn from the 8 bit games, and
even from the 16 bit ones…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 24 February 2001 12:18, Pius II. wrote: