Need some analyse on my sprite animation work

  • Thread starter Thread starter patataboy
  • Start date Start date
Thanks Damon

I just found a version that runs on my system, but I got other problems know, even if I make the background to disappears while pause ... It blinks like crazy when I put the game back on so I can't fraps it and then make multiple png out of the avi.
But anyway, someone just saved my day by finding me Rick Sprites and I will check your method for the future ripping I will want to make.

And by the way, you are a rock star man
 
I got it too, a nice soul here told me where to look at.
I really believe there is a big potential using Some of Ricks Move for Adam, as well as some of the Adam Sprite made for SOR Syndicate
 
ah Syndicate wars was made by Gsaurus, Doars contributed his Adam from the SoR2 Adam hack to that hack. I have those sprites as well.
 
OK, my combo is 90% finished

Just some minor adjustment between kick and palm strike and that is it
I should be able to show you that soon.
I'm starting to make the hold and release hit button technique ... front knee followed by a brazilian kick.
 
Ok, did the biggest part of it, need to make the hair and cloths to move properly and make the flame and shock wave effect, but at least my sprites are definite

combotest1_6_50ms.gif
 
Even though you said you don't want to go with transparencies and all that, please accept this pro tip. Never, EVER draw special effects (flame, Ki, etc.) directly to your entity's sprites. These should get their own sprites and be spawned separately as needed. There are a TON of reasons why. Just trust me, do yourself a favor and follow that advice.

:)

DC
 
Actually it is, but I had to flatten the layers to make a gif out of it
One layer has the character's sprite the other, all the effects.
Knowing that I wouldn't be sprite limited with Open BOR I thought to make my effect sprite separately even if it means more scripting ...  :'(.
That said, The effect will not get any transparency to keep the SOR feeling (except for the background transparency color)

But thanks to you I know that was the right choice

Merci
 
Damon Caskey said:
Even though you said you don't want to go with transparencies and all that, please accept this pro tip. Never, EVER draw special effects (flame, Ki, etc.) directly to your entity's sprites. These should get their own sprites and be spawned separately as needed. There are a TON of reasons why. Just trust me, do yourself a favor and follow that advice.

:)

DC
Click to expand...

By the way, You said that there are TON of reason not to draw effects directly on the sprite and I found out that editing would be easier with separate effects, why would be the other reasons ... knowing some of them will definitely help me (and probably others noobs like me) being more effective while making new game using Open BOR or any other programs

Thanks
 
To name a few:

[list type=decimal]
[*]The main sprite set stays clean instead of being mangled up with draw in effects. This makes it much easier to reuse and edit later on.
[*]Same goes for the effect sprites, and in many cases you can reuse an effect in the same module, which can actually save memory in the long run.
[*]You can remap or tint effects even on the same entity without remapping or the entity itself.
[*]Color palette issues are eliminated. You won't find yourself accidentally remapping a fire effect to Fuchsia when all you wanted was to change the belt color. In the case of extremely ambitious sprites, it also leaves you with more breathing space for colors.
[*]It allows you to experiment and adjust anything about the effects you like. Want to try scaling, blending, rotation or whatever on the effect? No problem. You can always just turn it right back off.
[*]The effect itself can have its own set of sounds/scripts/collision boxes/etc. to handle functionality separate from the main entity, and more to the point - it should. If you have ever done web development you'll hear about separation of structure and content. Same concept really.
[*]Debugging becomes much less of a hassle. The less "stuff" in your main entity, the better.
[*]It's a massive time saver in the end. Even when going for an old school look, nobody draws fake transparency directly into sprites anymore; it's a waste of human resources. Blending was a holy grail back then and would have been used if CPUs had the power for it - now they do. Processing cycles are cheap, human time is expensive. Let CPUs handle the monkey math (that's all blending really is) and save your own time for real artwork.
[/list]

There are more, but I think you get the idea.

DC
 
Thanks Damon

Now I got the idea, this is going to be helpful  ;)
I'm happy to have done my effects on a layer and not on the sprite.
 
Allow me to add another reason in Damon Caskey's list:

9. Prevent bad animation interruption. Without interruption, all effects might play and look fine when entity performs the animation however in game, we can't be certain if enemies won't interrupt. In fact, you can expect them to do so. This might cause bad animation such as fire from palm immediately gone or aura vanished instantly when entity is attacked.
If you use seperate entity for the effects, you can avoid those.
 
