Anyone know of any custom collision map scripts?

[jimfalcon]

Figured I'd make a new topic since I'm narrowing down the things I need.

I'm trying to break away from the square based grid. (Pink represents the tiles the player can move in)

To something more realistic and player friendly. I don't know if this requires a smaller tiles script, or a custom whatever (both of which I cannot find).

I'll still be looking for something that can enable me to do this. In the meantime if anyone knows anything it would kick ass.

 

[Shaz]

I've moved this thread to RGSS3 Script Requests. Please be sure to post your threads in the correct forum next time. Thank you.


If you are not using VX Ace, please say so, and I'll put this into the script requests forum for the correct maker.


What you are after is a pixel movement script. I'm not sure if they still handle collisions in a 32x32 grid though.

 

[jimfalcon]

Thanks for showing me the script requests section.

Yeah I managed to find a pixel movement script: http://area91.multiverseworks.com/blog/rmvxa_script/gameplay/free_movement

It works, but  (its kinda hard to explain, which is why I tried through visuals) only inside a 32x32 tile. For instance, say I used rpg maker to make a map using the tiles, all the bounds and borders and everything are pretty much square shaped. 

However I want to use pixel movement with my parallax map, which looks more realistic as far as homes and roads that arent 90 degree angles (square shaped) there are curves and everything. If I used 32x32 tiles to create paths the player could walk on, the player would collide with hundreds of invisible corners and walls during gameplay. 

 

[Tsukihime]

My collision maps supports pixel collisions but it's up to pixel movement scripts to actually check the passage settings.


Unfortunately, most movement scripts are based on tile coordinates rather than pixel coordinates so they probably will not automatically check for pixel passage settings.

 

[jimfalcon]

My collision maps supports pixel collisions but it's up to pixel movement scripts to actually check the passage settings.

Unfortunately, most movement scripts are based on tile coordinates rather than pixel coordinates so they probably will not automatically check for pixel passage settings.

Your collision map? Care to elaborate on that? You've successfully create a map with pixel collisions? how?

 

[Erojiji]

I tried Tsukihime collision map before, it used a pictures to make custom passability which very useful for the this script Idea because we can make the custom map organic.

The problem is when I tried to put organic collusion like this http://i.imgur.com/1Sp7L08.png
the passability will ended up like this http://i.imgur.com/jAscgdY.png on the game.

I'm not a scripter so I don't know how to fix this =w=a

 

[Shaz]

The problem with pixel-based collision is that it's going to be a LOT more CPU-intensive than the regular 32x32 collision. And since it will apply to the player PLUS events, it's going to be incredibly difficult to avoid a whole heap of lag.

 

[Erojiji]

Btw I just remember this guy using the same script like you want, maybe you can ask him.

http://rpgmaker.net/games/3082/images/38623/

 

[Tsukihime]

Your collision map? Care to elaborate on that? You've successfully create a map with pixel collisions? how?

This script http://himeworks.wordpress.com/2013/09/06/collision-maps/


The actual "collision map" (map as in, bump map) is stored as pixels, so if your passage settings perform proper pixel checks, it would be correct.


However as erojiji notes, the script doesn't provide any passage checking since the purpose of the script is to just load collision settings.


I have not been successful trying to modify existing pixel movement scripts because all of them use are tightly integrated with tile coordinates.


I might write my own pixel movement script at some point.

 

[jimfalcon]

Thanks for the replies, all of you, I appreciate it. 

Thanks Erojiji, I'll try and contact that guy.

Edit: Cool, i'll try this out anyway and see what happens. By the way, when it says, "place collision.dll in your system folder", do they mean the rpgmaker vx ace folder or the windows system folder? I wish they were specific about that.

 

[Venima]

I don't see why there would be lag problems, if coded right. On top of storing pixel collisions, you should also store a second map of tile coordinates that are completely free, completely full or partially full of pixel bounds (0, 1 and 2?).

That way you can check that first to see what value it is to avoid going through the pixel collisions unnecessarily. Since 90% of movement will not be on partially full tiles, you'll barely notice a difference. Character to character collisions can be summed up in a few if queries so that won't be a problem either.

 

[Shaz]

