Sorry your browser is not supported!

As some of you might be aware, I'm currently translating an Education Software 3D Engine into AppGameKit ... primarily Studio, but I'm fairly sure it also works in Version 2 as well.
In doing this, I've been learning a lot about the limitations (and oddities) of how AppGameKit BASIC works.

Now while I wouldn't say no to seeing support for Pointers, as Dark BASIC Professional v1.05+ introduced., I get why References (Ref) is used instead.
Those who are new to Programming, having a "Safe" Pointer approach is an excellent idea.
So, I won't suggest adding Pointers ... instead what I'd like to suggest is an expansion of how References work.

While it might seem weird, but as it stands "Ref" will not work on Built-In Data Types.
i.e.



Doesn't work... and while this might be an "Edge Case", I think it would be a very useful.
Using it for things like Cryptography for example, would be very useful where you don't want to keep clear results in Memory to be sniffed out.
Just as an example.

The next Suggestion is Data Containers.
Within Dark BASIC Professional, we could use the "DATA" Operator to internally Store Data... and it didn't have to be a single type.
Rather it could be an Integer, Float or String.

AppGameKit lacks this... or rather should I say, it has VERY Specific Support for this.
You can use the Square Brackets [ ] as a 1-Dimensional Data Container.

This means we can do things like:
myArray As Integer[] = [1, 2, 3, 4, 5, 6, 7]

However we can't do this on Multi-Dimensional Arrays, i.e.
myArray As Integer[1, 1] = [ [1, 2], [3, 4] ]

Doesn't work.. instead you'd have to do it like
myArray As Integer[1, 1]
myArray[0] = [1, 2]
myArray[1] = [3, 4]

This can start to get complicated as soon as you start have larger Multi-Dimensional Arrays.
The same is true for Typed Data, which you can populate with Json ... but I'd argue that Json is a bit, clunky.
i.e.



It's a somewhat needlessly complicated approach, which is fine if the Data is "Out-of-Order" ... but it'd be better to have a Data Container.
After all everything is 4-Byte Aligned (32bit)., so really the only "Special Case" ends up being the String; which as clearly is being handled here via the fromJSON, it doesn't make sense why we can't have it for actual Data Containers.

i.e. it would be better to have the above as
myValue As myType = { 1, "Mark", 1.5 }

The same I'd argue should be true for arrays... each { } Data Container, could be used for each Dimension.
i.e.
Array[ 2 ] = { 0, 1, 2 }
Array[ 2, 2 ] = { { 0, 1, 2 }, { 0, 1, 2 }, { 0, 1, 2 } }
Array[ 2, 2, 2 ] = { { { 0, 1, 2 }, { 0, 1, 2 }, { 0, 1, 2 } }, { { 0, 1, 2 }, { 0, 1, 2 }, { 0, 1, 2 } }, { { 0, 1, 2 }, { 0, 1, 2 }, { 0, 1, 2 } } }

I mean when we keep in mind that Data Types themselves are merely Data Pointers., so the Size is quite literally 4 * Elements = SizeInBytes
When we have a String, what's happening is you have the Pointer to the String (Char*) that it's connected to; so the String itself could be anywhere in Memory; while the Data Type itself remains the same size. Same is true for Arrays, and as I've recently showcased; you can actually have Arrays of any size (that grow and shrink) ... because again Arrays themselves are little more than a list of Pointers to where the Data is actually located.

So handling Data Containers like this, esp. given JSON is supported that would also have to look for the actual Element Name (where-as Data Containers don't., you HAVE to order them in the same Order as the actual Type Elements... not because they won't work, but let's say we want to add a String where just an Integer or Float is; the Data gets truncated and converted; meaning what ends up in the Data Type isn't what you actually wanted)

And support for these, would allow the ability to Populate Data Types when you create them.
I mean the same could also be true for populating from an existing Data Type... I mean it actually confuses me why:



And again this would be easier with a Data Container... i.e.



I mean you could still use the [ ] Square Brackets... but I'd argue against such, as it's better to use different Symbols; as this makes it easier for the Compiler to be less prone to issues; but also from an end-user perspective, it's more overt as to what you're doing.

Now the last thing is something that frankly I have a feeling will actually be exceptionally easy to add, especially given References exist providing the language Functionality... what we lack is the Compiler Rules to construct the code to provide the End-User Functionality... and that's Function Return Type Casting.

What I mean is something like:


I mean if you think about it, this functionally is no different to passing in VectorC Ref As Vector
The only difference here, is that the Function is automatically handling creating the Output Ref As Vector., then using that as the Ref for whatever you're outputting to.

As such, we might write something like

Length = Vector_Add( Start, End )
what would actually be happening is
Vector_Add( Length, Start, End )

I mean realistically this is how Normal Data Types are working in terms of the Runtime Bytecode... with the Function being called First, and the Output Data being Referenced rather than the Function... if there was no "Ref" for Types / Arrays, then I can see it being very difficult to do; but as we do have them, surely such support is relatively straight forward.
This would make Functions in AppGameKit BASIC exceptionally powerful., and greatly cut down on the Developer having to add in the extra lines to handle this behaviour ourselves., as well it's always going to be a fairly common behaviour.

In many ways the same is true here in regards to not being able to simply construct said Data in the End/ExitFunction ... In-fact I'm not sure why this has always been denied.
It would make sense if there was a "Return" like in C/C++, where you're populating the Output Data; and I get why we don't have that, as Return is used for something else in BASIC but I don't see the issues with having constructs within the Output Lines.

As it just means the Compiler needs to handle the additional lines itself, as it doesn't really matter what the Bytecode looks like; or how "Easy" it is to use that... what's better is how it's structured for the ease of the Developer.

Well, let me know what you guys think... but these are just some improvements that I think would be very beneficial to AppGameKit BASIC.

+1 on being able to use "ref" with built-in data types. I think it has been suggested several times.

A small correction on multi-dimensional arrays.
This works:

But maybe that doesn't help much.