FadeFrame in Transitions: why a custom model?

In the Transitions class, I see that “fadeFrame”–the DirectFrame used for fading, as used behind DirectDialogs–uses a custom model rather than just setting the colour and alpha of the frame. I imagine that this is at least in part to allow customisation–but why is a custom model used in the default case, especially given that it appears to be no more than a coloured quad? Why not use the model when one is specified, and use colour and alpha in the DirectFrame itself otherwise?

To explain my interest in this, I’m trying to remove Panda’s use of default models in my copy of the engine: I seem to keep tripping up by virtue of forgetting to include them in builds (likely because they’re used transparently, and thus are easy to forget), and it feels a little cleaner to my mind to not use them. To this end I want to remove the use of the custom model in the default case, but don’t want to do so without understanding why it’s currently used, against the possibilty that not using it will break something.

Hmm, you’re right, it doesn’t seem to be a particularly interesting model. I don’t see any reason why it can’t be done procedurally.

That sounds like a good goal, such cases have bothered me as well. Feel free to contribute your changes back.

Noted, and thank you.

I’ve already done some work on DirectRadioButton, but should perhaps clean it up a little. ^^;

However, presuming that I get everything working properly and reasonably cleanly, I’ll hopefully remember to indeed post my changes.

Come to that, should I just post such changes to the forum, or is there some better way to contribute them?

Patches are best submitted via the bug tracker, as an attachment.

Noted, and thank you.

Hmm… I’m currently looking at the Transitions class, which seems to be the source of the fade-object. I’ve found that the fade seems to be parented to aspect2d, with the default model simply made very big in order to cover most reasonable aspect ratios (this can be seen by setting a particularly wide, short ratio: the default model then covers only part of the screen).

Now, if a custom fade model is used, then parenting to aspect2d has the benefit of not distorting it as when the aspect ratio changes; on the other hand, switching to render2d has the benefit of potentially covering the entire window regardless of aspect ratio.

If I’m going to contribute this back, I’m hesitant to make unilateral changes, so I ask: is there sufficient benefit in continuing to parent transitions to aspect2d? Is there anything that I’m missing there?

My own opinion is that custom fade models seem likely to be uncommon, and more likely than not to be intended to cover the whole screen when they are used; I’m inclined to change the parenting to render2d.

Yes, it needs to remain parented to aspect2d. Can we simply parent to render2d when no model has been provided, and to aspect2d otherwise?

I’ve subsequently discovered that a DirectFrame parented to render2d doesn’t prevent mouse-events reaching other DirectGUI objects (or at least those parented to aspect2d, as is the default, I believe).

For now I’m going with the expedient used with the default model: leaving the frame parented to aspect2d and just making it enormous.

There are a number of other complications of various scales coming up as I work on this, but rather than create separate posts for each, I think that I’m going to implement my version, provide the patch, then post for comment and discussion.

I’ve posted a new thread for community examination discussion of my changes.