Messages

Just a quick question: now that the Wait(1) is there, no_loop_check is not really necessary anymore, is it?

Make sure that the Letterbox Mode checkbox is ticked in the setup program. The D3D driver hasn't changed in 3.0.2 so there shouldn't be any differences in how it behaves to the previous version.

I'm sure, because letterbox mode (or, 'force alternate letterbox resolution') is greyed out on winsetup.exe, so i couldn't have turned it 'off'.

As a matter of fact,  I tried to start a new game using the default template, and it didn't work too, fullscreen or windowed (same error message).

When I try to run 640x480 games full-screen in D3D mode I get:

There was a problem initializing graphics mode 640x400 (32-bit)
(Problem: 'Failed to create Direct3D Device: 0x8876086C')
Try to correct the problem, or seek help from the AGS homepage.

Possible causes:
* your graphics card drivers do not support this resolution. Run the game setup program and try the other resolution.
* the graphics filter you have selected does not work. Try another filter.

Notice that the error message states that it could not use 640x400, not 640x480. Strange isnt it?

If I switch the game resolution to 320x240, I get a similar error, saying that it could not use '320x200' resolution.

I used to be able to run 640x480 in D3D in previous AGS versions, so I posted this.

Do you have more than one background in the room? Try putting SetBackground(0) in the 'before fadein' event.

Would it be useful if you could specify that lucasarts-style speech was drawn in a text window GUI, which would allow you to use an alpha-transparent background image?

I have implemented my own 'Say' routine, in a custom GUI because I needed to fade the background too (assigning an alpha masked background to the GUI). Actually, it also uses a 'queued' approach to the speech, so the dialog can be rewinded/skipped.

I am about to publish it as a module, if you find it interesting. You can customize the appearance of the GUI, in a much more flexible way than the 'text window' GUIs.

Anyway, it would be interesting to be able to apply an alpha-masked background to a text window GUI too.

Say/SayAt/FadeOut calls still go through as well.  Would it be possible to modify or at least add another type to guis to freeze EVERYTHING except themselves and mouse control?  Everything would include processing Waits,changerooms,animations, anything except gui scripts, mouse movement and control and keypresses.

I agree that a 'modal' dialog should 'freeze' code execution as soon as 'visible' is set to true. In my game, I have a gui dialog that shows up now and then, presenting the user with some options. Depending on which option he picks, the game would do something different.

So, I had to come up with the 'infinite loop approach' to halt the script. The solution is not very pretty, because it can't be transformed into a module or something more 'global'. Whenever i need to call this dialog, i have to cut&paste code... 

I'm sorry to hear that I may have stolen your thunder here. I actually had an idea for a game that involved the module, so I started working scripting it.

Dont be sorry, my game also needs a large text area and I started coding my own because there was no other option! Actually, I'm glad you did it, because i had to stop working on mine to do other stuff in the game, and it was not finished.

I've actually just gotten the cursor placement code working in my own module.

Good to hear that too. It's not too hard, once you find the line the user clicked at (given mouse.y), it's just a matter of using GetTextWidth with that line's characters until it reaches mouse.x.

The scroll code is going to be one of the simplest ... I'm taking advantage of a ListBox.

That's very clever. I started from a Label and had a very hard time. But I find the 'default' scrolling buttons really ugly, hope you can code functions to scroll the lines up or down, just so we can assign these functions to 'regular' gui buttons.

There's nothing like a little friendly competition!

I agree with you.

There are a couple of things I need that I hope you continue working on, like proper word-wrapping, and a blinking cursor that indicates where the user is at. I have these on my module, so I can always 'merge' them in your module and then post them back for your approval.

I'm looking forward to see your module finished!

[]s

Wow, THATs coincidence, because I was working on my very own text area module!!! I haven't released yet it because there are still some bugs around... if I'd known I would have released it before... 

I would be happy to work with you on it, maybe we can 'merge' some code. Maybe the best feature of my module is the ability to place the cursor exactly where the user clicked. The 'scroll' feature is half-done, I guess.

I was just experimenting with another method, doing an additive alpha channel where the opacity of the sprites is added to that of the background:

I think this actually looks reasonable (I still need to fix the non-alpha one) -- but the question is, is this sort of approach suitable for all you guys who use alpha channel GUIs, or would this be fixing one problem only to cause another?

