When is it appropriate to use Types?

Blitz3D Forums/Blitz3D Programming/When is it appropriate to use Types?

Cubed Inc.

(Posted 2012) [#1]

I've been getting into this habit of creating types for EVERY entity in my game. This created some much confusion and inconvenience that I decided to rewrite the game's code altogether.
Before I begin the process again, when, in your opinions, is it appropriate to use types when working on a game?

Yasha

(Posted 2012) [#2]

Any data structure that isn't a number or a string should ideally have its own type to represent it.

There are a few weaknesses in B3D (to do with the fact that it didn't originally support custom types) that makes this less sensible in practice, but in general, it is as follows: "Here?" "Yes." Use them pretty much everywhere, for everything practical, and you will not regret it.

(If you found that using them was causing confusion, it's a sign that you need to go back to basics and do some more reading, or ask the rest of us some more questions: types are to data as functions are to process: they always simplify the program's expression and should be preferred where possible.)

Cubed Inc.

(Posted 2012) [#3]

Actually I do have a question.
How do you parent two object together when they are from 2 different types?

Bobysait

(Posted 2012) [#4]

"When" should we use type or not :
- when the size of datas is not fixed : all you can't achieve with Dynamic array without generating a biiiiig array, you 'd better do it with types
For the rest, it's up to the spec of your project to deal with the best way to store datas.
types are for confort, you can store as many as you want (from of to the range of your memory), but it's not that easy to access a specific instance of a type without an other support (because Blitz3D types uses internal linked-list), where a simple array could have been more usefull (or not)

as your citation says :
"It's not about the engine, it's about the person, and how he uses it."
;)

Then, your question "How do you parent two object together when they are from 2 different types?"

You have to think about the structur of your datas before any coding
If you have instances from differents types, maybe you should use a "main" type for your objects, and have sub-types to deal with different kind of objects (and you'll probably have to deal with Handle/Object functions)

Type Furniture
 Field name$,x,y,z
 Field sub
End Type

Type Chair
 Field furniture.Furniture
 Field style$
End Type

Type Table
 Field furniture.Furniture
 Field width#,height#,depth#
End Type

Function CreateFurniture.Furniture(name$,x#,y#,z#)
	Local f.Furniture = New Furniture
	f\name=name
	f\x=x
	f\y=y
	f\z=z
	Return f
End Function

Function CreateChair.Furniture(name$,x#,y#,z#,style$)
	Local f.Furniture=CreateFurniture(name,x,y,z)
	Local c.Chair=New Chair
	c\style=style
	c\furniture=f
	f\sub=Handle(c)
	Return f
End Function

Function CreateTable.Furniture(name$,x#,y#,z#,Width#,Height#,Depth#)
	Local f.Furniture=CreateFurniture(name,x,y,z)
	Local t.Table = New Table
	t\width=Width
	t\height=Height
	t\depth=Depth
	t\furniture=f
	f\sub=Handle(t)
	Return f
End Function

; create a standard furniture
Local f1.Furniture=CreateFurniture("My Unspecified Furniture",10,0,2)

; now create a furniture that is a table
Local f2.Furniture=CreateTable("My Table",2,0,4, 1.0,.8,1.9)

; and here are some chairs
Local x#,z#
For x=0 To 1 Step 1
	For z=.1 To 1.8 Step .6
		CreateChair("My Chair["+x+","+z+"]",2+x,0,4+z,"classical")
	Next
Next

Print "list of tables only"
Local t.Table
For t=Each Table
	Print " - "+t\furniture\name
Next
Print ""

Print "list of chairs"
Local c.Chair
For c.Chair = Each Chair
	Print " - "+c\furniture\name
Next
Print ""

Print "list of all furnitures"
Local f.Furniture
For f=Each Furniture
	Print " - "+f\name
Next
WaitKey
End

the second method is (imho) unoptimized
You create a type with all fields that any sub-type should have required. and a "class" field to specify which kind of type you have created
- advantage : no use of handle/function (smarter code)
- disadvantage : more memory used per instance
more difficult to access specific types

Type Furniture
 Field name$,x,y,z
 Field class%
 Field style$
 Field width#,height#,depth#
End Type

Const CLASS_UNDEFINED = 0
Const CLASS_CHAIR = 1
Const CLASS_TABLE = 2

Function CreateFurniture.Furniture(name$,class%,x#,y#,z#,w#=0.0,h#=0.0,d#=0.0,style=0)
	Local f.Furniture = New Furniture
	f\class=class
	f\name=name
	f\x=x
	f\y=y
	f\z=z
	f\width=w
	f\height=h
	f\depth=d
	f\style=style
	Return f
End Function


; create a standard furniture
Local f1.Furniture=CreateFurniture("My Unspecified Furniture",CLASS_UNDEFINED,10,0,2)

; now create a furniture that is a table
Local f2.Furniture=CreateFurniture("My Table",CLASS_TABLE,2,0,4, 1.0,.8,1.9)

; and here are some chairs
Local x#,z#
For x=0 To 1 Step 1
	For z=.1 To 1.8 Step .6
		CreateFurniture("My Chair["+x+","+z+"]",CLASS_CHAIR,2+x,0,4+z,0,0,0, "classical")
	Next
Next

Local f.Furniture

Print "list of tables only"
For f=Each Furniture
	If f\class=CLASS_TABLE Then Print " - "+f\name
Next
Print ""

Print "list of chairs"
For f = Each Furniture
	If f\class=CLASS_CHAIR Then Print " - "+f\name
Next
Print ""

Print "list of all furnitures"
For f=Each Furniture
	Print " - "+f\name
Next
WaitKey
End

third method :
Use your own Linked-List for types.
(It is generally the way I use types in blitz)
- Advantage : less memory
you can create lists of types that does not contain "all" the instances of the specified type, so you can have an octree based system for entity partitioning, that contain lists of entities

- disadvantage : You'll have to program your own linked-list support and it is not always very fast (depend on the way you do it)

Last edited 2012

Rroff

(Posted 2012) [#5]

Theres almost no time you wouldn't want to use types imo tho you need to be a little creative with some useage of them.

You don't need to program your own linked-lists for parent/child grouped types either they are extremely powerful when you start to think outside the box.

The trick is to use dummy type instances as demarcation points between groups of the same type - then you insert a new one after the demarcation type instance for the group it is in and can walk the group until you come to another demarcation indicating the end of the group (or reach the end of the list of types).

Last edited 2012

Yasha

(Posted 2012) [#6]

My advice is to try to keep separate in your mind the idea of Types as data structures and by-reference objects, and Types as lists of those data structures. The two are 1:1 in B3D - every time you define a data structure, the engine will automatically create a linked-list of every instance of that type that you create - but that's solely a design decision by Mark, and on a theoretical or logical level, the two aspects of Type-in-B3D have nothing to do with each other. It's only there for your convenience, and there are plenty of other ways to store and access collections of objects, or to get list functionality.

So if you're still not too familiar with individual objects being created on the heap and passed around by reference, you should start by completely ignoring anything to do with the For/Each command (and its friends First/Last/Before/After/Insert): this is really something else entirely, and will not help you understand what the data structures/by-ref semantics are.

H&K	(Posted 2012) [#7]

I've been getting into this habit of creating types for EVERY entity in my game

I hope you dont mean that every entity is a seperate type.
(For everyone else ; Is he saying every entity is a instance of a singleton?)

Rroff

(Posted 2012) [#8]

While your correct in that commands like first/last/before, etc. will quickly get someone new to it in over their heads I think its important to get your head around these as at a more advanced level they open up capabilities in B3D that a lot of people don't seem to realise exist.

I will try and get some decent fully featured examples up over the next little while as I feel they add a lot to B3D when the scope is realised. (Plus I need to get my head around the most efficent way to implement it).

Last edited 2012

Bobysait

(Posted 2012) [#9]

@Rroff:

You don't need to program your own linked-lists for parent/child grouped types either they are extremely powerful when you start to think outside the box.

The trick is to use dummy type instances as demarcation points between groups of the same type - then you insert a new one after the demarcation type instance for the group it is in and can walk the group until you come to another demarcation indicating the end of the group (or reach the end of the list of types).

Yep, but, keeping Head/Tail instances to contain lists of types between them still remains a way to build our "own system of linked-list".

Anyway, at the moment, it's probably premature, but as he wanted to know, here it is.

@Yasha :
For someone new with the blitz3d types, I think the best way to explore them is to test the whole thing about types (internal linked-list too) checking a bunch of exemples to read and try
And understanding "what a type really is", generally comes later
All programmers not coming from an Object Oriented language probably always start this way, and maybe it is the best way to understand them.
(The famous "try and understand by yourself" method)
Then, when the practice is good enough, it becomes more theorical and we can accept concepts of why/where/what/when do we choose a kind of data structur

For a non-beginner programmer, it is different, we have notions about class, data structures, lists, maps, vectors etc ... We probably don't have to deal with thinking about things we already know :)

@H&K :
(quote]I hope you dont mean that every entity is a seperate type.[/quote]
It's probably a mispelled thing
In the french blitz3d community, we use to say a "type" for "instance" or "instance of type", (Yep, it's a bad "habit" ;) ) maybe he does the same here ... maybe
I Hope so ....

So, maybe the first "legitimate" matter is :
TaGames, Have you already done simthing involving blitz3d-Types ? and what do you want to do exactly ?

Last edited 2012

D4NM4N

(Posted 2012) [#10]

I would say always!

Even for global variables eg:

Type T_Globals
     var1 = 123
     var2 = 123
     var3 = 123
     etc....
end type

Global Globals.T_Globals = new T_Globals

then you can access everything with globals\var1 etc..
why?
..well, the reason for this is that it is the only "strict" var referencing in b3d, and will not permit you to make variable spelling mistakes (something that is a HUGE debug pain in non-strict languages).

One thing about using types in B3D though (and javascript actually), if you have a function that has a lot of -really- heavy repeated processing of type variables, it is faster to "unpack" them into simple local variables . It also makes it nicer to read. (dont forget to write them back where needed when finished :)

eg:

function doSomething(player.t_player)
    h% = player\handle
    x% = player\x
    y% = player\y

    ....do a million things with h, x and y........

    player\x = x
    player\y = y
end function

note we only write back values we need to be written back, the handle is unnessecary because it is just a pointer to the sprite or whatever and has not changed.

I found this was significantly faster when there are 100s of type access calls. Of course if you just have a few access calls, don't bother.

Last edited 2012

Bobysait

(Posted 2012) [#11]

the reason for this is that it is the only "strict" var referencing in b3d

That's not totally true, you can send a local array as function parameter

function Do(Arr%[0])
 Arr[0]=2
end function

local a%[0]
Do(a)
print a[0]
waitkey
end

But you're right, it's a good method for debuging

Other point :

I would say always!

I would say it too, but I also use blitz3d to program some fast templates to test a gameplay or else, and in many case, dealing with types will probably be slower than not using them (see: in programmation time)
So, it really depends on the purpose of the program you're ... programming.
A matter of comparision between :
- time to code/timeline
- required performance
- complexity of datas involved

Rroff

(Posted 2012) [#12]

Actually thats a very good idea D4NM4N suprised I didn't think about that, very nice way to both organise and enforce strict useage of globals.

I generally do the 2nd method when handling a lot of data from types out of habit but never really thought about the performance implications - another thing to keep in mind for future reference.

D4NM4N

(Posted 2012) [#13]

That's not totally true, you can send a local array as function parameter

Yes sorry, arrays are strict too and faster, but nowhere near as versatile. :D

RemiD

(Posted 2012) [#14]

I use arrays (dim) to store most of my pointers and variables, i like how i can access an entity or a variable with its index without having to go through a For next loop. And i often use multi dimensional arrays to define parents/childs.

I use Types only to create/store/delete particles or others things that have a variable list size.

It is a matter of preferences, if the program behaves as expected that's all that matters...

Last edited 2012

dynaman

(Posted 2012) [#15]

I used types for EVERYTHING possible. It helped to even make a single instance type for variables - since the compiler will crash on a non-declared type variable but would happily use a non-declared variable, mis-typed variable names are the bane of existance.

Blitz3D types are fast and easy to use as well, so unless speed of exectution became an issue (and I don't recall it every happening) I used types exclusively.

_PJ_	(Posted 2012) [#16]

I use Types a great deal too.
I rarely use dim, but when I know there's a specific, fixed-size of data members, I find BlitzArrays also help.
More typically, I combine the two, having a BlitzArray within a Type Field.

Types are nice, since they can be randomly accessed with the Object/Handle commands, and also, you don't need to know how many instances there are or a maximum.

Charrua

(Posted 2012) [#17]

There are more pros than cons in using types.
normally the worst thing i found (and as i saw, many others) is to scan a list of typed vars with a for each loop.
This was true until i found the (undocumented lamentably) Object/Handle

normally we has a MyEntity, returned by a blitz function (say PickedEntity or EntityCollided) and we need to find a MyTyped var wich has other properties we mantain associated to it (MyEntity)

if we Name each entity with the Handle to the instance of the Typed var, then we evade the scan with a for each loop.

an example:

;*******************************************************************
;*                                                                 *
;*   Use of Object and Handle                                      *
;*                                         					       *
;*******************************************************************
;
; Autor : Charrua
;
;when working with typed variables, it's usual that we has to scan the full list of objects
;to find a particular one, that holds in it's fields inforation related to some entity
;for example an enemy, it's ammo, it's life, etc, basically any property other than the ones xors keeps track (like position...)
;
;Handle and Object are two useful functions
;


Graphics3D 800, 600

camera = CreateCamera()
PositionEntity camera, 0, 0, -10
light = CreateLight()

cube = CreateCube()
sphere = CreateSphere()
MoveEntity sphere,3,0,0
cylinder = CreateCylinder()
MoveEntity cylinder,-3,0,0

Type tEntities
   Field Mesh
   Field Name$
   Field VariablesToKeepTrack1
   Field VariablesToKeepTrack2
   ;... the one you need
End Type

Local EntityStruct.tEntities

;create an instance of tEntities for each mesh and name it with it's handle
EntityStruct = New tEntities

EntityStruct\Mesh = Cube
EntityStruct\Name = "I'm a cube"
NameEntity cube,Handle(EntityStruct)

EntityStruct = New tEntities
EntityStruct\Mesh = sphere
EntityStruct\Name = "I'm a sphere"
NameEntity sphere,Handle(EntityStruct)

EntityStruct = New tEntities
EntityStruct\Mesh = cylinder
EntityStruct\Name = "Don't know ho i am!"
NameEntity cylinder,Handle(EntityStruct)


For EntityStruct = Each tEntities
   EntityPickMode EntityStruct\Mesh, 2   ;apply a pickmode for all the entities
   EntityColor EntityStruct\Mesh, Rand(16,192), Rand(16,192), Rand(16,192)
Next

Local Msg$
HidePointer()

Local UseObject = True

Const KEY_ESCAPE=1, KEY_SPACE=57

While Not KeyDown(KEY_ESCAPE)

   If KeyHit(KEY_SPACE) Then UseObject = 1 - UseObject

   TurnEntity cube, 0, 1, 0
   
   CameraPick(camera, MouseX(), MouseY())
   
   If PickedEntity() Then
   
      If UseObject Then
      
         ;Technique one: use object and handle
         EntityStruct = Object.tEntities(EntityName(PickedEntity()))
      
      Else
      
         ;Technique two: for each loop
         For EntityStruct = Each tEntities
            If EntityStruct\Mesh = PickedEntity() Then
               Msg = EntityStruct\Name
               Exit
            End If
         Next
         
      End If
      Msg = Entitystruct\Name
   Else
      Msg = "+"   ;none picked
   End If
   
   RenderWorld()
   
   Text MouseX(), MouseY(), Msg
   Text 10,10,"Using Object: "+UseObject
   Text 10,30,"Press SPACE to switch technique"

   Flip()
      
   
Wend

@ pj: i post almost over you!

Juan

Last edited 2012

Rroff

(Posted 2012) [#18]

Very quick and dirty example of grouping objects of the same type without having to iterate through each one to check what its parent is.

In this example we are using an instance of player objects each with their own inventory group of items.

Type t_item
	Field dummy

	Field parent ; not used in this example but allows reverse lookup from an inventory item to its owner
	Field name$ ; id of the type of this item
End Type

Type t_player
	Field inventory.t_item ; to be able to forward and reverse walk the inventory group with minimal command execution we would create start and endpoint dummy items
End Type


; create a new player and create an inventory group for it

player.t_player = New t_player
player\inventory.t_item = New t_item ; NOTE if your using multi-threading this could cause new t_items to appear in the wrong group
player\inventory\dummy = True
Insert player\inventory Before First t_item


; create items in the players inventory

this.t_item = New t_item
Insert this After player\inventory
this\name$ = "gold coin"

this.t_item = New t_item
Insert this After player\inventory
this\name$ = "small bag"

this.t_item = New t_item
Insert this After player\inventory
this\name$ = "cloth cap"

; create another player and build their own inventory to show the grouping at work
; normally this code would be part of a function to save duplicating the code over and over

player2.t_player = New t_player
player2\inventory.t_item = New t_item
player2\inventory\dummy = True
Insert player2\inventory Before First t_item

; create an item in player2's inventory

this.t_item = New t_item
Insert this After player2\inventory
this\name$ = "silver coin"


; walk through each item in the first player's inventory (this works backwards from the latest to oldest item)
; to reverse iterate requires dummy objects at the start and end of each group

this.t_item = After player\inventory

While (this <> Null)
	If (this\dummy = True) Then
		Exit
	EndIf
	
	Print this\name$
	
	this.t_item = After this
Wend

WaitKey()
End

There is so much more you can do with this tho.

Last edited 2012

RemiD

(Posted 2012) [#19]

if we Name each entity with the Handle to the instance of the Typed var, then we evade the scan with a for each loop.

The same thing is possible with arrays (dim) without having to use the "handle".
You can retrieve the index of a mesh stored in a dim by using EntityName(Mesh) after a collision or a linepick or a camerapick and by reading the name of its list and its index number if you have properly named it before.
Also, if you use several Types you have to use more than the Handle in the NameEntity in order to be able to find the correct list.
For example, i use a name for each list like "CHA"+Handle and "ITE"+Handle for lists with types, and "CHA"+Index or "ITE"+Index for lists with dim.

But you can achieve the same result.

The difference is that you can read/write directly a variable or an entity with its index in a list with dim, but i haven't found a way to do this in a list with types. But maybe there is a way.

It is a matter of preferences...

Charrua

(Posted 2012) [#20]

yes, it's a matter of preferences, planning and/or needs, as always.

there are other things to take into account like speed/memmory usage

typed vars: dynamic memory allocation (handled by blitz)
arrays: static memory allocation (yes use redim!: manually handled)

or the type check (strict) made by blitz wich isn't an isue if you use IDEAL or a similar editor.

so as you said and i agree 100%, "its a matter of preferences"

it's better to use a tool we felt comfortably, probably because we know better their issues.

Juan

Last edited 2012