bugBattle for Wesnoth - Bugs: bug #21883, Extremely jerky motion when...

Show feedback again

bug #21883: Extremely jerky motion when clearing fog

Submitted by:  Matthias Schoeck <mattsc>
Submitted on:  Tue Apr 1 17:37:29 2014  
Category: BugSeverity: 4 - Important
Priority: 5 - NormalItem Group: Graphics
Status: FixedPrivacy: Public
Assigned to: David Mikos <coffee>Open/Closed: Closed
Release: 1.11.12+devOperating System: OS X 10.9

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Sun Apr 20 09:29:11 2014, comment #11:

Tested to work by mattsc (on irc). Marking as fixed and pushed to the 1.12 branch.

David Mikos <coffee>
Project MemberIn charge of this item.
Sun Apr 20 03:22:19 2014, comment #10:

I've pushed a change in commit f2f30b175768e7c456255a3207e6f4b3ffc57b60 for the 1.13 branch that should fix the problem. Can someone please test that had this problem before?

The problem looks to me like the default movement animation cycled between 0~1 offsets with increments of 200 ticks. If the tick counter was delayed the animation between individual hexes could repeat. i.e. 0, 33, 100, 177, 233 (picks up 33 in the next cycle backwards), etc. I set it to match the 'magic number' in the move_between function that I mentioned before and it appears smooth here now.

David Mikos <coffee>
Project MemberIn charge of this item.
Sat Apr 19 13:23:39 2014, comment #9:

Alright, this time it should work properly.

(file #20525)

Christian Bielert <cib>
Project Member
Sat Apr 19 13:16:53 2014, comment #8:

Oops looks like my transcoding tool messed up. Let me try that again..

Christian Bielert <cib>
Project Member
Sat Apr 19 13:15:24 2014, comment #7:

Okay, I've created a video showcasing the problem on my system.

/proc/cpuinfo gives me "Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz", and I'm not using CPUlimit, nor was there any load on the core running wesnoth(the other core was doing the recording), so this is a problem that definitely affects reasonably modern laptops.

(file #20524)

Christian Bielert <cib>
Project Member
Wed Apr 16 22:12:08 2014, comment #6:

Sigh. I had also hoped it would be fixed by now and I'm instead still working on it.

I thought I might post a script that I've created to quickly test this bug for reference:

./wesnoth -m &
cpulimit -l 12 -p $! > /dev/null 2>&1

David Mikos <coffee>
Project MemberIn charge of this item.
Wed Apr 16 19:47:13 2014, comment #5:

A few months ago I compiled from git and had this same issue. I had hoped it would be fixed by now. ;) The git version I used back then was 03777e745bf39a6bd6082ef7766f4326cf543d69, problem is at least this old.

Sun Apr 6 21:33:25 2014, comment #4:

After a bit more investigation I don't think it is a dirty graphics buffer issue any more.

In unit_display.ccp the funtion "move_unit_between" has a target_time with a magic number of 200 for an increment. Increasing this number manually leads to a cycling of the unit path between the individual hexes in a similar fashion to the earlier attached video. Lowering it speeds up the animation too quickly. This issue looks to require some more prodding and poking.

David Mikos <coffee>
Project MemberIn charge of this item.
Tue Apr 1 18:30:35 2014, comment #3:

Another thing from testing is that I get a similar issue with 1.10.6, just less of it with the same cpulimit approach on Linux.

David Mikos <coffee>
Project MemberIn charge of this item.
Tue Apr 1 18:04:20 2014, comment #2:

Actually with cpulimit and no fog/shroud I get the same type of problem, just to a lesser extent.

David Mikos <coffee>
Project MemberIn charge of this item.
Tue Apr 1 17:48:47 2014, comment #1:

I believe this is related to https://gna.org/bugs/?21316, where I used a workaround to fix for the specific case of "skip AI moves."

This bug can be easily replicated on linux by running "cpulimit -10 wesnoth" (or lower than 10% until the issue is apparent). This does not appear to be a disk loading issue, but an issue with the algorithm that draws the movement of units between hexes.

I should have some time to take a look this weekend at this bug, unless jamit wants to also have a go at it -- given this only occurs with fog/shroud on.

David Mikos <coffee>
Project MemberIn charge of this item.
Tue Apr 1 17:37:29 2014, original submission:

Since on-the-fly fog clearing was introduced, unit movement animations can be very jerky in OS X. This does not only result in stop-and-go motion, but in the units jumping back and forth between hexes erratically.

An extreme case is captured in this video. (It's 4MB and with that too large for an attachment.)

This only happens when the map is fogged (yes, fog was on in that video, it just doesn't show for a technical reason) and it is worse when map, idle and standing animations are enabled in the preferences, as well as when other processes take up CPU time.

It happens in both windowed and fullscreen mode, and in normal speed and accelerated speed. It also happens for both debug and release builds.

This seems to happen on OS X even on medium-fast systems because
of the way how the framebuffer is handled on Macs (or something like that, I don't understand those issues very well). However, it has been reproduced on Linux using 'cpulimit -2'. It is therefore likely an issue at least for slow systems with other OSs as well.

To reproduce:
- Start first scenario of Heir to the Throne
- Type :debug and :fog (to turn on fog)
- Recruit a couple fighters and end the turn
- On turn 2, move the fighters so that they clear as many fogged hexes as possible

Matthias Schoeck <mattsc>
Project Member


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #20525:  fog.mp4 added by cib (850kB - video/mp4 - Showcase difference between movement with and without fog.)
file #20524:  fog.mkv added by cib (773kB - video/x-matroska - fog.mkv is "realtime" and fog_slowmo.mkv is at 1/3rd speed)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by shadowmaster (Updated the item)
  • -unavailable- added by cib (Updated the item)
  • -unavailable- added by coffee (Posted a comment)
  • -unavailable- added by mattsc (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Apr 23 00:54:34 2014shadowmasterOpen/ClosedOpen=>Closed
    Sun Apr 20 09:29:10 2014coffeeStatusReady For Test=>Fixed
    Sun Apr 20 03:22:19 2014coffeeStatusNone=>Ready For Test
    Sat Apr 19 13:23:39 2014cibAttached File-=>Added fog.mp4, #20525
    Sat Apr 19 13:15:24 2014cibAttached File-=>Added fog.mkv, #20524
    Tue Apr 1 17:48:47 2014coffeeAssigned toNone=>coffee
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup