How do I enforce solid behavior on high speed bullets

I'm running through the tutorial for Jumble Art at

downloads.scirra.com/books/levelzero.pdf

I've designed the app exactly how the PDF tells me to. When I set the Bullet Speed of the MonaPieces to 2000 they fail to stay within the 4 sprites arranged into a box with the solid behavior set. If I pull back the speed to 1000 the problem seems to go away.

I thought this might be a timing issue so I set the Bullet initial speed to 0 and set it to 2000 after a 5 second Wait. The problem repro'd again.

Is this a bug or is 2000 too high?

I think it's just too high. If you divide your speed by the framerate, you get the number of pixels your object will move in one tick. I'm not sure how the collisions work, but I think your threshold for missing collisions is when the bullet travels farther in a single tick than the sum of its length and the thickness of the object you want it to collide with.

If the object is going 2000 pixels per second it then moves 2000/60 or 33 pixels in one frame. If the framerate ever goes lower than 60 then the distance moved in a frame will increase.

Solutions include checking in between positions for collisions, or stretching another Sprite as a line from the old position to the new and check collisions with that. Alternately you could also lower the speed or make the obsticles thicker. If you use the the physics behavior you can check "bullet" collisions for objects to solve the issue internally.

There have been other topics on this with examples of solutions.

Part of the problem is well described in above posts. I have seen many proposed solutions, and none satisfies me (at this point).

I would like to add another part to that description of the problem.

Most behaviors are fps corrected. Meaning: their units are given in unit/second. The bullet speed is given in pixels/second. Meaning distance traveled / tick depends on the fps. To accurately detect a collision, at high speeds, at the inevitable sampling frequention 60/dt, it is needed to calculate from units in pixels/second to units in pixels/tick. And back. This, i found in the past, is very tricky. (well for me it is, i am no math wonder at all)

Conclusion (in my opinion) it is to difficult to use fps corrected behaviors, when dealing with high speeds. It is quite impossible to get them sync with the sample rate that goes with a fps. Rather build an own system based on units/tick.

This is an example.

https://drive.google.com/open?id=0B1SSu ... W5OcTRxV2M

Now, the max possible speed is now distance to travel * fps.

In this capx that comes to Speeds like 60.000 pixels/second, that is close to 1000 pixels / tick at 60 fps, theoretical, in practice probably 50.000 pixels/second.

Thanks for the feedback. I guess i'm still wondering if this is a bug with the platform? I say that because I thought the idea behind the platform was to abstract any issues or dealings like this away from the developer and "just work". If I say it's a solid, it's a solid, it absolutely will not allow anything to pass and the platform should calculate and guarantee that. Or maybe this is an intentional design that developers want, wherein x% of objects will escape a solid?

Thanks for the feedback. I guess i'm still wondering if this is a bug with the platform? I say that because I thought the idea behind the platform was to abstract any issues or dealings like this away from the developer and "just work". If I say it's a solid, it's a solid, it absolutely will not allow anything to pass and the platform should calculate and guarantee that. Or maybe this is an intentional design that developers want, wherein x% of objects will escape a solid?

I think it's extremely unlikely to be a bug with the platform (and by that I'm assuming you mean Construct 2 itself). As in any software, bugs in C2 do happen, but I would think this is not the case, and the problem you're experiencing is due to the limitation of how computers actually work and how the ticks actually run and are computed. I believe the above posts are correct. That tutorial is massive so I've not been able to look at exactly what you're talking about, but I think in my words, this is what's going on:

• Bullet is shot
• Bullet travels at speed 2000
• The above means it travels very fast at 33 pixels per tick or something
• The wall is not thick enough/the bullet is too small, meaning:
• Bullet literally is able to teleport through the wall and this is normal

Construct is working like this: During one frame, the bullet is close to the wall but not yet colliding with it, so Construct has no reason to check for collisions. It cannot predict the future! During the next frame, the bullet has to be moved at its speed (still assuming 33px per frame). The bullet is moved and appears on the other side of the wall. Construct didn't check for collisions because it never hit the wall. This is due to the "jump" of 33px per frame being too big; wall thickness / bullet length is not enough to even cause physical contact between the two to happen. As far as I'm aware it can't detect between a tick.

The only solution I can think of would be to detect when the bullet is outside of the wall (either by using its X or Y, or having some kind of large, invisible sprite outside of the wall that a collision could be detected from). When you detect that collision, you run your code that's supposed to happen after that, and for example that may be destroying the bullet and creating particles on the inside of the wall at the appropriate place using some kind of calculations. It's a bit dodgy though imo. Hope this helps!

Thanks for explaining the mechanics. Makes perfect sense. I don't agree that this isn't a bug though. From a black box perspective, I think it's fair that if the developer, in saying, this is my collision object and nothing gets past it, it's the platforms job to ensure that. If the design of the platform fails to enforce it, that shouldn't be the developers fault.

I do like the option to let things pass through solids personally and this issue seems for the most part easy to mitigate. It would be nice if it wasn't a surprise followed by confusion however and exposed as maybe a property of a solid, such as Solid.BlockThreshold? For example if I set it to 50%, only half of the total bullets would collide, the others would pass through.

Possible resolutions.

-Document this behavior for now to prevent this conversation Is it documented?

-Post a warning in the IDE when setting high speeds on bullets, etc that collision objects should be sized appropriately.

-Assuming no performance loss, update the platform engine to calculate bullet direction, collision objects in it's path, pixel distance traveled per tick, bounce the bullet off collision in current tick if next tick will put bullet out of bounds, ...

-Block high speed values for bullets, etc by some form of intelligent reasoning, maybe based on existing objects, or just in general, ...

self-censorship

kirksl

I do see your point, but I guess there are always use cases that just don't work with many things.

Anyways it wouldn't hurt to file a bug report I guess. That way you could get an official response. I do think that the issue was filed before, so maybe a search could find it.

Another option would be to request an addon. I don't see any reason an "enhanced bullet" behavior can't be created, with one of the described additional functionalities built in. Besides the fact that someone actually has to do the work of course. It would probably involve adding a raycasting function to the bullet movement behavior that could return an expression with the collision point. This may be significantly more resource intensive than the original bullet behavior though.

On the other hand, when people try to design with bullets travelling so fast I generally feel its safe to recommend using a raycasting bullet system to begin with, and not use the included bullet behavior.

IMO, I always felt bullet was a bit of a misleading name to begin with, as it ends up being useful for so many things that are not "bullets". Maybe "Linear Motion" or "Projectile"? Guess it's not that important.