mirror of
https://github.com/TheRavenwoodArts/LunaLightXMG.git
synced 2026-07-31 01:35:03 -07:00
jme9
49 lines
3.1 KiB
Markdown
49 lines
3.1 KiB
Markdown
## March 15th, 2025 - JME
|
|
|
|
Currentlly the camera is static, or non-existtent really.. we need to create a camera class that handles creating and managing a viewport that follows the player wihin the level.
|
|
|
|
- If the level is the same size as the viewport then the camera is static.
|
|
|
|
- We also want to have a zoom capability that zooms between 320x180 and 480x270. The current view is 320x180.
|
|
|
|
- We should be able to use a lot of the code from LunaLightGML however we will need to create the class objects and restructure to work with MonoGame.
|
|
|
|
## March 16th, 2025 - JME
|
|
|
|
Created intitial Camera2D class. We will need to add in code from GML for the smooth following effect, screen shake, etc. I did add some other stuff that is cool though.
|
|
|
|
- Zoom, we can set the camera zoom between 0.1f and 10f. These values may need to be changed after testing.
|
|
|
|
- Rotation, I thought this might be fun.. might come in handy for an effect later on. The camera is 2D but rotates on what woudl be the z-axis.
|
|
|
|
- We can set the level bounds that the camera exists in when moving from level to level.
|
|
|
|
## March 17th, 2025 - JME
|
|
|
|
**Zoom Weirdness**
|
|
Testing shows some serious pixel distortion when zooming. Rotation is odd.. but could still be cool at somepoint, lets focus on fixing the zoom.
|
|
|
|
I think the probelm is due to the fixed render target. We are changing the veiwport width and height when zooming but the render target stays the same. We are also zooming at sub-pixel values so it is possible to land on a zoom value of 1.5f for example which isn't pixel perfect and causes distortion.
|
|
|
|
Solutions:
|
|
|
|
- We could abandon zoom in the camera and control zoom by changing the render target values.
|
|
- We should in either case only zoom at integer values to preserve pixel-perfect zoom.
|
|
|
|
Leaning towards abstracting the render target code to its own class and handling zoom there. Overall I think this will be better as it is what draws to the backbuffer.
|
|
|
|
## March 19th, 2025 - JME
|
|
|
|
**ScreenShake**
|
|
|
|
I have already done this in the GML version however it has to be reimplemented to work with our current class structure. We should be able to add a ScreenShake() function to the Camera2D class that takes in shake time and shake magnitude arguments.
|
|
|
|
The function will work by randomly changing the cam position between the current position + magnitude and current position - magnitude. We already have a nice function written in our LunaLigthGame class that randomly chooses a number between to set numbers. **side note** It might be nice to create a utility class and move this function over there so we can use it from anywehre.
|
|
|
|
**Refining camera movement a bit**
|
|
|
|
When the player stops the camera slows to a stop. This is good except that in the last few mometns the camera gets kinda shakey beacause the Lerp() function we are using calculates to the 5th decimal and as it approaches the final postion the camera jumps from pixel to pixel slowly.
|
|
|
|
Rather than use Lerp() let's explicitly define our follow code and once the cam position is witin a certain threshold of target position we can snap it to the target position.
|
|
|
|
**Needs more refinement** |