ID:1321875
 Jul 12 2013, 3:55 am
|
|||||||
| |||||||
I'm not particularly sure on how easy this would be to implement but the idea of specifying a bounds_radius, that would extend from the bounds_x/y would be a really neato feature that would be realistically used quite a bit, currently softcoded methods are possible, but kind of messy and wouldn't be nearly as quick as a hardcoded one.
| |||||||
I totally disagree on this one. First we just have boxes, and now we just have boxes and circles? That's just pointless and inflexible. The correct feature to implement here would be bounding masks, where you can choose to make every pixel that's not transparent into a bounding shape. In this way, we can make bounds out of anything we want, and it will be compatible with any possible game. The only problem is, the bounding system will have to detect the transparent areas of an atom's icon.
| |
That's a pretty good suggestion to be honest, but again I'm not sure of feasibility of such a feature. If the BYOND staff can just whip that up easily, then go for that. If it's easier to implement my suggestion first, baby steps.
| |
The problem is, if your feature is implemented, it will be a bad excuse not to implement actual masks. If we get masks, then we can create circles with no problem.
| |
I have requested in the past a per-pixel collision detection pretty soon after pixel movement was released, optional; of course. Anything that could help to make bounds more flexible is a good step in my book.
| |
Tom has mentioned both mask-based collision and circular bounds in the past, in the original pixel movement announcement topic.
| |
Well, what you could have instead of circles is some kind of "algorithmically" based bounding shape system, although I'm not sure how that would work. You would at least be able to describe different kinds of ellipses, which would work better for things like isometric format. You could technically make whatever shape you wanted in this case, but the algorthms would get overly complicated, so masks would still be the ideal choice.
Either way, we really do need to start thinking outside the box! | |
Multiverse7 wrote:
Either way, we really do need to start thinking outside the box! I give you 9/10. | |
It's a lot more complex to use math to describe an ideal bounding edge, especially if you wanted a non-symmetrical one, or something. A mask would be ideal.
Circle-circle collision is super basic and I've played with it a ton before native pixel movement. It'd be more feasible to make my own collision to work with native pixel movement if there was something like Cross() that would work from within a bounding box (and of course, support sub-movements with fast projectiles). However, circle-square collision... yeah, no. | |
It would be interesting to see a mask type, as a 1-bit image that can be used for collision, as well as limiting what part of an atom is drawn without icon manipulation.
Also, I think that most recent CPUs have instructions that operate on many values at once, which might make testing two masks (or a mask and a bounds rect) faster, without needing much (relatively) advanced math like you would for a radius or ellipse. | |
Need more options for bounds, I hate just having boxes that are hard to form to your items/mobs more accurately.