Hi!
I'm helping someone with a custom dialog GUI that should have a semi-transparent background. This is a part of the code I use
function dialog_options_render(DialogOptionsRenderingInfo *info)
{
// Clear the area
info.Surface.Clear();
// Draw border
...
// Fill transparent background
DynamicSprite * ds = DynamicSprite.Create(info.Surface.Width, info.Surface.Height, true);
DrawingSurface * sf = ds.GetDrawingSurface();
sf.DrawingColor = Game.GetColorFromRGB(0, 0, 0);
sf.DrawRectangle(1, 1, info.Surface.Width - 2, info.Surface.Height - 2);
info.Surface.DrawImage(0, 0, ds.Graphic, 50);
sf.Release();
ds.Delete();
// Render all the options that are enabled
...
}
However, all I get are different shades of purple, depending on the transparency value. Only if I use 0 I get a fully black and if I use 100 I get a fully transparent background. The text and border I draw are shown correctly.
Am I doing something wrong or is this an AGS bug?
Thanks, cat
The stock version of AGS cannot blend two alpha channels together. So drawing transparency onto the background is fine because there's no alpha on the background but trying to blend on a 32bit sprite will just cause it to blend with magic pink.
Your options are use my blending plugin or using a custom version of the engine like Draconian.
Thanks for the info. I contacted the game author because it is his decision if he wants to use any of them.
Or you could work around it in script, but since nobody uses AGScript (as it's useless) then there's not much point in doing so.
Yeah, I was thinking about suggesting using a second, black GUI with its .Transparency set to 50. This should do the trick, provided dialog_options_render doesn't block other GUIs' changes.
monkey, if you must act like a pouting brat, why don't you reply to my last Mormonism PM instead?
Showing a GUI works fine, but when do I remove it again? dialog_options_render is only called when DRAWING the dialog GUI, not when clearing it. So now it is shown correctly as long as the dialog options are shown, but the transparent gui stays on screen, when the character is saying the dialog line. Also how do I know when the dialog has stopped? Can I somehow check this in rep_exec?
OT: monkey, I do not intend to use LUA or any other non-compiled, curley-bracket-free, not-strongly-typed language, so AGS script is fine for me ;)
Right, I hadn't thought of that.
What if you use a sprite as GUI background graphic that's already 50% transparent, as in a 32bit png? Is this going to clash with rendering the options yourself?
No, if I draw it on the surface I get fully opaque purple again.
info.Surface.DrawImage(100, 100, 6);
I'll try to use a textwindow GUI.
Edit: Nope, textwindow doesn't support alphachannel either.
What I meant was, set the sprite as the GUI's background graphic in the editor, then render the options without clearing the surface.
I doubt it's going to work though.
Hm, I'm not sure what GUI you mean. If I use the dialog_options_render function there is no GUI for the dialogs, this seems to be created by AGS on the fly.
I tried to use a textwindow with a transparent background image, but alpha didn't work there as well.
I haven't read all of this, but as far as having a GUI turned on while the dialog options are shown, and turned off while they're hidden (the option is being run)...
Dialog *runningDialog;
// dialog_options_get_dimensions --> this is essentially your dialog start event
runningDialog = info.DialogToRender;
// dialog_options_render --> dialog options about to be drawn, essentially dialog's own rep ex
gGUIToShow.Visible = true;
// repeatedly_execute_always
if (runningDialog != null) gGUIToShow.Visible = false; // this check will allow you to use the GUI outside of this purpose
// repeatedly_execute --> essentially dialog end event
runningDialog = null;
This requires the default setting so that game loops are not run while the dialog options are shown (General Settings pane, Dialogs). If you absolutely need that on then you could check other conditions such as Character.Speaking, Character.Animating, etc. depending on your needs. The check for runningDialog isn't strictly necessary here, as notated, but it could come into play for other things too.
Edit: For all intents and purposes it actually occurs to me that the custom dialog option rendering functions negates the need for the global setting if you're already making use of them (if you're not, then it would add a significant workload unnecessarily). You can achieve the same effect by adding any code that needs to be run while dialog options are shown to the dialog_options_render function (in addition to rep_ex_always). IIRC modules can supply their own versions of the rendering functions which stack in the same fashion as other event methods. Just some food for thought regarding the way you're designing your dialogs.
Doesn't the custom dialog gui module feature this? I'm pretty sure I've included Monkeys workarounds. If I recall correctly the module takes a screenshot of the area, blends your background into it and assigns it to the GUI. I think it just doesn't feature proper character tinting if there's one behind the GUI.
Great idea! I'll try that this weekend.