Rendering of dialog. Under or above GUIs?

Started by Monsieur OUXX, Mon 20/04/2015 09:51:13

Previous topic - Next topic

Monsieur OUXX

I've always found it odd that character speech was rendered on top of GUIs. I suspect this choice was made randomly along the years -- Like, the function "RenderDialog" being written just below "RenderGUIs" (fictional function names!) in the C++ code, by cheer chance, by CJ one night while he was drowning his sorrow in whiskey on a rocking chair under the full moon.

- How hard would it be to swap them?
- Would that make sense? I think it would. Dialogs are part of the "inner" game while GUIs are out of it. They are meta, if I may say so.


 

Gurok

Okay, #1 problem, it's not all one process right now. Character speech is rendered on top of GUIs, but character portraits are rendered beneath them. This is because while the _displayspeech function renders portraits, it merely sets up the text overlays involved.

I don't think it's a matter of swapping them. I think it would involve some restructuring, but speech should be able to take a z-index just like GUIs can. By extension, this means speech should become one big overlay and overlays should be able to take z-indices just like GUIs can. The compositing functions for GUIs and overlays would need to be merged.

I'm not saying I'm prepared to do it, but if I did, it would be a major rework. The speech code in particular is just a mess of conditions that should really be broken up and reorganised (if only to eliminate confusing variables in the function).

It would also be possible for the engine to have a global setting that tells it to render out the speech inside the _displayspeech function (similar to how the portrait is currently blitted there). We might also have an alternate setting that forces the creation of an overlay for the portrait instead of blitting it in the speech function. That seems hacky though and far less flexible than z-indices.

Your reasoning makes sense, but people use AGS to do strange things. Recently, I wanted to use a GUI to "fade out" the screen underneath and then draw speech over the top. That's a situation where the reverse order makes more sense.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

#2
Yes, I believe, configurable screen layers is a way to go. This way we could have dialog overlay between two GUI layers, if we would like.
But, indeed, its a matter of significantly reworking program design.

UPD. Perhaps, there might be a switch as a temporary solution. But I can't tell for certain if it is easy to add, without some research first.

Monsieur OUXX

 

SMF spam blocked by CleanTalk