ID:2081045
 May 7 2016, 8:12 pm
|
|||||||
| |||||||
Not sure how feasible this is but it would be pretty cool if the engine supplied an option to give movables a circular bound by letting us supply a radius to bounds
| |||||||
|
May 7 2016, 8:13 pm
|
|
DistantWorld101
 |
+ for circle bounding/moving
|
+
| |
Would rather have elliptical bounds with axes provided by bound_width and bound_height. Then you can set square dimensions for bound_width and bound_height and get a circle.
Either way though, this isn't too hard to do yourself by overriding atom/movable.Cross() | |
Cross() isn't going to be enough, Cross() is called once upon overlapping, as soon as you determine the circle can overlap another movable you'll have to keep track until Uncross() is called.
I think doing it manually will just end up being a lot of work for very little benefit and I didn't really ponder about how much tougher path finding will become. Should probably comb through previous posts on this topic and try to come up with a nice detailed setup from everyone's previous thoughts. No doubt this topic came up at least once before. | |
I had thought of an idea for bound_state and bound_mode vars. The concept could be extended to include a bound_mode = BOUND_ELLIPSE setting. Using bound_width and bound_height for the axes isn't actually good enough to define an ellipse in a general sense. You would also need a new bound_rotation var that can take any number from 0 to 360, to adjust the angle of the bounding shape. This could also work with bound_mode = BOUND_RECT, which would be very useful for isometric maps.
For the other, icon-based bound_mode collision settings, my current idea is to generate a kind of concave hull, by splitting a concave shape into multiple convex parts. This is known as convex decomposition. It all depends on the shape, and many shapes are just too complex to generalize with convex hulls. It would allow us to do things like this, other than the physics: | |
After seeing Ishuri's gif of the free form bounds he made for Land of Fire I asked him to point me in the right direction. He told me to look into GetPixel(). Using GetPixel(), Cross(), and some basic math to calculate positions you can make bounds any shape you want already. Done right the overhead is fairly minimal, depending on what you're using it for.
Ishuri's gif:  That being said, a built in feature specifically for elliptical bounds would be nice. | |
i find it hard to believe that the overhead would be small even if "done right" hence the reason for this request
| |
A lot of people find a lot of things hard to believe that this engine can pull off pretty well. Literally all this system checks for is a single pixel in an icon being a specific color. If you find the color don't let them move in that direction. It's not rocket science.
| |
If anything, that working so well in softcode is just proof of how efficient something like that could be if it was built-in.
I can imagine the CPU usage is quite high with multiple players doing that at the same time. I should also point out that you could simulate elliptical bounds with an icon-based approach simply by using an icon with a nearly invisible ellipse drawn in it. Clearly icon-based collision would be superior. There's just so much more that you can do with it. | |
I know right?
I was attempting to quickly implement circle/rect collision, I had same idea Dark had. Every second of it I kept thinking it could be better, more efficient. But perfectionism often gets me nowhere, it's advised to fight it, I'll worry about efficiency when a working code exists, not before. If it's important to you, try to get it done, ask for help when you face problems you can't solve. -Insert "Just do it" video- | |
The GetPixel() method is, I have to say, very very inconvenient to use; it probably only performs decently because once the /icon is loaded, if you're not doing a lot of other /icon work, it tends to stick around in the read cache and occupy memory. I'm glad it's working out, but I wouldn't recommend it for a general solution.
It's usually more preferable to setup some kind of system where you can look up which tiles have which properties, like for instance that certain tiles are ramps or whatnot, or certain ones are rounded. | |
Just to clarify the GetPixel only happens once. It uses GetPixel on the bound icons on startup and stores them in a global list for later use. Runs like a charm, even with multiple people, I don't even consider it in my CPU calculations because that's just how little it takes.
| |