Games, paths, sprites and animation

By wimpie3

Champion (419)

wimpie3 さんの画像

15-07-2022, 20:00

Everyone designing a game will recognize this. You've got a hero sprite you can move. But for each step he takes, there's another frame in a set of animations (for instance with his feet moving). When he goes up or down the stairs or when he climbs a ladder, there's also a certain animation sequence. Or when he has to jump... How do you guys handle this in your games? With structures containing the frames and x and y coordinates needed for the animation? I'm sure this has been done before and I don't want to reinvent the wheel...

ログイン/登録して投稿

By Uninteresting

Champion (301)

Uninteresting さんの画像

15-07-2022, 20:42

I'm sure more experienced devs have better ideas... but one thing I should pay more attention to is having the four bytes of sprite data in RAM in the same order as I'd copy it over to VRAM (Y, X, pattern, colour -- whatever the correct order is) so that it's a simple LDIRVM call to make. Especially if the sprites won't need to set the early clock bit (or whatever that was).

Then I've had the execution branch based on entity states (dying, respawning, moving in different directions) which then update those fields. Maybe it's wasteful RAM usage, but my bottlenecks usually aren't in RAM usage.

As for swapping between states -- not really animation, but in Bumper Ship Racing the different properties of vehicles were done by having a different modulo for "how many frames must I press sideways to make the ship turn". I have a faint recollection of using a bitwise AND with a frame counter to determine swaps between animation frames (change pattern every two frames, four frames or eight frames), but I can't think of any place where I actually used that, unless it was my aborted "flying dragon game" project.

By MsxKun

Paragon (1111)

MsxKun さんの画像

15-07-2022, 20:51

Depends on the game.
There are many ways to do it, and all are ok as long as it works fine for your purpose.

By Sandy Brand

Champion (285)

Sandy Brand さんの画像

15-07-2022, 20:55

It really depends on what game you are making and what language Smile

On MSX you usually don't have that many frames of animation, so building some lightweight state machines is simplest.

This will also make it easier to implement specific behavior in various states (e.g.: being locked in a certain movement direction on stairs).

Personally not a fan of hard-coded jump-arc tables because for good responsive controls you will need to allow for things such as mid-air steering anyways. Implementing something with fixed-point math will be more flexible and allow automatically for things like falling down, knock-backs, changes in gravity, slippery surfaces, etc.

By geijoenr

Champion (321)

geijoenr さんの画像

15-07-2022, 21:58

I usually do this in the following way:
- Every sprite consists of a sequence frames divided in N states, with each state consisting of M frames. All those frames must fit in VRAM pattern table along with every other sprite's frames.
- For every sprite object on screen, keep a data structure that contains the current state and animation frame (here a sprite object can be a composition of several VDP sprites).
- On every animation cycle, apply logic to update the current state and the current frame for the main sprite object and the enemies. That logic depends on the game and can get complicated because usually involves collision detection.
- At the end of the animation cycle, update the sprite attribute table with the right frames and push to VRAM all at once.

The point 3 is the most important because it determines the play-ability, and there is no right solution. It can be very simple or very complex. For instance, Mario Bros uses something called subpixels to have smoother movement effects.

By aoineko

Hero (519)

aoineko さんの画像

15-07-2022, 22:26

In MSXgl there is a module dedicated to animation and movement of a "pawn" (the hero, an enemy or any animated object): the game_pawn module.

It is based on several structures:
- Game_Sprite which describes the different layers of a character.
- Game_Frame which describe the keys (time and frame) of an animation.
- Game_Action which describe behaviors (idle, move, jump, fall, etc.).

Once well configured, the program only needs to choose which action to perform for the whole visual to adapt automatically.

The module can also handle collision and physics.

There is an example of use in the sample program s_game.

By Timmy

Master (193)

Timmy さんの画像

16-07-2022, 10:39

For me, this is usually part of the movement code. But it's still mostly dependent on the game.

For example, do you want to be able to attack or jump while in the middle of a walking animation? If you don't need to do that then the code will be much easier to write.

So, somewhere, after you've decided how and where the player has moved, then magic sprite number is chosen. This sprite number will then be shown on screen.

All of this is completely unnecessary for your very first game, and you can use any game library for your first game. And then improve on it later.

For example, Heart Stealer 2 (my game in MSXDev 21) had 2 frames for walking left, and 2 sprites for walking right. These 4 are also used in mid-air so there are 4 sprites in total in game.