changing sprites when pressing arrow keys?

[Noob]

I was the whole day busy with it, and I thought I understand it, but no.

For a normal walking hero it will work, say like a 32x32 square. But for a 32 width and 64 high sprite it wont work.

For left and right I then need 32 high and 64 width and somewhere there it goes wrong

Really, at the moment I dont get it. I thought I had it, but all went wrong when I tried to make the hero hitting his sword. Its way out of the center then.

The enthousiasm is cooled now, so I try a few times and then I think I give up.

 

[Andar]

It would really help if you would simply tell us what you want to achieve instead of how you want to achieve it. Then we might be able to give you the correct templates (which most probably are very different from what you're coming up with at the moment.

As I said before it doesn't make any sense for you to have the empty space on all sides of your sprite, so please show us hwat you plan to use such a sprite for.

 

[Celianna]

Andar you're explaining this very, very confusing, there is no need for percentages.


Spritesheets, as read by the program, are divided into 12 cells, 3 across, 4 down. All cells must be the exact same width and height. One cell contains one frame of your sprite. They can be any width and height (yes, even 2000x4000 pixels), as long as each cell (so 3x4 = 12 cells) is the exact same height. So if you were making an outrageous sprite that takes up 2000x4000 pixels, you would have to multiply the width by 3 (2000 x 3 = 6000), and height by 4 (4000 x 4 = 16000), this will give you a final image size of 6000x16000 pixels.


Let's try a smaller size. Let's say your sprite is 32x64 pixels (width is always mentioned before height, so 32 pixels is the width), so 32 x 3 = 96, 64 x 4 = 256. Your final image size will be 96 x 256 and will fit 12 same sized cells (which will be your sprite).


Hopefully that explained it better.

 

[Noob]

Celianna that where my findings to.

So I make a spritesheet like this.



Then I add that to my game and its way off, like this.



Its walking in the wall.

And I cant get that right without stumbling into other problems. So I reccon thats impossible to get the sprites like that

 

[Andar]

If you make a sprite that is larger than 32x32, then that sprite will no longer fit the map grid - that can't be changed, because the grid is 32x32.

The sprite example above has the additional problem that the hero is not centered in the sprite cells, so he will be off-center depending on the direction into which he's walking.

However, if you want to show a swinging weapon from above, then you have no choice but to go for a larger sprite.

But unless you either use tricky mapping or use scripts to change the collision/movement into pixelmovement, the larger sprites will end up partially in the wall if the sprite comes near a wall.

 

[Noob]

well, I cant script.

So that leaves me with tricky mapping

With a sprite size of 96 and adapted sprites for the tiles to a size of 64 (divided by the 32x32 mechanics) I can use the tricky mapping

I am still experimenting with it.

 

[Shaz]

I really don't know what the issue is here. The spritesheet I gave you works, unless you do something to mess it up. If the left/right images are a little high or a little low, then move them up/down by a pixel in the spritesheet.


Try using a standard, RTP sprite and see if you have issues? I really think you're making this WAY harder than it needs to be, and I don't know if it's just because you don't understand what you're doing, or because something you've done has messed things up, or if you're just using wrong sprites or tiles.


If your character is walking in the middle of the wall and you are using the spritesheet I gave you, then something else is going on - have you created your own tileset? Are the tileset passabilities correct? Are you using some script that adjusts character movement (like a pixel movement script)?

 

[Noob]

Shaz, I am not using a script. I make my own spritesheet. The spritesheet you made was for a walking hero with a sword. Thats a 34x34 big drawing.

Now I have one thats 52x52 pixels. And that wont work. Allthough I cant get it to work. When I move the drawing a pixel, or more up and down then its so far off that it is unplayable.

When ya press the down arrow key it walks down. when ya press left or right then the char jumps to another position.

The only way is to make sprites with 96x96 big squares. This will make the game use the 32x32 walking mechanisme but then shifted.

I see now that I made a mistake with the picturs, I show a hitting soldier. My hero in the game is however build the same way, and he is standing in the wall. srry for that.

 

[Andar]

When ya press the down arrow key it walks down. when ya press left or right then the char jumps to another position.
The only way is to make sprites with 96x96 big squares. This will make the game use the 32x32 walking mechanisme but then shifted.

Your first problem is because the figure in those sprite is not centered in the middle of the sprite cell, but as you said for yourself, when you want to center a figure with a long weapon, then you need to make the sprite bigger - causing it to fill part of the adjacent tiles.

And then you'll need to prevent the sprite from reaching the floor tiles adjacent to a wall by either cluttering the floor at the wall with impassible tiles or by a scripted collision detection.

The second problem is that when you're using weapons of different length, the distance from the wall neccessary for sprites with long weapons will no longer work with sprites with short weapons - those will stop at some distance from the wall as well, even if they don't need that distance.

And that cannot be overcome with tricky mapping alone - if you want to use differently sized actor sprites, then the collision detection has to be variable based on sprite size, and that is only possible with a scripted pixel collision detection.

 

[Shaz]

Are you saying that IS the only way, or YOU have to make them that big? Because you don't, unless your game requires it for some reason.


By default, Ace sprites are 32x32 pixels per cell, and there are 3 cells across and 4 down in a spritesheet for a single character. So by default, a spritesheet for a single character is 96x128 pixels. The size of the individual images don't matter - if you make them bigger, the whitespace will just be ignored. Collision is done on a 32x32 square, unless you're using a pixel movement script, regardless of how big your actual images are.


I have given you a spritesheet that will work. Did you even TRY it? I don't understand why you're saying it won't.


The only thing I can think of, because the things you say just don't seem to make sense, is for you to load your project up somewhere, so someone can take a look at it.

 

[Noob]

Quote Noob: Shaz, thnx for that sprite sheet. I try to understand what you did, but at the moment I dont see it   Also, when moving up and down, the hero sprite is good. But moving left and right lets the sprite jump a bit out of the center. When I go left he jumps a bit up, and when going to the right, he jumps a bit down. I tried to move bote drawing a pixel up an down but that doesnt help. End quote

Shaz, why do you ask or I even tried it? Notice that your sprite sheet is not good for vertical movement. The only way to conclude that is ingame. I have improved that sprite sheet by taking the minium measures for a square, What was 34x34 pixels. That brings the sheet on 102x136.

2 pixels difference is not that much, but the game uses a collison detection on a grid of 32x32... allways. This 2 pixels difference is seen when moving to a wall. When moving down and bumping into a wall lets the sprite further away then walking up and bumping against a wall. When walking up the char is 2 pixels in the wall.

So a sprite of 52x52 sets the sprite collision on 32 is a difference of 20 pixels. Making the sprite 64x64 sets the drawing 16 pixels down. Allthough when centered.

With a 96x96 and the sprite centered its solves the 32x32 collission. Only the sprite now will collide with the tiles beneath it. So standing in the corridor at the top side let the actor go into the wall above, but not down, when the wall tiles down have a X. Thats logical and normal. So thats the tricky part to make the corridors good. I make the top floor tiles with a X instead of a O and the lower floortiles and the lower wall with a O instead of a X.

Andar is right. To solve the problem is not in the drawing but in smart tiling the dungeon impassable parts, or to use a script.

Today I had no time to experiment with it, but tommorow I shall try to make an example for you.

 

[Shaz]

No need. Andar sent me a PM and explained the extra details that you left out of this thread. Since he has a handle on what you're trying to do and what's causing it not to work, I am bowing out of this thread so I don't complicate things