Request: Putting talking portraits in front of GUIs

[Dave Gilbert]

Hi all.  I have an area of my game which uses a large GUI that takes up a lot of screen real estate.  The only problem with it is that it blocks all the character dialog portraits.  I spoke to some AGS techies about it and it seems the only way to fix this is to create another GUI entirely for the talking portraits and push that to the front. 

It seems like a lot of work for something that appears relatively simple to fix.  Is such a thing possible for the next release of AGS?  Or is there a way to fix this using the existing system?  As a last resort I'll bite the bullet and build another GUI, but I'd prefer not to if there's an easier way.

[GarageGothic]

Is the GUI interactive while the dialog portraits are shown? I don't think that's even possible with the default Sierra talking portrait mode, so what you could do is to replicate the GUI as a DynamicSprite using DrawingSurface functions (depending on how complicated it is, perhaps you just use a premade GUI sprite grabbed from a screenshot). This could then be displayed using a dummy character or possibly an overlay (I think overlays created before the speech runs will be displayed behind the portraits). Then remove it after the speech finishes. You would in effect use a custom speech function to 1) duplicate the GUI, 2) remove the GUI and display the replicated sprite 3) trigger the Say command 4) Remove fake GUI and make the real one visible.

(you could use DynamicSprite.CreateFromScreenshot to grab the GUI, but its a rather slow function, especially in Direct3D mode. Drawing the GUI background and then its button graphics onto a DynamicSprite would be quicker - of course this is made more difficult if you have ListBoxes and other non-graphical GUI elements)

[Dave Gilbert]

Hi Garage.  Nope, the GUI's not interactable while the portraits are shown.  The portraits just appear behind the GUI, instead of in front.

And to clarify, I'm not asking HOW to make a new gui that will do this.  I'm just wondering if it's possible to bring the dialog portraits to the front and, if not, can CJ put this in the next release.  Is there anything resembling a Z-order for the talking portrait?  Having the dialog portraits appear in front of in-game GUIs is something others would want to have too, I'm sure.  My game will take long enough to make that I can easily wait, but if it's not possible at all I'll bite the bullet and make the GUI.

Thanks!

[GarageGothic]

Ah, sorry. I thought you were asking for easier solutions than replicating the character portrait as a GUI.

[SSH]

How about something liek this, Dave:

Code: ags

function NewSay(this Character *, String what) {
   int tmp=guiIntheWay.BackgroundGraphic;
   guiIntheWay.BackgroundGraphic=SAME_SPRITE_BUT_WITH_TRANSPARENT_HOLE_IN_IT;
   this.Say(what);
   guiIntheWay.BackgroundGraphic=tmp;
}

One could even dynamically create the Sprite by drawing on the original sprite with the "magic magenta" colour a rectangle based on the size of sprites in the talking view. I guess a problem is if the talk view sprites are not rectangular themselves.

If its not just a background graphic obscuring the portraits, but also buttons, text boxes, etc, you could do the same trick with them or just turn off their visibility. If you could give a screenshot of the problem, it might help to gauge how easy a solution might be.

[Dave Gilbert]

Neat, SSH.  Will that work with animated portraits that use seperate blinking and talking animations?

A screenshot won't really help, since the protrait is totally obscured by the GUI.  But I could be wrong, here you go:



The portrait is supposed to be on the upper left, but it's hidden behind the computer screen GUI, and the browser GUI.

[SSH]

Don't think that approach would work with that GUI. But instead, I proudly present:

The GuiPortrait module

GuiPortrait documentation

Let me know if you need any additional features!

[Dave Gilbert]

...

Wow.

That totally fixes the problem, SSH.  Thanks!

[Pumaman]

Nice one, SSH

Adding an option to the engine to specify the z-order is on my to-do list, and I do agree that it should really be part of AGS.