I flatout don't understand types

Blitz3D Forums/Blitz3D Beginners Area/I flatout don't understand types

Cubed Inc.

(Posted 2010) [#1]

For as long as I have been working with blitz3d, I have never been able to grasp the concept of types.

For about 4 months, I have been trying to add jumping into my 3d game, and I have yet to succeed.

I then decided to go with the concept of jumping that was in the castle example that came with blitz3d.
It seems that the jumping is created using types.
The problem is that I just absolutley don't understand types.

Can someone please explain how to use types correctly to my advantage?

I desprately need to add jumping in my game, and I'm running out of attempts on how to do it.

I really don't want to abandon my game becuase of this situation, becuase I believe that my game has potential.

So can someone please...please explain this and help me out please.
Thanks for your patience.

please reply.

Yasha

(Posted 2010) [#2]

A type is a way of interpreting data, giving it structure so you know what to do with it. Blitz3D has three built-in types: integers, single-precision floating-point numbers, and dynamic strings. The type command lets you define new kinds of structured, type-checked data, for use in other situations.

For example, if you were writing a program that needed to manipulate simple vector images, an important concept is the 2D point - the X and Y values that define a location on the plane. One way to handle this is to simply pass the two pieces of data around next to each other, which would work - but you'd need to do a lot of rewriting if you ever decided to give the program a third dimension.

Since you're thinking about "points" as a single concept, we should pass them around as a single piece of data. So we can define a point as a complex type, in terms of more basic types that represent its components:

Type Point
    Field x#
    Field y#
End Type

You can now use the Point as a single concept when writing code:

Function SetSomethingsPosition(p.Point)
    Local somevar# = p\x        ;This is how you get at a component value
    ...
End Function

The fields of a type act like variables anywhere else: they can be int/float/string, references to other custom type objects, and even arrays (the square-bracket kind, not the Dim kind). You manipulate a field using the backslash, as shown above; and if the field is further subdivided (an array, or a reference to another object) you can use the array element access syntax, or more backslashes, until you reach the subfield or element you need. e.g. car/door/doorHandle/bolt[23]/head

Conceptually, it's that simple. The real opportunity for confusion comes next: all user-defined types like this are reference types, whereas all three built-in primitives are value types. When you pass around an int/float/string, the value is copied from one variable into another, and modifying the second one does nothing to the original; but reference types are like entities or images: they need to be manually created (in the case of type objects, with New), and if you simply copy the variable to another variable, you have two names that point to the same object - the object being somewhere else in conceptual space.

Similarly, like entities and images, custom type objects need to be manually freed after use, otherwise you waste memory. Instead of FreeEntity and FreeImage, you need to use Delete when you're done.

Custom types do have several advantages over unstructured data in banks (which, from a logical point of view, is the same sort of thing: the variable "points" to an object created "somewhere else" in the computer's memory), or entities, images and other Blitz objects, because they're type-checked, and the variable is automatically set to Null when the object is deleted (so you can't assign it to a variable intended for another kind of object, as you can with entities and images that are stored in integers, and you can quickly and safely test whether it still exists by checking against Null).

I found the documentation on this topic to be quite confusing too when I first looked at it. One problem is terminology: a lot of people say "type" and mean a specific instance or object, instead of the structure of the object. There's also the entirely separate issue of For/Each, Before/After, First/Last - you don't need to know anything about these to understand types and they don't have much to do with the subject in a theoretical way (when objects are created, they're added to a global list of all objects of that type - you don't need to make use of this though and it's best to leave it until you understand the basics).

Rob the Great

(Posted 2010) [#3]

Types had me confused for the longest time. I couldn't figure out how they worked. After playing around with the examples for a long time, I've finally gotten the concept of types figured out. Now, I tend to over-abuse the type system in order to simplify the programming process.

Here's a hypothetical situation:

I'm the senior programmer for a game in development, and I have asked you to write me some code for a monster in this game. I have told you that the monster will be sort of a "template" for other monsters of the same family, and therefore I will need you to write me some code that will allow me to define where the monster starts in the level, how aggressive that monster is, how the monster will react under certain circumstances, how much life the monster has left, and how much damage the monster can inflict on our hero, all quickly and easily. And most importantly, I want to be able to store ALL of these values so that I can read them back later.

Without the custom types system, this can be a very tedious process. You would have to define a separate variable for EACH monster, and if there were thousands of these monsters wondering throughout your game world, you could very easily have to type out thousands upon thousands of individual variables for your program. Sounds like a headache, right?

This is where the beauty of types comes into play. Take a look at this code:

Type monster
   Field entity  ;Use this to hold a name for our monster
   Field startx  ;The Starting 'X' Position for that monster
   Field starty  ;The Starting 'Y' Position for that monster
   Field startz  ;The Starting 'Z' Position for that monster
   Field aggression  ;The Aggressiveness for that monster
   Field stateofbeing  ;The State of Being for that monster
   Field lifeleft  ;The amount of Life Left for that monster
   Field damage  ;The amount of damage that monster can inflict
End Type

You have just told Blitz that you're going to make a special "group" called the "monster" group. Every "monster" in this group is going to have it's own variable, stated by the "Field" command. Now, whenever you create a new monster (I will show you how below), they will each have their own data sets of "startx", "starty", "startz"...

Now, let's create some monsters for our game:

For number = 1 to 100  ;Do this part 100 times and then move on
   m.monster = New monster  ;Create a new 'monster' and call it 'm'
   m\entity = CreateSphere()  ;Create a ball to 'entity' to represent our monster
   m\startx = 5  ;The variable 'startx' for the new monster is now '5'
   m\starty = 0  ;The variable 'starty' for the new monster is now '0'
   m\startz = 10  ;The variable 'startz' for the new monster is now '10'
   m\aggresion = Rand(1,10)  ;The variable 'aggresion' is now randomly 1-10
   m\stateofbeing = idle  ;The variable 'stateofbeing' is now set to 'idle'
   m\lifeleft = 10  ;The variable 'lifeleft' is now set 10
   m\damage = m\aggresion  ;The variable 'damage' is now whatever 'aggresion' was
Next

The code above would make 100 monster spheres, and give them each their own unique name, starting point, aggressiveness, state of being, life, and damage they can inflict. You can define the variables yourself, or you can have Blitz randomly select them for you.

This is a great start, but now I, the senior programmer, have asked you to make a way in which I can cycle through hundreds, maybe even thousands, of monsters at one time and see how they will respond.

Here's how you could do this:

While Not KeyDown(1)  ;The Main Loop

   For m.monster = Each monster  ;For every single monster we've created
     If m\aggression > 5  ;If they're aggressive
         If EntityDistance(m\entity,ourhero) < 20  ;And if they're within 20 units of our hero
            m\stateofbeing = attack  ;Attack the hero!
         Endif
         If EntityDistance(m\entity,ourhero) >= 20  ;But if they're not close to our hero
            m\stateofbeing = idle  ;relax and drink some coffee for a while...
         EndIf
      EndIf
      If m\aggression <= 4  ;If the monster is 'calmer'
         If EntityDistance(m\entity,ourhero) < 10  ;And if they get really close to our hero
            m\stateofbeing = attack  ;Attack the hero!
         EndIf
         If EntityDistance(m\entity,ourhero) >= 10  ;But if they're not close to our hero
            m\stateofbeing = idle  ;relax and drink some coffee for a while...
         EndIf
      EndIf
      If WeHitTheMonster = True  ;If we hit the monster with our fist
         m\lifeleft = m\lifeleft - 1  ;Take some of the monster's life away
      EndIf
      If TheMonsterHitOurHero = True  ;If the monster hits our hero
         HerosLifeLeft = HerosLifeLeft - m\damage  ;take some of the hero's life away
      EndIf
      If m\lifeleft <=0  ;If the monster has no life left
         m\stateofbeing = die  ;It will die
      Endif
      If m\stateofbeing = die  ;If the monster has 'died'
         RespawnMonster(m\startx,m\starty,m\startx)  ;It's resurrected at the starting point
      Endif
   Next

Wend  ;End the main loop

This is a pretty specific example, but the above code would cycle through each monster created and perform actions based on the condition of each monster. You can see how this is much more efficient than checking each one individually, even with the help of functions.

Now, me being the jackass senior programmer that I am, I now approach you and demand that we be able to delete the monsters not needed anymore, to help save space for the rest of the game.

Here we go:

For m.monster = Each monster
   If m\stateofbeing = disappear
      FreeEntity m\entity  ;Don't forget this, otherwise the mesh will still exist!
      Delete m
   Endif
Next

Now that particular monster is gone forever.

Look out! Here comes the senior programmer who you secretly despise but have to suck up to in order to keep your job. He claims that the code you've provided takes too long to delete ALL of the monsters, and he wants you to write some code to do it all in one swipe.

This will do exactly that process:

For m.monster = Each monster
   FreeEntity m\entity
   Delete m
Next

And there you have it. Keep in mind that I threw this together very quickly, and it's very possible I made some mistakes along the way. This was designed for example purposes only, and the Blitz documentation covers more commands that I'm not so familiar with (e.g. "Before", "After", ect.).

In short, think of custom types as a giant container for a group of similar items. Types make it easy to handle many, many, many things at once without the added code. Typical items used in types could be bullets for a gun, arrows for a bow, enemy groups, special effects (fires, particles), basically anything which has a tendency to repeat itself, or anything that is part of a group or a family.

Charrua

(Posted 2010) [#4]

hi

types are great stuff but i think that you don't need they for the jumping part of a game. I think you are confused somewhere. Following is a code without types for jumping. The key is y_vel variable that controls the y velocity of the player.

btw the EntityType command nothing has to do with types, it is related with the blitz collision system, but if you know that, please do as if i never write this line!

Graphics3D 800,600,0,2

SetBuffer BackBuffer()

Global Player, Player_y#, y_vel#, z_vel#


Light = CreateLight()
Camera = CreateCamera()
PositionEntity Camera,0,4,-10

plane = CreatePlane()
EntityColor plane,255,255,255
EntityAlpha plane,0.7
Mirror = CreateMirror()

Player = CreatePlayer()
player_y = EntityY(player)

EntityType Player,1
EntityType Plane,2
Collisions 1,2,2,2

While Not KeyHit(1)
	UpdatePlayer
	UpdateWorld
	RenderWorld
	Flip True
Wend
End


Function UpdatePlayer()

 	;left/right turn
	If KeyDown(203) Then
		TurnEntity player,0,2,0
	End If
	
	If KeyDown(205) Then
		TurnEntity player,0,-2,0
	EndIf
	
	; z_vel controls the forward velocity
	;if you press up arrow then the player has a z_velocity of 0.1 and while that key is down
	;the player moves forward .1 blitz units in each game loop
	;if you release that key, then the forward velocity is decreased by .001 in each loop so the player
	;will not stop abruptly, say: .1 / .001 = 100 game loops at 60 fps, it will continue to move for more than one second...
	If KeyDown(200) Then
		z_vel=.1
	Else
		If z_vel>= 0.001 Then z_vel = z_vel-.001
	End If
	MoveEntity player,0,0,z_vel


	;that's the JUMPING part
	;as with forward velocity, the player can have a Z velocity
	;if you press SPACE then an Y velocity is initialized
	;and aplied to the player by TranslateEntity, from now on, the z_vel is decreased by some ammount
	;so for some loops the player has a positive z_velocity ( 0.3, then 0.29, then 0.28 and so)
	;but in the near future the player will has a z_velocity with a negative value and finish going up and start to fall
	;
	;when it collides the plane, then blitz collisions stop the player's fall
	;
	ty# = EntityY(player)
	y_vel# = ty - player_y
	player_y = ty
	
	If KeyHit(57)	;jump?
		y_vel=.3
	Else
		y_vel=y_vel-.01
	EndIf
	
	TranslateEntity player, 0, y_vel, 0

End Function

Function CreatePlayer()

	p = CreateSphere()
	EntityColor p,255,0,0
	temp=CreateCube(p)
	ScaleEntity temp,.1,.2,.5
	EntityColor temp,0,255,0
	PositionEntity temp,0,0.8,-.4,True
	PositionEntity p,0,5,0
	Return p

End Function

hope that help

Juan

Cubed Inc.

(Posted 2010) [#5]

Rob The Great and Charrua

Thanks for the explaination on types and how to use them.

I understand them better now.

Thanks:)

Ross C

(Posted 2010) [#6]

The problem i had with types at first, was the fact you couldn't instantly access a type object. Coming from using only arrays, it was a bit of an adjustment. Took me a good couple of months too. Stick with, do very basic examples and it'll come :)

Rob the Great

(Posted 2010) [#7]

Couldn't instantly access a type object...I'm not quite sure what that means. Are you referring to always having to use a For...Next loop with types, and arrays don't require that?

Ironically, I've never learned about array process. I kinda-sorta understand what they are, but I've never found use for them in my games. It's probably not good programming practice to never use an array.

Who was John Galt?

(Posted 2010) [#8]

Couldn't instantly access a type object...I'm not quite sure what that means.

I think he means that as opposed to a simple variable where declaring it creates a variable, with types you declare a 'template' and then separately instance it.

Arrays are good for storing tile maps, among other things.

Adam Novagen

(Posted 2010) [#9]

The problem i had with types at first, was the fact you couldn't instantly access a type object. Coming from using only arrays, it was a bit of an adjustment. Took me a good couple of months too.

Same here. I finally cracked it when I had the idea to include an "ID" field in the Type. Now I can find any specific one like this:

Function FindType(TypeID)


For MyType.MyType = Each MyType
    If MyType\ID = TypeID
        
        ;Do stuff :D
        
        Return ;Type's been found, show's over.
    EndIf
Next


End Function

_PJ_	(Posted 2010) [#10]

I was scared of Types when I first encountered Blitz, avoiding them like the plague I eventually had to take the plunge when looking through some code archive stuff that I really wanted to know how it worked. I still had to post here a few times to fully understand it (or at least, as fully as I do understand it) but eventually, it all fell into place.

Here's a small bit of code that should help showe how types work and interact with each other. I made this back when I was trying to get used to working with Tytpes myself!

; Working With Types

; Types are a means of collecting data of different variable types together within groups. The 'groups' are the "instances" of the Type, and the various data are
; the Fields. Each "instance" of a Type has its own data in each field.

; As an example, let's look at a typical scenario of a Type that comprises a group of people. We can call this Type "PEOPLE"
; Each person, then will be an "instance" of the PEOPLE Type.
; We are going to store data of each person. Their Name, age and gender.
; The advantage over using arrays is already apparewnt, since Name is a string variable, yet age will be an integer. With Types, we can store these differeing variable types.

; Firstly, then we must declare the Type:

; The Type name is "PEOPLE" (I've used upper case for this, it's not essential, but I find it helps separate Type names from variables, Handles and Fields etc.)
; Also unnecessary but good for clarity is the prefix of "P_" in the names of the Fields. This is only to remind us that these Fields belong to the "PERSON" Type.


; Note the use of the $ and % symbols at the end of the Field names. This specifies the data types we are using, for example, $ (string) for Name and % (integer) for Age.
Type PEOPLE
	Field P_Name$
	Field P_Age%
	Field P_Gender$
End Type

; Now we have the structure in place for our collection of data, it's time to add the information.
; To add information about a person, we need to tell ther compiler that we are going to be dealing with an 'instance' of the PEOPLE Type.

; Just as with other variables, 'instances' can be Local or Global, however, the Field information we enter later will be retained permanently until the 'instance' is DELETE'd.
; Don't worry too much about this now, only note that we are using Local because we are only temporarily naming an 'instance' in order to create the reference.

Local NewPerson.PEOPLE

; The name I have chosen is (unimaginatively) "NewPerson". Note the syntax of .PEOPLE at the end. This tells the compiler that NewPerson will refer to an 'instance' of the PEOPLE Type.

; So now we have a name for the 'instance', how do we populate the Fields with our data?

; Well, first we need to specify which 'instance' this name refers to. Currently, since it was declared above with Local and no '=' it contains a Null value.
; You may have noticed that of course we don't have any 'instances' yet, so we must make a New 'instance'. By assigning the name (NewPerson) to this New 'instance'
; we can finally add this NewPerson's data to the correct Fields.

NewPerson.PEOPLE = New PEOPLE

; You can see how NewPerson is now the name given to a New 'instance' of the PEOPLE Type.

; To add the data to the fields, we use NewPerson and \ to separate the 'instance' name from the Field name:

NewPerson\P_Name$ = "John"

; NewPerson\P_Name$ (technically  NewPerson.PEOPLE\P_Name$ ) can work just like any string variable. It is essential that the whole 'instance' name be used, since
; P_Name$ alone does not exist as a variable, so would be assumed to be a new Local variable P_Name$ and be null  ( "" )

;You can see this with the below command:
Print P_Name$

;And now to add the rest of the data...
;simply adopt the same method, Again, note the whole 'instance' name (NewPerson) is used:

NewPerson\P_Age%=21
NewPerson\P_Gender$="Male"

;It is actually possible to list the contents of the NewPerson 'instance' with the Str$() command, this can be seen with:

Print Str$(NewPerson.PEOPLE)

;The format for this Print output of Type 'instances' will show: 
; [ "John" , 21 , "Male" ]

;That's one person, now for the next...

NewPerson.PEOPLE = New PEOPLE

; You may be startled to see the same name being used. Don't worry, "John"'s data wont be overwritten. All we are doing, is 
; making a NEW 'instance' using the same name. Since the nam,e we used ( NewPerson) was Local and temporary, we are simply changing it from referencing the
; first PEOPLE (John) 'instance' with a New one. The information for John is stil;l retained in memory, and can be retrieved
; with the First command:

Global John.PEOPLE = First PEOPLE

;More on that later, for now, let's continue with our New PEOPLE 'instance' that is now called NewPerson.
;Again, we use the NewPerson name in conjunction with \ to identify the Fields belonging to the Type.

NewPerson\P_Name$="Sally"
NewPerson\P_Age%=20
NewPerson\P_Gender$="Female"

; Just in case, we can check the details for Sally with:

Print Str$(NewPerson.PEOPLE)
; [ "Sally" , 20 , "Female" ]

; and for completeness, and confirmation we haven't overwritten John with an impromptu, digital sex-change:
Print Str$(John.PEOPLE)

; So, iot should be easy enough now to fill in more data for more people...
; Simply assign the name NewPerson to a NEW 'instance' and add the data to the Fields...

NewPerson.PEOPLE = New PEOPLE

NewPerson\P_Name$="Peter"
NewPerson\P_Age%=25
NewPerson\P_Gender$="Male"

; We can keep doing this for as many people as we need (within reasonable consideration to memory, but that ought to be thousands of entries!)

NewPerson.PEOPLE = New PEOPLE

NewPerson\P_Name$="Jane"
NewPerson\P_Age%=22
NewPerson\P_Gender$="Female"

; . . . and so on


; Now we have a few people in our collection of PEOPLE Type, we need to know how to get to the information.
; Using Str$() is fine for retrieving the whole lot in one go, but impractical for working with individual Fields, and what about
; changing the data?

; We can access any existing Type 'instance' by assigning a name similar to how we did with NewPerson.
; However, this time, we wont need to use the New command, because we're not making New 'instances'.

; If we wanted, too, we could re-uise the NewPerson name, since that's now redundant having served its purpose as a name for when we made the 'instances'.
; Though to avoid confusion, let's make a new name.

Local EditPerson.PEOPLE

; I'm going to use EditPerson as a name now, to remind us we are going to use it to reference an 'instance' for editing.
; What to edit?
; Let's imagine Peter has had a bitrthday, so now his age (P_Age%) has risen from 25 to 26.
; However, remember that P_Age% is NOT a variable, so adding +1 to P_Age% alone would result in P_Age% = 1

;You can see this here:
P_Age%=P_Age%+1
Print Str(P_Age%)

; Maybe you are thinking we need to use EditPerson\P_Age%=26 or rather, EditPerson.PEOPLE\P_Age%=EditPerson.PEOPLE\P_Age%+1
; This still would not work. Why?
; Because the name EditPerson.PEOPLE doesn't actually point to an existing 'instance' yet. Currently EditPerson.PEOPLE will return Null.
; When trying to access the fields of Null 'instances' such as EditPerson\P_Age%, the program will crash with an "Object Does Not Exist" error.

;So how do we identify the 'instance' for Peter?

; Without using Handle and Object commands (see later) or assigning Global names to 'instances' the only way to find specific instances is to search through an imaginary list of 'instances' the computer has in memory.

; Luckily, in this particular case, we know that Peter was the 'instance' made BEFORE the LAST one (the LAST one being "Sally") So we could use:

EditPerson.PEOPLE = Last PEOPLE
EditPerson.PEOPLE = Before EditPerson.PEOPLE 

; And we can test that we have found the correct 'instance':
Print Str(EditPerson)
; [ "Peter" , 25 , "Male" ]

; Other commands such as BEFORE and LAST are: AFTER, FIRST and INSERT

; This is going to be a little faster in most cases, but unfortunately it is not always possible, especially if the required 'instance' is in the middle of a very large
; number of 'instances'.
; So, we usually iterate through with a For/Each loop.
; A For/Each loop is similar to a For/Next loop that iterates from the FIRST 'instance' of a Type until it reaches the LAST 'instance'

; Note the syntax. It is important to tell the compiler which Type is being iterated.
For EditPerson.PEOPLE = Each PEOPLE

; Each loop, the name "EditPerson" (EditPerson.PEOPLE) will reference the next 'instance' of PEOPLE in the computers memory until it has reached the LAST 'instance'.
; After this LAST 'instance', EditPerson will again return NULL.

; We want to know when EditPerson references the 'instance' for "Peter", so we add the next line:

	If (EditPerson\P_Name$="Peter") Then Exit
	
; So we stop iterating and exit the loop.

; The For/Each loop is closed with Next command
Next
		
; Now hopefully we have found the 'instance'	 for "Peter".
; And we can test that we have found the correct 'instance':
Print Str(EditPerson)
; [ "Peter" , 25 , "Male" ]

; So now to give him his birthday treat!

EditPerson\P_Age%=EditPerson\P_Age%+1

; Now Peter should be 26 years old!
; Since "EditPerson\P_Age%" as a whiole can be manipulated just as any integer variable, we can check this value with:
Print Str$(EditPerson\P_Age%)

; What if we wished to change something else?
; This is just as simple. We can shorten his name to "Pete" like so:
EditPerson\P_Name$="Pete"

; What about editing someone else?
; Again, we need to iterate through to find the right person. However, for this example, I will use the shortcut of LAST, knowing that Jane was the LAST 'instance' created!

; Since we're still editing, and we're done with Peter for the moment, we can re-use the EditPerson name.
EditPerson.PEOPLE = Last PEOPLE
; Let's correct the spelling of Jane to Jayne!
EditPerson\P_Name$="Jayne"



; So finding, accessing and manipulating the basics is relatively simple once you get the hang of it, but Types can do a LOT more too, and get very powerful.
;Before moving on to more advanced areas, let's quickly look at DELETE since it is an important aspect of working with Types.

; As the name implies, DELETE deletes an 'instance'. It completely removes all the information from the Fields for that 'instance', and the 'instance' itself is removed from the
; computer's memory list. After DELETE is used, the reference to that 'instance' will return Null and therefore, any attempt
; to access the Fields will result in an "Object Does Not Exist" error.

;As an example, let's kill poor "Sally" at the tender age of 20.

; I'mn using a new Local name (DeletePerson) for this 'instance'.
; The following iterates through the list and identifies "Sally"'s 'instance' by her name just as we did for "Peter" earlier:

Local DeletePerson.PEOPLE
For DeletePerson.PEOPLE = Each PEOPLE
	If (DeletePerson\P_Name$="Sally") Then Exit
Next
; As a test, the next line will result in a null string ( "" ), since the 'instance' "DeletePerson.PEOPLE" has now just been DELETEd and is Null.
Print Str$(DeletePerson.PEOPLE)

; A common mistake (which will cause a crash) is to DELETE  'instances' within a For/Each loop befrore all the operations concerning Fields 
; have been completed.

; However, please be aware, that DELETE does not Free up memory allocated to handles etc.
; This may be drifting a little from the topic, but it is an important note.
; If we had an Image Handle (or a Mesh, Sound, Texture, Sprite, Buffer ... any entity or handle) in a Type Field, then Delete the 'insatance',
; the handle would still exist and point to the media, only it could no longer be accessed through the Type 'instance'

; If you are using Types to track handles in this way, remember to Free the memory form the Handle Before you DELETE the instance!!!
; Example:

Type IMAGES
	Field IM_Handle%
End Type

Local NewImage.IMAGES = New IMAGES
NewImage\IM_Handle%=CreateImage(128,128)

Print "Image Handle Memory Address: "+Str(NewImage\IM_Handle%)
Local remember%=NewImage.IMAGES\IM_Handle%

Delete NewImage.IMAGES

; Now we can no longer retrieve the value of "NewImage.IMAGES\IM_Handle%" since the 'instance' has been DELETEd
; Fortunately, the value was kept in " remember% " but otherwise, "NewImage.IMAGES\IM_Handle%" would need to be Free'd proir to DELETE
DrawImage remember%,0,0	; The image wont show because it's blank, but the DrawImage command doesn't fail proving the Image still exists.
FreeImage remember%
remember%=0
















; More advanced areas of Types: Linked Lists, Handle() and Object()

; Much of the potential of Types is achieved through the use of Linked Lists, and the commands Handle() and Object()
; The documentation for these commands is not cvery clear (at least, it didn't seem so to me initially), so to introduce these in a hopefully more accessible fashion,
; I will continue wwith the PEOPLE Type from above.

; You may recall that I had already set the name John.PEOPLE as a Global reference to the 'instance' for "John"'s data. The FIRST 'instancve' in the list.
; so we don't need to iterate or reassign any names to use John.PEOPLE provided, (for now at least) that we wish to access John's data.

;A quick check to make sure:
Print John\P_Name$

; As it's a Global reference, and that more importantly, we haven't reassigned the name John.PEOPLE to a different 'instance', or DELETEd the 'instance'
; We can refer to John's data anytime by using John.PEOPLE
; This quick reference idea is handy, but often, Global variables may not be efficient for this purpose.
; That's where Handle() and Object() come in.

; Instead of using John.PEOPLE to identify the instance, we could use a single Handle (just like a handle for images or meshes etc.) 

Local InstanceHandle%=Handle(John.PEOPLE)
Print Str$(InstanceHandle%)
Print Hex$(InstanceHandle%)

; The advantage of this is, that as an integer Handle, InstanceHandle% can now be used to populate arrays, other variables or used in function calls without
; issue. Also, in the case of Null 'instances', we can avoid crashes as Handle(Null) will return 0 rather than throw an error.

Local TestHandle%=Handle(Null)
Print TestHandle%

; When we wish to work with the Fields of the 'instance' again, InstanceHandle% can be converted back to the familiar format of Type objects ('instancves') with the Object() command
; It is essential that the Type name is specified note the syntax of Object.PEOPLE()

John.PEOPLE=Object.PEOPLE(InstanceHandle%)

; To verify John.PEOPLE is pointing again to the correct 'instance' :
Print John\P_Name$

; There arte advantages and disadvantages to either method, so it's likely a program will use interchangeable means to identify 'instances':
; Compare these functions one accepts the typical Type object format, the other accepting the Handle%

Function GetPersonsAgeByInstance%(ObjectPerson.PEOPLE)
	Local ReturnAge%=ObjectPerson\P_Age%
	Return RetuirnAge%
End Function

Function GetPersonsAgeByHandle%(TypeInstanceHandle%)
	Local ReturnPerson.PEOPLE=Object.PEOPLE(TypeInstanceHandle%)
	Local ReturnAge%=ReturnPerson\P_Age%
	Return ReturnAge%
End Function

; Now these functions which return different formats:

Function GetInstanceByName.PEOPLE(Name$)
	Local IteratePerson.PEOPLE
	For IteratePerson.PEOPLE = Each PEOPLE
		If (IteratePerson\P_Name$=Name$) Then Return IteratePerson.PEOPLE
	Next
	Return Null
End Function

Function GetHandleByName%(Name$)
	Local IteratePerson.PEOPLE
	For IteratePerson.PEOPLE = Each PEOPLE
		If (IteratePerson\P_Name$=Name$) Then Return Handle(IteratePerson.PEOPLE)
	Next
	Return 0
End Function

; Linking Lists.

; More depth can be added to the potential of Types when they are linked.
; Types can be linked by linking Instances of one Type to the Field of another, or by making Fields of Arrays.
; To explain the former of these links, lets make a new Type.

; We're going to give our 3 remaining PEOPLE (John, Pete and Jayne) some pet animals. So we need a Type for ANIMALS which will
; contain details of the pets' names, type of animal and who owns them. Also I have added a Field for the number of legs each pet has.


Type ANIMALS
	Field A_Name$
	Field A_Type$
	Field A_NumberOfLegs%
	Field A_Owner.PEOPLE
End Type

; You may notice the last Field, A_Owner has the syntax for a Type object 'instance', and specifically for the PEOPLE Type. This tells the program that the A_Owner is actually a name for a reference to
; an 'instance' of PEOPLE.
; In the same way as NewPerson.PEOPLE, EditPerson.PEOPLE, DeletePerson.PEOPLE and even John.PEOPLE referred to specific 'instances' of the PEOPLE Type, so too does this Field.
; The Syntax for workiong with this linked Field is explained a little later. First, let's just populate our collection of ANIMAL data.

;Yup, you guessed it! Another unimaginative name!
Local NewAnimal.ANIMALS = New ANIMALS
NewAnimal\A_Name$="Rex"
NewAnimal\A_Type$="Dog"
NewAnimal\A_NumberOfLegs%=3
;Now for the Owner!

NewAnimal\A_Owner.PEOPLE = John.PEOPLE
;The whole name should be used so it's clear we are referring to the PEOPLE Type. As we have a Global John, we can just stick him in already.

; For the next animal, though, we need to identify the correct owner. As earlier, we can iterate through to find the right person. (The correct PEOPLE 'instance')
; To save writing out a new loop, though, I'm going to substitute the Function written earlier.

; Yet again, we can re-use the name for NewAnimal
NewAnimal.ANIMALS = New ANIMALS
NewAnimal\A_Name$="Tiddles"
NewAnimal\A_Type$="Kitten"
NewAnimal\A_NumberOfLegs%=4
NewAnimal\A_Owner.PEOPLE = GetInstanceByName.PEOPLE("Jayne")

; Here's the neat part... Jayne has more than one aniumal, thanks to the link, though each pet (ANIMALS) can be linked to her as a (PEOPLE) person!
NewAnimal.ANIMALS = New ANIMALS
NewAnimal\A_Name$="Widdles"
NewAnimal\A_Type$="Kitten"
NewAnimal\A_NumberOfLegs%=4
NewAnimal\A_Owner.PEOPLE = GetInstanceByName.PEOPLE("Jayne")

NewAnimal.ANIMALS = New ANIMALS
NewAnimal\A_Name$="Fluff"
NewAnimal\A_Type$="Hampster"
NewAnimal\A_NumberOfLegs%=4
NewAnimal\A_Owner.PEOPLE = GetInstanceByName.PEOPLE("Jayne")

; We'll leave Pete out, he has no pets!

; The references to PEOPLE from within the Field ANIMALS\A_Owner act just as any other 'instance' name. Just remember to use the \ symbol to separate the
; 'instance' name from the Field.

; Since NewAnimal is still "Fluff" the "Hampster", we should be able to identify Jayne...
Print Str$(NewAnimal\A_Owner.PEOPLE)
; Or manioulate the Fields of that 'instance' directly from the ANIMALS 'instance':
Print NewAnimal\A_Owner.PEOPLE\P_Name$
;Or even use the Handle() or Object() commands too:
Print Str(GetPersonsAgeByHandle%(GetHandleByName%(NewAnimal\A_Owner.PEOPLE\P_Name$)))

; Finally, we could use the link to identify the pets by their owner too, by iteration with conditions:

For NewAnimal.ANIMALS =Each ANIMALS
	If NewAnimal\A_Owner.PEOPLE =John.PEOPLE
		Print Str(NewAnimal.ANIMALS)
		Exit
	End If
Next

; You may have thought that we could have made a Field in the PEOPLE Type for pets, but how then could we deal with Jayne having 2 kittens and a hampster?
; Clearly a single variable Field would not be enough. Also, Arrays would not be ideal due to the differing  variable types (A_NumberOfLegs% being an integer and A_Name$ being a string for example)
; as well as the fact that BlitzArrays (The [] square bracket kind) cannot be re-dimensioned and therefore will use up an amount of memory regardless of how many pets an owner has.
; Clearly, this form of linking Types is a great way to assimilate a lot of data together.
; In other cases, however, Arrays can be extremely useful.

; In addition to the Pets, let's give the PEOPLE some jobs. These jobs earn them a wage, but for some, the salary is not consistent from month to month! So for each JOB, there needs to be a Field that can represent
; the salary for each of the 12 months of the year. We COULD have 12 different Fields, but that's overkill and a lot of typing. Instead, we'll use an Array.
; An Array is ideal here because there is a definite fixed 12 months (12 Array Members) to be filled in for each job.

Type JOBS
	Field J_Title$
	Field J_Wage%[12]
End Type

; To Populate the field, it works just as any other BlitzArray, just remember to use the full name of the 'instance' and the \ symbol:

;Oh, and don't forget, Array members begin at ZERO!
Local NewJob.JOBS =New JOBS
	NewJob\J_Title$="Manager"
	NewJob\J_Wage[0]=4000
	NewJob\	J_Wage[1]=3000
	NewJob\	J_Wage[2]=4000
	NewJob\	J_Wage[3]=3000
	NewJob\	J_Wage[4]=5000
	NewJob\	J_Wage[5]=4000
	NewJob\	J_Wage[6]=5000
	NewJob\	J_Wage[7]=4000
	NewJob\	J_Wage[8]=3000
	NewJob\	J_Wage[9]=4000
	NewJob\	J_Wage[10]=3000
	NewJob\	J_Wage[11]=3500


; END NOTE:

; Really, the JOB should be linked to the PEOPLE by a Field in the PEOPLE Type as below:

;	Type PEOPLE
;		Field P_Name$
;		Field P_Age%
;		Field P_Gender$
;		Field P_Job.JOBS
;	End Type

; But this was not done in order to allow this code to be run and followed.

stanrol

(Posted 2010) [#11]

wy reinvent the weheel?

go read the help docs.

_PJ_	(Posted 2010) [#12]

Because the help docs do not nrecessarily explain it all in a readily pertinent fashion.
From what I've seen from your code, stanrol, the Help docs haven't even been considered at lot either.