quick one
Blitz3D Forums/Blitz3D Beginners Area/quick one
| ||
| how do you remove an object from the game as if you were to pick up a key and the object is a door . is there a way to remove it and save memory the right way thank. i appreciate all the help i bin getting. |
| ||
| http://www.blitzbasic.com/b3ddocs/command.php?name=Delete&ref=2d_cat |
| ||
| im still lost i can really use some help on this . |
| ||
| if you have the object referenced in a type, as H&K mentioned you can remove the type you can remove loaded models with freeentity() you can remove loaded textures with freetexture() and so on.. |
| ||
| that help a bit but i still have trouble understanding type's |
| ||
| Types are intimidating, but once you understand them, they're very useful. Imagine this: You have a level in your game which will have 5000 copies of the same enemy, each getting a little harder as you progress through the level. How on earth are you going to have the time to type up variables, ai, ect., for each one of those 5000 enemies? Even just creating the enemies becomes a huge pain.
enemy1 = LoadAnimMesh("enemy.b3d")
enemy2 = CopyMesh(enemy1)
enemy3 = CopyMesh(enemy1)
enemy4 = CopyMesh(enemy1)
;..........
enemy5000 = CopyMesh(enemy1)
The above is ugly, tedious, hard to understand, and rather useless. Even if you created a For...Next loop for creating all of those enemies, what would you do next when you wanted to update all of them? Would you have to create 5000 different variables, one for each enemy, just to tell Blitz how much life they had? This is where the beauty of Types comes into play. Think of a Type list as a way to handle a group of things which are similar. To change the above example using a Type list, this is what some code could look like (All of this is pseudo, keep in mind. There would need to be a lot more to make a fully functional program):
Type enemy ;Make a new Type, and call the type "enemy"
Field entity ;We know that all enemies will have an entity attached
Field lifeleft ;We know that all enemies will have a life left value
Field damage# ;We know that all enemies will have an amount of damage they can inflict
Field startx# ;We know that all enemies have to have a starting X location
Field starty# ;We know that all enemies have to have a starting Y location
Field startz# ;We know that all enemies have to have a starting Z location
Field StateOfBeing$ ;We know that all enemies will behave differently based on what is happening in the game.
Field IsDead ;We know that all enemies are either alive or dead.
;Make any fields you want here, all related to the group of enemies
End Type ;That's all we need to know about the enemies Type
Global masterenemy = LoadAnimMesh("enemy.b3d") ;Load a mesh to use as a copy mesh
Global e.enemy ;This is for IDEal highlighting but is not required
Local enemycount ;Again, for IDEal highlighting but not required
For enemycount = 1 To 5000 ;MAKE 5000 ENEMIES!
e.enemy = New enemy ;Make a new enemy type here
e\entity = CopyMesh(masterenemy) ;Give the new enemy form
e\lifeleft = 100 + enemycount ;The new enemy's life will increase if he is further down the list
e\damage# = 1 + (enemycount/100) ;The new enemy's damage rate will also increase further down the list
e\startx# = Rnd(-100.0,100.0) ;Randomly pick a starting X location
e\starty# = 10 ;Typically, the starting Y location should be the same
e\startz# = Rnd(-1.0,1.0) + enemycount ;With mild variation, the enemies will continue to move further back into the screen
e\StateOfBeing$ = "Idle" ;To start with, the new enemies will all be idle
e\IsDead = 0 ;And, they're all alive.
PositionEntity e\entity,e\startx#,e\starty#,e\startz# ;Go ahead and postion the new enemy where it should go.
Next
Already, I've set up a system to effectively create 5000 unique enemies which all have their own values tied into them. So, what if you want to change their behavior based on gameplay?
For e.enemy = Each enemy ;For every enemy we've already created
If EntityDistance(e\entity,OurHero) < 50 ;If the specific enemy is close to the player
e\StateOfBeing$ = "Attack" ;Then they should attack the player
EndIf
If EntityDistance(e\entity,OurHero) >= 50 ;But if they're far from the player
e\StateOfBeing$ = "Idle" ;They should wait until he gets close again
EndIf
Next
;In here, just write a function which makes each enemy do different actions based on what e\StateOfBeing$ is equal to.
Now, when you kill an enemy, you want it to disappear. This is directly related to your original question, so pay attention:
For e.enemy = Each enemy ;For every single enemy we've created
If e\IsDead = 1 ;If they died
;Animate the entity do die here, if you wish. Check when that's finished
FreeEntity e\entity ;IMPORTANT, otherwise your enemy will freeze but still exist
Delete e ;This removes that specific enemy from the Enemy Type list
EndIf
Next
Now, imagine that the player grabs a mystical Juju bush, which enables him to instantly engulf all of the enemies in flames and kill them all instantly. To delete every enemy from the Enemy Type list, do this: For e.enemy = Each enemy ;For every enemy that we've created (and that still exist) FreeEntity e\entity ;Delete the body from memory Delete e ;get rid of the place holder in the type list Next And now they're all gone. This is a very basic overview of types, but the possibilities go very far. Consider Types an easy way to manage large groups of similar things, called Objects, with as little code and work as possible. |
| ||
| Rob's post is great - far better than the docs tutorial, which is confusing - but it is quite heavily focused on lists. Each type in B3D has an accompanying list, which is very useful, but not an inherent property of types and objects, just a Blitz3D extra feature. However, a type is also not a confusing thing at all, if you take the word literally. It's just that - a type, an arrangement, of data. Just as there are two ways presented by Blitz to store numbers (whole numbers, or integers; and fractional numbers, or floating point) and one way to store text (strings), type definitions give you a way to store any kind of data. For example, if you needed to store a point in 3D space, you could use three floating point variables, or you could even put them in a small array, but why make things more difficult by messing around and removing yourself from the logic of the problem? Instead, you can simply declare one variable that hold a Point, define functions that accept and return Points, and thus operate on a much simpler level. But because points aren't a fundamental data type of the language (ignore the 3D engine for the sake of my bad example), you have to add it. That's what the type declaration does; it creates a new structure for data that can then be manipulated at the same level as any other structures for data, and be read in the ways that you determine. Obviously you're limited to describing things at the bottom level in terms of the base three data types (you need to be able to break up a Point into some combination of ints, floats, and strings: in this case, it's obviously three floats); but you can also abstract things further when you need more complex arrangements. Say you then wanted to play with 3D directions (two points connected by a line in space?). All of the maths for working with Points has already been defined in the previous step, and instead of messing about with groups of six floats, you can just compose two Points as the fields of a new type, Direction, and define Direction operations in terms of Point operations, thus building on your existing abstractions and creating a much simpler framework than if you'd had to redo all the maths. As a general rule, you should define a type to handle every distinct form of data in your program. This will keep your program structure clean and simple (many Blitzers either don't use custom types, or only use one or two for very "special" things like "player" or "enemy". This is wrong; you should use them basically as much as you can, to break up the complex structure into simpler things. It's not uncommon for big projects to have dozens or hundreds; in more type-oriented languages, thousands!). Because each defined type has its own tag to attach to variables, they also have another, related, use. Not only do they provide structure to your data, but they also constrain it, give it a name, and keep it reined in to the paths you define for it. This is called "strong typing"; there's no way for some chunk of data to accidentally be misinterpreted as a list of prices when actually it was a table of speeds, for instance, if each use of the data is strongly represented by a dedicated data type. This helps you keep a track on the flow of data in your program, as well as just its shape, and makes sure than nothing ends up accidentally being somewhere it shouldn't. (However, most people don't bother defining strong types for single numbers or words, for the sake of efficiency - there does come a point where it stops being worth it!) There is one limitation, which you need to remember, which is that unlike the "core three" data types, instances of your own designed types must be created and destroyed manually (ints, floats and strings just "are", whereas a variable of your own types actually "points" to the object it references). This should come naturally quite quickly, as it's exactly the same as how you would use an image or entity (it also means, as with images and entities, that more than one variable can reference the same object - or that if you're not careful, an object could become "lost" and not be referenced at all. But the global lists mentioned by Rob give you an escape hatch here, so don't be afraid to play around, as you can always get an object back if you really need to). The best way to learn this? Try setting some up. Think about how you might use custom types to define a compound value such as the aforementioned Point. What operations can you now define much more easily on said Point? How can you use it? How can you compose your Point with other things to create more complex structures? Once you start thinking in terms of structures, using types to describe them will make your program much simpler and cleaner. Last edited 2011 |
| ||
| Using a type to store a 3D point in space....Simple, brilliant, and not something I've ever thought of before....I really need to find me a programming class sometime. |
| ||
| thank yo so much for the help i was gone for a few days i seen this code and im working on it right now hopefully i get it to work right. thank you so much again . ( back to the grind) |
   |