This is a small collection of mostly game example source codes. These source codes are made available to help PlayBasic programmers kick start their game programming journey.
Looking for more source code / tutorials & media, then remember to visit the PlayBasic Resource board on our forums.
Found #4 items in Sprites category by Kevin Picone
In this example we look over three methods for doing Pixel Perfect sprite collisions manually in program code, rather than using the built in sprite collision method (see SpriteCollisionMode) .
Sprite Collision Method 1: Raw Image (point by point) - The first example computes the common area the two sprites share and then reads the source pixels from the source sprite, checks for a mask colour then does the same for the Destination sprite. If the two pixels are Not mask colour, then we have a collision. This method works but there's a lot of surface overhead constantly pulling individual pixels from the surfaces via Point()
Sprite Collision Method 2: Byte Mask (Preprocess images into a 8bit Collision Mask) - The second method actually works almost the same as the first, except this time we create a collision mask of each image. The mask is an 8 bit version of the image, where each byte in the mask is either 0 for transparent or 1 for solid. The sprite collision routine then uses the same logic as method #1 but directly reads the mask bytes rather than reading pixels. This means it doesn't matter what type of image format (video/ FX/ AFX) the cost of reading the mask is the same regardless.
Sprite Collision Method #3: Span Buffer (Preprocess the images into a span list of hard pixels only) - The last method we look at is an extension to the mask concept, expect rather than store pixel data, we scan the image and make list of hard spans (none transparent pixels) for each row. Each span is just two values, the starting coordinate and length of the span. The data structure contains a table at the top of offsets into the span list, so we can look up each row as need be. Rows with no solid pixels, don't create any data, so we're only every comparing solid pixels to solid pixels. The regions might not overlap, but for most sprites it all boils down to only a couple of compares per row..
PlayBasic has a number of sprite collision methods built in, ranging from simple bounding box intersections, rotated bounding box, Vector Shape ( Polygon Collision supporting Convex / Concave & complex polygons), Various sliding methods through to Pixel Perfect collision mode.
Video
Sample Code
This is the pixel perfect sprite collision function from the first demo, it basically just computes if the two sprites share a common area and then runs through the pixel data point() by point() exiting when it finds two pixels that aren't mask colour
PlayBasic Code:
; *=---------------------------------------------------------------------=*; *=---------------------------------------------------------------------=*; *=---------------------------------------------------------------------=*; >> Sprite Hit Pixels <<; *=---------------------------------------------------------------------=*; *=---------------------------------------------------------------------=*; *=---------------------------------------------------------------------=*; This function check if two spites overlap at pixel level. ;;; *=---------------------------------------------------------------------=*constant SpriteHitPixels_DEBUG =falsefunction SpriteHitPixels(SrcSprite,DestSprite)
SrcX1 =GetSpriteX(SrcSprite)+GetSpriteHandleX(SrcSprite)
SrcY1 =GetSpriteY(SrcSprite)+GetSpriteHandleY(SrcSprite)
SrcWidth =GetSpriteWidth(SrcSprite)
SrcHeight=GetSpriteHeight(SrcSprite)
DestX1 =GetSpriteX(DestSprite)+GetSpriteHandleX(DestSprite)
DestY1 =GetSpriteY(DestSprite)+GetSpriteHandleY(DestSprite)
DestWidth =GetSpriteWidth(DestSprite)
DestHeight =GetSpriteHeight(DestSprite)// Manually check if the two sprites at least share the same area; if(SrcX1+SrcWidth)> DestX1
if SrcX1 <(DestX1+DestWidth)if(SrcY1+SrcHeight)> DestY1
if SrcY1 <(DestY1+DestHeight)//Status=true// Scan through smallest region of the two
OldSurface =GetSurface()
SrcImage =GetSpriteImage(SrcSprite)
SrcImageMaskColour =GetImageMaskColour(SrcImage)
DestImage =GetSpriteImage(DestSprite)
DestImageMaskColour =GetImageMaskColour(DestImage)// Compute the rect the two images share
ClipX1=MaxVal(SrcX1,DestX1)
ClipX2=MinVal(SrcX1+SrcWidth,DestX1+DestWidth)
ClipY1=MaxVal(SrcY1,DestY1)
ClipY2=MinVal(SrcY1+SrcHeight,DestY1+DestHeight)#IF SpriteHitPixels_DEBUG=trueBoxc DestX1,DestY1,DestX1+DestWidth,DestY1+DestHeight,False, Rgb(255,0,0)Box ClipX1,ClipY1,ClipX2,ClipY2,false#ENDIF// Translate the world space cords to local // image space cordinates
OffsetX =SrcX1 -DestX1
OffsetY =SrcY1 -DestY1
ClipX1 -=SrcX1
ClipX2 -=SrcX1
ClipY1 -=SrcY1
ClipY2 -=SrcY1
OldSurface=GetSurface()// Brute force scan through imagesfor ScanLPY = ClipY1 to ClipY2
// Check if this row overlap rendertoimage SrcImage
for ScanLPX = ClipX1 to ClipX2
ThisPixel1=Point(ScanLPX,ScanLPY)if ThisPixel1!=SrcImageMaskColour
rendertoimage DestImage
ThisPixel2=Point(OffsetX+ScanLPX,OffsetY+ScanLPY)if ThisPixel2!=DestImageMaskColour
STATUS=TRUE#IF SpriteHitPixels_DEBUG=falseeXITfor ScanLpY
#endif#IF SpriteHitPixels_DEBUG=truerendertoimage0dotc OffsetX+ScanLPX,OffsetY+ScanLPY,$00ff00;ThisPixel2 #endifendifrendertoimage SrcImage
endifnextnextrendertoimage OldSurface
endifendifendifendifEndFunction Status
Downloads
The examples are attached to this post. Log in to download them.
This example lets the player move a sprite character around an oval shaped track. The player has full sliding collision with the track and fences. The demo uses the built in sprites sliding world collision mode to handle the positioning of the sprite. All we do is move it, the collision engine will work out the new position for us. Obviously if the collision is world based, we need to create world, which is done randomly here in code. In a real game you'd knock up a little tool for such things.
To create the track shape, we draw two ovals to a world buffer, an outer and inner edge. These two edges form the track. Sliding collision is single sided so the line segments in the outter oval and inner oval need to be connected in opposite directions. Together these form the area that will keep the moving sprite within.
The track also includes some randomly sized rectangles splodged around it. These also drawn as line segment outlines. Where each segment is pointing outwards. So when a sprite pushes against the segment, the collision engine pushes/slides the character into new safe position.
Anyway, most of this example is really in setting the collision world. The actual movement code in the main loop is trivial, nothing more than MoveSprite. In a real game we'd obviously use our own game editor to built the collision world to suit the game visual environment.
This example breaks away from the concept that depth is straight into the screen. In fact, Sprite Depth/ Scene Depth are just a sort order keys for the object. We can set the depth key to anything we like (0 to $ffff). Here i'm creating a scene where the sprites drawn vertically sorted upon their Y values.
To do this, we're using the sprites screen position on the Y axis, and inverting it for our depth value. We need to invert the value as the sorting engine draws things in highest to lowest. So smaller z values are drawn after higher ones.
What this means is that characters further down the screen (represented as some coloured ellipses) are drawn after characters above them. So foreground characters can appear to walk in front of other characters.
Release Type:
The source code & tutorials found on this site are released as license ware for PlayBasic Users. No Person or Company may redistribute any file (tutorial / source code or media files) from this site, without explicit written permission.
