I have to admit I’m still sometimes confused about when to use for each. I would normally have to use it always, but Gdevelop has the “select” feature in which it should select one object that satisfies a condition, among many. E.g. if we have 1000 enemies, all moving from left to right, isn’t it enough to have e.g. If Enemy.X() > 1000 then Delete Enemy without using for each? If there are multiple enemies outside of the location, I would presume they would all get deleted in whatever random order, which should be invisible to the user, so the order shouldn’t be important.
I would like to ask about a couple of things:
-
What is the problem with using layers, does collision check or distance comparison not work between layers, or something else maybe? I haven’t yet used layers with gdevelop much, so it would be good to know.
-
Regardless of number of boxes used, why do we need any more boxes than it takes to fill out the screen (I mean, why do we need any boxes outside of the screen)? If you have a character and camera movement, then I understand eventually there will be no boxes once you move outside of the initial screen.
Layers would definitely fix this, but we can also position the boxes to follow the camera position on each refresh (or better, each time that the camera moves, update the position of boxes as well to follow camera).
Finally, we are doing pretty serious optimizations here comparing to some other work (e.g. limiting to 40 boxes). It shouldn’t be a big problem to position or check collision against hundreds of low polygon objects. I made a small 3D FPS shooter with polygonal precision collision, bullets firing, effects showing, and it would still work on a Netbook (which is less powerful than modern smartphones) at acceptable FPS. Admittedly, that is using a 3D game engine that compiled to Native Direct X, and not WebGL/HTML 5, and the collision engine was using optimizations to check only the nearest vertices (but still likely in float or even double precision). Possibly WebGL still carries serious limitations. I hope there’s room for improvement, that is, that Gdevelop code can run somewhat faster in the future updates by default.
That said, I just remembered that we can limit our collision check to integers.
So, then we could use this kind of distance check:
[code]X1 = floor(Object.X())
Y1= floor(Object.Y())
X2=floor(Object2.X())
Y2=floor(Object2.Y())
FastDistance=abs(X2-X1+Y2-Y1)[/code]
Then we can check for each object with something like:
If FastDistance < TargetDistance then Hide Shadow
If FastDistance > TargetDistance then Show Shadow
Of course, this doesn’t “fly” as an accurate collision test, and that’s why we have Pythagoras. But here we’re talking about as fast as possible, rather than accurate.
Also, I see that because we’re not using else, we actually perform this comparison (larger/smaller) 2 times. This probably takes nanoseconds as long as the browser assigns priority to the game at that point in time (I would be largely surprised if it takes more), but might take more to do such checks with collision, or other more resource intensive checks.
So, in this case we wouldn’t get any advantage, but let’s say we have a more resource intensive check, and then here’s a way to avoid doing the check twice (for any type of such check):
If ComplexCollision(Object1,Objec2)=1 then variable InCollision=1
if Variable(InCollision)=1 then do...
if Variable(InCollision)=0 then do...
variable InCollision=0
This should actually help with complex collision check, or other intensive calculations.
