You'll get no argument from me. I for one agree with you on all
points, and that is why I don't use Java for any of my games.
Especially, for the Genesis Engine. The accessibility of Java
applications is too inconsistent between screen readers and different
platforms to make it a reliable option for an accessible game
developer such as you and I.
I chose C++ for many of the same reasons you did. First, reliable
access to DirectX, SAPI, screen readers, and anything else I want to
use in my games. Second, direct support of the Windows API and GUI
components that offers reliable accessibility for message boxes,
registration dialogs, and any other text I want to present on screen
to the end user. As you said the Java Access Bridge is no longer being
maintained now that Oricle has taken over Sun, and we don't really
know where Oricle is heading with Java accessibility currently. The
only way to avoid the issue with Java accessibility is to drop Swing
and use APIs like SWT, and JFace but that doesn't resolve everything
Plus as others have mentioned AWT Events are to slow for reliable
keyboard/mouse support in games, and javax.sound.sampled leaves a lot
to be desired. I just felt rather than use Joal for OpenAL support or
JInput for input support etc I would be better off with DirectX or
using OpenAL directly rather than through a Java wrapper.
On 12/2/11, QuentinC <quent...@cfardel.net> wrote:
> Hi Thomas,
> You are going to a central point here. As you know, I'm still a big java
> fan, I wrote past games in java, and upcoming games outside of the
> playroom will very likely to be in java again. Why I haven't written the
> playroom in java ? There is two reasons for this:
> 1. You might have experienced the problem I had with magic blocks most
> notablyy: speech via screen reader support was totally absent. I tried
> to arrange something myself using COM and DLL proxy libraries and failed
> to make something really reliable. All screen reader supports including
> SAPI were quite buggy and it mades the application to crash randomly,
> especially on 64 bit machines but also on 32 bit ones.
> As reliable speech output via screen reader is a very capital point in
> the playroom, I had first to find a solution for that problem before
> going further, and nothing came to mind at that time.
> 2. The playroom is a little different to most of audiogames we have out
> there. It uses true windows GUI components, when most audiogames simply
> open a blank window and directly react to user input from there. Most
> audiogames actually use virtual menus and controls that are not shown on
> screen at all. Why this choice ? Again, there are multiple reasons:
> a. Initially the playroom was in french only. At the very beginning, I
> received comments telling that it would be good to be able to play with
> braille display. As you know, direct speech output to screen reader does
> not use braille, and the easiest way to have all so different braille
> displays behaving correctly is to place text into standard controls so
> that the screen reader does the job nicely in the way the user usually
> set in his preferences.
> b. I found also nice to be able to navigate through the game's text
> freely, to allow easy review, easy copy/paste, easy saving, and as easy
> to use as in normal applications. In fact this feature is quite rare,
> even on mud clients (where it's indeed a must-have in my opinion). I
> suffered not having easy review and copy/paste on mud clients I had, and
> I'm still suffering not having this feature on console windows and
> SSH... In playroom this is important because there's a lot of text to
> deal with, just like in a mud.
> c. Using normal GUI components has a nice edge effect: it allows sighted
> people to play. Of course, the playroom is not as interesting for
> sighted people as other common games because there's no graphics, but
> still, I know that there are a couple of sighted players in the
> playroom, they wouldn't be able to play if I had used virtual menus and
> controls in a blank window.
> To come back to java, standard GUI controls in java with a screen reader
> remain problematic: they are slow, sluggich and somewhat buggy. The bugs
> there are are very stupid indeed: before very latest jaws 13, backspace
> in an edit field says empty instead of the character being cleared, and
> NVDA sometimes says empty instead of reading a line of text in a edit
> field. For all screen readers, when you press up or down arrow sometimes
> it reads the old line instead of the one where you just arrived. Some
> less common screen readers don't support access bridge at all, etc. and
> don't forget the most important thing: java access bridge is no more
> actively maintained. In brief, all that is not very reliable, is not
> going to be more in the future, and this is not acceptable. You will
> tell me that there is scripting: yes, certainly. But if scripting is a
> working partial solution for experienced computer users, installing
> scripts is another problem on itself and especially if you aim to
> support multiple screen readers.. clearly not doable for less
> experienced computer users. And because the playroom is conceptually a
> simple game, it must be manageable by less experienced computer users as
> This closes my probably longest english post.
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> 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.
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.