0 Members and 3 Guests are viewing this topic.
Here is a pretty small method for pixel-based sprite collision checking. Whereas your previous combination of 22 hard-coded pxl-Test() checks weighs in at a whopping 620 bytes, this routine is 99 bytes. As you might expect from this loop-based approach, though, it trades size for speed. Whereas your previous method would take about 9,000 cycles, this method will take about 26,000 cycles for your sprite.Another great thing about this approach is that it, instead of using a large list of X and Y offsets for each pixel that you want to check, it simply reads from a sprite. This means that this routine can be adapted to any sprite by simply changing the Pic0 reference to point to your 8x8 sprite. However, this also means that is slowed down additionally by checking pixels inside of the sprite, which you may not need to check. You can get rid of these unnecessary checks by having this routine read from an 8x8 sprite only containing the collision points (probably the border). If you added another 8x8 sprite containing the 22 collision points you used in your hardcoded method, you would be adding 8 bytes for the sprite but subtracting about 6,000 cycles from the collision checking.Code: (99 bytes, ~26,000 cycles if no collision (based on Scout's helicopter sprite)) [Select]8While 1 -1→T .that's a subtraction sign {+Pic0}→U 8 While 1 -1→S If U^2 If pxl-Test(X+S,Y+T) Goto COL End End U/2→U End!If SEnd!If T
8While 1 -1→T .that's a subtraction sign {+Pic0}→U 8 While 1 -1→S If U^2 If pxl-Test(X+S,Y+T) Goto COL End End U/2→U End!If SEnd!If T