As best as I can tell... AppGameKit Studio is just an iterative version.
It's like comparing Visual Studio 2015 with 2019., like there are a lot of Quality of Life Changes that are awesome for more Modern Application Development but I've seen and heard absolutely NOTHING about any improvements to the BASIC Language., which I'd argue is perhaps
THE most compelling element of AGK; when all other Middleware use Python, Typescript, Rust, JavaScript, C#, etc... and in their Script as opposed to Native Forms.
And this is frankly why AppGameKit is more compelling., because rather than being Yet Another C++ Inspired Language with it's own peculiarities … an in Scripting Form at that., AppGameKit not only using BASIC (which is criminally under serviced today) but it's their own variant, with their own Compiler / Interpreter Engine; well it means they have absolute control over what it can and can't do.
An excellent example being., Arrays v2 that was added in AppGameKit v2.
Using a Scripting / 3rd Party Language... you can't simply be like "I think we'll add this Feature..." or "Let's change how THAT works to be more user friendly" where-as TGC can with AppGameKit BASIC.
And really BASIC was and remains one of the most approachable Languages for Non-Programmers.
Now I'd argue TGC should be focusing on that unique element... by looking closely at improving the Features and Performance., I'd also argue that their Engine Commands should equally match the intuitive nature of said Language.
As people won't be upset at it not being 100% Compatible., if what it's replace with is better, easier and more intuitive to use.
The new "Runtime Variable UI Tweaker" is a nice feature … but if very little is actually changing under the hood, to make it more approachable and sensible., well then it's little more than unnecessary fluff at the expense of time that could be better spent on actual improvements.
I would argue., I'd like to see expansion with Namespaces... Virtualised Functions... Type Output from Functions, and not as merely Input References.
I actually discovered the other day (and this isn't documented in the help, so I'm not sure you're "Supposed" to be able to do this) that I could create Zero Arrays within Types and handle them exactly like a Native Array; meaning <Vector> Lists that can be expanded within Types.
(I'll showcase some code with this in the next few days, as it's pretty versatile and was unexpectedly awesome)
Support for Signed Integers (Dword / UINT32)., and Double Values (Int64) and Quarter Values (Int8)
Finally add True (-1) and False (0) as Default Values... Support Booleans, and Variable Swapping.
Sure, a lot of this can be kind of supported via BASIC Code., but it really should be part of the Core Features.
I'd also like to see all of the String Functions see the addition of $ at the end of their Name., to remove the stupid Keyword Reserve of things like Left and Right.
See... if TGC can provide a Solid Foundational (and Higher Performance) BASIC., with most of it's Functionality being more "Streamlined" … to where the more advanced Functions are provided as Toolkit (.agc / .hpp) files well that just works out better. As the focus shifts more from the Middleware to the Language., after all; we can actually mostly replace the Middleware itself via Plug-Ins; it was one of the useful Elements of Dark BASIC Professional... where you could replace like 95% of the "Build In" Functions / Engine with a 3rd Party Solution; without Sacrificing the BASIC element.
By all means use an SDL Framework and Core., that is then expanded with OpenGL / Vulkan / DirectX / Windows RT … so that we're not handling the Boiler Plate, but beyond that... I'd argue that the Engine should be more of a Toolkit than an Engine per se.
< • >
But eh, those are just my ramblings.