Animation And Limitations?


devlkore

^_^
Joined
Jul 15, 2004
Messages
274
Website
www.sparktasty.net
Heyo,
I've been reading up and practising with Fenix, but I was wondering a few things. How should I go about character animation? I was thinking of programming the animation myself with an array for each action with a frame defined in each variable in the array and then using states (eg, walking, running, jumping, etc) to tell the character what to do.

Also, what are the limitations of Fenix on GP32? I heard there were problems with mode 7, what kind of problems are there? Is mode 7 completely useless or do you just have to use it in a special way?

I was also wondering about how certain things affect the processor load, for example, does the above method of animation offer benefits over using animated sprites, or anything. When calculating collisions for each bullet and sprite on screen, as well as the angles they travel at, does it use a lot of processor power, or is it reletively simple?

ThanX a lot for any help anyone posts, because I've got lots of theory, but I don't have the knowledge regarding what effect all this theoretical code has on an actual processor. I've got at least 3 ideas for games, so hopefully you'll all be playing something new soon :)

BYEEEEE!!

PS: Sorry for the long winded post.
 
Hm, let's see, I'll try to answer and hope anything helpfull comes out:)

First on the animation. You can use animated sprites in the FPG itself, but I would advice against them. Using an array for it, or having the sprites subsequent in the FPG so you don't even need an FPG is much better. More control of what is happening and easier to adapt when the surroundings change(imagine if you want to have running and walking, it would in code be much easier to speed up the animationframe changings than it would be with a predrawn in-fpg animation). Of course it's also a bit personal preference.

Mode 7 is bugged indeed, it doesn't work at all in 16 bit mode, in 8 bit mode it is supposed to be buggy, never saw it myself as I stay far from it. :) However I think it is usable, Nazca used it in his games(judging from the screenshots, damn i should play those games :ph34r: ).

On the speed, Fenix is slow in general. Don't expect it to be fast, and you will not be disappointed :). However, the thing that is slowing it down is mainly the interpretation of the code. So if you can check all bullets with one command that is will be relatively fast, but if you check half the bullets with a nice loop and a few commands in it, it will be slow. So for speed, don't worry too much about individual commands, worry about doing loops lots of times every frame.Things like editing all pixels on screen is unbelievably slow, while a build-in full screen effect is fast(relatively of course).
(these are not facts, mere more-or-less-educated guesses)
 
About restrictions (quoto from Moogle's Page
Gp32 Restrictions
There are few constrictions comparing the Gp32 port to Fenix developing for other platforms:

* Only resolution 320x240, 640x480 is resized and speed will drop dramatically
* If using 8 Bit colors, all graphics must have the same palette.
* Do not load from the SMC when playing music.

About mode 7 restrictions i think it's a matter of speed issues. Check some Fenix games for GP32 using mode 7 like Nazca Pertiga, Nazca Runners , NazcaSphere or Nazcatron.

And about how certain things affect the processor... i don't know, it's hard to tell. Your best bet is to try it yourself. But think that some things affect the processor more than others (16bits/8bits, etc...)

I think the worst restirction is the small RAM memory avaliable.

Maybe Moogle can say something more accurate, as he is a true Fenix coder.

Byes!
 
Maybe Moogle can say something more accurate, as he is a true Fenix coder.

lol, well, in the land of the blinds one-eye is king :)

I think from the div-arena scene(which is slowly evolving in Fenix' direction) I'm the only one with a Gp32(except for Mike Green, the man currently programming the new div).
 
put in you process
FLAGS=1; // Flip Horizontally
FLAGS=2; // Flip vertical
FLAGS=4; // Transparent
FLAGS=8; // alpha

There are some more... try yourself.

Byes


EDIT: I think that if you want to flip vertically and Horizontally your grapf you must sum their valors
Example:
FLAGS=3; Flip Horizontally & vertically
FLAGS=7; Flip Horizontally & vertically & transparent
 
Nice!

Btw: If you put any Flags they affect to all graphs of this process... you don't need to put a Flag for each frame of animation.
 
Back
Top