I would also be interested in knowing if there is a good briding language away from BGT. BGT is working for our purposes at the moment, but thinking/planning ahead, I can see where BGT will start to fail us.
On 8/25/17, Damien Sykes-Lindley <dam...@dcpendleton.plus.com> wrote: > 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 > -- Justin M. Jones, M.A. atreides...@gmail.com (254) 624-9155 701 Ewing St. #509-C, Ft. Wayne IN, 46802 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117667): https://groups.io/g/blind-gamers/message/117667 View All Messages In Topic (9): https://groups.io/g/blind-gamers/topic/5867914 Mute This Topic: https://groups.io/mt/5867914/21656 New Topic: https://groups.io/g/blind-gamers/post Change Your Subscription: https://groups.io/g/blind-gamers/editsub/21656 Group Home: https://groups.io/g/blind-gamers Contact Group Owner: blind-gamers+ow...@groups.io Terms of Service: https://groups.io/static/tos Unsubscribe: https://groups.io/g/blind-gamers/leave/607459/1071380848/xyzzy -=-=-=-=-=-=-=-=-=-=-=-
