Messages

Why don't you just set up a talking animation for him (specify a talking view in his character pane)? Then AGS will trigger his talk animation whenever he's speaking.

If it's some other kind of animation (blacksmith stops hammering, then talks to you), you have to specify what you're trying to do. Also, you cannot run functions directly from inside dialog scripts. You'd have to use e.g. "run-script 1" and setup a function call within the global "dialog_request" function ("if (xvalue == 1) DoSomething()").

Yes, a Photoshop macro I could probably set up and distribute along with the module. Seems like the best solution would just be to add a "bool UseRGB" parameter to the SetScaleMask(int spriteid) function, so that non-Photoshop users and those wanting to use the in-game editor will have to settle for 64 tones.

Edit: Hmmm, wouldn't the black->blue->cyan->white method only allow for 32 more levels? While it's better than 64 I'm not sure it's worth the hassle. If it was set up to accept mixed colors (e.g. 128 red, 64 blue, 0 green)  we could have a hell of a lot of tones (32*32*32), but to set up this process in a Photoshop macro is becoming quite complicated.

Edit: monkey beat me to it, but I'm posting anyway just for the few snippets that are different.

In your Hotspots events pane (the little lightning bolt in the hotspot editor), there should be an option called "Use Inventory on Hotspot". Click that item and then click the three-dots icon to the right. This should create a new function called function hHotspot3_UseInv() (if it's hotspot 3).

Here you check for the currently selected inventory item, like so:

Code: ags

function hHotspot3_UseInv() {
   if (player.ActiveInventory == iSpear) {
      Display("I found drugs")
      player.AddInventory(iDrugs);
      }
   else Display("No, that's just not long enough to reach.");
}

The function "AddItem" is used for listboxes, not inventory items, by the way.

[.SYM Example PhoneID]

From a quick comparison it seems that Annosoft use pretty much the same phonemes as Pamela. Though whithout the numbers (not sure what they signify, stresses?). Here's their phoneme list from Microsoft SAPI 5.1, which Annosoft uses:

.SYM Example PhoneID
- syllable boundary (hyphen) 1
! Sentence terminator (exclamation mark) 2
& word boundary 3
, Sentence terminator (comma) 4
. Sentence terminator (period) 5
? Sentence terminator (question mark) 6
_ Silence (underscore) 7
1 Primary stress 8
2 Secondary stress 9
aa father 10
ae cat 11
ah cut 12
ao dog 13
aw foul 14
ax ago 15
ay bite 16
b big 17
ch chin 18
d dig 19
dh then 20
eh pet 21
er fur 22
ey ate 23
f fork 24
g gut 25
h help 26
ih fill 27
iy feel 28
jh joy 29
k cut 30
l lid 31
m mat 32
n no 33
ng sing 34
ow go 35
oy toy 36
p put 37
are red 38
s sit 39
sh she 40
t talk 41
th thin 42
uh book 43
uw too 44
v vat 45
w with 46
y yard 47
z zap 48
zh pleasure 49

So conversion shouldn't be necessary, except the few compatibility issues already mentioned - capital letters and the number after the phoneme. If your phoneme list doesn't distinguish between AY0, AY1, AY2 and so on, it should be safe to just add 0 to the phonemes needing a number. I haven't seen the stress values used in any of my Annosoft scripts so far, and I assume they're just not part of the automatic lipsync output - perhaps they're used if you also input a source text?

It should be possible, and it's definitely not a bad idea. But I see no user friendly way to implement it without a plugin or external converter - neither of which I'm able to code. While the concept COULD work for my in-game mask editor by drawing the mask to two separate surfaces (one for the actual mask, one for the grayscale image displayed to the player), the player would still only see the 64 grayscale levels while editing. You could possibly have a toggle key to show the full color image, but I doubt anyone would like to try editing that directly.

An alternate solution could be to fake more grayscale levels in the map editor by drawing some colors as semitransparent pixels (perhaps using a temporary DynamicSprite for the brush). But at the moment the idea makes my head hurt. I'll think about it some more.

I wonder if it would be possible to use the full RGB color spectrum if CJ implemented DrawingSurface.GetPixelRed, GetPixelBlue and GetPixelGreen values, or whether they still would be locked to the 16-bit range?

I just read his "Four fat bitches" rant - this guy really needs to get back on whatever medication he ought to be taking.

If there is a limit (which I have yet to encounter or hear of), it's more than 10.000. 150 lines is absolutely nothing in terms of script length. Most likely your problem is to be found in the script itself, not in its length. There is however a limit to how much memory can be assigned to variables within a function, but if this happens AGS will give you an error message. It shouldn't be a problem though unless you're declaring huge structs or arrays within a function (as a workaround they can be declared globally and called from inside the function).

I think AGS can get by without the "Preferences" section in the .pam file, but Pamela needs it to locate the directory of .wav file.  Maybe the directory could be written to the .pam file based on where you opened the .wav file from.

If you add phoneme editing to the plugin, it would make sense to read the .wav (or, hopefully, .mp3 or .ogg) directly from the speech folder. Especially as people tend to move their files around when upgrading to a new AGS version. But for those wanting to use that god-awful Pamela tool, legacy support is a good idea.

How did you come up with that phoneme list? Trial and error? It seems to differ just slightly from the Preston Blair mouth shapes (see here for original, here for an alternate version, and here for 3D version). I think it's definitely important to set up a good default scheme, since that's what a lot of people will end up using. Perhaps even with a default animation to model your own artwork on and to test lipsyncing for characters who don't yet have speech animations. Would it make sense to have two default phoneme setups, simple phonemes (for pixel art) and extended phonemes (for hi-res or pre-rendered art)?

DISCLAIMER: This is NOT a finished module, merely a proof-of-concept. It is not suitable for public consumption.

I talked to indie_boy in the AGS Stickam room, and he was having some problems with creating a smooth scaling effect using walkable areas. So I decided to whip up an alpha version of my LightMap module so he could see if the module's scaling-map function would be useful for him.

Basically it allows you to use bitmaps (stored as sprites) to specify character scaling and character tint. The color map tints the character the color of the pixel he's standing on in an RGB image. The scaling map scales him depending on a grayscale bitmap where pure black is 5%, 50% gray is 100% and pure white is 200%.

The map dimensions are in 320x240 coordinates. So for hi-res games the mask can maximum be half the background's resolution (there would be no point in having it larger since character coordinates are in 320x240 scale. At the moment, sprites that are too large will crash the game). However, you CAN use LOWER resolutions for the map to save disk space. The only rule is that it's dimensions must be proportional to your game resolution, so for an 800x600 game, the mask could be 400x300, 200x150 or even 100x75 - but the latter would only be recommended for very basic lighting.

Since the AGS color system only supports 64 different gray-scales, I had to add some tweaks to allow for the full 5-200% scaling range (previously the scaling jumped 6 points at a time). The module currently interpolates the scale from three (x,y) sets - the one from the previous frame, the current one and an estimation of the characters next position. It does create a bit of wobblyness when moving in-and-out of standing positions, so I'm trying to come up with alternate solutions.

The module is at the moment totally undocumented and does not confirm to AGS module guidelines. The only two functions available are:

LightMap.SetLightMap(int spriteid);
and
LightMap.SetScaleMap(int spriteid);

Typically you'll want to run these in on_event for eEventEnterRoomBeforeFadein, but to change a light-/scale-map during gameplay just call it again with a different sprite number. I haven't yet set up animation support but plan on it (so the player specifies a View instead of a sprite). You can also input 0 as spriteid and any light/-scale maps will be unloaded. The characters will be stuck with their current scale/color though.

*FILE LINK REMOVED DUE TO 2DADVENTURE SERVER PROBLEMS*

Edit: I should add that it's a good idea to paint your light/scale maps slightly larger than the walkable areas. Otherwise you míght see strange effects when moving near the edges.

Yes. Probably by converting them back to wav...

Yeah, you could just decode them to a temporary file, use it as a source for Annosoft and then delete it. Since your AudioManager already supports .mp3 and .ogg playback, the lack of a wav wouldn't be an issue in your own phoneme editor.

I definitely want to add an editor for .pam files which also shows a preview of the speech animation.

That would be absolutely awesome! Especially with Pamela being so buggy, only working with .wav files and having a far from smooth preview playback. Being able to import, automatically lipsync and then tweak the lipsync animation, all within the editor would make the process so much smoother.

This whole thing has completely changed my view on adding speech to my game. Now it's beginning to seem manageable, despite the huge job of recording and processing the voice clips.

Ah yes, if the script was generated on-the-fly with AGS file commands, then the alternate language Strings could be retrieved directly from the translation file itself.

This certainly can be done, all you have to do is make an avisynth script with text commands (the subtitles) and fire it up in AGS with PlayVideo. Since avisynth scripts are text files, you can even generate them on the fly, prior to calling PlayVideo.

If it was possible to parse the name of the AGS translation file to Avisynth, would Avisynth scripts be able to display language-specific subtitles? 

Instead of just playing videos full-screen, Avisynth could be used to play video 'inside' the game screen, if only you take a snapshot of the screen prior to playing the video, then 'composite' the video inside the snapshot using the Avisynth scripting language.

But pressumedly this wouldn't work during gameplay? You could just have static screens while the video plays? E.g. the player character sits down and turns on the tv. The video plays. He gets up and you resume gameplay.

Nevetheless, it's an interesting technology. And whether it's Avisynth or Ogg Theora, I'd be happy to see an AGS video format not dependent on installed codecs.

Looks great so far. And I love the floor tiles too. As S said, experiment with the rest of the colors. Use different layers for each material and then play around with the hue/saturation after basic coloring to find a color scheme that you like.

Excellent! Do you plan to add .ogg and .mp3 support? It would definitely be great to be able to batch process speech files from the Audio Manager menu.

I guess this means that I can cancel my, ahem, aquiring of the 3GB+ Visual Studio

Goldmund!!! My favorite lost AGS forum member! Is this a one-night-only appearance, or should we expect to have you back regularly on the forums? Anyhow, great to see you again! (I would ask how you were doing and about the status of Donna, but I think this is off-topic enough already).

Thanks for the code, CJ! It's nice to know exactly which parts of the file AGS interprets and which it ignores. It's a bit ironic that AGS internally interprets the data to a format much closer to Annosoft's (in milliseconds and with end timings). For a moment the timing calculation confused me, but it all adds up to 0.360 as I had discovered (dividing a number by (1000/15)/24=2.777777 is the same as multiplying it by 0.36). That is only true if the fps setting hasn't been changed in Pamela, but with AGS using hardcoded values it's not a problem.

Regarding my attempts with the source code, it turns out that the source depends on Microsoft's ATL classes which are not included with the free Visual C++ Express. Is there anyone out there with the full Visual C++/Visual Studio version who would like to give it a try?

I don't think compiling the pamela source code would be particularly useful for this -- all you'd need to do would be to write a separate application that could convert output files from Annosoft into .PAM files that AGS can read.

Ah, no I meant for compiling the modified Annosoft code. I'm not touching the Pamela source at all, only using it for reference.

You will not gain any image quality by scaling up an image. As Nacho and Becky have noted it's impossible to recreate "lost" pixel data, and most times you will just end up with a blurry, larger version of the image.

However, if you absolutely need to use an higher resolution image (for example for print) and only have a lo-res source file, there are interpolation methods which can sharpen the final image to create the illusion of more pixel data. The commercial products GenuineFractals and Alienskin Blowup claim to do this much better than Photoshop's built-in resizing and sharpening functions. But their example images should definitely be taken with a grain of salt.

Also, 250x187 is a tiny format. Depending on the motive of course, but I doubt you can retrieve enough pixels for proper interpolation.

Thanks for your input, AGD2. Great to hear from someone experienced with lipsyncing!

Of course an automated process will never be as accurate as manual lipsyncing. But considering the time saved, I'm quite happy with my tests so far. Even low quality samples (a low-bitrate clip sampled from an old VHS tape and voice recorded with a cheap headset) seemed to process quite well. As you say, it's always possible to tweak the file in Pamela, and it probably will be necessary for non-vocal sounds such as a character coughing.

Your phoneme list will also be very useful. I just have to figure out whether it makes most sense to force simplified phonemes during file format conversion or just let the developer set it up himself within AGS. I guess the latter solution would be more flexible, though you're right that the total amount of phonemes output by Annosoft's code is overkill for non-3D games.

Regarding my attempts with the source code, it turns out that the source depends on Microsoft's ATL classes which are not included with the free Visual C++ Express. Is there anyone out there with the full Visual C++/Visual Studio version who would like to give it a try?

Did you actually put the code inside the function on_mouse_click(MouseButton button)?