It looks very good to me!! Can't say that it won't cause any problems though... Maybe you should add a drop-down to the GUI panel, asking which method would be used for alpha-blending (backward compatible, additive, differential, etc).

The closest to the ideal is the 'differential' one... But even this is not '100%' right, the character shadows are missing. Ok, I'm convinced... it's not that simple to keep 'temporary bitmap' approach with transparency.

Would it be too difficult to extend DrawingSurfaces to alpha channels, like I suggest in my previous post?

Or, another idea is to implement a CopyTransparencyMask() method that takes a sprite and applies it to another sprite's alpha channel (using the luminance of the pixels as the transparency).

   You can alpha blend to the extent of having an alpha channel but can you have a character with the background showing through him (i.e translucsent characters like ghosts etc) if so how?

First, your game need to be using at least 16-bit color depth. There are two ways to do this:

• Applying an alpha channel to your character sprites (only works in 32-bit);
  
• Setting the Character.Transparency between 0 and 100 (for this to work, though, the character sprites must NOT have alpha channel);
  

1. The leftmost 'check-mark' inside the GUI has artifacts around it

So can't you just not use that import method, then?

Sure, but as I said, I think that behaviour is a bug (those artifacts shouldn't show up), and so I was trying to help. I'm a software developer too, so I like when someone tries to help me by trying to isolate the problem for me instead of just saying 'it does not work as I expect'.

Since the sprites have alpha channels, when you copy the second sprite you overwrite the alpha channel of the first sprite, so all the areas that are transparent in the second sprite become transparent and "disappear".

Hmm... I guess you're right, so the copy operation should not 'overwrite' the alpha channel, but 'add' to it.

This could be done with the scripting interface, if AGS provided a way for us to draw directly on alpha channels. Right now we can copy a transparency mask from one sprite to another, but we can not alter the mask in any way.

I made a suggestion a while ago about a 'GetDrawingSurfaceForAlphaChannel()' that would return a DrawingSurface*, then we could alter the transparency of any sprite.

I forgot the mention this in the last post - the GUI is draggable, as well as all the controls inside it.

I thought that maybe this 'feature' would help to diagnose the problem.

[http://www.i9acao.com.br/ags/AlphaMaskGUIs.zip]

You can download it from here: http://www.i9acao.com.br/ags/AlphaMaskGUIs.zip

Ok, I decided to post a snapshot of it for your convenience... 

The window on the top-left, with the black embossed border, is the GUI. The black frame is the background sprite, and it has an alpha mask suited to make the interior semi-transparent and the borders opaque. All the elements inside the GUI (apart from the text labels) are buttons with images applied to them.

Noteworthy stuff:

1. The leftmost 'check-mark' inside the GUI has artifacts around it, which don't show on the next two versions to the right, even thought all of the three were imported from the SAME png file. The only difference was the import method;

2. The female character has an alpha-mask to provide a shadow beneath her feet; note that, right in the middle of the shadow spot, there is a 'hole' which does not show in the 'object version' of the sprite. The same happens to the male character.

3. Note that the character sprites 'overwrote' the pixels in the border of the GUI (the opaque area) to black, BUT kept the transparent areas of the background intact

4. The same 'pixel overwriting' happens at the area in which the female 'overlaps' the male character, inside the GUI. Compare this to how they (correctly) behave in their 'object version', at the bottom of the room.

I cant help but feel ...

Any comments are welcome.

I also thinked on that, but I'm pretty sure there must be another way to solve it.

Hi, I would suggest you to include alpha channels on your buttons also, and selecting 'top-left pixel' when importing them.

To sum it up, it seems to me that to get what you want you need:

- A background with an alpha channel (even if it is opaque, it still must have an alpha channel)
- Button images with alpha channels (same as above)
- Background color set to 0 on your GUI
- Border color set to 0 on your GUI

Let me know if this works. I'm having my share of problems with alpha channels in GUIs, and I posted a thread about this two days ago in the technical forum, I suggest you follow that discussion.

[]s

Therefrore, ideally the RGB-transparent area and the 100%-alpha area on the sprite should be the same.

I do my transparent sprites in Photoshop, usually on single layer, with no background layer, and save it as a PNG file. If I open the PNG in The Gimp, or even Firefox, the transparent areas dont show, like it should be, so I guess there's nothing wrong with this method.

However, I noticed that in AGS, the transparent areas DO SHOW, if the sprite is inside a GUI, and if you chose 'leave as-is' in the import settings. I coded up a real quick and dirty game ('borrowed' from SSH's QueueBGSpeech module demo, IIRC) to show the results. Since the sprites are there, and the originals (the PNG files) are in the zip, you can compare the 'ins' and 'outs'.

You can download it from here: http://www.i9acao.com.br/ags/AlphaMaskGUIs.zip

I did this because maybe there is some bug hiding in AGS somewhere, which nobody has bumped into yet because using alpha-masked buttons on GUIs is rare, I guess.

Please pay special attention to the two characters, male and female, which are alpha-masked and overlapped inside the GUI. There is shadow underneath their feet, and the center of the shadow spot has a 'hole' when the sprites are place inside the GUI.

Also, the area where she overlaps the male character has 'wiped out' the pixels from the sprite behind her! Isn't this strange?

But what this means is that when the GUI controls are being drawn, they are being drawn onto a temporary bitmap and not onto the screen itself.

Ok, but it seems that the alpha masks are not being used like they should when the sprites are drawn on the off-screen bitmap.

I appreciate that this is rather confusing, because intuitively you'd expect the background to be drawn to the screen with its alpha channel, followed by the controls afterwards with their individual alpha values. The reason AGS works this way is for performance reasons, but I might do some experimentation to see whether on modern PC's this is still an issue.

I understand, and I'm sure there are workaround to these situations, I mean, I can always change my GUI, but my intent is to point out some strange behaviour that was overlooked.

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.

Yes. Avisynth supports 'traditional' subtitle file formats, like .srt, .ssa, etc, so you would have to supply one subtitle file for each language, and generate the script on-the-fly to match the movie and the appropriate language.

It could be done with multiple audio tracks too. I mean, you could have one video track and several audio tracks, and have avisynth play the selected audio track according to the language it is running on (supposing each audio track is in a different language).

This really opens up a lot of possibilites...

Just wish I could AGS-code subtitles for while movies display... ah well, maybe this Xmas Santa will surprise me!

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.

This in particular interests me A LOT. And if regular AGS processing could go on in the meantime (even if non-interactible - a cutscene would do) it would be even perfect...

Unless i'm mistaken, while PlayVideo is working its magic, the screen is no longer controlled by AGS, but by WMP. Then, to mix an AGS cutscene and video you would have to use an Avisynth script, because it HAS the control of the screen (although indirectly, via WMP).

But you would have to convert your cutscene into a 'video', in order to Avisynth to 'play'. Avisynth scripting language is pretty powerful, but I wonder if it's worth the trouble to code a cutscene in it... but i guess it's possible, if you really like to experiment...

My suggestion was waaaay simpler than that, just take a snapshot of the room, for example, one that has a large LCD screen next to your character, and then, inside Avisynth script, compose the snapshot (which would be a PNG file sitting somewhere) with the video, using Avisynth commands to size & position the video right inside the LCD screen.

[Avisynth]

I'm still investigating, but in my game I intend to use Avisynth to handle the videos. In short, Avisynth is an open-source app that acts as a proxy to WMP. Which means that in AGS, you just have to call PlayVideo and point it to an '.avs' file, which is an Avisynth 'script'.

I'm sure this explanation is overly simplified, and my english is not very good, so you'd rather visit the site to understand it better than take my word for it. But the advantages, from an AGS game designer perspective, are:

• You can distribute the codec along with the game (the codec is just a dll file, unlike traditional win32 'codecs' which have to be installed), thus alleviating the user from the hassle of finding the right codec and installing it. I'm sure Avisynth can be installed on the user's system easier than a third party codec (like Xvid);
  

• Avisynth has a lot of filters you can apply to your video, like transformations, transitions, and even text (you can subtitle your clip, for example), because its scripting language allows you to do so;
  

• Avisynth has a plug-in architecture, and there are some streaming plugins around that allow for video over the network (hasnt done much research on this, but i think its possible);
  

• You can mix two or more video clips, with audio, so you can achieve all kinds of effects, like voice overs, effects/music/no-music, etc. You can even 'make' a video out of a couple of still pictures!
  

• 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.
  

As soon as I'm done with it, I intend to post a new thread explaining it, but if you guys want to do some research on your own and exchange information via PM, that would be awesome.

Avisynth has a huge following among video editors, and a huge community also. I think it would be a great addition to an AGS game designer's toolbox.