Messages

All right, confirmed that that's fixed now. Just came across another little quirk which seems to affect room objects only.

Select any room object by clicking on it (so the yellow border appears around its edges). Normally, you can use the arrow keys to nudge the object 1 pixel at a time in any direction. However, only the left and up arrows seem to work now. Attempting to nudge down or right doesn't do anything.

Sorry, AGA. Didn't notice your post earlier. And yes, that did the trick. Thanks.

I just found a new bug in beta 10 with the editor.

If you click on a room object, and then edit its x or y values, the object's position will not move. It still moves if you click and drag it or select it and nudge it with the arrow keys, though.

The above also applies to the characters section in rooms.

--EDIT--

I just tried to change an inventory item's sprite by typing a new number into its "Image" text field, and it also didn't update. It only showed a new image if I manually selected one from the Sprite Manager. It seems that anything you type into these fields (regardless of what the field is) isn't being properly updated.

Yes, though the effect looks more pronounced on a low-res 320x200/320x240 background than it does on a 640x400/640x480 background.

[imgzoom]http://www.himalayastudios.com/scratch/hi-res_scaling.jpg[/imgzoom]

The issue only becomes visible when the character sprites are scaled down. As soon as pixel art gets scaled smaller at the native resolution, the pixels begin to lose symmetry and the artwork becomes horribly jagged and blocky. So it comes down to a decision between blocky sprites or hi-res ones. In my view, the hi-res ones look much better in regards to keeping the pixel artwork intact.

The only other ways around this are to avoid scaling down the characters completely or to make batches of character animations that are optimized for various pre-set sizes. But I'm afraid that these two approaches aren't feasible (not for a game this size anyway). Of course, players can change the filter setting to "none", and the game will still play. They just won't see the optimal, intended result.

Just make the game in the resolution you want the sprites to be. If you absolutely must have this awful effect, you can scale up the backgrounds from a lower resolution before importing them.

The game has over 70 rooms at 640x400 resolution. scaling up the backgrounds to 1280x800 would increase the filesize dramatically. Why do that when a simple setting to achieve the same effect will suffice?

There's a graphical glitch with the Nearest Neighbor filter: it is not applied to characters. If using (e.g.) the 4x NN filter, then each pixel in the game is displayed as a 4x4 block of pixels on the screen. However, characters if zoomed use the full resolution, not 4x4 blocks. It appears the graphical operations are performed in the wrong order: the character is enlarged to 400% first, then reduced from there to account for scaling; whereas it should be the other way around; this discrepancy simply looks odd, as if the characters use a higher resolution than the backgrounds. I haven't checked, but this likely also applies to objects.

