changing sprites when pressing arrow keys?

[Noob]

Is it possible to change the sprite of the actor when I press a arrow key?

 

[kerbonklin]

I'm guessing this will affect the map scene?

Unless you want to use a risky parallel process that could result in lag, I would recommend having a script done that checks for input triggers to change he actor graphic. (game_interpreter-based script call)

the parallel process method would just be conditional branches checking for button presses, then changing the actor graphic.

 

[Noob]

I dont know how to script. And after searching how I could make a conditional branch in a parallel process I still have no idea how to let the game know that a arrow key is pressed.

 

[kerbonklin]

I think it's either the 3rd or 4th tab of the Conditional Branch dialogue box, "If Button is being pressed"

You can always make a script request thread.

 

[Noob]

It was the 4th tab.

I reccon one parallel process is not that harmfull?

 

[kerbonklin]

It depends, because the parallel process will check every every single frame (60 times a second) and it might affect everything (not just maps but battles and menus too if that parallel is a common event) unless you go out of your way to make complex switch-work to prevent that.

I'd say just go with a script request thread.

 

[Andar]

do you want that change only at the beginning (for character creation or so) or during the game as well?

If it's only for the beginning, the parallel process shouldn't matter because the character generation is probably on a map that will never again be visited.

If it's in the entire game, such a parallel process can become problematical and you should enter a wait(5) or wait (10) after each button check...

 

[Noob]

Ok, I have made this in a common event parallel process. Its started by a chest with a weapon he finds

Spoiler

Its used thru the whole game. I will later add the possibility that the sprite will change when the hero finds another weapon whats automaticly equipped when its stronger.

Where does this wait come?

 

[Andar]

Ok, I have made this in a common event parallel process. Its started by a chest with a weapon he finds

Spoiler

Naamloos.jpg

Spoiler

Its used thru the whole game. I will later add the possibility that the sprite will change when the hero finds another weapon whats automaticly equipped when its stronger.

Where does this wait come?

below the last command, because without the wait, the script would check every frame wether a button is pressed or not. That is 60 times per second and would create a lot of lag.

wait(10) would force the event to skip the next 10 frames before running again, resulting in "only" six checks for button pressed per second...

You might consider triggering the CE only when the weapon is equipped - one of Tsukihimes Skripts allows common events to run when an item is equipped, adding that instead of using a parallel process would make everything much easier for you.

 

[Noob]

Before I try that script from Tsukihimes I want to show what I try to do.

I made this sprite sheet.

Spoiler

As you see there are empty squares between the sprites. I mean vertical.

Now in the game this sprite for down is showing:

Spoiler

And for left this one:

Spoiler

If you watch closely you see the point of the sword of the down sprite at the top in the left sprite.

I tried at the moment different things to get that away. Like enhancing the sprite sheet and put everything with two squares between them, but then it is showing in the left sprite two squares up and still drawing the point of the sword in the picture.

What it draws is this for the down sprite:

Spoiler

and for the left sprite:

Spoiler

Now if I can solve this problem, that the point of the sword is no longer visible in the left sprite, then I don not need to change sprites while walking.

Do you have any idea about the measures for the sprite sheet to get that allright? At this moment it tried allready around 30 different sheets but somehow I cant get it right.

or is it impossible?

 

[hiromu656]

There aren't any specific measurements for a sprite sheet, it's an error in the sheet itself. Each of the "poses" need to have the exact same amount of space that both contains the image and separates them. For instance if you have the "Facing Left Pose" contained in a 10x10 pixel box, every other sprite must be in a 10x10 box, making the image 30x40 pixels. Somewhere in the creation of the sprite sheet, the images got off balance, just looking at the image of the complete sprite sheet, it's pretty clear that it isn't contained very well, there is much more empty space at the top of the spritesheet than the bottom for instance.

So, it just requires a bit of graphical editing, I don't think there will be an event to fix that mistake.

 

[Shaz]

Your spritesheet is set up incorrectly. You need to figure out the MAXIMUM width and height for ANY direction, then make sure ALL your sprites are that size and have the character placed correctly.


Changing the graphic via a parallel process event based on keys being pressed would give you exactly the same results that you're getting now.

 

[Noob]

hiromu656, the total sprite sheet in the first spoiler works further perfect. If I try to shift the sprites to other places, and make the sheet bigger (vertical) all gets off balanced untill I have them on the right place again. Only it allways draws near the bottom of the down sprite. Is that the mistake you mean?

In the number 5 spoiler I show what he is drawing for the left sprite. It doenst matter or I make 1, 2 or 3 or more empty squares between it. It is simply drawing from the bottom of down sprite.

When I was trying I also made a sheet with two empty squares at the top. It doesnt matter Two empty squares at the top means also two empty squares between the sprites

 

[Noob]

No Shaz, I have altered those different sprites when I use the parallel proces.

As far as I can see are the sprites placed at the right place, but does VX ace it a bit different then logic should say. Allthough there is a logic in it as how they are drawn.

I go to bed now, tommorow a new day

 

[Shaz]

Noob, please avoid double posting, as it is against the forum rules. You can review our forum rules here. Thank you.


