-
Notifications
You must be signed in to change notification settings - Fork 360
Description
The camera provided in Arcade currently has many issues that need to be fixed.
• Only provides a 2D orthographic camera
• Has janky and incorrect zoom functionality
• Has an update/use method that breaks arcade conventions
• Does not provide a way to rotate the camera
• SimpleCamera is not simple as it should be
• Normal camera has features that would be better served as an external class(es).
Okay, point three about the update methods might need explaining. The camera provides an update method, but it does not respect delta_time and is automatically called in the use method without a way to disable it. This means that camera speeds are variable based on the update rate and how often a camera is used in a single draw call. On top of this, it also breaks arcade conventions by having non-draw logic within the draw call.
I propose that the cameras in Arcade be totally overhauled.
Proposed Changes:
• Provide simple data classes to store information about cameras.
• Provide an interface called Projector for objects, which sets the underlying arcade matrices.
• Create a Default Projector, Orthographic Projector, and Perspective Projector, which satisfy most people's needs.
• Use the Default Projector to allow users to use cameras in context managers safely
• Create a new Camera2D that follows conventions and makes it easy for users to plug and play.
• Provide controller classes that users can use to move their Cameras easily in complex ways. [EDIT: these have been called 'grips' after the colloquial term for camera, and other operators on movie sets]
• An all-new tutorial explaining how cameras in games work and how to use the arcade system.
• Move all examples over to using Camera2D and Grips.
Why do it this way?:
Cameras are just represented by PoDs (Packets of Data) rather than fully fledged classes to promote composition over inheritance. While Camera2D can be treated as though it stores all the data internally, the user should look to the PoDs for more complex use cases. An example benefit is when a user wants multiple projections to share a single position. If you have multiple cameras with the same projection but are placed in different locations (like a CCTV system, for example), having them all share one projection PoD would save memory and decrease the chance of mistakes.
It also means that camera controllers don't need to know anything about the camera they are moving, and they can know about the position, direction, etc.
These breaking changes should occur in 3.0, with later improvements and tutorials coming in 3.1+.
TODO LIST:
- Dataclasses for view and projection matrices
- Camera Data (viewport, view data, zoom)
- Orthographic Projection
- Perspective Projection
- Projector and Camera Protocols for typing
- Default Projectors
- A simple projector that Arcade uses internally
- An orthographic projector capable of both 2D and 3D
- A perspective projector capable of both 2D and 3D
- A competent replacement for
SimpleCamera - A re-implementation of
SimpleCamerawith a depreciation warning - Provide camera controllers for ease of use
- A track-to-point method as seen in
SimpleCamera - A lerp to point method (2D and 3D)
- An lerp to point which accepts an easing function (2D and 3D)
- Methods to rotate the camera around the view axis (forward, up, right)
- 2D screen shake
- A track-to-point method as seen in
- VERY IMPORTANT. Remove internal assumptions about projection being Orthographic
- Make
WindowandArcadeContextconsistent about the name ofprojectionandviewport - Complete typing and Doc Strings
- Fix all examples which used the old camera
- Adding new examples
- One that shows off the easing methods
- A replacement for the
SimpleCameraexample - An isometric example
- A detailed tutorial page on how the cameras work
- A camera section for the API quick index
Metadata
Metadata
Assignees
Labels
Type
Projects
Status