Some games use this 'feature' in conjunction with a NN filter as a way to display higher resolution characters while keeping the game backgrounds at 640x400 (we used this trick in both Al Emmo and Mage's Initiation). Disabling it would destroy the pixel artwork in the latter game. So, if this is going to be 'fixed', it would be necessary to make it an optional setting for any games that rely on the current behaviour.

Just got this one when I used CTRL+F5 to test the game, and clicked away from AGS to another window while it was compiling (I use a dual monitor setup). I've never seen this happen before, but it seemed to interrupt the compile process somehow, and then returned to the editor with this crash:

Error: The operation was canceled by the user
Version: AGS 3.3.0.1146

System.Exception: The operation was canceled by the user ---> System.ComponentModel.Win32Exception: The operation was canceled by the user
   at AGS.Editor.Tasks.RunEXEFile(String exeName, String parameter, Boolean raiseEventOnExit)
   at AGS.Editor.Tasks.TestGame(Boolean withDebugger)
   at AGS.Editor.InteractiveTasks.TestGame(Boolean withDebugger)
   --- End of inner exception stack trace ---
   at AGS.Editor.InteractiveTasks.TestGame(Boolean withDebugger)
   at AGS.Editor.Components.BuildCommandsComponent.TestGame(Boolean withDebugger)
   at AGS.Editor.Components.BuildCommandsComponent.CommandClick(String controlID)
   at AGS.Editor.GUIController._mainForm_OnMenuClick(String menuItemID)
   at AGS.Editor.MainMenuManager.MenuEventHandler(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripMenuItem.ProcessCmdKey(Message& m, Keys keyData)
   at System.Windows.Forms.ToolStripManager.ProcessShortcut(Message& m, Keys shortcut)
   at System.Windows.Forms.ToolStripManager.ProcessCmdKey(Message& m, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Form.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Form.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.PreProcessMessage(Message& msg)
   at System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
   at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)

Yeah, I just found it odd that it only started popping up this error message after I put this newest acwin.exe in my AGS directory. I don't recall Windows ever complaining like this about previous versions that I downloaded separately from the web.

I might be forgetting something, what is this "skipping music" problem, when does it happen? I was thinking that maybe there's just not enough music polls during some lengthy processes. In which case all we need to do is to update music more frequently.

By "skipping music" I just meant the way that the music stutters for a few moments sometimes when you change rooms or play an intensive animation etc. I should have said "stuttering music", which is a more accurate description.

--EDIT--
After putting the new acwin.exe into my AGS folder and using CTRL+F5 to test the game, I get a pop-up box saying, "The publisher could not be verified Are you sure you want to run this software?" before the game will run, which applies to the game exe file in the games "_Debug" sub-folder. It doesn't seem to happen if I compile normally with F7 and run the exe from the "Compiled" folder, though.

Yeah, if it's a significant amount of work, then I'd agree with Radiant and say it's probably best to release 3.3.0 first. While it would be handy, it's not the end of the world, and I suppose I can release another updated version once multi-threading is addressed.

One question, though. If I compile and released the game with 3.3.0, and then later put out an updated version compiled with 3.3.1 (or whatever the number will be), if multi-threading is addressed between these versions, is that likely to invalidate players' savegames from 3.3.0?

Ah, I've pinpointed the problem now. It has nothing to do with the code at all!

Basically, the gBlack GUI was set to "Normal, Initially On" and the "When interface disabled, GUIs should" setting was set to "Be Hidden". To fix the problem, I had to set the gBlack GUI to "Always Visible" in order to make it show up and start fading. Sneaky little detail.

Cheers for the code, though. That's a much more efficient way of handling things.

Hmmm and another fatal editor crash to report. This happened when I tried to copy and paste some text from the forum here into an AGS room script.

The Editor panes jittered around for a bit while it was attempting the to paste the text, and then the following crash error message appeared. At the time, my Windows clipboard was locked and I couldn't PrintScreen any screenshots or text so I had to take a couple of photos of the error message with my phone and stitch them together.



After I clicked the error message away, the editor remained open (gave me the warning that I should close it or risk corrupted files), and at that point the text I'd pasted appeared in the room script.

I'm not exactly sure where the most appropriate place to post this is, so I figured I'd post it here. It seems a relatively simple issue but I'm not sure if I'm overlooking something obvious or have stumbled across a strange bug!

The AGS manual entry for the GUI Transparency property displays the following code as an example for how to make a GUI fade out:

int trans = gInventory.Transparency;
while (trans < 100) {
  trans++;
  gInventory.Transparency = trans;
  Wait(1);
}

will gradually fade the INVENTORY GUI out until it is invisible.

It also says "Some rounding is done internally when the transparency is stored. Therefore, if you get the transparency after setting it, the value you get back might be one out. Therefore, using a loop with gInventory.Transparency++; is not recommended as it will probably end too quickly."

Yet, I discover that if I put the above code (or similar) into a custom FadeGUIOut() function and then later call that function, the GUI transparency doesn't fade at all. It fact, I never see the GUI visibly appear on the screen. The GUI in question is a 640x400-sized black rectangle. The Background Image for the GUI is an imported, black 640x400 image sprite with no alpha channel. The GUI's X and Y coordinates are 0/0 so that the GUI appears at the top left corner of the screen and should completely cover the entire 640x400 game window when it's visible.

So, I also tested it by putting the following code in the custom FadeGUIOut() function instead, but got exactly the same result:

gBlack.Visible=true;
gBlack.SetPosition(0, 0);
gBlack.Transparency=0;
int trans = 0;

trans=5; gBlack.Transparency=trans; Wait(1);
trans=10; gBlack.Transparency=trans; Wait(1);
trans=20; gBlack.Transparency=trans; Wait(1);
trans=30; gBlack.Transparency=trans; Wait(1);
trans=40; gBlack.Transparency=trans; Wait(1);
trans=50; gBlack.Transparency=trans; Wait(1);
trans=60; gBlack.Transparency=trans; Wait(1);
trans=70; gBlack.Transparency=trans; Wait(1);
trans=80; gBlack.Transparency=trans; Wait(1);
trans=85; gBlack.Transparency=trans; Wait(1);
trans=90; gBlack.Transparency=trans; Wait(1);
trans=95; gBlack.Transparency=trans; Wait(1);
trans=100; gBlack.Transparency=trans; Wait(1);

gBlack.Transparency=100;

I then tried adding the above code directly into the "After FadeIn" script of a room file, and still experienced the same issue. But if I replace the above code in the "After FadeIn" script (or FadeGUIOUt() function) with this below, then it works. Go figure...

gBlack.Visible=true;
gBlack.Transparency=50;

I seem to recall using this method in the past and it used to work fine. I will also mention that it works works fine if using a character instead of a GUI with the same code.

So what's up here? Am I missing something incredibly obvious?

Awesome job on getting beta 9 out and thanks for the new fixes and improvements!

CW, do you think it may be possible to look into the issue I mentioned earlier where multi-threaded audio throws off the timing of Pamela lip-syncing audio? I'm planning a major release with this newest 3.3.0 build (which should be a good public stress test for it), but at the moment I'm forced to trade-off between non-skipping music with inaccurate lip-syncing and skipping music with perfect lip-syncing. It would be ideal to have non-skipping music and perfect lip-syncing.

Might it be possible to implement a simple variable timer that runs alongside playing speech audio (i.e. have the .pam file take its timing cues from this timer, rather than directly from the audio file) as I talked about in more detail here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47966.msg636469876#msg636469876

Otherwise, as an alternate solution, how about enabling multi-threaded audio, but excluding all speech audio so that it's not affected by mult-threading?

What happened to Erpy? He was the main goto man in the community!

He kind of just sauntered off into the sunset, never to be heard of again!

This is a bit of an experiment at this point.  See if you can edit the first post?

Hmmm, I can't see a 'Modify' link at the top of the first post, so I guess not...

It happened to me when I was moving dialog topics which aren't contained in folders - there are actually no dialog folders in my source code. It happened when I switched the order of dialog topics 5 and 6.

Here's a fairly severe editor bug in the 3.3.0. It regards the feature mentioned here: http://www.adventuregamestudio.co.uk/forums/index.php?issue=340.0

If you drag-and-drop any dialog topic to change the order, and then compile and run the game, when clicked in-game, every topic option will point to completely unrelated topics' options in different trees. In addition, if you double-click on one of the dialog topics you dragged to a new position, the dialog script opens, but the font will look entirely different; it will appear smaller (plain arial) and without any of the color-coded formatting that the editor normally adds to scripts.

[0 (Mouth Closed):]

In AGS's "Lip sync" tab, you specify which Pamela phonemes (mouth positions) should correspond to each frame in your character's talking view. In other words, each phoneme frame represents a unique sound a person makes while talking. You can assign more than one phoneme to a view frame. Below is a list of all the phonemes Pamela uses, and how I have personally set them up in the AGS "Lip Sync" tab:

0 (Mouth Closed): ZH/None
1 (A Frame): AY0/AY1/AY2/AA0/AA1/AA2/AH0/AH1/AH2/AE0/AE1/AE2
2 (W Frame): W/OW0/OW1/OW2/OY0/OY1/OY2/UW0/UW1/UW2
3 (E, C, & K frame): EH0/EH1/EH2/CH/ER0/ER1/ER2/EY0/EY1/EY2/G/K/R/Y/HH
4 (S & Z frame): S/Z/IH0/IH1/IH2/IY0/IY1/IY2/SH
5 (F & V frame): F/V
6 (T & N frame): T/TH/D/DH/JH/N/NG
7 (L & TH frame): L
8 (O & U frame): AO0/AO1/AO2/AW0/AW1/AW2/UH0/UH1/UH2
9 (B, M, & P frame): B/M/P

It doesn't really matter how you set them up, this just shows how I've done it, and it covers every single phoneme used in Pamela. For each of these 9 frames, you'd create a speech graphic for your character's dialog portrait in Photoshop (or similar) with his mouth in that visual position.

Next, you open a WAV character speech file in the Pamela utility. You drag vertical bars (which represent the above phonemes) into various positions along the WAV timeline. These bars tell Pamela which points in the WAV file each visual frame should be displayed. When you've finished positioning all the bars and have set them to the correct phonemes, you finally save a .pam file which corresponds with the character's speech file you just opened. So, EGO1.wav would correspond with EGO1.pam. Here's an example of the contents of a short .pam file where the character says "Do you sell sunscreen?"

Spoiler

[Speech]
225:L
555:ZH
390:S
360:N
75:Y
45:AO0
270:S
15:D
435:AY0
180:AY0
150:S
120:W
90:AO0
315:AO0
525:T

[Preferences]
translationfile:sample.mot
soundfile:C:/pam/EGO1308.wav
framespersecond:24
textdata:Do you sell sunscreen?
framesperphoneme:3

[close]

As you can see, each phoneme is preceded by a timing number which determines when that phoneme should play (and thus, when the corresponding View/frame for the dialog portrait is shown in AGS). When watching the talking portrait in-game, each phoneme (visual mouth frame) is held until the timer reaches the next phoneme along the timeline, and then it is replaced by the newer one.

At the moment,  multithreaded audio throws off the timing, presumably because multithreading pre-buffers the audio and AGS relies on the speech playing real-time so that it can use the correct timing in the .pam files. I could be wrong about this - I'm not actually sure how it's coded, but if this is the case, I was wondering if a possible solution would be for the engine to run an independent timer alongside speech audio. Whenever Say(), or legacy DisplaySpeech(), is used, an integer timer could start counting. Then the .pam file could take its cues from this integer timer, rather than taking them directly from the speech audio file.

Giving the option to disable and enable multithreaded audio is good, but obviously, the music stutter is a real pain too. So if the issue can be resovled entirely, then even better!

Crimson Wizard, was anything ever looked into regarding the issue with Pamela lip-syncing not working with speech files when multithreaded audio is enabled?

If not, could you make multithreading an option which the game developer can set? I have over 5,000 lip-synched lines and the multithreading murders every one of them.

Thanks! I can confirm that it all works as intended now. I'll try that hack for the tooltip bar/label as well.

Sorry for not being more thorough about where to find the relevant code. I was in a rush to get it uploaded, and I didn't actually script that section myself, so I wasn't overly familiar with it.