Using 16x16 Tiles in RPG Maker - How it's Possible?

[Evan Finkel]

Hello, I was wondering if using 16x16 tiles in RPG Maker VXAce is possible, since it uses 32x32 tiles. Parallax mapping is a solution but I didn't know how to do this.

Thank you.

 

[Shaz]

I've moved this thread to VX Ace Support. Please be sure to post your threads in the correct forum next time. Thank you.


No, it's not possible to use them in the editor as tiles. As you say, ALL versions of RPG Maker use 32x32 tiles, so that's what you have to supply.


There are a number of threads on parallaxing and a few tutorials. Just do a search.

 

[Sharm]

You could, however, take 16x16 tiles and double the size of the image.  This is how the Old School Modern tiles and Tiny 16 does it.

 

[no dur hah]

Yup, you resize it to 32x32. It gives the same effect.

 

[Espon]

Are there any scripts that could take double-sized tiles and downsizes the maps to 16x16 tiles during gameplay?  That could actually be a useful way to making more detailed maps, although it would effectively half the total number of tiles you can use on a tileset.  Would be even better if it supported half tile movement.

 

[Andar]

No - the problem is that you cannot exchange the grid of 32x32, and all default functions are based on that grid.


Even parallax mapping only allows you to change the display, but the actors still move in the 32x32 grid.


There are scripts that allow pixel movement, but they all have their limitations as well because the events could not be handled outside the grid. You'll have to completely rewrite the engine to use a different gridsize.

 

[Engr. Adiktuzmiko]

That note though that it seems like Hime is working in the past few month/s about figuring out how to do pixel movement with collision and event triggering correctly... It's really a huge amount of work to get those to work though. 

 

[Matombo]

I was actually thinking of the other way around: making char models 64px wide ad let them move 2 tiles at a time (im combination with the high-res dll)

is there a way?

 

[Millefeuille]

You can more or less modify the player's movement metrics to be whatever you want, but it's a concern of whether or not the result is good. As far as I know, everything done in terms of movement is subject to the limitations of the tile grid, and I think that was already mentioned. If you're effectively moving two tiles ahead per keystroke, you'd have to be making collision checks for the 32x tile in front of you and the one two spaces away. It introduces a lot more variables for things that can go wrong and probably will look a little clunky moving a larger sprite in such a fashion.

I dislike that kind of modification that requires you to struggle against the engine though, so don't take my word for it!

 

[Engr. Adiktuzmiko]

@Matombo - Pixel movement still... Plus the problems with smaller than 32 pixel movement would still be there if you use a higher than 32 pixel movement.

 

[Evan Finkel]

@Shaz I know how to parallax a map, but I didn't know how to get it to working in the game.

@Sharm That's a solution too, thanks.

 

[Andar]

@Shaz I know how to parallax a map, but I didn't know how to get it to working in the game.

You need a parallax script to do that, and how to use that script depends on which script you're using. Which means that there are several tutorials and description how to get a parallax working available, but each tutorial only works for a specific script and is useless if you try to use a different script.
You'll have to select which parallax script to use first, and then search for a matching tutorial.

 

[Tsukihime]

That note though that it seems like Hime is working in the past few month/s about figuring out how to do pixel movement with collision and event triggering correctly... It's really a huge amount of work to get those to work though.

Pixel movement and collision detection should be two separate things really.


I don't like how most scripts, mine included, try to address it as one problem.

 

[Andar]

Pixel movement and collision detection should be two separate things really.


I don't like how most scripts, mine included, try to address it as one problem.

Yes and no - movement and collision detection are closely connected, because you can only have a collision when one or more of the objects move.
Knowing how an object moves allows the collision checks to be limited to that kind of moves only - that's the entire reason behind the grid structures.


Making a general collision script that can check all kinds of movements and shapes requires a lot more processing power - and in most cases the player wouldn't be able to see the difference to a movement-specific collision script.

 

[Tsukihime]

Yes and no - movement and collision detection are closely connected, because you can only have a collision when one or more of the objects move.


Knowing how an object moves allows the collision checks to be limited to that kind of moves only - that's the entire reason behind the grid structures.


Making a general collision script that can check all kinds of movements and shapes requires a lot more processing power - and in most cases the player wouldn't be able to see the difference to a movement-specific collision script.

They are closely connected, but that's like saying battlers are closely connected to battle systems because without battlers there will be no battle.


A general collision script would be preferred because movement would simply be a matter of "does it collide with anything if I move here?" and you wouldn't have to worry about how to actually check for collision.


But as you say, collision is expensive, especially if you want pixel-perfect detection.


If coarse detection is acceptable (eg: grid-based), then now you have separated collision from movement cleanly.