|
|
|
| CreateWorld | |
| CreateWorld WorldIndex | |
| Parameters: WorldIndex = The Index of the world you wish to create |
|
| Returns: NONE | |
| The CreateWorld command initializes an empty world space where you can capture gfx commands to. Worlds are an extension of the camera and scene buffer mechanisms. They're designed to hold entire level layouts of a game, or perhaps many levels in a static form. Worlds can hold any type of graphic item that PlayBASIC can draw. Including Dots, Lines, Circles, Images, Maps, Text etc etc. Once a world is created, the programmer can either quickly draw/grab screen sized sections of this larger world via the camera, or perhaps use it for sliding collision or ray intersections. You construct a world by first initializing it with CreateWorld command. Next, you'll need to position your graphical items in the world so you have something to draw. To do this, you instruct PlayBasic to capture all drawing operations to this world via the CaptureToWorld command. This will redirect the drawing commands to your selected world. When capturing, your drawing in World Space coordinates and not screen coordinates. The world has no limit upon size, and can be as large as you like. You're only limited by the amount of memory. As a general rule, the bigger your world and more gfx elements you place in it, the more memory your computer will consume. Once you have created your world (& captured some items to it), you can view it via a camera. In short, when you wish to render the section of the world the player can see, you'd position the camera, then by using the CameraGrabWorld command, you'd grab this part of the world to the scene buffer. Once the elements in view have been grabbed to the camera scene buffer, their ready for drawing just like your sprites or any other graphical elements. Sliding Collision & Ray Intersection Using Worlds Worlds actually have two purposes, the first is they allow the programmer to lay out a graphical elements (the game level) that are larger than the screen. These worlds can then be managed easily by PB internally, so the programmer can just draw them at will. The second purpose is for collision testing. Which is one of the most powerful features of PlayBasic When building a world for collision proposes, we're only concerned with defining the areas where the player/characters are not allowed to move through. This is done by drawing the outlines of the shapes/structures in our world that we need to be hard. These outlines are constructed with lines. These lines will normally create a enclosed regions. So each region will represent an area in the world where the player will not be able to move into/through. When creating your collision outlines, it's important to understand that these hard boundary lines are only single sided to the collision engine. So you have to connect them so their hard side is facing the correct way. So you can think of a collision world, much like being traced outline that sits over of the real worlds visible graphic elements. This collision world is invisible to the user, since it's never drawn. It's only purpose is for calculating collisions/intersections. Sliding Collision For Sprites: To make programmers lives easier, sliding collision has been integrated into the Sprite System. Once you've created your collision world, then you need to set your sprites to use this world for their sliding collision (SpriteCollisionWorld), then set the appropriate collision mode (sliding) and collision radius for the sprite . Once these are set, each time you change the sprites position using the MoveSprite command, it will automatically slide of any boundary lines it might run into within the world. You can detect if the sprite hits the world by using the GetSpriteWorldImpact, and you can detect what it hit using the GetSpriteImpactObject Sliding Collision is based upon the assumption the player/characters starts off in a 'safe' position and are then slide/rebounded off hard surfaces within the world when they move, keeping the player/characters in safe positions. If however the characters are positioned behind the hard surfaces then there's no way to detecting this. So they will appear to move through apparently solid section of worlds. Ray Intersection: Another useful feature is projecting ray off into the world and being able to check what the ray impacts, using RayIntersectWorld. This is useful in all sorts of situations. but there's a couple of uses that come readily to mind, which are pre-calculating bullets impacts within the world and allowing characters to stand on the world environment.. Often when programmers write code to control bullets in their games, they check each bullet for collisions against the environment and other sprites each time it moves. This can be quite a mouthful for the game if there's a lot of bullets or sprites to process. So a clever optimization is to pre-calculate the bullets path. Now assuming the bullets travel in a straight line. What you do is when the bullet is launched. You cast a long ray off into the distance. If this ray hits something. We now know the when bullet impact the environment (the world). From this we can calculate the distance the bullet can freely move before it's impacts the world. If we take this apporach we no longer have to check this bullet against the environment each update. Just the alien character sprites. Saving our game some work Another use will be for making characters stand upon world surfaces. The simplest way to achieve this, would be to cast a ray down from where the player sprites is standing. Where this ray impacts, is the nearest/highest ground point bellow the player. So to make the character on this surface you would position this sprite at the position of the ray impact, minus the characters height. So it will appear to walk on the ground. Regardless of what it actually is. Make sure you check the example/demos folders for more world examples. Mini Tutorial: This example first creates a world, then fills this world buffer full of static stars. During the main loop it then grabs a camera full of this world data and places it into the scenebuffer for drawing. Next it calls the camera to render it. This allows us to mix data from different worlds, through different cameras, and maintain the scenes depth.
|
| Related Info: | CameraGrabWorld | CameraGrabWorldAt | CreateCamera | DeleteWorld | GetFreeWorld | GetWorldStatus | NewWorld | PartitionWorld | RayIntersectWorld : |
|
|
|||||||||||||||||||||||||||||||||||||||
|
(c) Copyright 2002 - 2024 - Kevin Picone - PlayBASIC.com |