-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nolan,
Wow, there's a lot in here. I'll tackle as much as makes sense for me. On 23 Mar 2006 at 19:05, Nolan Darilek spoke, thus: [...] > My laptop and desktop are OS X-based, so I nearly have AQ running > nicely on Tiger. Yesterday I managed to build ZQuake under OS X, a > confusing process as the code needed to be compiled with gcc but > linked with g++, necessitating changes to the Makefile mid-compile. > Today I ported ag_say to the Carbon speech API, so AQ is now self- > voicing. Tomorrow's goal is to write launcher scripts that create AQ > directories in the standard OS X preferences location, then search for > either the shareware/full Quake datafiles in the application- specific > libraries folder, making the structures if they don't exist and popping up > semi-helpful dialogs. The eventual goal is a self- contained drag-n-drop > AudioQuake.app bundle for OS X. But I have some questions along the way. Great work all round! > I'm not a Windows coder. I'm trying to keep the ag_say code as > portable as possible, so I've refactored the code to place all the > API-specific checks into separate functions that are different based on > conditional compilation. What's a WCHAR, though, and is it interchangeable > with char *? It'd be much cleaner if the code could standardize on char*, > and I think it'd allow for the possibility of hooking into more speech > APIs more cleanly. Anyway, what I'll probably do is fire off my version of > ag_say.cpp and let someone who is more familiar with Windows coding clean > up my refactoring, as I'm a bit out of my league with the Windows aspect. Well, that's really supposed to be me. :-) If there's a chance this'll work, we might as well investigate the possibilities. So yep, please send it along. Matthew wrote ag_say.cpp, which in turn is based on an example in the SAPI 5 SDK. I have a C version that doesn't link, because I for some reason cannot use the clean C interface to COM, but it was supposed to enumerate all SAPI synths and use a textfile to configure which version and ID to use. The idea there, though, was to dedicate the filter to the one interface and let the user choose the filter based on the platform by editing the launcher script. I also do not know (or want to know!!!) C++, so if you can constrain yourself to C for a portable program it'd be nice. A wchar_t is a wide character, and it is indeed a standard type. Alas, it cannot be made to interchange with char directly (there are portable conversion routines provided by most C libraries though, because they're all standardised by ISO). I have often wondered whether, as part of further cutting down on low- level components, we could use scripted interfaces seemlessly to get at these OS speech services. Tcl, for example, provides seemless character mapping and commands for COM. Perhaps a common Tcl script which encompasses variations on both Windows and OS X for software speech synthesis services? Alternatively, an additional perl script could be invoked to do the job, if the launcher does not do it itself (and in the name of modular design, it probably shouldn't). SAPI is something of a bad apple, and it's very noticeable when you get users telling you that their SAPI 4 installed engines will not be found by AQ, because of course SAPI 5 is an entirely different animal. Hence, other mechanisms for accessing large amounts of speech synthesiser variations are sought, and are generally not found, are not documented properly, are not sufficiently industry standardised or have grievous requirements (Window-Eyes, for example, must be fully running to get the benefits of speech output, and we all know what happens when AT collides with heavy video rendering...). Indeed, our support of SAPI can be attributed to a miracle of patient suffering. To summarise: yes, let's have your code, but for now you are probably best off writing clean code for your own purposes and supplying it as an additional filter module. Maybe one day I'll return to writing for Microsoft's yucky interfaces or others ... but I doubt it, and you're code will probably be cleaner and easier to read without the extra baggage. Furthermore, you can probably rely on scripting languages or packages already installed on the target system, and should fully exploit them. How about the say binary on OS X? > I notice that the code includes a means of popping up a voice > configuration window. How is this done from the game? I should be > able to do so with the OS X version, but if there isn't an in-game > function to do so then it'd make more sense to just require the user to > make the changes from the system preferences menu. There's no per-program configuration feature, and no dialogs pop up. The defaults are set by the user from Control Panel and are used out of the box by the SAPI routines. > I had some thoughts about the game sounds. I'm not a huge fan of the > tonal sounds, and had some thoughts on how they might be changed. The > bang noise that is played when menus are accessed and F10 is pressed > always reminded me of a door. Perhaps this could be used as the door > noise. It'd also have the advantage of fitting in with the other audio > icons for health, armor, ammo, etc. as the sound would reflect what it > represents. Hmm... That's more of a coincidence, I think. That sound is part of Quake and intended for the menus. Not sure how I feel about reusing it for something else, but it's an interesting idea nevertheless. Other door sounds might be considered, but they are all action sounds you already hear when you move through or manipulate the doors. If you have your own sounds, of course, they'd be most welcome. > Is there any means of detecting whether a slope is moving up or down? If > so, perhaps up and down slopes could be represented by the same sound made > by the player moving up or down, only shifted down an octave. Not only > would this convey more information about what is being scanned, but it'd > be more instantly recognizable as a slope than would a low E tone. :) Sorry, I lost you somewhere along the way. Do you mean that you want to identify slopes that move up or down, or when slopes slope upward or downward in the player's perspective view? If the latter is true, we already have sounds indicating when the player moves along an upward or downward slope - that's Z-motion and is the bweeping that rises or falls according to the direction travelled. I can't see any use for knowing in advance what direction a slope travels, but is this what you mean? > Can the wall scrape sound be made less loud? It seems to distract me > quite a bit. Does anyone actually find the continuous wall warning > sound useful? I've had that feature turned off, and use a combination > of the "l" function and the fact that I don't hear footsteps when I try > moving to know that I'm up against a wall. This has the advantage of > using the continuous wall warning noise as the scrape sound, which is > far less distracting IMHO. My strategy is to turn off wall warning on sides. You want some sort of gauge for distance to wall - if indeed a wall is present - because otherwise you could well end up, say, tossing grenades which immediately deflect upon you. Maybe turning off the contact sound in conjunction with the wall sound, and in accordance with the side/front toggles, would alleviate the situation in those cases where the player is happy just to use footsteps, because then at least the most obvious player mistakes like that grenade example can be noted well in advance while the majority of space-facing navigation doesn't suffer. What do you think? The scrape is only heard when you actually scrape, so is it that following walls is your mode of navigation or do you typically walk at non-rightangles? Perhaps an actual scrape toggle is needed... > Actually, does anyone turn footsteps off? If not, might it make sense > to remove that ability entirely and always have them on? Seems like it > might decomplicate the interface a bit, and you can offer a bit more in > the way of implicit accessibility if footsteps are an explicit feature. The time when they had to be a choice was when we didn't have great sounds for them. Then, I always had them off; now, I always have them on. On the other hand, there are interesting relationships between the footsteps, wall touch notification and wall warnings. We'll have to think about it again and see if it needs changing, with input from others. Right now, though, we are trying to keep the overall number of significant changes down to a minimum, and we've already declined a similar proposal for gameplay reasons (the suggestion was footsteps notifying players of advancing enemies, and it was eventually ruled out by the fact that this technically didn't constitute part of the game). So maybe there are players out there who really do not want footsteps and want to play it like it is. > I also had some documentation questions while browsing through the > manual. When jumping, how do the existing systems let you know when > you are at the edge of a gap? The manual tells you to move up to the edge, > and there are ESR modes that let you know when you're near, but nothing > that indicates that the next step will be your last, so to speak. There are no special signals for this case, although I don't see why (but this is Matthew's ground) one shouldn't be added if it isn't difficult. The current scheme means you have to guess based on passed experience. Usually, this means you will always perform a running jump and clear the gaping void while in the air. > Section 6.2.1.1 says to use "t" to toggle continuous wall warnings. > Section 7.3 says to use "t" to toggle monster detection. The latter > seems to override the former, and there seems to be no way to toggle > continuous wall detection. Am I missing something, or is this a mistake? There is a mistake, as you've indicated. The latter meaning of t is the correct one. W is the continuous wall warning key. > 6.2.4 should probably clarify the difference between the initial > corner sound and the final one indicating that you've passed the > corner. I know that confused me for a while, and I thought that I was > being shot at. :) Doc. > 7.2 suggests, as a tip, using "k" to see if you can make a jump. > Shouldn't this be "j"? Doc. Do you see a pattern here? :-) > Is any discussion given about how to shoot monsters? Should they be > on the same level to shoot them? Right, this one needs to be explained. Basically, and this isn't ultimately decided yet, but we are considering making the ESR auto-aim vertically. We've essentially had to hijack the player's vertical POV to prevent the accessibility going wonky, and in single-player and in certain speedy botmatches this means we are getting shots from so far away or on a different level from the player giving the player cause to search for an enemy which, though technically possible to shoot at, isn't immediately detectable by the ESR (or if it is, the audio level of the signal is no longer audible). That is to say, the ESR doesn't account for the actual range of fire possible by any given weapon, it just makes a tracebox from you to the target and doesn't get into more detailed possibilities (like dropped grenades from overhead, for example). Equally, we're thinking that a vertical auto-aim may very well compensate for the lack of functionality enjoyed by sighted players, like rocket jumps. The manual correctly explains how the ESR is used, but the implementation wants review for all possible corner cases. In many, many instances it is right and all those years perfecting it have paid off, but if you do get into one of these unfortunate situations you'll probably not come off too well. Hopefully we'll get this drilled down proper before the next release. > Can we have more explanation about how to jump obstacles using ESR > mode 2? I'm stuck on how, exactly, to pass the 7th (at least I think > that's which it is :) tutorial map, with the jump around the corner. Keep trying. If you're really stuck, please fill out the enclosed registration form and send it to us with your registration fee of $5000.00 (plus P&P) and we'll send you a complete hints pack and feelies collection. :-) Or you could let us know if you're still stuck. > And, just out of curiosity, has anyone had much success with playing > the standard e1 maps in single-player mode? I'm struggling with them, > and am wondering if the "normal" maps are just too complex for non- > sighted players? Or am I just too new? Once again, they really want practice. E1m1 isn't so hard when you get used to a thousand deaths - just keep at it. Of course, the AGRIP maps which are devoid of roughness and architecture are easier to navigate, but it's reassuring to know that the standard maps are possible to tackle if you seek long enough. I suppose this explains why the AGRIP maps are so frequently used for deathmatches, but there's obviously a few other workable maps out there that people have found pleasant. I'm sure we can do something with these in future developments of audio and so on. Another possible aspect to the problem is the prototypical nature of AQ - some more tricky bits, like water navigation, have a fairly barebones audio user feedback. If you've ever fallen into the water under the bridge on the first map, perhaps you've seen this. But yes, believe it or not, it's actually possible to get out with only what you've got. > Also, I've noticed a file in the demos folder. How do I play this, > and is it possible to start this demo after start-up if it's AQ- > specific? If so then I may configure the OS X application to do so in > order to give the user a more immediate taste of how AQ sounds. The demo is old and not a very good demonstration. Nevertheless, use the playdemo command to "Watch" it. Thanks for your continued comments and work; hope these answers have helped. Cheers, Sabahattin - -- Sabahattin Gucukoglu <[EMAIL PROTECTED]> Sound, QA, Misc. Development, AGRIP Project http://agrip.org.uk/ Voice: +44 20 88008915 or +44 7986 053399 -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 -- QDPGP 2.70 iQA/AwUBRE+YUiNEOmEWtR2TEQJ6xACfUg6ODSGg0wMMIxa7S1Kd2TwkAggAn3UU xeZ0KJ5JPKEonI/ecVlnMt9p =KKTf -----END PGP SIGNATURE----- _______________________________________________ AGRIP-discuss mailing list [email protected] http://lists.agrip.org.uk/cgi-bin/mailman/listinfo/agrip-discuss
