Marcel Kilgus makes some magical things to make me read
} Phoebus R. Dokos wrote:
} > So what I see is writing some sort of toolkit (a-la SSG) which can do this
} > in high-colour (and more)... for example clever background redrawing of the
} > screen on the anticipated movement of the sprite,
}
} This I don't understand. When doing sprites you only have to save and
} redraw the part that is directly under the sprite. Why do you want to
} predict where the sprite is moving to?
Because he is taking the 'amiga/commodore' approach of game with sprite:
he want the system to handle the graphic and the collision detection as
well as (de-)synchronisation of the movements,
thus leaving the game program with very little thing to do:
managing the score and life counter, changing the level display,.
IMHO, it's not the right approach. He should make his game without sprite,
using instead 'Letter' and detecting collision in memory, not on the screen.
Once the 'low-level graphic' works, he could replace it with all the fancy
sprites he wants. In the mean time, he would have learned that he need
to have the moving objects in memory, but also the full background, but not
as a monolithic part, rather like an assembled puzzle. Thus moving a sprite
is resumed to: draw the background where the sprite is (erasing the sprite),
perform movement calculation, draw the sprite, wait for some event/time
(or do something else somewhere else), do it again!
Problems unrelated to not having the sprite managed by a dedicated ship are:
- The hero moves according to input stroke, unless input provide only a change
in the direction of movement (the 'always-moving' type of pacman vs
the 'one touch=one move' type of some other games).
- The bad guys usually move in a kind of continuous ways, at least it's
not like a chess game (bad guys wait for hero to move, then move themself,
and wait again). So the management of the bad guys must be interlaced with
the scanning of the input for the hero move.
- collision between hero and bad guys: can happen when hero move, when bad guy
move or when both move at the same time. Using letters to illustrate:
...HB... : hero(H) is just on the left of the bad guy(B)
If hero move right, H & B are on the same cell, collision.
If bad guy move left, H & B are on the same cell, collision
if hero move right and bad guy move left, we end up with:
...BH... but a collision really occurs in the 'game logic'.
This last case is the most difficult to detect.
If hero move right and bad guy move right (at the same time),
there should not be any collision (unless the hero is too quick !).
- To add fun, the speed of the hero and the bad guy might be different,
thus collision detection should use a finer grid and each object occupy
more than one cell at the same time in this grid.
Anyway, reading the screen to detect collision is just a bad approach, because
it means that you are adding contraints to the graphical representation of
your objects. It was the easy way with machine like spectrum and other,
but it gives really bad habits and empeachs adaptation of the engine for
other graphics.
