Quasi Movement

[JosephSeraph]

Cool! Awesome! Now... A feature that I think would be pretty cool, but I'm not sure how easy would it be, is to have the ability to get collision data from images.

For instance, have a regular Outdoors.png tileset, and an Outdoors_Collision.png tileset. The Outdoors_Collision would have Transparent as completely passable, and Black as completely impassable. Maybe Red would make it react like a counter. (not sure how would it go with directional passability, though... But that's kind of a minor loss.

That would be especially cool with parallax mapping, because it'd allow for some pretty rad PS1-ish prerendered backgrounds! Or more organic drawn backgrounds, too!

Also, this last one would be a bit hard, but in case of Parallax mapping, we would have parallax.png, parallax_collision.png AND parallax_depth.png. What parallax_depth.png would be: A grayscale map of the depth of the map. The blacker, the farther the player'd be from the camera. The whiter, the closer. The sprite being zoomed in or out accordingly, as well as character movement speed. Together with the rest of the functions, this would allow for a perfectly functional pseudo-3D system, reminiscent of Star Ocean 2!




in the last 15 seconds of the video you can see depth being applied to full extent!

I... Know this is kinda hard. Just a suggestion. This would make the simply and absolutely coolest pixel movement script in the history of RPG Maker LOL xD

I have no idea of what it takes to do it though

 

[Archeia]

I know what you mean by using image collisions but that is going to tax on performance. Hime made something like that though. And this.

I honestly liked this script for what it is though.

 

[Quxios]

The image collision does seem nice, but as archeia stated that's already a script for that + performance issue.  Also my boxes currently only support well boxes lol so if I were to tackle that I would convert the image into boxes that are loaded into my tileboxes, and that should only drop performance on map load.  But having weird shape like a circle depending on the algorithm I'd use, it'd either turn into a square or a bunch of tiny squares, doing the tiny squares would make it take even more time to load.

Another way could be like.. Forgot the name but it was the side-scroller where it has an ingame editor where you "painted" the collisions and that was saved into a file.

But I created the region tiles so you could have some custom sized boxes for parallax maps, but that may be hard to place accurately if you weren't using a grid. 

 

[Archeia]

it would be nice to have a circular collision but I could see why that would be pretty hard ;;;;

 

[deathsia]

Problem: Your script doesn't like it when people use paralax maps because it keeps flinging up errors at me saying its not finding tiles more or less.

any work around for this?

 

[Quxios]

Circles shouldn't be too hard, I'm just not sure how to draw them with bitmap lol

@deathsia: What parallax script are you using?  When I use my own it works fine.

 

[deathsia]

Tskiune's collision map script and what parallax script are you using? My maps hardly ever constrain to a 32x32 pixel grid which is why I THOUGHT hers would work fine but as it turns out, its still restricted to the 32x32 pixel grid instead of working like I thought it did. If yours works better please let me know what you use.

 

[Quxios]

Still need to know what parallax script you are using.  I don't think hime's collision map should be the issue but it shouldn't work/run with my script because I use a different collision check method, so hime's method shouldn't even run.  As for the parallax I use, its just a very simple parallax I made for my project, nothing fancy, all it does is "lock" the parallax by moving whenever the display moves so it looks like the parallax didn't move.

 

[Susan]

@deathsia:

First of all, the author of that script's name is Tsukihime.

Secondly, the script you are using is a collision map script, which helps to provide collisions to a parallax map, not a parallax script.

Thirdly, Tsukihime's script helps you to provide collision for your parallax map in a 32 x 32 grid. It was not meant to overcome the 32 x 32 grid limitation. She might have plans later, but for now, it is what it is.

Lastly, I have not found any errors related to Quasi's Movement script per se. If you are going to combine two scripts that affects collision, you are going to find some problems.

 

[Quxios]

Next update won't be for a while since I have finals next week.

But things I'm planning on adding in the next update/fix:

- Initial px/py values for events.  Noticed it was kind of weird having pixel movement but the sprites still started on a 32x32 grid

- Fixing vehicles hopefully

- Extra smart move options

And 2-3 addons:

- Region locking events.  Events can't move out of region.

- Collision Map

- Line of Sight with shadow casting (My wordpress has an old version, but it's been rewritten for better performance + workes with my current movement version, while old one doesn't. )

I won't be adding much support to the collision map though, because I didn't really like how it turned out, and feel bounding boxes is a better choice.  Collision map with "true" pixel collision doesn't feel right with just 8 directions, it needs a more fluid/ free movement/(360degrees direction?) because with just 8 directions you get stuck quite a bit. + The performance with bigger maps with events might be low since this is written in all rgss3 no external dll.
Example:

 

[Archeia]

I found a bug that the events don't face the right direction when talking to you.

 

[Quxios]

I ended up working on this a bit even though I should have been studying lol.

Most Vehicle issues were fixed ( I also noticed a bug that it still used the players box not the vehicle when inside a vehicle. )

Event facing direction is fixed.

Started to work on some 8 Direction sprite support.

Next update will still be posted sometime at the end of this week.

 

[Archeia]

Wow that Round collission is impressive and I'm super curious about it! Can't wait to try it out.

 

[Quxios]

@Archeia - I was thinking of doing the circle boundings but when I tried out the image collision mapping, it was easier then expected ( super easy, was like 10 lines of code ).  So I ended up not making it since you could just make the circle inside an image collision map.

Finally ironed out most of the bugs! (Hopefully)

- Link

I removed some of the documentation out of the header, and the stuff that was removed will be on my site and the first post here.  The documentation still hasn't been written so give me 2-3 days to get to it xD.  Nothing new, bounding boxes are still set up the same as before, but there is the new <ox=NUM> and <oy=NUM> which just offsets the events px / py (ignores grid, so it can take events off grid).

Going to try to finish up that Collision Image Map addon and have it up within the next 2 days as well.

 

[Quxios]

Collision map addon is finally out!  I'm not going to make a separate topic for it, since it's just a small add-on / patch? for this script and doesn't need much documentation, so sorry for the bump!

Site Post - ( small documentation, basically a rewrite of the header )

Collision Map - ( make sure quasi module and movement are up to date, I had to do a few changes to them )

Demo

Links will also be added on first post.

 

[deathsia]

Okay ran into a problem. I figured out that I needed to chuck your scripts at the bottom of my list in order to get it to work, hate that but i digress it works but as I said there is a problem... I set it to the hex value of white being the unpassable color and instead I can move all over the map, now I have set clear tiles on the map but I'm not sure this would affect it. If it does, please tell me how to delete said tiles because I have no freaking clue how to do that. I looked at your demo and it works EXACTLY how I want it to but in my game it seems to not work right for some reason.

Edit: Dumb question: Do I have to use the exact same map except with the color code over it or something?

Also: I noticed the events are unable to move yet the player can, what's up with that?

Update: Its still flinging up errors btw on basic tileset maps on line 1102. I have no clue what the cause is. I have disabled all other map based scripts as far as I know.

Update 2: I've tested to see if its scripts causing the problem by copying over all my basic project files to a new prject with only your scripts in it and I run into the same error and being able to walk through everything on the first map. I would LOVE to know what I'm doing wrong here.

Update 3: I'm uploading a zip file with my basic project files in it for you to view. I'll also include my scripts data file that you can also download to see what scripts I'm using though I've already determined its not the scripts, it may help you none-the-less to look at them. I will update this post once they are uploaded

My project: https://drive.google.com/file/d/0B_YDArpZ0YDqWTg3bjU1b3h6THc/view?usp=sharing

The script data file: https://drive.google.com/file/d/0B_YDArpZ0YDqT2JvWXhRWnJlemM/view?usp=sharing

 

[Quxios]

Collision map has a separate collision from tiles, so tiles shouldn't affect it.  First you should make sure both movement script and my module are the current ones.  Movement needed a small patch for errors and module has the color methods, probably best to copy it off the demo, cause there's a slight chance I uploaded the wrong versions lol.  Other then that it might just be some incompatibility issue overall, so I'll pm you for info on that in a minute. 

"Do I have to use the exact same map except with the color code over it or something?"

Not sure what you mean by this.  But in the demo, there's 2 images in parallax, you don't need the parallax map, it can work with normal tiles too, but then no point of using collision map if its not for parallax.  The 2nd image is an overlay with the collisions + some pixel regions ( for testing purposes ), just make sure you use the <cm=FILENAME> tag inside the map that you want to use that collision map.

 

"I noticed the events are unable to move yet the player can, what's up with that?"

Not sure what's wrong with that, events work perfectly for me and in the demo.
 

"Its still flinging up errors btw on basic tileset maps on line 1102. I have no clue what the cause is. I have disabled all other map based scripts as far as I know."

On which script? and what's the exact error?

Edit: Found a small error/typo in the color method, I was putting it in as rbg instead of rgb lol, not sure if that'll fix any of your problems, but the githud is updated for the fix

 

[Tsukihime]

I'm using 1 pixel grid. However, when I try to move along the floor, you can see that there's a visible gap there.

Is this a bug or is it intended? It doesn't occur in every direction though (approach from left looks fine as shown)


I'm using the default collision box that you've provided.

 

[Quxios]

I think that is a slight bug, I tend to see only when facing direction 6 and 2, but it's usually only a 1 px gap.  The gaps are probably because of the characters movement speed, since that changes how much pixels they are moving, so I built in some method which you can turn on by setting SMARTMOVE to :speed or :both to try to fix it.  But I still see it so it might be just some slight miscalculation in the collision check like misusing a great then/less then sign.

Edit, kinda.  Tested while typing this and changed the <=, >= signs to just <, > seemed to fix this for me.  If you want to change that yourself, the changes were on lines 576, 577, 603 and 604,  didn't really test this much so not sure if this might cause overlaps in other situations.  But I'll look more into this over the weekend.

 

[Tsukihime]

That works well.

Do you have suggestions on move routes? For example, moving one step would now be one pixel for me (as opposed to 32), which means I would need to basically copy the command 32 times to move like before.

Now, that's in theory.

In practice, it works differently.

My move route is "move left, move down".

The way the script does it is to repeat this a bunch of times, so instead of the character moving left and then moving down in a clean movement, you see it repeatedly moving left and down very rapidly.

I assume this is the decision you made to provide some backwards compatibility, but I think it would make more sense to multiply the commands.

Move LeftMove Downto

Move LeftMove LeftMove LeftMove LeftMove LeftMove LeftMove LeftMove LeftMove DownMove DownMove DownMove DownMove DownMove DownMove DownMove Down

Based on the ratio of the current grid size to the default grid size.Of course, I would make it so that if there's a COMMENT before the move route, only then would it perform this multiplication.