Configure camera boundaries based on map size

[heinezen]

Required Skills: C++

Difficulty: Hard

Since the implementation of #1682, the area the camera can move in can be limited by boundary coordinates. Currently, the boundaries are hardcoded into the initialization of the camera manager to exactly match the (also hardcoded) map size of our demo game. However, for the future, it would be nice if the camera boundaries would adjust dynamically based on the current map size. This requires that we can transfer the map size and coordinates to the renderer thread and the camera manager.

Passing the information to the renderer should follow the exact same flow as the other simulation -> renderer communication in the level 2 renderer (see the associated architecture documentation).

Tasks:

• Renderer thread:
  • Create a new render entity subclass for the camera that can receive updates from the game simulation. The only update the renderer entity needs to receive for now is the 4 coordinates of the terrain map.
  • Check for updates from the render entity in the camera manager and, if there are any, update the camera boundaries
• Simulation thread:
  • Let the simulation thread create camera render entities via the RenderFactory
  • Update the render entity with information from the simulation, i.e. pass it the map coordinates. For now, this only has to be done once, when the map is initialized first. Later, we can make this update more dynamic, so that the render entity is updated if the map size changes

Further Reading

• renderer level 2 architecture documentation

[jere8184]

so the size of a map is given by a vector2? hence one of the points will always be zero, zero; or am I missing something. And if so wouldn't we only need to pass the vec2 and not the four points mentioned in this description, from game simulation to renderer?

[heinezen]

Yes the map size is a vector2, but why would one of the points be (0,0)? Do you mean because it's the map origin? There is no guarantee that the origin of the map will be at (0,0) in the scene at all times. The map could move or shrink in physical space. Hence you should always pass 4 coordinates. You eventually need 4 points anyway, so no reason to not do that.

[jere8184]

Do we currently store the four coordinates (or origin) anywhere? I couldn't find them when I originally looked into solving this, which led me to ask my first question :p.

[heinezen]

@jere8184 There is WORLD_ORIGIN in

openage/libopenage/gamestate/definitions.h

Line 17 in 846c1fa

constexpr coord::phys3 WORLD_ORIGIN = coord::phys3{0, 0, 0};

Though that's currently not used by the terrain code. The current code does not store the coordinates of each terrain chunk, but in the future it might be.