The problem here is that the animation frames for the character standing and moving are something like 16x22 pixels. The frames for the sword swinging are larger--and every frame is a different size since the sword extends in an arc. However, animation and player models are decoupled--no matter what the character's doing, it's defined in in-game units as 32x44 (the fact that it's double the pixel size is arbitrary; the same problem would occur, and be solved by my solution, if the player was 50x50). So, what you're seeing is a larger image being jammed into that 32x44 box, which looks messed up.
The solution was to add metadata to each texture to define a 'model-box', or model-relative coordinates, to 'anchor' that sprite such that the in-game model will fit into that area. Here's a quick video of me lazily setting up a few of these boxes. Some of them are probably off by a pixel, but whatever.
The blue boxes, therefore, represent the entire graphical image that will be displayed. The yellow box corresponds to the model. And here's what we get when we run the game again with the updated data:
Also added and not shown (because it's just code): basic logic to handle switching between player states from an input processing perspective. That is, different states allow the user to process different combinations of commands--you can move, change direction, and start swinging your sword while you're walking around, but not while your sword is swinging. But you can pause the game (once I implement that) during just about any state. Right now there's only two (basic) states (swinging and not swinging), so it's implemented with an if/else block, but I can see each player processing state being its own class in the future.
Next up: Configuring tiles and sprites to reference animation data rather than just texture data.
No comments:
Post a Comment