Koh's New Sprite Joint

[Vipershark]

I think that's honestly kind of a downgrade. I know you didn't spend much time on them, but those cliffs are pretty ugly and their repetition sticks out a lot more than the original.

[Koh]

That's exactly the problem I was facing. Since the original tiles repeat so often, and in such a weird way, the hardest part was figuring out how to add more detail to the tiles themselves (rather than looking like a clay hill-slide), and retain their original shape at the same time. The bush and Link were easy. The grass took a bit to get to line up perfectly, but wasn't too bad. But dem cliffs though. I like the Gameboy Zelda cliff tiles better, but then again, I like that style in general better. Everything was done in a clean-looking way, and adding detail to those graphics is easier.

[Koh]

Movements for Lo-Res



Just practicing getting the right kind of body movement. Will probably animate Mid-Res tomorrow.
Lo-Res: 4 Frames, Mid-Res: 8 Frames, Hi-Res: 16 Frames.

[nicktheslayer]

It's getting hard to read with it getting so small. I'd try cutting about half of those colors out, you might have to sacrifice detail for readability.

[Koh]

It already doesn't use that many colors to begin with o.o. Mid-res and on actually implement the 4th shade. Lo-res only uses the 3rd shade for things in the back.

Will be moving onto the running animation next, but here's a quick little showcase thingy.

If you just hi-res the existing frames of an animation, you get this.


Looks fine for the lower res, but for the higher res, it looks jerky. So what do you do? You treat those frames as key frames, and create a new frame after each, that transitions to the next key frame.


Ahh, much smoother.

Side by side

[TheShyGuy]

It's not enough to just use the same keyframes from the low res to high res and make linearly spaced in-betweens. Especially since there's a large difference in approximating movement between the two. What you should atleast be doing is making in-betweens based on timing, not object spacing. The animation is very stiff as a result. Every movement is too linear which makes him look very robotic (most noticeably in the 'smoothest' walk). Everything changes momentum instantly. Things need time to accelerate and decelerate. This includes the hair which also seems to 'pop' from the lowest point to highest point. Knees/feet and arms/hands swing forward during a walk/run instead of "keeping up" with the upper leg/arm which also results in stiffness.

Besides the animation issue, I think the mid res smoothest is moving too much given he's only walking. It looks more like a jog to me. Maybe in-game it'll look fine?

[Koh]

That's what I'm placing my bets on. Sprites by themselves usually look a bit odd anyway, but put them in their home environment with their programming, and they move along according to the actions fine.

I do like your critique though, because it's geared towards more realistic animation, where things have variable movement instead of linear movement. However, the reason you don't see all of that exaggerated movement you mentioned here is precisely because of your last statement; he's only walking. The running animation () has more exaggerated motion (look how far the arms and legs go in either direction, as well as the head movement), since that is a motion that requires the most effort. When you're walking, you won't be extending your leg nearly as much, since you're just casually taking each step, instead of forcefully kicking the leg off of the ground.

And you'll have separate animations for things like coming to a stop (skidding) anyway, so you aren't placing your bets on each body part moving at a variable motion for just one animation. You'll have an animation to take care of hair blowing in the wind from skidding, for instance.

The inbetween keyframes are just to help guide your eyes as to where the parts would have been in general, instead of them teleporting from one place to the other.

[TheShyGuy]

I meant to imply that his mid-res walk is over exaggerated- specifically his shoulders moving waay too much for a walk. I didn't mean to add exaggeration either. When I said that things moved too linear, I meant that things goes from A to B without ..well what I said before - acceleration. There's no slowing down or speeding up of anything when they change directions. The arms, shoulders and legs move linearly in your animation. They rotate forward and then back without slowing down. It's ok if you had less frames or lower-res. But if you're going to go that extra step in smoothness, simple tweening isn't enough. It's not enough in 3D animation either. You can't make 2 key frames and think that interpolation will make things move correctly that way they should. With CG, you have key tangents which help create the kind of easing you want. In 2D, you have to do it all manually. Just filling the in-betweens linearly spatially means having linear tangents which means no easing and things stop and go in a robotic manner.