Damn, didn't thought about animation interruption ... but that means that I need to make movement stop animation for the character and the effect ...... ARRRGGGGHHH so much more work. Anyway I still love spriting so it does not matter.

And I'm still struggling with the flame effect ... I might switch to KOF style flame effect to make something that will fit my animation better (and separating effect from sprite means working with 15 colors and not the 4 colors left from shiva)

As I was still looking for a way to make that bloody effect the way I want it to be, I worked a bit on my hold and release button attack animation) and it will be a front knee followed by a brazilian kick
Still sketches stage, but the idea is there

kneebrazilian.gif


It might look a bit strange but all the sprites are hand made, no copies from other sprite, no rotoscoping, plain pixel by pixel drawn animation
 
patataboy said:
Damn, didn't thought about animation interruption ... but that means that I need to make movement stop animation for the character and the effect ...... ARRRGGGGHHH so much more work. Anyway I still love spriting so it does not matter.
Click to expand...

Don't worry, the engine has tools to help once you get to that point.

And I'm still struggling with the flame effect ... I might switch to KOF style flame effect to make something that will fit my animation better (and separating effect from sprite means working with 15 colors and not the 4 colors left from shiva)
Click to expand...

This doesn't change what you are doing, but just FYI the engine does not and will not think of Shiva or any other sprite as having 16 total colors. Every sprite in OpenBOR is operating from a 256 color table whether you choose to use them or not.

DC
 
Damon Caskey said:
This doesn't change what you are doing, but just FYI the engine does not and will not think of Shiva or any other sprite as having 16 total colors. Every sprite in OpenBOR is operating from a 256 color table whether you choose to use them or not.

DC
Click to expand...

Shoot.
I really have to go through the technical possibilities of Open BOR (I really thought the color table would be bigger like 16 bits or at least 12 bits like the neogeo  :-\)
Where can I get a technical document with all the limitation (colors, number of sprite, sprite size, levels of alpha colors ...) of Open BOR, I just have the tutorial you made (that is already big and detailed but I didn't go through it completely  yet  :P

Anyway thanks for the warning DC

Patataboy
 
Uhm, what are you talking about? The OpenBOR graphics engine makes a complete joke out of the Neo-Geo. You are mistaking individual sprites for on screen colors. OpenBOR supports a 32 bit screen, meaning it can display 16+ million colors at once. That's more than twice what our human eyes are capable of discerning, never mind blowing away the Neo-Geo's paltry 4096.

Now for sprites, there is no such thing as a sprite that uses more than 256 colors, because there is no such thing as a > 256 color table, and no such thing as a sprite engine that does not use color tables. There are some engines that can use RGB images for backgrounds and such, but not full sprite sets.

Now, if you know anything about sprites, you know that 256 colors is hardly a limitation. The mighty Neo-Geo never exceeded 16 colors per sprite, and even modern HD games rarely get past 30 or so. Even then they are typically drawing from a predefined static palette. OpenBOR has no such limitation. You get 256 colors of your choice per model. As in Shiva's body can have 256 colors, each of his fire effects can have 256 more and so it goes for every model in the game. You get another 256 for the background (which can always be augmented with panel models, each one adding yet another 256). Oh and BTW, every remap for every model is also 256 colors. Black Shiva, Red Shiva, Blue Shiva, Green Shiva? They aren't sharing a color table. Each remap is its own set of 256 colors.

That's all before you throw in binding, blending, tinting, alpha masking and so on - all of which are supported. You're going to run out of lifetime before you even approach the upper limits of available color.

What I was telling you above is that limiting yourself to 16 colors out of some old school principal is fine, it's just that the images and the engine don't care and will still be using 256 colors for each, filling in the ones you don't make use of with default values (what those defaults are depend on your imaging software).

DC
 
Ah ok ... I didn't understand it this way. I thought there was a general color table which every sprites have to refer to for colors.
That will make my work a lot easier not to have to worry about color palette ... 256 is a lot more than I need so that is cool ;D

Sorry for the misunderstanding.

Note to myself : Finish reading the tutorial. :-[
 
You must log in or register to reply here.
Back
Top Bottom