Skip to content

Conversation

@Enovale
Copy link

@Enovale Enovale commented Mar 20, 2023

Currently, even with BasicInputQOL you cannot zoom out very far and it makes the game feel very claustrophobic and makes navigation more cumbersome than it should be. I set out to rectify this problem and ended up resolving a lot of other things along the way.

  • I've reworked the game's rendering code to be able to handle the camera being outside of the world bounds (SceneGraph.width/length, or below 0 on either axis). This required:
    • Adding more sanity checks to the code that adds the visible tiles to the stack
    • Adjusting the view limit sanity checks to have 1 be the minimum, instead (I would like to improve this in the future but currently the only functional difference in rendering this causes occurs if the camera is out of bounds so it's not important.)
    • Renaming and deobbing a TON of rendering code
  • I've adjusted the Plugin API to allow the user control of their camera. This entailed:
    • Modifying the Plugin API to let you specify your own minimum and maximum Camera.ZOOM values with an overload.
    • Updating the BasicInputQOL plugin to allow you to customize the minimum and maximum zoom with some chat commands.
    • Adding a new plugin called RenderSettings that let's you increase/decrease the game's TILE_DISTANCE and it's dependent variables with a chat command.
  • I've overhauled the Plugin API to fix a few bugs that existed in it. This involved:
    • Call OnLogin when the state is 25 instead of 30 as OnLogin was never getting called before
    • Adjust getTileHeight in SceneGraph and clampCameraAngle in Camera to be able to catch a race condition that's caused by API trying to clamp the camera angle on another thread (Honestly this should just be done manually because a lot of redundant code is still run)
    • Rename the current Plugin Update() to Tick() so that it indicates better the function of the override. This forced me to change:
      • All the existing plugins to use Tick instead of Update
    • Add a new Update() method that gets called every game loop so that plugins can check for game state and other such things. This meant:
      • Moving the deltaTime parameter to Update instead of Draw as Draw shouldn't be using it
      • Adjusting XPDropPlugin to use Update for moving the new gains and Draw to actually display them, for consistency.

@Pazaz
Copy link
Owner

Pazaz commented Mar 20, 2023

Hi Enovale - thanks for the contribution!

I need to check through it a bit but from a cursory overview the changes/refactoring look positive.

If there’s any breaking API changes (I see you touched on the plugin system) I’ll have to do some coordination first before merging and deploying after everything checks out. Tagged releases will deploy automatically and clients will break when loading.

I’ll review here if I notice or need anything.

@KamjaImo
Copy link

KamjaImo commented Jun 1, 2024

Hey there - I'm curious if this PR is still in progress? I forked Enovale's branch because it had a lot of good deob that I wanted to make changes on top of, but now that I've seen the age of this PR, I'm starting to doubt that decision. Should I go ahead and rebase my changes to the original, or should I just be patient for a bit longer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants