Hi John,
I will reply to you off list, as we are straying away from gaming here.
Cheers.
Damien.
From: john
Sent: Thursday, August 24, 2017 3:29 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] bgt exclude components
Hi Damien,
Well said on all counts.
I'm in about the same position; I'd like to move to something with more
features and support, but BGT does so many of the little things so easily
its difficult to not look for ways around the engine's limitations
(getting
drive information via wmic and batchfiles rather than built-in calls, for
example). I've also been struggling to find anything that compiles down to
executables easily (java's special at best, python files are huge and have
to decompress themselves, C is... C).
Have you had any luck finding a language that can bridge the gap at all?
Best,
John
From: Damien Sykes-Lindley
Sent: Wednesday, August 23, 2017 16:22
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] bgt exclude components
Hi John,
I’m afraid there are no public updates to BGT at the moment. To be honest
until I hear any different I’m treating it more or less as a dying
language.
There has actually been an entire topic on Twitter today regarding the
suitability of BGT, and I’ll say here, albeit more detailed, what I said
there. BGT has its place. But it also has its limits.
BGT is very good for creating 2d-based audiogames while being friendly for
beginners in the process.
BGT is not good for general purpose applications. Its speed isn’t
optimised
for it, neither is its size. Most importantly, its library support is
extremely basic, meaning that in order to use a good 95% of available
libraries with BGT, they would need separate wrapper libraries.
When I first started to learn game programming, I started with VB6. While
that was considered a programming language, it was still very much a
limited
environment. Tutorials were becoming scarce, examples low on the ground,
and
the language itself was dying out thanks to the introduction of the .NET
platforms. Even DirectX needed it’s own VB-compatible DLL, hence the
reason
many users are struggling to play older games on Windows 7, 8, or 10.
Believe it or not, my journey with VB6 came to an unceremonious finality
during the beta testing phase of BGT. From that moment on, anything I
wanted
to do was done using BGT.
So, to clarify. I started with VB6 (a COM/OLE/ActiveX environment),
tinkered
with AutoIt (a UI automation scripting language which also tried its best
to
serve a general-purpose environment but was far too specifically designed
to
do so efficiently), then moved house to BGT (a gaming platform).
As much as some people may class these as programming, to me they are very
much scripting. All sandbox environments, limited functionality, very
specific purposes, and encouraging software development management skills
which are not generally encouraged in general programming.
It’s unfortunate, but a lot of people go through one of two phases: Either
they switch to a general purpose language rather quickly, realise how much
better it is, and come to despise the scripting languages they learned as
introductory tools, or they treat it with unrestrained reverence, use them
forever and a day, and become so reliant on these scripting alternatives
that nothing else matters to them, to the point that they will even
attempt
to push these languages far beyond the boundaries of perhaps even twice
their limits.
I’m not saying that anyone on this list is at one phase or the other.
Personally, I’m stuck sitting on the fence. I realise how much better
general purpose programming languages are, in terms of speed and size
optimisations. But the sheer size and the tasks that are either possible
or
mandatory with these languages I find all too overwhelming, to the point
that sometimes finding libraries and compiling them can be a challenge in
itself, without the extra coding and debugging.
So while I appreciate some of the benefits of many general purpose
languages, I have myself become all too reliant on the sandbox
environment,
having used it for the past 16 years. As a consequence, pointers, handles,
data structures and callbacks on the coding end, and version control,
package managers, bug trackers, unit testing, automated building and
dedicated debuggers on the software engineering end, have only entered my
programming world very recently – a sad situation for any application,
games
included.
So, the upshot. If you know for an absolute 100% certainty that you only
want to concentrate on audiogames, and 2d-based audiogames at that, BGT is
a
good option. However if you feel you also want to branch out into end
product optimisation, 3d-based audio, environmental effects, general
purpose
applications etc, I would give the advice to skip the scripting stage and
go
straight to learning general programming and software engineering
concepts.
As far as I’m concerned, scripting languages are hinkypunks. They lure you
into a false sense of security and then watch heartlessly while you’re
dragged down by the realisation that programming isn’t as simple as
scripting makes it out to be.
Cheers.
Damien.
From: john
Sent: Wednesday, August 23, 2017 7:48 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] bgt exclude components
Hi Damien,
Thanks for such a detailed response, that gives me exactly the info I was
looking for.
Unfortunately it is the base size of BGT I'm looking to reduce (an 850kb
executable is a lot more than needed for 2kb of code).
Do you happen to know if there's any development being done on it at all?
I
remember Philip had said a while ago he had some updates in the works, but
that time to work on them was limited.
Again, thank you for such a clear and helpful response. I can't say how
refreshing it was to get this email, especially since I've been dealing
with
Microsoft support recently.
Best,
John
From: Damien Sykes-Lindley
Sent: Wednesday, August 23, 2017 13:05
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] bgt exclude components
Hi,
Unfortunately this isn’t possible. These components are part of the BGT
engine rather than included scripts. Of course since BGT itself is a
compiled executable, you can’t tell it to reduce its own size. If it were
a
C or C++ library that would be different.
Also, BGT’s version of AngelScript doesn’t do any size optimisation
techniques like removing code that isn’t used. For instance including the
sound_pool library and not using it would still include the sound_pool
code
to your final executable. AngelScript is updated much more regularly than
BGT is, however, so later versions of AngelScript may or may not utilise
these optimisations. This is one of the reasons I don’t use BGT half as
often as I used to.
Literally the only way to optimise BGT executable size, is to use less
code,
and compile in release rather than debug mode.
Cheers.
Damien.
From: john
Sent: Wednesday, August 23, 2017 5:54 PM
To: blind-gamers@groups.io
Subject: [blind-gamers] bgt exclude components
Hi list,
I've recently been trying to find ways to reduce the size of BGT
executables. Specifically, I'm looking to exclude unused sections of the
engine during compiletime; for example, if I'm writing a program to work
entirely offline, then there's no need to include the network subsystem.
Does anybody know if something like this is possible?
I write a lot of small, single-purpose applications that don't need many
features, so it'd be really useful to trim them down to size, per say.
Best,
John
