Blitz arrays

Blitz3D Forums/Blitz3D Beginners Area/Blitz arrays

Ross C(Posted 2012) [#1]
Hey guys,

A bit of a beginner question I suppose, but how would one go about setting the size of a blitz array (type field array), based on an external save file. I know you could just set the blitz array to it's maximum needed size and cover all possible outcomes, but is there another way?

The only time you can use a variable to declare a blitz array, is if it's a const you use. But const's have to be set using a number, so... Any ideas?


Adam Novagen(Posted 2012) [#2]
The answer to this question is an easy "no," because constants aren't really variables. Literally, they aren't; although they look like that to us in the IDE, all instances of a constant are converted to its contents by the compiler. Therefore, as far as the ultimate program is concerned, constants are just fixed, hard-written values the same as any other.

Therefore, there's no way to use a variable to set the size of a Blitz array. In a case like this, I'd say banks are more along the lines you'd need.

Last edited 2012


Ross C(Posted 2012) [#3]
Yeah, I keep forgetting about banks! Cheers.


Adam Novagen(Posted 2012) [#4]
No problem; I did the same thing a week or two ago in my own game when I decided that I wanted enemies to be able to have "sub-parts," like legs and such, but I didn't want to be limited to a preset maximum. Once upon a time I would've tried something silly with Types, but I've discovered more recently that such a solution isn't really possible/practical in Blitz, and requires an OO language instead. Realizing that all I needed was an expandable way to store the integer handles for the sub-part entities, banks were the only real remaining solution.


Yasha(Posted 2012) [#5]
something silly with Types


Foo?

Depending on what you wanted to do, there may be a way that's not as silly as you initially thought. Blitz3D can certainly implement trees and lists without any great difficulty.

From an intellectual/academic point of view, it's "cleaner" to try to avoid banks where possible as they have no structure. Performance-wise they're often one of the better solutions since more structured approaches sometimes require a bit of runtime casting, but that performance boost isn't always necessary and may come at the cost of some clarity, depending as always on what you're doing.


Adam Novagen(Posted 2012) [#6]
True. Fortunately the sub-parts methodology only has one level of the hierarchy, i.e. the base enemy entity and all the parts (if any) attached to it. Most of the enemies don't even HAVE additional parts.

I'm not quite sure how Types would be much good for a tree though; I tried fancy things a while ago like


This just counts through every single Child Type, instead of those "attached" to the parent, thus returning all 15 children instead of 3 per parent. There's no way that I've ever found to just affiliate specific children with their parent Type[s], and then not loop through ALL the child Types later.

Last edited 2012


Adam Novagen(Posted 2012) [#7]
And by the way, wot's "foo?"

(inb4 dozens of smart answers)


Yasha(Posted 2012) [#8]
("Foo?" = onomatopoeic-noise-representing-innocent-curiosity, rather than "Eh?" or "What?" that might imply hostility or condescension. Kinda misfired.)

As for trees... well there are a few things to cover, but the biggest problem with the above code is actually this line:

Parent\Child.Child = New Child


...put that inside a loop and you may as well not bother storing the pointer at all, as it keeps being overwritten.

Anyway, what you're currently doing up there (I think) is mixing the loose concept of trees with the built-in list functionality. Trees work best when they rely on fixed node structure (i.e. knowing in advance how many children each node has: canonise it in the object structure), and a non-fixed tree depth (so not distinguishing between parents and children, because any node could be both a child and a parent depending on the size of the tree).

This is because trees are mainly useful if you're going to search for specific entries: if you're going to go over the whole thing you may as well have a linear list anyway. Assuming the data is sorted, trees decrease the search time by making looping over the whole data set unnecessary (by an enormous factor).

So in answer to this:

There's no way that I've ever found to just affiliate specific children with their parent Type[s], and then not loop through ALL the child Types later.


Firstly, you can affiliate specific children with their parent by ...storing them in fields:



...the children are right there in the parent, in its fields (or in this case, elements of the Child field; normally for a tree you'd use two fields "left" and "right" or something like that). There is no second search-and-count step or comparing of IDs because you don't need to search for them: their existence is implied by the presence of the parent.

Secondly, you'd normally only have a single Node type rather than dividing Parents and Children in this way, because as I said above a tree with only two layers isn't really a tree at all. By analogy, consider a list: you'd use a single Element type with a NextNode field, not dedicated types for ListHead and ListEnd and so on; or you couldn't have a list of arbitrary length (instead the end is implied by pointing to Null as the next element, or something similar to that).

For some actual working tree code, see here: http://www.blitzbasic.com/codearcs/codearcs.php?code=2574

It might address some of your concerns about how to make custom types a little more useful (although it's a complicated working example, may not be entirely transparent).

I'm not really sure what to explain specifically, since I'm not sure which part it is that you're not comfortable with, but ...eh, if you actually want to get lectured, feel free to ask specific questions! (might do well to have a new thread for that that isn't titled with someone else's array question... sorry Ross)