Also, when people walk, their knees still swing forward (dragging back / lagging behind the upper leg). It's more subtle than during a run, but it's there (I'm not implying to exaggerate the movement at all). I just noticed that you reuse the exact same frames for your arms and legs going forward and back. This is what I'm talking about. When the knee comes forward, it looks nothing like how it was going back. The foot doesn't hit the ground midway going forward either. It makes the legs look like they're in a hamsterball skiing back and forth.

[Koh]

I've kinda got an idea I can try. Since the arm swinging forward would have more motion, instead of the interpolation frames being at the halfway point, they could be closer to the previous point for the beginning of motion, or closer to the end point for the ending of the motion. The hair doesn't need to be changed, since it only moves one pixel in both directions from gravity.

[Kelvin]

So these different resolutions, are you making it so when people play on different screen settings, different graphics are used to make it look nice on small screens, rather than depending on mipmapping to do it for you? That's just the vibe I'm getting.

[Koh]

So these different resolutions, are you making it so when people play on different screen settings, different graphics are used to make it look nice on small screens, rather than depending on mipmapping to do it for you? That's just the vibe I'm getting.

Actually, it's to appeal to the best of both worlds. The actual screen resolution of the game is constant (quadruple the size of the Gameboy Screen; 640x576). People are just given the option to switch between super pixely graphics with minimal detail (Lo-Res), not as pixely graphics with more detail (Mid-Res), and minimal pixely graphics with the most detail (Hi-Res). Doing this, you'll grab the attention of both those who prefer more detail, and those who like the more retro-style sprites, widening your audience, instead of only appealing to those who like one specific type of pixel-based sprite graphics. If you don't draw the higher resolution graphics by hand, they won't look nearly as nice, or have as much detail as they COULD, especially if you use one of those nasty filters like hq2x.

Also, I didn't like the results of messing with the legs; I have a feeling I'll have to try redoing the legs of the key frames to incorporate a bent knee for the leg going forward, so the inbetween frames can look nice.

[Koh]

(Anyone using a light theme probably won't see the swing effect.)

I have more fun with Lo-res, if only because it doesn't take as long to animate, and I can get to the more fun stuff faster.

[Koh]

Party members and random lols.

Old: New:
Better slashing style. What does this remind me of?

Oh yeah, this guy.

[Kelvin]

Oh, I get it. Kind of like how Cave Story+ does it. Just one thing: please tell me you're going to use software scaling and not have bloated graphic files like Super Mario Bros. X has.

[Koh]

If you're referring to the graphics, regardless of the graphics option people choose to use, to scale properly with full screen or such, that's taken care of automatically. But if you're referring to using a filter like hq2x to get the higher res graphics for the other options, no, that's not happening. That filter does not have good output. The graphics will be separated into three separate files. For example, Koh0.png, Koh1.png and Koh2.png, which are Lo, Mid and Hi respectively. The game imports the proper files based on the graphics setting the player chooses (because the variable itself is just a value between 0-2, inclusive).

As for what each file would look like, to minimalize or totally negate the kind of roundabout coding you'd need to do to accommodate the use of extra frames for the higher resolutions, the lower resolutions just repeat frames as necessary, and are scaled up to their requisite size in the file. So for example, walking, as established earlier in the thread, consists of 4 frames for Lo (which needs x4 scaling), 8 for Mid (whih needs x2 scaling) and will have 16 for Hi (which doesn't require any scaling). This means in the Lo file, each of the 4 frames repeats 4 times. In the Mid file, each of the 8 frames repeats 2 times. For Hi, all of the frames would be unique.

The filesizes themselves actually don't get that large, since PNG is a file format that is the best suitable for sprites, due to having an alpha channel and no quality loss. BMPs are huge, and JPGs/GIFs get nasty compressions.

When the game first starts, it'll go through a "First Launch" routine, that asks you to choose which graphics option you want. From there on, it'll read from the options data file. The setting can be changed at any time, even mid-game.

EDIT: I am getting an idea that might negate the need to repeat the frames in the lower resolution, and their pre-scaling actually. It involves a little fun with some algebra, but I'm wondering if it'll work out graphically.