WorldBounds.Max default before Setup about engo

[matiwinnetou]

I would have even more general question that I would like to add.

I think we have to be careful, WorldBounds probably makes sense in certain apps (where there is a territory different than game's window). I can imagine a class of very simple games that do not need any WorldBounds are exactly the same as engi.Width() and engi.Height(). Therefore in my humble opinion these things should always be pluggable but not on by default. Camera falls into the same category. Most simple game I am writing - Galaxian doesn't care about camera. Pong needs no camera, etc.

When there is a complexity even for most simple games it is harder for people to use the engine because they have to learn more than they should.

Now there may be a difference in thinking between us or I am simply terribly missing the point, which I am happy to know your opinions.

@paked @EtienneBruines

[EtienneBruines]

I do get your point, @matiwinnetou. It might even be related to #65, in a way.

I think I know how I can make this work. The current HUDGround PriorityLevel uses a Shader which ignores the Camera completely.

The user could set the default either to what we use now, or to "handle everything as HUDGround", which would ignore all Camera settings. It would still use the PriorityLevel to set the order in which to draw things, though.

Thoughts on how we should name this 'setting'? Or if we should do this at all? @paked @matiwinnetou

[EtienneBruines]

I have given this some thought.

With new patches coming up, that allow for 'hovering' events, there should be no difference between HUDGround and any other PriorityLevel. Default zoom level is 1, which changes nothing. And default location of the camera, is also set to center the window. So nothing to change there.

Furthermore, with recent changes, this 'issue' even got addressed (unnoticed); WorldBounds.Max is now set after Preload, but before New(*World)