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
