The VG Resource

I'm posting this because I haven't seen any rips of dixie kong holding a barrel and walking or picking up/putting down a barrel.
So. Here it is.
I don't know if this is up to standards but I gave it a shot.




I just hope this isn't too messy.
Thanks.

Four hours? O_O

At any rate, the reason this isn't on the sheet is because the barrel overlaps Dixie herself. We'd need to tile rip to get Dixie alone.

(01-16-2012, 03:26 AM)Tonberry2k Wrote: [ -> ]Four hours? O_O

At any rate, the reason this isn't on the sheet is because the barrel overlaps Dixie herself. We'd need to tile rip to get Dixie alone.

Why can't you use a trick where once the barrel is grabbed, the barrel sprite vanishes and then it moves the player X location backwards by the width of the barrel sprite at it's starting x point.
Then... have the animation stay where it is and play through it.
Then if she throws it, switch to her throwing barrel sprite and then in the last frame when the barrel isn't in her grasp, re create the barrel as a seperate sprite and handle it's collision independent of dixie.

so you have a sprite like this
ABXY and the Y is the barrel.

Starts with ABX Y (y is a fair distance away)
ABX approaches y
ABXY
Dixie picks up barrel
Destroy Y then draw instead in the first frame
ABXZ where z is the barrel sprite as part of the frame animation for dixie picking it up.
Are you following? Uhm
and do it that way instead of trying to move the barrel sprite with dixie using code. once she's carrying it.
that code would be difficult to do since when she jumps or etc. the barrel bobs up and down with her . in the original the barrel has bobbing up and down frames when being carried that you cant just place a single image frame into... and make it look right.

Or you could just ZSNES emulator with vSNES tile viewer.
Here's one I did earlier

Ant... I may require your help very soon.

Anytime, mate

(01-17-2012, 01:07 PM)HandToeKnee Wrote: [ -> ]Or you could just ZSNES emulator with vSNES tile viewer.
Here's one I did earlier

There's a problem with this though which is exactly the point that seems to be ignored when people make sprite sheets like this for player characters in games.

Since the barrel itself has different frames for it's being held animation and being carried animation. Hence it bobs up and down as it's being carried and there's maybe 2-3 frames of it being done. along with it's being put down and rotated frames.
Placing the barrel acurately behind dixie kong's sprite when using programming code, is difficult.
You have to basically know the exact offset of where the barrel needs to be displayed for every frame, and then draw it in those positions offset to dixie's actual world coordinates location.

In programming terms this means you have to set your offsets for the barrel sprite frames coupled with dixie's carrying/walking with it and putting the barrel down frames.

So that instead of the barrel being in the same position on each of these frames it moves in the right way and is animated in the right way as dixie moves.

They may have accomplished this on the snes but it's alot easier to just have the barrel as part of dixie's sprite to begin with.
That way you only have to worry about object placement in two frames.
The frame where dixie picks it up.
The frame where dixie puts it down..
And this is the first, and last frame. in that order for the above.

I'll try to make a diagram to explain.
see below
I had a lot of crap typed out then it glitched on me and I lost the rest.
I'll try again.

The issue with this as you can see in the last frame, next frame example is that the coordinates for the crate in those two frames are extremely different.
You can't just assume that the crates Y and X coordinates will always be dixie's X and Y plus a certain amount for every frame.
Since, the position of dixie in each frame actually changes the position of the crates/barrels in game.

In order for this to work using code you'd have to set up some kind of table telling the game engine you're designing exactly where the object sits at each frame for each of dixie's interactions with objects, and facing both ways since it'll be different for those two.

Usually we use a table of some sorts to solve this. The problem is... it's tedious.
Here' what a table like this might look like.

note these are hypothetical values

<animstate1>
<frame=1>
cratex=+32
cratey=+12
</frame>
<frame=2>
cratex=+31
cratey=+13
</frame>
<frame=3> ;for example dixie ducking while just picking the crate up. the y value of the crates offset increases by atleast 10 while she's holding the crate
cratex=+30
cratey=+25
</frame>

I hope this example made sense.
If you have any questions about it let me know.

I think you said 'it's easier to make the barrel and Dixie as one sprite instead of being programmed'.

While it is easier visually, programming code for the barrel's offset creates a more fluid animation that you could with hard animation, and probably takes less space than having to resprite her carrying the most varied objects, such as cannonballs, flipped bugs, TNTs and crates. Also, once the hard programming work is done, I assume it's easy to use it as a 'model' and do it for every other objects, thus saving time, space and in the end, it looks better as a final result.