@46. Well, there are alot of bgt limitations, some more obvious than others, but all valid nevertheless. I won't list all of them here, they are, I believe, all covered in some part of a post from a topic or another anyway. Instead, I'll list the ones I've hit my self or herd about people hitting across bgt's history, as to not clutter this post with too many uselessly spent words.
The most important limitation of them all is the mediocre support for calling dlls. I'd say, if you can't get basic dll things right, then why bother releasing it?
for one, it can't create, pass or in anyway modify what C calls structs. For that thing alone, almost 97% of C interfaces out there would need to first be wrapped in other dlls that manage the structs for the stupid bgt to make sense of them.
for example, let's say you have this declaration in a file called something like capy.h
typedef struct{
float x;
float y;
float z;
double angle;
} rotate_vector_2d;
and you have something like this:
bool do_objects_collide(struct rotate_vector_2d *first, struct rotate_vector_2d *second);
...and so on...
This is a very simple C API, I get it and I get that structs are maybe not the most shini thing in this situation, but bare with me for this example.
Bgt doesn't support creating and managing C stile structs like, for example, autoit, or any other language with dll support does, so, you'd need to create yet another dll to wrap it up. Let's say, now you created a dll that, by whatever means you want, knows how to reference the header file with that other function and struct declaration. In the wrap_capi.c, you'd have something like this:
#include<capi.h>
#include<stdlib.h>
rotate_vector_2d* vector_new(float x, float y, float z, double angle)
{
rotate_vector_2d *vec;
vec->x=x;
vec->y=y;
vec->z=z;
vec ->angle=angle;
return vec;
}
//and because dlls don't know about program scope, we need to implement this as well, I think. Even if not, this is a good approach to follow if the struct is something heavy and memory consuming, like a file, image, socket, physics related things like solid bodies, etc.
bool vector_free(struct rotate_2d_vector *vec)
{
return free(vec);
}
and keep in mind you'd need to do something like this, perhaps minus the freeing function,every...fucking...time...you need to expose structs to bgt. Now, remember I said this trick only works for somewhat simple C API's with relatively flat and simple structs like I've shown you. But now, try to imagine you have something like this:
typedef struct{
float radius;
point center; //assume we defined the point struct earlyer in this file or in some other included file
}circle;

typedef struct{
engine_type type;
int hp;
circle wheels[4];
} car;
imagine trying to wrap that monstrosity, can you do it like I did the previous example? now, really think about that, OK?
now, another thing you might find frustrating about bgt is that it doesn't support passing of function callbacks, again, unlike practically any language with dll capabilities.
To be honest, I'm not going to explain what callbacks are in this post, suffice it to say, this is the only way for native dlls to pass events to their calling application, practically notifying them that something beyond their codespace happened. To better understand this, I'll provide, yet again, a short code example.
typedef void callback_func(void *userdata);//couldn't figure out anything better for a more interesting/illustrative params list, sorry.
void do_something_with_callbacks(callback_func *fnc, void *userdata)
{
while(whatever)
{
if(something_happened)
fnc(userdata);
}
}
well, if you'd need to access a function that requires callbacks like the one above, you'd be stuck in bgt, while with python or almost anything else really, you're not.
At this point, you might ask, why the hell did you need to read through all that, including the C code? well, to be honest again, the C code wasn't really necessary, but I put it in to illustrate what I say with examples, I'm not really good with explanations, so this is as good a way of communicating as any other.
But even the C code, you didn't read pointlessly, everything ties up together in a moment. In fact, those limitations of dll calling in bgt are, practically, for anyone really wanting to use such an outdated technology anyway, the only reason for which bgt didn't evolve any further. Without callbacks and structs, absolutely most of C interfaces are horibly hard to make compatible. Without compatible interfaces, we don't have libs. Without libs, we will never have plugins. And that's the gravest mistake of bgt, nowadays, it's practically a closed sandbox.
All other limitations can be solved, if not elegantly, then at least decently, if those above didn't exist.
the following is a very short and minimalistic list of the most important limitations of bgt, as requested.
no json support, including serialisation and deserialisation
no xml support, including serialisation and deserialisation
can't use rest or sope API's/web services directly from bgt efectively, unless you employ something like php on the server side, to make it compatible
no com support. This is not a very big deal nowadays, but if we're using old and unsupported and whatever technology, at least do it right
no database, either local(sql lite) or server side(sql server) supported. Again, this could have been solved if the dll related limitations didn't exist.
no uwp(universal windows platform). Well, I know I'm exagerating quite much by even thinking it, it's good to at least laugh at the absurdity of the idea. I just thought, if it's windows only anyway, and there is uwp for c++ and, I believe, C API'S exist as well. So, why not be able to publish our pathetic games to the microsoft store for everyone to laugh at them, not only us, but the sighted as well?
OK, I'll stop expanding this post any further, before it gets ridiculous in the absurdity of it all. If you want to know specific game scenarios where those limitations would come in place, just post and I'll come back to you, to smash this bgt forever.
and btw, the name of bgt lover is kind of intentional imho, it's irony at it's most bitter end, So, I'll keep it this way. I just like it as it is.
@47. Understood and noted. yeah, indeed to each dev their own, but your points were actually valid, so I'll try to answer them whenever My clear thinking ability returns. As a sidenote, I'm so tired that I hear my eloquence like it has flanger, a bit of reverb, distortion and corus applied to it all at once, so, I think you can imagine the level. Plus, here, it's actually the middle of the night, so you can imagine even further.