Is the collision set to the pixels of an object or the whole object space? If it is the latter can the collision be set to the pixels?
I am asking questions without actually checking as I get sucked in and start doing other things. I’m not trying to be lazy 
Rectangle creates a rectangle border from the farthest pixels of your initial sprite. Circle builds an oval barrier around the distance of your farthest middle pixels, unless your object is square, then the circle barrier would be bigger than the actual sprite.
This is a huge problem and one that will probably cause me to to leave flowlab.
Hey DopeteK,
Out of curiosity, what is the problem you are encountering? Collision shapes is a very common approach in games with physics for two reasons:
- This is far faster than per-pixel checks
- More fine-grained checking can cause your game objects to hang and snag on the environment
I’m just wondering what you are trying to do that isn’t supported by the current system.
Hi and nice site you have here.
I am not actually encountering a problem as such, I am foreseeing as many problems as I can. Planning is everything if you’re serious about creating something.
Not that I am making a one on one fighter but if I were to it wouldn’t work because an attack like a strong kick that extends the sprite would leave a big empty space when the strong attack is not being used. The player could then be hit with a sweeping kick by having the empty boundary of his sprite touched.
Maybe a workaround would work such as attaching several objects together to make player object but they would all have to depend on one central object. I have no idea if this would work.
I also thought maybe you could implement a mask to each frame to define the hit shape. Maybe…
Or even create a bunch of hit shapes to add to the circle and square and allow a different shape to used on each frame.
I was also curious, because pixel detection is usually only made for rectangle. Even in the old street fighter games. Idk if you’re looking for some way to make large fighters that aren’t single sprites, in that case, maybe “attach” would work for you.
It’s a bit of a hassle, but basically, you could make a body, attach a head, attach 2 arms and 2 legs, then give them each their own button controls. That’s how QWOP and CLOP was made, and Happy Wheels.
As I said at the start of my second paragraph, I am not making a fighter. Interaction between sprites is currently inaccurate.
I am going go need at least ten characters on screen at once so attaching extra objects may prove to slow the game down and also make animation fiddly. My sprites should only be around 96 pixels tall so bolting on extra parts seems a waste of assets. I have been playing games since the 70s and have an extremely well rounded understanding of games and theiro mechanics. I would be bolting on sprites for some attacks because it makes sense to do so but to base all sprites on that.
Dp you know the limit for onscreen sprites?
http://spritedatabase.net/files/mobile/1709/Sprite/SF2_DJ.png
The attach method used in SF2 (SSF2 in this example) works because the main sprites bounding box can change shape. As my sprites are quite small compared to SF attaching objects will work for the most part but my players could never duck due to the empty space being able to collide.
I am creating several styles to my main sprite in order to see what fits an object space the best and needs the least amount of attached objects. I shall post a gif of a walking animation soon.
http://postimg.org/image/lqy0q7g9h/
This sprite reduces most of the problems but reduces the animation detail. please note that I haven’t added the last four frames to the walking turtle as it is just a test and I got bored.
Just tried those games mentioned. Annoying games but I was better at the horse one.