Adding support for additional cameras in game

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-03-23 14:34:43
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
I figured this deserves it's own thread.
So, I have picked up issue number 71 from the project backlog.
I have spent the day working up a procedure that I hope won't break the existing engine.
And there is a risk.
My plan would result in changes in several classes:
iCamera
GameWorld
RenderComponent
Screen
GameScreen
ScreenManager
ScreenManager would see the biggest changes of all, as it requires a total rewrite to support this.
I took great care to make sure I had plans for any compatibility issue with any old code.
Now, there is a very good chance I missed something preparing this, so I'm putting my notes up here for you to read (if you really are insane enough to go though my 138 lines of rambling and psudocode).
I will start implementing it soon. For now, my brain needs a rest.
https://pastebin.com/w5gWeTbJ
But hey, here is a bonus. This change, if it works, accidentally also lays the groundwork for a graphical overlay panel. Well, maybe not all that accidentally.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-03-23 23:22:03
User: steffen [Admin 👑, Mod 🔧] (age: 1568 days 🔥; posts: 100)}
Wow, I wish the people at work would describe their implementation plans in such great detail! 👍
A few notes from my side before I go to bed:

• * In general, the plan you compiled seems reasonable and well thought out.
• * As you already pointed out: This is a crucial part of the engine and it needs to be worked on with precision in order not to break anything. Rendering on two Screens/cameras in one frame will effectively split the potential frames in half but I don't see an easy way around this. So, multiple cameras will be very costly.

  • * One Camera will still be the engine's default. As such the API should provide simple access to the default Camera (but I think you already accounted for this in your concept)

  • * Once this feature is done, we definitely need to test the engine entirely, check out any graphical feature and also check the editor and maybe some example games (I can help out with that, once we have a working branch of the feature).

• * General Hint: The camera is used in many places to translate map coordinates to "viewport" coordinates: see ~~~~Game.camera().getViewportLocation() as in "to determine where stuff should actually be rendered" and in some cases "in which size (depending on the zoom) stuff should be rendered". There might be places outside of the normal render pipeline that also rely on this (e.g. ~~SpeechBubble.update()). If I understood the concept correctly, the current camera that the pipeline is rendering on will be set (only?) during the rendering process.
  I think we can change the way this API is intended to be used by limiting it to "while something is being rendered" but for this we might need to touch some occurrences in the engine. Maybe we should even throw an exception if this is called outside the rendering process.
  Regarding the ****~~general workflow****: I'd suggest forking the repository and create a branch on your fork. Then, once you're done (or even while still working on the branch) you can open up a Pull Request, so we can discuss details and merge the changes into the LITIENGINE master branch.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-03-24 06:28:52
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
steffen
Thank you. Writing those notes really took all day. With all the psudocode and planning.
And yes, in the rendering pipeline, the variable set for the currently active camera, is set during rendering. It is simply where I need it.
Off course, there are several alternate ways I could have solved this, but I wanted to cause the least amount of damage to the existing API.
I had a quick look at SpeechBubble#update. I think that update could be moved to SpeechBubble#render.
I will look into fixing it after implementing the changes.
Meanwhile, I don't suppose you know of a good demo-map or something I could test on?
I could make my own, sure, but why spend the time when I'm sure you must have some testing assets you use internally that would be of use here.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-03-24 13:17:30
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
I have hit an obstacle. Hey steffen, could you help me with adapting ~~~~ScreenChangedEventto the change in the ~~~~ScreenManager ?
For now, I'm just gonna ignore it, and leave a TODO-note.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-03-24 14:45:53
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
Well, I did what I could, for now.
The pull request is up.
#324

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-03-24 19:41:06
User: steffen [Admin 👑, Mod 🔧] (age: 1568 days 🔥; posts: 100)}
KvaGram Sure, I can have a look. And I'll review the PR anyway (not sure if I can find the time this evening though).
> Meanwhile, I don't suppose you know of a good demo-map or something I could test on?
We typically do some smoke testing with the utiLITI editor and some of our games. The tutorial game ~~~~Gurk Nuken is freely available, so you could test it with that game. I'll go ahead and test it with some other games.