Fast Shooter Collisions In Etoys <https://www.youtube.com/watch?v=HSAwpGog0Ic>
Moving forward with testing and maximizing Etoys tick profits (i.e. how much can we make it do per tick!?), I've made a short documentation of looking at collision from a standpoint of 'do we REALLY need to check EVERY pixel?' I think asking this question every step of the way when two things need to *appear* to collide and/or touch, it's definitely worth thinking about that. In this case, the fewest amount of pixels we can check are the player's ship and shots. From the perspective of the ship detecting death from enemy shot, all of the enemy shots quickly tally up pixels that are far more than the 8x8 pixel arrangement of the ship, so we can just check underneath the ship for bullets. For the aliens...it might seem smarter to check the aliens because there's far fewer of them than shots, but from a pixel perspective, one alien has as many pixels as about 6 or 7 player shots hovering in the air, especially since each one is 3 8x8 blocks. In this case, having the shots check for collisions is cheaper/faster. Once they detect they're over AN alien, then all the aliens are asked if they see the a player's bullet. If they do, they go away. One of the other things you'll notice here was an uncovering of Etoys ERASE functionality being a little strange. Basically, when something 'dies' in this demo, it's erased. Erasing is strange because the morph becomes 'limbo-fied' momentarily...so you need to prepare for it to, as a nonexistent morph, not cause Etoys script issues! To do this, I simply made a variable called 'isDead' and set it to true so that all normal game functions only get carried out if isDead is False. What would happen is that when a 'dead' alien went to shoot, it was making a copy of a bullet to it's 'i'm not actually real' state of being and thus couldn't finish the script, causing bullets to be created and then scripts couldn't bla b l a h b a . . . you get the point. At any rate, if you run into Etoys scripting issues when making copies and erasing said copies frequently, be sure to let them have a way to 'make sure the real world knows they're dead' in some fashion before executing a script in which you do things like 'tell all contents' or 'tell all siblings' etc. Okay, that's this installment of 'Jeremy says stuff about Etoys 10 years after anyone cared about it'. :P On Wed, Dec 24, 2025 at 1:15 AM Jeremy Landry <[email protected]> wrote: > I just wanted to post here my findings experimenting with Etoys. My goals > are basically doing arcade style games (complete with chunky graphics) with > fast gameplay, cool animations and nice sound comparable to NES or Super > Nintendo, nothing fancy with crazy shaders and such and one of the problems > that happens is collision detection. > > Now, there's tons of programmatic ways to do this, but I think I stumbled > into a 'free' way to do it without sacrificing graphical fidelity (you'll > see what I mean in a moment). > > So for collisions we have multiple options: > OVERLAPS DOT > OVERLAPS ANY DOT > SEES COLOR > COLOR SEES COLOR > DISTANCE TO > > Now, what I want to get at is that collision detections are happening all > the time between all game objects. The background blocks, the characters, > their projectiles, random powerups, all these things are checking if > they're colliding and then deciding if they want to do something about it. > > In using OVERLAPS, you have to figure out a way to create a custom > collection of siblings IN your playfield. This is possible because you can > make a clear playfield that contains these objects. Why you'd do this is > becasuse you'd run through all the objects in there to see if the thing > you're looking at OVERLAPS one of them, specifically. And you'd do this by > running a TEST on COLLECTIONS using a REPEAT tile. Seems slow to me and I > didn't even bother. Call me a poor scientist. > > Next, the most promising is OVERLAPS ANY DOT. This means that you can > check your object against all siblings. However, depending on the kind of > collision this can be VERY SLOW! So if we consider that things showing and > not showing on the screen are part of OVERLAPS checks, this includes every > single morph in or out of the playfield, you quickly add up checks that you > don't even need. I don't need to check if my bullet overlaps the numerical > readout of a flap. Just the aliens! This proved to be the case that it was > slow when implemented. I tried to run individual alien scripts checking for > overlaps with any bullet but it was slow with just 10 aliens and no > bullets! So then I thought, Maybe it's the ticking scripts, let me have th > eplayfield tell them all at once to check. Nope, same result (slightly > faster, but not playable fast...something like 20fps...and we're shooting > for 60 and we just have 10 aliens and NO BULLETS? unacceptable > performance!) > > So next we only have the obvious color checks. But this poses a problem. > We want GRAPHICS. If we're checking colors, this means we can't have > unique graphics. I have a bullet that blue, that's fine, but I'm checking > for one color on an alien made of 30...this is not going to make good > collisions! > > However, it's FAST. SUPER FAST. I made about 50 aliens and filled the > screen with bullets and no slowdown. It turns out I discovered what is > happening...when checking overlaps, every object is 'woken up' to check if > they are in position or not, one at a time. Doesn't matter of individually > through own scripts or one script triggering all of those individual > scripts, they all individually move memory around for checks. > > The screen is just ONE object checking ITSELF. The colors are just pixels > inside the display screen object. How can we take advantage of this free > collision? > > By just drawing right on top of it when it's done and don't worry about > the details. > > Literally the solution is to hide it in plain sight. Make a playfield > that mirrors your objects and hide it for checks then show it before the > screen updates. It's like Etoys was just made for this, being able to do > it so fast. > > Attached is a link to a demo video, but a more complete demo is obviously > forthcoming with both screens filled. I just had the 'eureka' moment and > had to share it and record it so I can make sure my brain internalizes it > going forward. > > Fast Collision with Custom Graphics in Etoys > <https://www.youtube.com/watch?v=xOTDDfBeF8Q> > > I hope this helps folks using any smalltalk and looking to get some > performance. There's a lot of 'pure smalltalk speed tricks' I've been > figuring out. I know this probably isn't incredibly interesting to anyone, > making silly explody boom boom games, but I hope the idea of collisions > here for 'free' might be of use. I suspect it was implmented this way > because of what I found, but I'm never sure as there's not an especially > loud neon sign pointing to this as the 'proper way'. > > At any rate, thanks for reading. Just sharing in hopes it helps other > folks starting out getting some speed when checking collisions for a lot of > moving objects. The other thing I can tell you is don't do rotation math > unless you have to and don't scale objects UP, scale them DOWN. Memory and > CPU wise, these make a lot of savings when stacked. >
_______________________________________________ Beginners mailing list -- [email protected] To unsubscribe send an email to [email protected]
