Bigger char sprite (Editted)

[Noob]

Is it possible to have a bigger character sprite for a actor or NPC?

Normally its 32x32. But can it be also 64x64?

 

[cosmickitty]

sure, as long as the sheet is set up 3x4 it takes any size

 

[Andar]

there is no size limit (smaller or larger) on sprite pictures, you just have to follow the correct multiplies for each segment, based on the file nameing conventions of Ace (follow the link in my signature to reade about ! and $ in the sprite's filrename).

The High-Fantasy-resources from the shop show examples of larger sprites

 

[Noob]

Thanx for the answers, but I do not understand it fully.

I found this Andar:

To change that, the $ sign can be added in the front of the filename. An example from the RTP would be $BigMonster1, which contains only a single sprite group of 12 monster pictures. You can also see that this sprite contains four different monsters instead of a single monster from four sides - if you use such a sprite in an event, make sure to check "directional fix" to prevent the graphic from changing depending on which direction the event turns.

If the $ is in fron of the file name, the spritesize will be calculated as 1/3rd the width and 1/4th the height of the imported picture.

So normally its using 32x32 for the squares and then I have this:

when I put a $ before the name of the sheet. Can I then do 64x64 for the squares?

 

[Andar]

Thanx for the answers, but I do not understand it fully.

I found this Andar:

To change that, the $ sign can be added in the front of the filename. An example from the RTP would be $BigMonster1, which contains only a single sprite group of 12 monster pictures. You can also see that this sprite contains four different monsters instead of a single monster from four sides - if you use such a sprite in an event, make sure to check "directional fix" to prevent the graphic from changing depending on which direction the event turns.

If the $ is in fron of the file name, the spritesize will be calculated as 1/3rd the width and 1/4th the height of the imported picture.

So normally its using 32x32 for the squares and then I have this:

Image1.png when I put a $ before the name of the sheet. Can I then do 64x64 for the squares?

No, you misunderstood that - the $ sign has nothing to do with the size of the sprite, it has to do with the number of the sprites.

Without $, Ace assumes that the spritesheet contains 8 sprites (in 12x8 pictures), with the $ Ace is informed that the spritesheet contains only one sprite (in 3x4 pictures).

If you want to make 8 different oversized sprites, the spritesheet you're planning needs to have a size of 12 times the sprite's width and 8 time the sprite's height and must not begin with a $.

In the example mentioned above, the HF-Sprites (look at the pictures in the store!) are usually using a 96x192 picture with a $ in the name to create a single sprite sheet for a 32x64 pixel sprite.

The size of the sprite depends on the size of the picturesheet, but the filename changes how Ace calculates the size, depending on wether the picture will be assumed to contain 8 or 1 sprites.

If you want to make one single oversized sprite, then the spretsheet needs to have 3 times the sprite's width and 4 times the sprite's height and need to begin with an $

 

[Noob]

I still dont understand it, sorry.

If I want to make this:

Spoiler

The squares are 32 and the total width of the sprite is 96. I know something is wrong in this sheet.

But how do I get the right size for the sheet? Are there somewhere examples sheets?

 

[Andar]

You need no example sheets, because you only need to multiply the size of the sprite. However, you can export each spritesheet you want from the resource manager.

Here are four examples, perhaps that'll help you see that you're looking in the wrong direction with your problem:

One sprite with a size of 32x32 needs a sprite picture sheet the size of 96x128, with 12 pictures 32x32 arranged in a 3x4 pattern.

One sprite with a size of 64x64 needs a sprite picture sheet the size of 192x256, with 12 pictures 64x64 arranged in a 3x4 pattern.

One sprite with a size of 32x64 needs a sprite picture sheet the size of 96x256, with 12 pictures 32x64 arranged in a 3x4 pattern.

Onw sprite with a size of 25x75 needs a sprite picture aheet the size of 75x300, with 12 pictures 25x75 arranged in a 3x4 pattern.

Because all four examples would create a single sprite only, all four filenames would have to begin with a $ to preserve the sprite structure when importing into Ace.

But then all four sprite examples could be used in the program without problems.

 

[Noob]

I found out that ya need indeed a $ for the name. Then it takes the whole picture into it. Ya can also make another different measure like 31x31 in the accordingly 3 to 4 sheet.

Allthough there is a problem with the tiles. I cant walk left or right annymore. The char is offgrid for the vertical movement left and right. The char sprite is moved a few pixels up when I make the sprite 96x96.

Any ideas about that? I can walk up and down in a dungeon but not left or right

Edit:

I have brought the sprite back to 64x64. Its the size I could use the best. Only now is the char walking 16 pixels on to a wall tile when he moves up.

And when walking down the sprite stops at around 48 pixels from a wall tile.

Can I also change the tile sprites to another size?

 

[Andar]

Tiles cannot be changed to other sizes.

And the larger sprite will be centered on the regular 32-grid, so part of it will overlap into the next tiles (like the wall). To prevent that, you have to make sure that the space next to the wall is also impassible, preventing the character from moving near the wall (that can be accomplished by making an impassible floor tile, by using a script like Yanfly's restrict region or by changing the defualt movemen/collision area with scripts).

If the sprite stops 48 pixels from the wall when going down, then you have added scripts for collisions OR made wrong passabilities on tile  regularly, while the sprite can be any size, all movement and all collision detection is still based on the 32x32 bottom center of the sprite.

Follow the link in my signature to the sprite explanations again, either you made the sprite wrongly or you missed the ! in the filename.

By default, Ace assumes that the feet of the sprite touch the bottom end of the picture - if you have any transparency between the feet and the end of the spriteframe, that will displace the sprite from the grid.

However, on any tile set as grass/bush in the tileset settings, the bottom part of the sprite gets turned invisible to give the impression of walkin in grass - the ! in the filename ist the keay to disable that (usually for doors or similiar objects.

 

[Noob]

I found it out.

So I had my char centered on a 64x64 sprite, only having 16 pixels at each side. This was causing a problem with the tile sprites. Like you said the game is working on a grid of 32x32.

So I changed the char sprite to 96x96 and the sprite in the center of that. Now I have 32 pixels at all sides.

I cant use the !. The $ before the name makes it a correct sheet to use. The ! does not.

My dungeon tiles are all 64x64. Thats lucky because I can now us the O and X for passing, or not passing, a tile. I can not use the A tab. This A tab is totaly different then the rest of the Tiles Tabs.

I am still experimenting with the other Tabs

Thank you both for the help.

 

[Andar]

I cant use the !. The $ before the name makes it a correct sheet to use. The ! does not.
My dungeon tiles are all 64x64. Thats lucky because I can now us the O and X for passing, or not passing, a tile. I can not use the A tab. This A tab is totaly different then the rest of the Tiles Tabs.

You need both ! and $ to prevent the shift for bush and to make a single (instead of 8) sprite on the sheet, if that was the problem.

A-Tiles are Autotiles - they use a special definition area six tiles as large as regular tile for a single autotile that changes behaviour depending on which tile is adjacent to the tile you painted. The autotile-Formats are described in the help file, and you schould really start experimenting with them instead of "only" painting the dungeons with the B to E tiles - especially as the B to E-Tiles are all on the upper layer, and you need A-Tiles (bottom layer) to use the B-E-Tiles with transparent parts to place on them.

Just follow the official basic tutorials for mapping to see how that is handled...

This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.