Some tips about Blitz3D
Blitz3D Forums/Blitz3D Tutorials/Some tips about Blitz3D
| ||
| Feel free to add to these. Just feel like some folks are getting caught up on a couple of points. Never store entity handles using a floating point variable. Always use Integers :o)
entity# = LoadMesh("car.b3d")
Will cause entity doesn't exist errors on some/many computers, as floating point numbers aren't accurate enough to hold large numbers.When placing entity in Blitz3d, make sure you hide them or position them first then give them a collisions type. Trying to move entities after you given them a collision type, might cause them to get stuck (collide) with scenary, or other meshes. Hiding an entity disables collisions with it, thus enabling you to position it without getting "stuck" If you are going to use functions in your code, make sure you make the variables that you will be using in your main code, GLOBAL. If not, you could lose the information they hold when visiting a function. If you compile your code or save it, and realise you've overwritten something important, Blitz will create 2 backup files, from the past two saves. So, just open them with blitz to get the last two source code saves. If i think of anymore, i'll add them. Feel free to contribute :o) |
| ||
It is always worth checking the result of any load (LoadImage(), LoadMesh() etc) command. Do it like this:alienimagename$ = "myImage.bmp" alien = LoadImage(alienimagename$) If alien = 0 then RuntimeError "Couldn't load image: "+alienimagenameIt will help you in the long run and will make users less annoyed. :) |
| ||
| use a global type to hold all global variables so you won't get caught with silly typo errors especially when your code grows huge eg Type GlobalType field Fps field MaxFps field etc etc end type instead of Global Fps , MaxFps if you do mistype a GlobalType value blitz will let you know. Declare all arrays before the first include right at the start of your program is wise too!! |
| ||
| Dont ever scale meshes in blitz, it messes up linepicks and animation. |
| ||
| Nothing wrong with scaling meshes if they are not animated, quite a useful feature at times. Some tips I find useful for slower PCs: - Try and use linepicks/entitypicks/camerapicks as little as possible for performance reasons. - Nested for loops are sometimes needed but try and avoid this if the number of iterations in each for loop is quite high. For example: An army of 1000 'units' is trying to find targets in the opposing army of 1000 'units' - the simple method is: for each unit in army 1 for each unit in army 2 ..code for deciding if to target this unit goes here .. next next a slightly better approach is: for each unit in army 1 for a few units in army 2 this frame (then a few more in the next frame etc) ..code for deciding whether to target this unit goes here next next and a better method again (some of the time) is to divide up your playfield into sections and only loop through those enemy units within a section visible and in range of the target. Another blitz3d tip for low end systems: If you have a lot of 3d animated entities moving around a 3d interior environment but not all of those 3d animated entities are always visible to the player then I often use this kind of logic: Use a pivot for each 3d character model with a collision type as appropriate (ellipsoid to polygon). If a 3d animated entity has been 'not seen' for more than a few seconds then rather than hide it (which blitz does automatically when not in camera view), free it (ie freeentity) but keep the pivot. Then when the entity comes into view again copyentity the character model from a 'master' mesh that is simply used as a reference to copy entities from. I have found that while Blitz culls entities not in view they still have a decent performance hit on older PCs even when hidden, particularly if animated and so it is better to just remove the entity entirely and keep a pivot behind to 'act' while the entity is not in view. Collisions with levels: Make a detailed level model as normal and split it up into sections. Don't give this mesh a collision type but rather create a mesh that has basically the same layout with as few polygons as possible, with as little detail as required, set its alpha to zero and use it for detecting collisions between characters and the level. TFormVector, TFormNormal and TFormPoint are your friends - they can be used in many situations and are simply mathematical transforms which incur no real performance hit. I often use them rather than line picks when detecting if bullets have hit a target, for example: Slow method of detecting if bullet has hit a target: Linepick between old bullet position and new bullet position each frame and determining if it hit an enemy. Faster method: Use TFormvector/Tformpoint and entitydistance to determine if the bullet has hit a target. |
| ||
| ScaleMesh should be ok, but Scaleentity could admitady cause problem. |
| ||
| oh yeah thats what I meant - SOZ! |
| ||
| More Blitz Supertips |
| ||
| Here's one more, happens oftenly to me :) Image cannot be found, although it's there... I used the image handle for X and X for the image handle: DrawImage x,y,img instead of DrawImage img,x,y (must be a relict of my GFA times) An other thing that used to freeze my machine several times: Using a parent handle as the number of facettes with CreateSphere... sp=createsphere(parent_pivot); now that's a big lot of Tris instead of sp=createsphere(12,parent_pivot) |
| ||
| 1 Blitz unit is deemed to be equivalant to 1 metre: http://blitzbasic.com/Community/posts.php?topic=31118 and this thread shows that this is also relevent with Milkshape: http://64.233.183.104/search?q=cache:-Aby1KlEEtgJ:www.blitzbasic.com/archive/posts.php%3Ftopic%3D15919+blitz+unit+blitzbasic+metre&hl=en So, it is also considered that 1 MilkShape unit = 1 Blitz Unit = 1 metre EDIT: When you create a cube in Blitz3D - the cube is actually 2 metres high: http://www.blitzbasic.com/Community/posts.php?topic=55797 |
| ||
| Assign constants to values that you know will not change in your game (screen width/ height - scoring values - etc). Doing so reduces the load of the 'variable memory', since Blitz knows they will never change size unlike other variables which can grow and shrink in size based on what value they hold. |
| ||
| for really Big Strings its better to work with a File as with the Memory. |
| ||
| About time this thread had an update. Bones are inside meshes. So, if you make a boned mesh an obscurer then you may not be able to 'visually' detect its bones. You can be led into trying to resolve this by creating additional pivots and markers etc for bones when, in fact, you just need to unobscure the bones. Rember that a bone is a Child of a mesh, so to track the bone's position, make sure you use the 'Global' flag. Bone_Xpos=EntityX(bone_name,True) instead of Bone_Xpos=EntityX(bone_name) |
| ||
| Continuing from that, boned animated meshes can only be collided with, in their default first pose/frame. Blitz cannot give you the location of any of the vertices of the mesh whilst it's animating. It will always return the default vertex locations. Object and Handle are the two most useful commands in blitz. Type weapon Field name$ End Type w.weapon = New weapon w\name$ = "1st weapon - gun" w.weapon = New weapon w\name$ = "2nd weapon - gun" w.weapon = New weapon w\name$ = "3rd weapon - gun" w.weapon = New weapon w\name$ = "4th weapon - gun" w_handle = Handle w.weapon w.weapon = New weapon w\name$ = "5th weapon - gun" w.weapon = New weapon w\name$ = "6th weapon - gun" w.weapon = Object weapon(w_handle) Print w\name$ This code creates 6 weapon objects in a type collection. It saves the handle to the 4th type object. Then at the end, jumps back to the 4th object by setting w.weapon to the w_handle (handle of the 4th weapon) What this means is you can store these in an array. For instance, store all the handles to your weapons. When you want a particular weapon, 5 for instance, get the 5th handle in the array and plug it into w.weapon = Object weapon(handle_array(5)) weapon - being the type collection Object - being the Blitz command for this process handle_array(5) - being the 5th handle in the array you created. Other uses of this are, storing the handle inside the EntityName() of an entity.
e.entity = new entity
e\mesh = loadmesh("mymesh.b3d")
NameEntity e\mesh, Handle e.entity
This way, when ever say you shoot an entity, and you use linepick, for example. You get the picked entity, the one you just shot. You grab that entities EntityName(). This contains the handle to the type object it's stored in. You can now modify that enemies health and such. e.entity = Object entity(EntityName(PickedEntity)) |
| ||
| Never use B3D sprites in your project, the sprites are TOO SLOW. Look in the "Code Archive" if you need a particle system. |
| ||
| nah, use sprites wisely!!! with single surface particle systems you'll get nasty z-order problems. you have to decide... |
| ||
| And sprites have other uses other than particles. |
| ||
| yupp. |
| ||
| be sure to set the sprite view mode to what you want it to be... The computer doesn't know what you are thinking. :) also use rotatesprite not turnentity. It saves me some trouble. |
| ||
| I found some of these tips really usefull. End is a usefull tool to debug your code. when something isn't working the way it should just keep cutting and pasting it into diffrent sections of your code(for next, if end if, gosub, function) so you know where your code is getting to(or not getting to) |
| ||
| As I have learned from others meshes have a vertex limit with Blitz3d. So if you have something really complex or a large level you will need to break it up into smaller sections. Blitz3d has no built in culling but you can make one yourself. Always check your models for duplicate faces or extra geometry that is unneeded. If you have problems with your game stuttering it is possibly your computer bottle necking and not blitz3d itself. Every game should make use of render tweening or in other words separate the logic from the video cards frame rate. Some may argue this is not necessary if you have fast hardware but this will help your game scale better across a wide variety of machines. Micro stutter is the most annoying thing a gamer can experience and not every developer looks to solve this issue. As mentioned above you really need to write some code to check your game assets are valid. This is best done before the main game is launched. It will make identifying MAV errors so much easier. Use IDEAL instead of the built in IDE. I wouldn't try coding anything Blitz without it. |
| ||
| +1 vote for Ideal, the workspace (iws) files are a great help. |
| ||
| Sorry to resurrect an old post, but Sprites cause major issues with modern Video Cards and Operating systems. It would be better to code a single plane(2 triangle mesh) than use the built in sprite functions of Blitz3d. |
   |