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.
This example recreates a classic 3d effect that was popular on the 16bit platforms such as the Amiga / Atari ST. Those older systems support bit plane display modes, which makes such effects relatively easy. The effect works by drawing each side of the cube to different bit plane. This allows the program to alter the individual bits of the output pixel without ever accessing that memory
Modern computers use a chunky display modes though, where either a byte, 16bit word or 32bit integer are used to represent each pixel. Such displays are easy to draw dots onto, but make altering individual bits within the pixels more work. To recreate such effects in PlayBasic, we're setting up a 16bit Palette Mapped screen, then rendering the cube sides using the OR inkmode, so each side is drawn onto a separate power of 2. Creating an emulation of a bit planed display mode.
This example computes map of 'occupied' rects from the 2 colour image. The Image is expected to be either black (rgb=0 ) or pure white (rgb=$ffffff). The user can draw circles with the mouse to fill the frame in. The occupied Map is drawn behind it in GREEN and RED blocks in real time.
This following example create a conceptual 256 colour screen in memory (in a PlayBasic bank). The program fills the conceptual screen with colour index byte values. These values are written to form and sinus arc (See SIN) ranging from 0 to 255, where and each row displaced by one pixel. Creating a sort of curved diagonal pattern. Each frame we colour cycle the 256 colour palette with all of the shades of the current random colour. So it appears to move, even though we never have to modify the pixel data once it's created.
Here's a 16bit example that's using 4096 colour palette. The screen colour indexes are set up so that each pixel on screen is the distance from the screen center. The palette created each frame from 16 banks of 256 colours. Each block of 256 colours is shaded via sinus and offset in the palette table, creating the illusion of motion.
This source code example recreates the hires screen (character map) mode from the classic 8bit home computer the commodore 64. The code uses the new palette mapping commands to convert the bits in each character to groups of eight 32bit pixels.
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.