You have way too much empty space around your sprites. There is no way the game would choose those 'highlighted' areas for each direction that you have shown in the post above. It breaks each spritesheet up into equal-sized rows and columns, and they do not overlap. The areas you have highlighted DO overlap.


Here is the corrected sheet. Let me know when you have it, so I can remove it from my photobucket.

Make sure you put $ in front of the file name, to tell Ace that you've only got ONE character on your spritesheet.

 

[Noob]

I have that picture Shaz, thanks

I also tried a new sheet with the pictures 96x96 at a right size for the sheet. That works also, but then I cant walk left or right because the char sprite bumps into the 32x32 wall sprite.

And now I am really of to bed, its 02:30 here

 

[Shaz]

I don't understand what you're trying to do. You must be doing something really weird with it if it's not showing up properly in the game.


What you have in the sprite has nothing to do with whether the character can walk into walls or not - what you're describing is exactly what I'd expect to happen, if you have walls on both sides.

 

[Andar]

Before I try that script from Tsukihimes I want to show what I try to do.

I made this sprite sheet.

Now if I can solve this problem, that the point of the sword is no longer visible in the left sprite, then I don not need to change sprites while walking.
Do you have any idea about the measures for the sprite sheet to get that allright? At this moment it tried allready around 30 different sheets but somehow I cant get it right.

or is it impossible?

Your main problem is that you're trying to make a single part of the sprite sheet into the border of two different sprites, and that is impossible.

The size of a sprite can be varied, but every single pixel of a spritesheet is always part of ONE sprite, it can never be part of two sprites - and that is what you're trying to achieve.

The borders between the sprites are calculated on the total picture size. Your picture has a size of 256x288, that means that the dividers between the sprites will be fixed at pixel coordinates 64, 128, 196 (horizontal) and 96, 192 (vertical). These divider lines are fixed, based on total picture size - and the program doesn't care where in that grid you actually place your sprites, it will display those parts only.

I made two pictures, one showing where Ace will place the dividers in your spritesheet automatically and one (not to scale, just a quick modification) what you would have to do to get the area you want around the sprite.

Yes, using that WILL prevent the sprite from touching a wall at the bottom - but that is because you are forcing the player to stay away from the wall by including that large transparent area as part of the sprite.

WHY do you want that area? I see absolutely no reason why you can't make the sprite filling the entire part of the grid.

If you want the sprite holding different sized weapons, then make the sprites for those weapons different sizes - you do not need to include transparent spaces around sprites that do not need the transparent areas...

This is how the engine divides a sprite sheet of size 256x288, and NOTHING you do will change that division - you can make the sheet larger to move the dividers, but the relative positions at 25%, 50%, 75% picture size for horizontal divider and 33%, 66% picturesize for vertical dividers will never change.

View attachment 8535

This is (not correct scale/positioning, only quick mixup) how you have to make the sheet if you want that (in my opinion not needed) transparent area around the sprite:

View attachment 8536

 

[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.

I am still chewing on what you say about the total sprite size for the drawing. (not the sheet)

Andar, your example is right, that was also what I got from drawing the sprites. The drawings are over eachothers borders.

What I dont understand is the 25, 50 and 75% of the horizontal drawings and there vertical 33, 66, 99 and 132%.

When I look at the original spritesheets for the chars they are all 32x32. So I dont understand that 33% and 66% thingie.

You say also that it doesnt matter where you put the sprite, but it does. Within the square the sprite can jump up and down, left right, when its not properly centered.

Also, I dont need that much empty space around the sprite, but I was under the impression that it was necassery for the mechanics behind the drawing. I know now that those mechanics are different then what I thought. 

I will try some more with this information because its not only a walking sprite, but also a hitting a weapon sprite, what has total different measures.

Shaz, before I started to alter the sprites I didnt now anything about it, now I also expect some things when I alter them

 

[Andar]

Andar, your example is right, that was also what I got from drawing the sprites. The drawings are over eachothers borders.What I dont understand is the 25, 50 and 75% of the horizontal drawings and there vertical 33, 66, 99 and 132%.

When I look at the original spritesheets for the chars they are all 32x32. So I dont understand that 33% and 66% thingie.

You are mixing spritesize with spritesheet-size.

Those are NOT the same.

An original Sprite has a size of 32x32 pixel. An original spritesheet has a size of 96x128 pixel, and the 25%/50%/75% are the dividers at 32, 64, 96 pixel that divide a spritesheet into the four different directional sprites (top/down), while the 33%/66% are the dividers at 32, 64 pixels for the three animation parts (left/right).

Now, if you change the spritesheet size to 288x256 (as you have done with your spritesheet), then those dividers move to 64 (25% of 256), 128 (50% of 256) and 192 (75% of 256) for the three horizontal lines and 96 (33% of 288) , 192 (66% of 288) for the two vertical dividers. This creates the spritesize of 64x96 that is FIXED for a spritesheet the size of 288x256 like you have used.

And those are the lines I placed on your sprite.

The size of the spritesheet with 12 sprites determines the size of the sprite - not the other way around.