On Feb 19, 2018, at 11:28 AM, john <[email protected]> wrote:
Our other hope is that an update to BGT comes out.
We know (because of VG storm) that some work has been done on it. Maybe
we'll get lucky.
--------------------------------------------------
From: "Damien Garwood" <[email protected]>
Sent: Monday, February 19, 2018 10:59
To: <[email protected]>
Subject: Re: [blind-gamers] accessible game engine
Hi,
Oh, I thought you meant have BGT as a library. If you're talking about
building a whole new library from scratch, obviously that would take a lot
of time, effort, and advanced programming expertise. Given that I've made
a
resolution to try to switch to C++ and I can't even do a basic timer
yet...Let's just say that I'm currently feeling way beyond my depths when
it
comes to managing memory and threads, so I'm a complete alien when it
comes
to writing audio engines and looking for pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you
think, since JavaScripts does a lot of the deep memory process for you to
start with. There also seems to be a few different JS dialects, like
Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming languages
than BGT, either because of work or programming classes etc, will more or
less know everything they need to to learn any language and get along well
with it.
Considering I spent the better part of five years parroting from VB6 and
AutoIt code to get something workable without actually understanding
anything, then actually being able to understand BGT to such a point that
I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can write
a
library that can do that for me. Hello multithreading, streams and
buffers,
dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons.
Run
blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh, and
we're not going to tell you how to do this in Windows because we're Unix
geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all its
resources in one application and could compile in a similar manner,
including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and
writing a C++ wrapper, there is no chance of porting my literally dozens
of
BGT modules straight over to C++ and have it work. That would just be too
much to ask.
So. Looks like I have a twenty year headache sentence ahead of me while I
learn, or at least attempt to learn, as much technical crap as I can
possibly retain in what I currently feel is a rather small and inadequate
brain, and then try to somehow port this mess over.
Cheers.
Damien.
-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: [email protected]
Subject: Re: [blind-gamers] accessible game engine
No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project for
a team of programmers totaling more than one. Best not put a team like
that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.
On Mon, 19 Feb 2018, Damien Garwood wrote:
Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [blind-gamers] accessible game engine
Hi,
Even if that were the case, it would still have its audio limitations,
HTTPS crashes and UDP-only networking. So we would still end up having to
ransack the internet just to find something decent. But yeah. I could
certainly use the pathfinder, calendar, timer, tone synth, input-related
functions etc as a library. That would be neat indeed. I mean,
programmers
often stress the brilliance of code reuse, right?
Cheers.
Damien.
From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: [email protected]
Subject: Re: [blind-gamers] accessible game engine
The BGT argument is one I have scene a few times on this list now. It
seams what we need then is all the functions of BGT wrapped up in a nice
platform independent library. It could be written in something like
portable C, with all the platform dependent stuff in platform specific
modules, and bindings for different languages generated with Swig or
something. Swig is quite good at generating bindings for many programming
languages.
Note: I'm not volunteering to write it, just want to get the debate
going.
Thoughts?
Rynhardt
On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<[email protected]> wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn?t indicative of real world programming. Once you realise BGT?s
limitations and want to move away from it, it?s much harder to do so
because you end up relying on it. Especially if you?re a programming
newbie and don?t have a clue how to write audio engines, let alone audio
engines that can play multiple file types, whether packed or on disk,
whether encrypted or open. Not to mention keyboard, mouse, joystick
support, screenreader and SAPI support, timers, pathfinders, combination
generators and calendars. The way I see it, scripting with something like
BGT is like having an overprotective clingy parent that just won?t let
go,
whereas programming something like C++ or Python wants you to bend down
and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.
From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: [email protected]
Subject: Re: [blind-gamers] accessible game engine
You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.
--
