Hi Paul, While it is possible to implement 3d functionality into the soundpool, there’s a huge limit to what you can do with 2d audio. We’re already having to shift pitch to represent the difference between in front and behind, the last thing you really want to do is to use the same technique to represent above versus below. Also, the BGT pathfinder only works on a 2d grid, presumably for this reason along with memory considerations, meaning that 3D AI is impossible unless the pathfinder is completely rewritten as a BGT script, again adding an unnecessary layer of abstraction. Cheers. Damien.
From: Paul Lemm Sent: Friday, August 25, 2017 5:52 PM To: [email protected] Subject: Re: [blind-gamers] bgt exclude components Hi Damien , So I’ve only ever coded/scripted using BGT and not used an actual programing language for coding , but in your email you mention that BGT is only good for 2D audio games, although I completely understand the BGT includes for things like the sound pool are only based on 2D audio games, since BGT supports 3 dimensional arrays there is nothing that stops people writing their own sound pool class which could support the third axis point which allows people to create 3d maps using BGT if they wish. All the above being said I still fully agree with you though that working with a full on programming language will always give you more control than working with a scripting language. Paul From: [email protected] [mailto:[email protected]] On Behalf Of Damien Sykes-Lindley Sent: 23 August 2017 21:22 To: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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
