|
Fri 20 Jul 2012 10:37:05 PM UTC, SVN revision 21594:
Make unit movement animation visible on gtk3-client.
Reported by Jacob Nevins , patch by Anonymous.
See gna bug #19921
(Browse SVN revision 21594) |
Fri 20 Jul 2012 10:37:00 PM UTC, SVN revision 21593:
Make unit movement animation visible on gtk3-client.
Reported by Jacob Nevins , patch by Anonymous.
See gna bug #19921
(Browse SVN revision 21593) |
Sun 15 Jul 2012 10:51:10 PM UTC, comment #8:
My mistake - that was simply iso, not isohex (Amplio2, if it matters).
Not that I looked closer at the code, but I suspect it's the method of measuring the distance that plays a role here - I was testing by setting very high Unit Movement Animation Time and N/S delays differed from S/W ones significantly.
|
Sun 15 Jul 2012 05:50:48 PM UTC, comment #7:
However, I can confirm that the attached patch solves my problem.
|
Sun 15 Jul 2012 05:50:31 PM UTC, comment #6:
> BTW, why does it seem that on an isohex map when moving in
> cardinal directions (N/S/E/W), N/S moves seem far slower than
> E/W ?
Not sure what you mean here? -- on an iso|hex topology, you can only move N/S, you can't move directly E/W.
I can't reproduce any variation in movement times in either the Gtk2 or Gtk3 clients.
|
Sun 15 Jul 2012 05:36:05 PM UTC, comment #5:
Raised longstanding "déjà vu" effect separately as bug #19946.
|
Wed 11 Jul 2012 01:34:52 PM UTC, comment #4:
In such case, lets add that call to try to solve the initial problem.
Still, that speed difference is odd.
(file #16063)
|
Wed 11 Jul 2012 12:16:16 PM UTC, comment #3:
I noticed comment in move_unit_map_canvas() about setting up target tile first, and wondered wouldn't it cause such problems of unit being drawn there before move animation. Maybe it was considered something that nobody's brain would register in the fractions of the second unit moves.
|
Wed 11 Jul 2012 11:47:23 AM UTC, comment #2:
> That is the unit gets drawn in the base while it's still moving there.
Yeah, I see that sort of thing a lot in the Gtk2 client. Also with transports containing lots of units, I think. Never got round to investigating it.
--jtn
|
Wed 11 Jul 2012 11:21:43 AM UTC, comment #1:
So,...
Adding 'gdk_window_process_updates(gtk_widget_get_window(map_canvas), FALSE);' in void flush_dirty(void) seems to get the desired effect (that is IIUC what the desired effect is), but there's a tiny catch.
In my save I've got a combined airbase/fortress with one guerrilla unit and a few engineers. If I select the guerrilla and move it a bit around the base (lots of railroads around), I'm getting a sort of reverse deja vu as I move the unit back to the base. That is the unit gets drawn in the base while it's still moving there.
It would seem that this is not the problem in this particular client, but in common client code.
BTW, why does it seem that on an isohex map when moving in cardinal directions (N/S/E/W), N/S moves seem far slower than E/W ?
|
Wed 11 Jul 2012 12:07:04 AM UTC, original submission:
As posted to freeciv-dev:
Not sure if this is a bug or expected behaviour.
With the Gtk3 client, I've noticed that intermediate updates to the map don't seem to be drawn. For instance if I start a game and then hit "X" on my Explorer, he instantly appears three tiles away, whereas with the Gtk2 client, I see all the intermediate steps.
(My Gtk3 machine is a slowish netbook, in case it makes a difference.)
cazfi responded:
"Even if it's "expected" result of the way buffering (or something) has been made, this has to be fixed somehow.
"I confirmed this by setting very high Unit Movement Animation Time. When I then moved a unit, nothing happened for a while (time I set) and then unit appeared in its target tile. I also added logging to move_unit_map_canvas() to show coordinates it tries to draw unit to, and that number changed pixel by pixel from old tile to new one."
|
Related Recipes:
Freeciv - Bugs: bug #19921, Intermediate animation steps in...