Hi all,

Thank you for the large number of suggestions! I'll respond to you all below in 
one big message, as to avoid cluttering up the list.

Thomas. If I added force feedback I think it would actually be advantageous for 
me to do everything through code, as the goal of BGT is to wrap everything for 
the end users without requiring use of the underlying facilities. I'll 
definitely look into it.

Kai. I have looked into XInput, but it does not support neither keyboards nor 
mouse devices which makes it rather unatractive for me. The only reason then to 
use it would be for extended joystick and game pad support which is certainly 
an option, but not something I'm sure about just yet. As for Midi support, I 
don't think this will happen. In order to provide a soundtrack that sounds the 
same for everyone, one would need to use some sort of instrument bank such as a 
soundfont or similar to play the music, which would require me to write an 
entire sound font player. This is not something that I'm very keen on doing at 
the moment. And as regards to reverse engineering, I'm doing as much as I can 
to avoid it (e.g. applying layers of encryption, not encrypting the actual 
script but rather the AngelScript byte code, including verification checks etc) 
but as with any software, it is not impossible. You can reverse engineer any 
program if you are determined enough, and BGT is no exception. Having said 
that, however, it certainly isn't easy. Lastly, Anti cheating is certainly 
possible in BGT. Right now there are only hash functions, but I can add a crc32 
function as well if there's an interest in that.

Allen. Multithreading would indeed be nice, but let's take a look at some of 
the practicalities there. Let us assume that you have two loops running in two 
separate threads, and they both modify the same global variable. You have no 
way of knowing what value the variable may or may not have, at any given time. 
To prevent this, we would need something similar to a critical section or a 
mutex to lock access to some resource during a short amount of time while a 
thread accesses or modifies it. Here we are getting into quite advanced 
concepts of programming (e.g. thread synchronization), which is way beyond the 
simplisity goals of BGT. Co-routines is one option that I am considering, 

Hayden. The idea with the helper layer is that it is meant to be open source, 
so that users can go in and modify the includes to their liking. Something like 
the sound pool or the dynamic menu class are perfect examples where the 
functionality is necessary, but not really as part of the engine's foundation. 
This way, you are able to choose which of these components that you wish to 
include in your game rather than having them forced upon you. The engine 
implements all the low level control such as the sound and timer classes, and 
then it is up to the script writer to make use of these as I have done in these 
wrapper modules. In other words, the helper layer is meant to let you pick and 
choose which bits and pieces you do and do not want, which you can't do with 
the core functionality.

Ryan. Loading dll's would indeed be very useful, but the main issue is that 
AngelScript currently does not support variable parameter function calls or 
optional parameters to functions. I could do something in the preprocessor 
stage like VB 6 does, where you specify the name of the function that you want 
to import as well as the dll filename but this still leaves me with the problem 
of turning the AngelScript classes into structs when these are passed as 
parameters, for instance. In short, this is probably possible somehow but would 
require a huge amount of time. I'll keep it in mind though, and if a lot of 
people want it it will make its way into the engine eventually, as will COM 

Bryan. I have an idea about what might be happening regarding your Sapi issues. 
In the dynamic menu class, if you do not specify a specific tts_voice object 
that you wish to use, a temporary one will be created for you behind the scenes 
if you are using tts options. The problem as I see it, is that NeoSpeech may 
not allow multiple instances of its engine to be run simultaneously and so the 
menu does not work. The solution is to always call the set_tts_object method in 
the class before calling any of the run methods, so that it uses your existing 
tts_voice object instance for its output.

Kind regards,

Philip Bennefall
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to