Skip to content

Add smooth-movement plugin - #5875

Open
notliad wants to merge 6 commits into
DFHack:developfrom
notliad:plugin/smooth-movement
Open

Add smooth-movement plugin#5875
notliad wants to merge 6 commits into
DFHack:developfrom
notliad:plugin/smooth-movement

Conversation

@notliad

@notliad notliad commented Aug 13, 2026

Copy link
Copy Markdown

Summary

Adds the smooth-movement plugin to DFHack. It provides smooth visual interpolation for creatures, items, vehicles, and related overlays in the fortress viewport.

Notes

I closed the previous PR in favor of this version, which preserves the original code structure that was already reviewed by humans in the standalone repository.

Standalone repository: https://github.com/notliad/df-smooth-movement

Testing

  • Built the smooth-movement plugin through the DFHack build system.
  • Built and ran smooth-movement-test.
  • All regression assertions passed.

@@ -0,0 +1,1314 @@
// SPDX-License-Identifier: MIT

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From our license statement

The core, plugins, scripts, and other DFHack code all use the ZLib license unless noted otherwise. By contributing to DFHack, authors release the contributed work under this license.

Please relicense under ZLib so I don't have to add an additional line to our licenses statement for this plugin

std::set<std::pair<int32_t, int32_t>> previous_coverage;
uint64_t visual_context_revision = 0;
const void *previous_viewport = nullptr;
std::array<int32_t, 12> previous_view_signature{};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this an array? looking elsewhere, it looks like each of these 12 elements has a fixed, established meaning, which means this should be a proper compound of some sort

decltype(&SDL_SetRenderDrawColor) set_render_draw_color = nullptr;

visual_animation_managerst animation_manager;
std::set<std::pair<int32_t, int32_t>> previous_coverage;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this not a tile_coveragest?

SDL_Texture *texture;
bool mirrored = false;
int32_t mirror_shift = 0;
std::set<std::pair<int32_t, int32_t>> coverage;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should also be a tile_coveragest

int8_t center_y;
};

constexpr std::array visual_layer_descriptors = {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where are the magic numbers here coming from?

@ab9rf

ab9rf commented Aug 13, 2026

Copy link
Copy Markdown
Member

A general comment as this is a pervasive issue and I do not wish to pepper the review with dozens if not hundreds of comments: there are a lot of operations in here that work on (x,y) coordinate pairs that involve effectively duplicated code. DFHack has a 2d coordinate type df::coord2d that can be used to store a coordinate pair as a unit and operate on both components in parallel. Consider using df::coord2d in lieu of separate x and y variables wherever possible as this provides clearer indication of intention as well as reducing the risk of updating one but not the other resulting in inconsistent behavior.

I've made some other specific comments but this should not be considered a full review.

@notliad

notliad commented Aug 13, 2026

Copy link
Copy Markdown
Author

A general comment as this is a pervasive issue and I do not wish to pepper the review with dozens if not hundreds of comments: there are a lot of operations in here that work on (x,y) coordinate pairs that involve effectively duplicated code. DFHack has a 2d coordinate type df::coord2d that can be used to store a coordinate pair as a unit and operate on both components in parallel. Consider using df::coord2d in lieu of separate x and y variables wherever possible as this provides clearer indication of intention as well as reducing the risk of updating one but not the other resulting in inconsistent behavior.

I've made some other specific comments but this should not be considered a full review.

This will be a substantial refactor. I will look into it and the others comments as well.
I'm bit worried making lots of changes cause I can't reproduce (on both of my machines) the most common bug and need someone to test it for me, this can take a day or two.

@notliad

notliad commented Aug 14, 2026

Copy link
Copy Markdown
Author

Camera feature was not working properly and introduced a mouse click bug so I opted to remove it.

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.

2 participants