Hey all guys!
One month ago i start my gaining of experiense in nes developing. Now, i create side scroll, character(and his move), background and enemys. And problems consist with:
1) I create flipping of character when he move to opposite site. But, i wanna to make hand and leg moving when he is walking.
2) And enother is that i can't imagine how to create bulet shoot system. I gues that it must be like limited amount of bullet sprites like i check it in Contra, but how this code must look like, i don't know.
3) One more, that i create gravity with collision of wall, but it needs one layout of Y position of character. And i want to make collision in specific places, like pits. I make same collision in C++ but i use comparison operators: greater than >> and less than. May be this operators consist in 6503 ASM, can you tell me about this operators or may be there is another way to make collision in spacific places like bullet collision to kill enemys.
That's all, thank's for attantion)) and i hope that someone halp me) good luck)!
1: Walking animations
To know what you should do codewise, it can be good to know what the code should animate. Here's a template for that. There are other ways, but i think this is a good start.
At the very least, a walking/running animation needs two frames, but that will often look cheap. Three or four is where you're starting to look at a good compromise.
Let's name them:
1) Transition 1
2) Extreme end 1
3) Transition 2 (optional, can sometimes be replaced with transition 1)
4) Extreme end 2
Transition 1
This is a good starting frame because it will also transit the character from standing to walking/running.
Keep this frame relatively short in duration. it's a quick-happening movement between two points.
Extreme end 1
This will be where the right knee and left hand are at their highest point. Or left knee, right hand. Choose one combo, It doesn't matter right now. You can turn the torso accordingly one step. Let's for the sake of the template assume l hand / r knee is up. This means r hand is slightly behind the torso and the left leg has its knee deep and foot behind the balance point. Keep this frame longer than the transition. As a rule of thumb, always keep extreme ends longer than transition. It takes time to change movement of direction of body parts. This simulates it with a still picture, and it works.
Transition 2
This should be like transition 1, but reflect that knees and hands on respective side are changing positions to the other extreme end.
Sometimes you can get away with substituting this with another frame refering to transition 1. But if you look closely or the animation is too slow or the pixel art is very clear about it, it might look odd. Again, the transition should be short - we're in full swing here.
Extreme end 2
The hand and knee position should now be fully swapped so that if right knee, left hand was up; now left knee and right hand is. Again, 'rest' here a little bit longer with a longer frame.*
*a frame in animation terms is not a screen frame, as in for example 60 frames per second. You set a timer for how many screen frames an animation frame should last. When hitting zero, increase to the next frame, and let it loop after being done with the last animation frame.
If you want to add more frames, a good point to start is adding frames close to the extreme ends. This is in order too smooth the deceleration/acceleration of body parts swinging to a stop. In animation terms, this is called easing in and out. Another thumb of rule: Less momentum "requires" higher fidelity with more frames with small differences. Conversly, high momentum "requires" larger jumps in pixel content from frame to frame.
So, once you're done with drawing pixels, your animation cycle should now look something like this:
(1-short) (2-long) (1-short) (4-long)
or (1-short) (2-long) (3-short) (4-long)
To achieve this in-game, you need a timer and feed it with values stored in a data block representing the duration of each frame. It ticks down until zero, where the zero condition calls the next frame and a new value to decrease every frame.
2: Bullets
I would try creating a short stack in RAM keeping track of a max of, say, three bullets shot by player. Once you kill off an entity, clear that stack position or move stack. When attempting to fire a bullet, check if a 'slot' is empty. if yes, a bullet entity is produced and placed on stack. You also check this list when updating entity and sprite movements to see if there's anything to update.
Maybe a distinction between slot system and stack should be made. The latter implies that you push things onto it, and quite possibly push things out of it. This is more flexible. You can, per game, choose if you're limiting the player to n bullets, or if firing more than n bullets simply pushes one entity out of memory; destroying it - shoot a 4th bullet while three are active and the 4th will replace the 1st. I'll look wierd but give the player more control.