If you are looking at tiles, you have ONE set of coordinates to see if you can walk onto.


If you are looking at pixels, you have 32x32 = 1024 pixels, any one of which could be impassable.


Not that you're going to check all of them, but there are a significantly larger number of possibilities when checking passability of pixels as opposed to tiles.

 

[Tsukihime]

That's assuming you're using hit collision to determine passability. None of the pixel-movement scripts do that; they simply check if the target (x,y) coords is passable from the player's current position.


Which is very unrealistic of course, but it works because we're assuming all character sprites are the same as the tile-size, and if the sprite is bigger...well that's our problem.

 

[Shaz]

Yes, x/y coordinates based on a 32x32 grid. But the OP doesn't WANT collision based on a 32x32 grid - he WANTS pixel collision. That is why none of the existing pixel movement scripts meet his needs.

 

[Venima]

You have a point. However, what about bit-wise operations? You can store each tile worth of pixel data as 32 rows of integers, calculate the rectangle's coverage on the fly (note this will only need to be calculated once since it's rectangle) and perform a bit-wise AND. If the result isn't 0, there's a collision.

This is only bit maths so it should be lightning fast. Note, the tiles will be calculated much earlier, or on an as needed basis but memorized for future uses.

Edit: I could totally code this.

 

[Tsukihime]

Yes, x/y coordinates based on a 32x32 grid. But the OP doesn't WANT collision based on a 32x32 grid - he WANTS pixel collision. That is why none of the existing pixel movement scripts meet his needs.

No, his comment was directed to mapping using tiles vs mapping using images.


The pixel movement scripts provide ways to move less than 32 pixels per move, but they do not provide a way to set up passage settings for anything smaller than 32 pixels.


The collision map script provides a way to set up pixel-precise passage settings, but unfortunately does not provide pixel-precise hit collision for passage-checking.

You have a point. However, what about bit-wise operations? You can store each tile worth of pixel data as 32 rows of integers, calculate the rectangle's coverage on the fly (note this will only need to be calculated once since it's rectangle) and perform a bit-wise AND. If the result isn't 0, there's a collision.

Do you mean, using a bounding box based on the sprite's image? That would be a good start for sure.


An issue with that is that your collision detection is too "rough"; if you had a nice round sprite, you'd be hitting the walls before opaque portions of the sprite come into contact.


But this isn't an FPS so it probably doesn't matter if you clearly missed someone and still managed to headshot them.

 

[Shaz]

You sure about that? The issue in the images in the first post indicates that he doesn't want tile-based collision, because it limits him to still moving around in 32x32 tile areas.

 

[jimfalcon]

You have a point. However, what about bit-wise operations? You can store each tile worth of pixel data as 32 rows of integers, calculate the rectangle's coverage on the fly (note this will only need to be calculated once since it's rectangle) and perform a bit-wise AND. If the result isn't 0, there's a collision.

This is only bit maths so it should be lightning fast. Note, the tiles will be calculated much earlier, or on an as needed basis but memorized for future uses.

Edit: I could totally code this.

Coding is totally beyond me.

But yes, my problem is that when I first learned how to use parallax maps, the only way to give my player spaces to walk was to lay down transparent tiles using rpg maker, which is limited to 32x32 tiles. And like some of you have gotten from the pictures I posted, I'm looking for more of a way to either lay down smaller tiles to give more realistic walking space, and collision, or of a completely different way to lay down a walking space, if there is any. Thanks always for the posts.

 

[Tsukihime]

Sorry, I think I misunderstood Venima's idea. If the sprite's rectangle was stored like

000000001100011110011110001100000000Where the 1's are opaque pixels, and the 0's are transparent pixels, then doing bitwise AND operations with the target rectangle (which is where you want to move) would correctly consider transparent pixels.

You sure about that? The issue in the images in the first post indicates that he doesn't want tile-based collision, because it limits him to still moving around in 32x32 tile areas.

Yes you're right. I didn't pay enough attention to the images.

 

[Shaz]

So, let's say your pixel movement script lets you walk forward at 8 pixels each turn. That's 8x32 pixels that could be passable or impassable, and each one of those would have to be checked.