Constructor and arrays in types?

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|615\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> Constructor and arrays in types?
Wed, 14 May 2008, 06:19
LostUser	Hi, I remember in the old forum that there used to be code to create a constructor for your types. Does anyone still have it? Also, I store quite a lot of info into Types and I normally use this style to grab the right info. ; ############################################################## ; # ; # Player ; # @updated: 14-May-08 ; # ; ############################################################## Type Tplayer Field id% Field parent% Field name$ Field cash Field health Field is_ai ; boolean Field r,g,b End Type Function Create_Player(name$="",cash=0, parent=0, is_ai=True) p.Tplayer = New Tplayer p\id% = Find_Player() p\parent% = parent% p\name$ = name$ p\cash = cash p\health = 100 p\is_ai = is_ai End Function Function Find_Player$(id%=0, searchTerms$="name") count=0 For p.Tplayer= Each Tplayer count=count+1 If (count = id) Then Select (searchTerms) Case "id" Return (p\id%) Case "parent" Return (p\parent%) Case "name" Return (p\name$) Case "cash" Return (p\cash) Case "health" Return (p\health) Case "is_ai" Return (p\is_ai) End Select End If Next Return count End Function --v But I was thinking, rather than doing that, which I still think is incredibily slow, why can't I use an array to hold the "field" data. I did some testing and came up with this; Type t_exotics Field eData$[5] ; Field parent% ; Field name$ ; Field cost End Type p.t_exotics = New t_exotics p\eData["name"] = "Car" p\eData["cost"] = Int(50000) --v Of course you still have to loop through every field, but now I've got an array key - it should mean that if I wanted a particular field in my object - it should be much, much quicker and less typing. So, my questions are: 1) Can someone post an example of a B2D constructor again? 2) Is there a faster way to loop through all type fields to get to the specific data you want? 3) Is using an array key (as above) a better/faster way to getting to the correct field you want? That's all. Thanks.
Wed, 14 May 2008, 06:26
Paul	The best would be storing it in an array and the accessing it with an int like you normally access the array. type test field x,y field data[3] end type Function GetData(t.test,index) return t\data[index] end function --v
Wed, 14 May 2008, 06:31
Jayenkai	Using a Select-Case is definitely faster than a bunch of if's, but if you're having to use Strings to find your entries, that's pretty much as quick as you're going to get. Personally I'd avoid having to use strings altogether. Either memorise (my method!) or use a bunch of Const variables, to store all the different parameters. Const Name=1 Const Cost=2 Const PullingYourLeg=3 Type Whathaveyou Field stuff$[50] End Type This.Whathaveyou=New whathaveyou this\stuff$[Name]="Bob" this\stuff$[Cost]="99p" this\stuff$[PullingYourLeg]="No" DebugLog Get$(This,name)+" says his donut cost him "+Get$(this,Cost) If Get$(This,PullingYourLeg)="No" Then DebugLog "And he isn't even pulling your leg!" Function Get$(this.whathaveyou,piece) Return this\stuff$[piece] End Function --v Dang, Paul got there first! -=-=- ''Load, Next List!''
Wed, 14 May 2008, 07:33
Afr0	... or simply ignore trying to hack in constructors in a language that wasn't meant to deal with it! If you want a real OOP language, try C# or Objective C. Edit: Or BlitzMax, though I wasn't experienced enough to use it's OOP features when I was still using it, and afterwards I've read it's OOP features are really bad. Edit2: I shouldn't even use the word 'real' here. C#, Objective C and C++ are OOP languages, Blitz 2D, 3D and Plus are not. It's as simple as that. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Wed, 14 May 2008, 08:48
LostUser	I understand. Thanks for that. But I distinctly remember someone coded a constructor. Or a fake-constructor function or somehting. As for rapid-file access (or in Qbasic it was called Random Access) I've been looking at seeking into files. But this might be a bit overkill. I think the solution of using arrays with keys inside a type will do for now. Thanks.
Wed, 14 May 2008, 09:08
mike_g	Techincally speaking, constuctors don't exist in Blitz; its an OOP feature. That dosent mean to say you cant imitate them, in fact you should as usually when you create objects you want them initailised somehow. I reckon the best way to do this would be to wrap it all into a function; the function would create an new object, initiallise it, then return the objects handle to the calling function. Something like: myThing = NewThing() --v
Wed, 14 May 2008, 10:10
JL235	I'd personally say that the CreatePlayer function you defined at the top is as close as your gonna get to a Blitz constructor. The only alternative I can think of would be to return the type from the function after you have made and initialised it, like Mike_G's example. Again I agree with Mike_G that you should do this anyway, and although it's not a constructor in the object-oriented sense of the word, it is a constructor from a design point of view and I write constructor functions whenever I use Blitz. Finally, is your code actually slow? Have you built profiling code into the project that is using it to see how much of the programs CPU time it is taking up in a real life situation? Have you sat down and calculated your algorithms time complexity? These are the real issues about benchmarking algorithms. Personally I'd just get it done. Wait until the end before you do optimisations. To be honest, apart from Jay's idea to switch from strings to constants, your proposed optimisation look very small and insignificant in the greater scope of things. Iterating over less types in the list would, for example, have a far bigger impact.
Wed, 14 May 2008, 12:05
Afr0	If you're forced to search using a string as a key (e.g. name$) and speed is a problem, hashing the string into multiple trees is one approach. But it would need to be a pretty massive player database before that becomes necessary. Yes, yes, good! In the .NET framework, there's a readily available class for this purpose! HashTable, I believe it's called. Edit: The Wikipedia Article on the subject is quite good. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Wed, 14 May 2008, 12:28
JL235	Most languages have these structures, but it's also very useful to know how to build them yourself. I have heard especially for game developers as they can build specialist data structures which are optimised with the game they are making in mind. For example I have been thinking of implementing some sort of a 2d binary tree (or maybe some sort of doubly linked one so it's easy to climb the tree too) where the left and right children are on the left or right based on the x position. Then on the next level it's based on the y position, then x again, and so on. This might be fast for collision detection because if I have say 1,000 units then each of them can just search in the branches leading off itself (including up towards the parent) until it's gotten x far away. That way each unit might only check against 10 units. An alternate would be iterating over all 1,000 against all 1,000 in two nested loops. 1,000 * 10 is far faster then 1,000 * 1,000. Even though the data structure itself would be far slower to build and maintain, iterating over less units (in theory) will more then make up for it.
Thu, 15 May 2008, 09:52
LostUser	Personally I'd just get it done. I agree. I'm working/hacking away on my project now. You don't need an id field. Your "constructor" should instead return p, which will be a unique pointer. This can serve as the id. Your count var is therefore also redundant (Find_Player just returns Null if not found). Moreover, if you want to delete individual players from the list (under your current scheme) you'll need to re-index the entire list - another unnecessary overhead. It is pointless "searching" for a specific field within a Type when you can just access it directly once you've located the player. Indexing an array using named constants? Viable perhaps for purely homogeneous Fields, but regardless - no real advantage over just using named Fields. And what happens when you need to add a new Field of a different type to the array? If your database is going to grow to a significant size, instead of using the default Type list, you could construct a tree. This will facilitate much more rapid searching than the linear For..Each traversal. If you're forced to search using a string as a key (e.g. name$) and speed is a problem, hashing the string into multiple trees is one approach. But it would need to be a pretty massive player database before that becomes necessary. I've never heard of tree structures before. And I wouldn't know where to start. I guess it depends on how much of a database structure it is and what point do you say, "screw this, I'll just use a MYSQL database". That reminds me, I've seen a library which connects to MySQL (https://blitzbasic.com/codearcs/codearcs.php?code=1308) but, doesn't it require MYSQL to be installed on the end-user's computer? Also, what about using CSVs in Blitz? I'm currently coding my "game" now, but there's lots of data calls for things you can buy. I'm having to type it all out by hand, but could I use a CSV generator like this (https://www.mirex.demon.co.uk/blitz/) (also here: https://blitzbasic.com/codearcs/codearcs.php?code=442) to simply output all the stuff I want? I'm going to try the above CSV generator and see if I can use that to help cut down on development time. IDs in Types are not needed I understand why you say that, but, what if I want to get a parent id, or only output those types that have a parent of X? what happens when you need to add a new Field of a different type to the array? A different type of array? I'd only use it for standard stuff like ints, floats, strings, and probably pointers if I wanted to. The only reason I wanted to do it was so that I didn't have to type out every field in a big switch statement. In PHP you can do a for-next loop outputting all the entries in an array using just the keys; so my thought was - why not use the same idea in Blitz to replace fields in types.
Thu, 15 May 2008, 10:21
JL235	Here is a simple linked list I made in Blitz and here is a binary tree I also made in Blitz. Both are just simple examples to illustrate the general idea. Although there is no real point in building a linked list because of the inbuilt type list. As for CSVs, I think it's completely up to you. If you really feel you need to buy some code to do it, then do so. Personally though, I once built a CSV reader and I found it a pretty trivial task. Mine was built for a specific CSV in mind so to be fair it couldn't easily be used for other CSVs. But thinking about it I would find extending it pretty trivial too. I would also imagine that a simple CSV builder could be written within 200 lins of Java, dunno about Blitz but I'd imagine you'd get something similar since it's file handling is a lot simpler. Also what exactly are you trying to do? It might be that your approach
Thu, 15 May 2008, 10:25
Orion Pax	Hey zardon...i am using that same mysql lib. It works for the most part. My problem seems to be sending a HUGE mysql command to it. I cant seem to get it to create a new player with 33 fields listed in it...hehe. I have rewrote the blitz side of it so it doesnt use that database type. And if you use a host like godaddy, your mysql server does not reside on the same machine....so I modified it greatly. How ever I have slightly modified the php file to reflect those changes that are needed with godaddy and mine accepts all needed info via params.
Thu, 15 May 2008, 11:08
Forklift_Fred	I've done a couple of CSV related things for work. Like Orion Pax, they were for specific reports that we receive but recently I added my own CSV into the mix on 2 separate occasions. One of them reads a report and removes any lines that contain the specified entries in my Ignore.CSV so basically it is comparing 2 CSV files. The second is more flexible and puts user-defined names of location sizes (as laid out in one CSV) against the report and counts how many of each size there are - the key feature being that the definitions list can be modified at any time to re-name a location size or change the size of a specific location (or with the help of Excel, a whole range of locations) Not sure how much of that makes sense because it's hard to put into words without explaining the whole scenario! It's all down to what you are wanting to do I suppose but working on these little projects has given me a better understanding of file handling, string wrangling, use of types and got me some nice brownie points from he boss (My point there is that however trivial a task it may be, if you've never done stuff before it can lead you in other directions of learning at the same time) -=-=- Come rain or shine...
Fri, 16 May 2008, 06:43
LostUser	The CSV thing was to save time on my typing out lots and lots of Data commands to store all the possible things you could buy. So, instead of; ; if parent is empty, it must be a folder/container ; parent name Data "" , "Sports" Data "Sports" , "Bat" Data "Sporst" , "Ball" ;etc... --v I could have created a simple CSV file with all my fields in it and then just have Blitz to read the file, parse it and then spit it into Types. That was the only reason I wanted to use CSVs: to save time on me typing everything out. It doesn't matter now I've used Editplus to wrap quote (") marks, and commas (,) quite quickly around my text notes and I've been able to copy/paste that in... so I saved myself a lot of time. --- As for MYSQL. I've never used the library. But I always assumed that if you used the library, the end user must therefore have MySQL installed. I mean its not a big issue, but it sure isn't user friendly, they'd have to create the database themselves, insert the SQL data... I didn't realise that you could potentially connect to an external MySQL database online. I don't intend to do that, its full of too many security issues. --- ;Instead of some arbitrary number (which you then have ; to use as a search key to get at the parent), just use ; a pointer to the parent's instance, i.e. ; Field parent.Tplayer --v That's excellent. That's exactly what I was looking for! Thanks.