[Wesnoth-bugs] [bug #20352] Assertion failure line 631 of src/whiteboard/side_actions.cpp line 631, done via planning mode

2015-10-12 Thread Wedge009
Follow-up Comment #3, bug #20352 (project wesnoth): Using the conditions jamit described (primarily ending the first planned move on a friendly unit), I find the following in 1.13.1+dev: Turn indicator 1: Not possible as this results in the friendly unit being selected. Turn indicator 2:

[Wesnoth-bugs] [bug #23932] show current turn when observing

2015-10-12 Thread anonymous
URL: Summary: show current turn when observing Project: Battle for Wesnoth Submitted by: None Submitted on: Mo 12 Okt 2015 15:51:32 UTC Category: Feature Request Severity: 3 -

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Andreas Löf
Follow-up Comment #1, bug #23918 (project wesnoth): I think this needs to be tested on SDL2, I suspect that at least some of these issues may be fixed already. ___ Reply to this item at:

[Wesnoth-bugs] [bug #23908] SDL2 SDL_BlitSurface Causes Crashes

2015-10-12 Thread Andreas Löf
Update of bug #23908 (project wesnoth): Status: In Progress => Ready For Test ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Adam Dunn
Follow-up Comment #2, bug #23918 (project wesnoth): I've tried checking out the sdl2 branch, getting the "Xcode compilation material", and putting the latest SDL2 development framework files into /projectfiles/Xcode/lib, but the compile fails with: Undefined symbols for architecture x86_64:

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Celtic Minstrel
Follow-up Comment #3, bug #23918 (project wesnoth): I removed that class because I was getting a runtime warning about multiple definitions of the class, but it looks like for some reason the other definition doesn't exist for you. The class is still defined in SDLmain.m but only enabled for

[Wesnoth-bugs] [bug #23934] Resize actions are laggy

2015-10-12 Thread Andreas Löf
URL: Summary: Resize actions are laggy Project: Battle for Wesnoth Submitted by: aginor Submitted on: Mon 12 Oct 2015 09:06:38 PM UTC Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Andreas Löf
Update of bug #23918 (project wesnoth): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #5: Closing as it's

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Andreas Löf
Update of bug #23918 (project wesnoth): Open/Closed: Closed => Open ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Ignacio R. Morelle
Follow-up Comment #6, bug #23918 (project wesnoth): Reopening since it affects 1.13.1. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/

[Wesnoth-bugs] [bug #23918] UI Graphics In OS X El Capitan

2015-10-12 Thread Adam Dunn
Follow-up Comment #4, bug #23918 (project wesnoth): Yes, that seems to fix it. Removing the line +verbose+ #if !SDL_VERSION_ATLEAST(2,0,0) -verbose- and the corresponding #endif from SDLMain.m (lines 19 and 49 at revision eebe3cf) let it finish compiling. Interestingly, if I try to run it from

[Wesnoth-bugs] [bug #23908] SDL2 SDL_BlitSurface Causes Crashes

2015-10-12 Thread Wedge009
Follow-up Comment #2, bug #23908 (project wesnoth): The work-around committed recently works around the first issue satisfactorily if not perfectly. Great job! The second case still results in a crash and I'm not sure how to apply the work-around to this situation. Clarification on how to

[Wesnoth-bugs] [bug #23910] Intermittent System Icon on Windows

2015-10-12 Thread Wedge009
Follow-up Comment #3, bug #23910 (project wesnoth): This seems to be fixed as a side-effect of working around Bug #23908. Bonus! Happy to have this closed as Fixed. ___ Reply to this item at:

[Wesnoth-bugs] [bug #23934] Resize actions are laggy

2015-10-12 Thread Wedge009
Follow-up Comment #1, bug #23934 (project wesnoth): Obviously this is exacerbated on slower machines. In Linux, I notice display corruption while waiting for the window to be updated with the new resolution. In contrast, Windows simply shows a clean blank display (all black) before the window