[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-20 Thread Marko Lindqvist
Update of bug #19921 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at:

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-18 Thread Marko Lindqvist
Update of bug #19921 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi ___ Reply to this item at:

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-15 Thread Jacob Nevins
Follow-up Comment #5, bug #19921 (project freeciv): Raised longstanding déjà vu effect separately as bug #19946. ___ Reply to this item at: http://gna.org/bugs/?19921 ___ Message sent

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-15 Thread Jacob Nevins
Follow-up Comment #6, bug #19921 (project freeciv): 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

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-15 Thread Jacob Nevins
Follow-up Comment #7, bug #19921 (project freeciv): However, I can confirm that the attached patch solves my problem. ___ Reply to this item at: http://gna.org/bugs/?19921 ___ Message sent

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-15 Thread anonymous
Follow-up Comment #8, bug #19921 (project freeciv): 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

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-11 Thread anonymous
Follow-up Comment #1, bug #19921 (project freeciv): 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

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-11 Thread anonymous
Follow-up Comment #2, bug #19921 (project freeciv): 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

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-11 Thread Marko Lindqvist
Follow-up Comment #3, bug #19921 (project freeciv): 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

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-11 Thread anonymous
Follow-up Comment #4, bug #19921 (project freeciv): In such case, lets add that call to try to solve the initial problem. Still, that speed difference is odd. (file #16063) ___ Additional Item Attachment: File name: update-map-anim.patch

[Freeciv-Dev] [bug #19921] Intermediate animation steps in map update not visible

2012-07-10 Thread Jacob Nevins
URL: http://gna.org/bugs/?19921 Summary: Intermediate animation steps in map update not visible Project: Freeciv Submitted by: jtn Submitted on: Wed Jul 11 01:07:04 2012 Category: client-gtk-3.0 Severity: