--- Log opened Tue Jan 12 00:00:16 2016
20160112 00:04:52< vultraz> gfgtdf: ok I think I've gotten gui1 relying on just cvideo now
20160112 00:05:36< vultraz> gfgtdf: I wonder if it's worth it to keep a CVideo argument to the gui1 constructor or just initialize a var with a pointer to CVideo::get_singleton()
20160112 00:05:39< vultraz> what do you think
20160112 00:07:20< vultraz> since it now relies on CVIdeo only (I thin) and there's only 1 cvideo instance
20160112 00:08:59< gfgtdf> vultraz: hmm i'd vote for the CVideo argument, just in case that soneone later wants to implement a ways to have multiple cvideos/screens or something
20160112 00:09:36< vultraz> hm
20160112 00:10:11< vultraz> can I give it a default value to cvideo::get_singleton()?
20160112 00:10:15< vultraz> in the header
20160112 00:10:22< gfgtdf> vultraz: hmm why?
20160112 00:13:18< vultraz> gfgtdf: well mainly to reduce function arguments 
20160112 00:13:40< gfgtdf> vultraz: hmm no i think there is no reason for a defauklt argument like that
20160112 00:14:09< vultraz> ok so I should revert this and just change display& to CVideo&? https://github.com/Vultraz/wesnoth/commit/817ace25dea041ca55c728b58d1c66beebb88794
20160112 00:14:33< vultraz> (and pass disp.video() to the callers where appropriate)
20160112 00:18:44-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 256 seconds]
20160112 00:19:44< gfgtdf> vultraz: y this also menas changing the memeber variable disp_ to video_
20160112 00:19:57< vultraz> ya
20160112 00:21:27-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20160112 00:36:39-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20160112 00:54:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160112 01:13:31< vultraz> gfgtdf: ok
20160112 01:13:41< vultraz> gfgtdf: https://github.com/Vultraz/wesnoth/commit/24b1b91dd138d851766e301476356f69c40ec446
20160112 01:33:55-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160112 02:00:32-!- mjs-de [~mjs-de@x4db51705.dyn.telefonica.de] has joined #wesnoth-dev
20160112 02:02:25< gfgtdf> vultraz: looks good but the travis gives errors
20160112 02:02:53< gfgtdf> vultraz: in file hotkey_preferences_display.cpp
20160112 02:02:54< vultraz> yes looking into it now
20160112 02:03:41< vultraz> oh, some changes didn't get in my commit
20160112 02:09:44< gfgtdf> vultraz: i just noticed that you replaced soem get_display().video() wiuth CVideo::get_singleton()
20160112 02:09:52< vultraz> yes
20160112 02:10:00< vultraz> I got errors saying get_display() wasn't declared
20160112 02:10:02< vultraz> not sure why
20160112 02:10:04< gfgtdf> vultraz: it woudl be better to have a get_video() method where the get_display() was, and teh use that
20160112 02:10:13< gfgtdf> vultraz: becasue you rmeoved get_display
20160112 02:10:19< vultraz> wait, I did
20160112 02:10:30< vultraz> ?
20160112 02:10:36< gfgtdf> vultraz: yes: https://github.com/wesnoth/wesnoth/pull/580/files#diff-91be02837a14cbe330ea0d1a90944283L280
20160112 02:10:57< vultraz> ohh
20160112 02:11:52< vultraz> you think I should change that to get_video?
20160112 02:12:03< gfgtdf> vultraz: yes
20160112 02:19:18-!- irker788 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160112 02:19:22-!- gfgtdf_ [~chatzilla@x50ab9553.dyn.telefonica.de] has joined #wesnoth-dev
20160112 02:20:29< vultraz> fixed
20160112 02:20:35< vultraz> also removed a change in about.cpp
20160112 02:21:31< gfgtdf_> vultraz: staticsitc dialog also uses Cvideo::get_singleton
20160112 02:21:37< gfgtdf_> statistics_dialog.cpp
20160112 02:21:48-!- gfgtdf [~chatzilla@x50ab97e3.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
20160112 02:22:02-!- gfgtdf_ is now known as gfgtdf
20160112 02:24:00< vultraz> Fixed
20160112 02:25:05< vultraz> gfgtdf: do you have any idea how to fix 24139?
20160112 02:25:37< gfgtdf> vultraz: yes but not completeley sure if wheterh it works
20160112 02:30:24< gfgtdf> vultraz: hmm seems liek my make CVideo a singleton commti broke the boost unit tests
20160112 02:30:48 * vultraz wonders why void game_launcher::show_preferences() is a thing
20160112 02:31:30< gfgtdf> iceiceice: doy ou know whether each boost unit test is run in a seperate process or whether all tests are run in one process ?
20160112 02:31:33< vultraz> hm...
20160112 02:31:38< gfgtdf> do you*
20160112 02:31:43< vultraz> gfgtdf: you wanted to remove game_display& game_launcher::disp()?
20160112 02:31:49< vultraz> that block, I mean
20160112 02:31:56< gfgtdf> vultraz: yes
20160112 02:32:20< gfgtdf> vultraz: there are quite soem codes that use
20160112 02:32:22< gfgtdf> it
20160112 02:32:34< gfgtdf> vultraz: not wure whther there is any which actually need it
20160112 02:32:38< gfgtdf> needs*
20160112 02:33:27< vultraz> yeah
20160112 02:33:32< vultraz> 13 cases of disp() in that file
20160112 02:33:55< vultraz> do you want me to look at some of the usecases?
20160112 02:34:43< gfgtdf> vultraz: hmm y, but i think its easier fi we first merge your pr
20160112 02:34:50< vultraz> ok
20160112 02:34:54< vultraz> i'm waiting on travis
20160112 02:54:42< gfgtdf> vultraz: wait
20160112 02:54:48< vultraz> hm?
20160112 02:54:52< gfgtdf> vultraz: why does the travis buidl now build?
20160112 02:55:07< vultraz> gfgtdf: I forcepushed
20160112 02:55:17< gfgtdf> vultraz: i thought teh previosul error was caused by my make it a singelton commit, but but it boulds on your pr
20160112 02:55:23< vultraz> I had accidentally left out some files from the commit
20160112 02:55:25< gfgtdf> vultraz: must have been something differnet
20160112 02:55:47< gfgtdf> vultraz: hmm but were runtone erorrs and not compilation errors
20160112 02:56:01< vultraz> ...huh
20160112 02:56:14< vultraz> i thought they were compliation 
20160112 02:56:22< vultraz> [13:02:50]	gfgtdf	vultraz: in file hotkey_preferences_display.cpp
20160112 02:57:31< gfgtdf> vultraz: its another commit
20160112 02:57:39< gfgtdf> vultraz: at this commit i mean: https://github.com/wesnoth/wesnoth/commit/88e1a69c0420e43460fd1f986dc496f6944e6586
20160112 02:58:08< gfgtdf> vultraz: it fives an eror about Cvideo beeong creaed twice and i dotn know why
20160112 02:58:11< gfgtdf> gives*
20160112 02:58:33< vultraz> that's not on my branch, is it?
20160112 02:58:48< vultraz> though
20160112 02:58:54< vultraz> that was the commti I left some changes out of
20160112 02:58:56< vultraz> commit*
20160112 02:59:22< gfgtdf> vultraz: ah wait
20160112 02:59:53< gfgtdf> vultraz: it still gives that errors but it seems liek its not importatn enough for travis to mar that test as failed
20160112 03:00:13-!- fabi [~quassel@176.6.123.5] has joined #wesnoth-dev
20160112 03:00:13-!- fabi [~quassel@176.6.123.5] has quit [Changing host]
20160112 03:00:13-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20160112 03:00:24-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20160112 03:13:56< gfgtdf> vultraz: 4 of 5 tests passed already i think you can merge
20160112 03:15:30-!- irker383 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160112 03:15:30< irker383> wesnoth: Charles Dang wesnoth:master 4afd41514386 / src/ (15 files in 7 dirs): Decoupled delay() from display class and moved it to a static CVideo function http://git.io/vztbF
20160112 03:15:33< irker383> wesnoth: Charles Dang wesnoth:master 41dab9fe5b11 / src/ (construct_dialog.cpp help/help.cpp): Remove GUI1 calls to invalidate_all() http://git.io/vztbb
20160112 03:15:36< irker383> wesnoth: Charles Dang wesnoth:master 716b6e8e8774 / src/ (construct_dialog.cpp dialogs.cpp help/help.cpp): Call CVideo::flip() instead of display::flip() in GUI1 http://git.io/vztbN
20160112 03:15:39< irker383> wesnoth: Charles Dang wesnoth:master 8c0e56213bb8 / src/ (18 files in 6 dirs): Convert GUI1 functions to use CVideo directly instead of display http://git.io/vztbA
20160112 03:15:42< irker383> wesnoth: Charles Dang wesnoth:master 5f732c3dfb49 / src/ (construct_dialog.hpp filechooser.cpp statistics_dialog.cpp): Restore a GUI1 get_video method http://git.io/vztbx
20160112 03:15:45< irker383> wesnoth: Charles Dang wesnoth:master aff6c1b998ab / src/ (31 files in 10 dirs): Merge pull request #580 from Vultraz/master http://git.io/vztbp
20160112 03:15:54< vultraz> gfgtdf: ^
20160112 03:17:18< gfgtdf> vultraz: ok
20160112 03:17:25< gfgtdf> vultraz: thx
20160112 03:29:42< celticminstrel> If it's not WIP, I wish you'd removed that from the commit message.
20160112 03:46:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 03:49:34< gfgtdf> vultraz: hmm i think a good start to remove teh display class from game_launcher woudl be ro remove it from the help_*** functions becaseu those functions are used by many other places it seems
20160112 03:50:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160112 03:56:42< vultraz> gfgtdf: yeah I want to remove the display argument from help so GUI2 dialogs don't need to pass disp
20160112 03:59:25< vultraz> will do that next
20160112 04:01:40-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160112 04:04:26-!- gfgtdf [~chatzilla@x50ab9553.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160112 04:05:23-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 255 seconds]
20160112 04:05:23-!- wedge010 is now known as wedge009
20160112 04:12:30-!- mjs-de [~mjs-de@x4db51705.dyn.telefonica.de] has quit [Remote host closed the connection]
20160112 04:34:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 04:39:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160112 04:54:35-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 240 seconds]
20160112 05:20:23-!- shadowm [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160112 05:32:37< shadowm> Hi.
20160112 05:40:13< celticminstrel> Finally got around to posting this https://gna.org/bugs/index.php?24304
20160112 05:49:05-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160112 05:51:08-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160112 05:55:09< zookeeper> shadowm, oh, you're back?
20160112 05:57:29< shadowm> At least one developer has contacted me thus far asking for 1.13.3, so if the team feels it's the right time for 1.13.3 I can't say no to that.
20160112 06:00:18< shadowm> Although moving forward I'd like to have someone replace me esp. in the steering/quality control role so I can actually devote time to my own Wesnoth and non-Wesnoth code. It's been a whole year of me and I'm pretty sure you're all yearning for a superior substitute.
20160112 06:01:57< shadowm> Plus the stuff I said about a break for health reasons still applies, I'm just pausing it momentarily.
20160112 06:07:14< zookeeper> well, that's unfortunate, but i guess you know what you're doing. i can't exactly picture who these potential superior substitutes might be, though.
20160112 06:13:09< Aginor> I'm opposed to making CVideo a singleton, just to make my postion on that clear
20160112 06:13:29< Aginor> shadowm: I hope you are keeping well and looking after yourselves
20160112 06:14:12< shadowm> Ij
20160112 06:14:16< shadowm> Oops.
20160112 06:14:33< shadowm> Uh, thanks, but AFAIK I'm only one person, not a collective. :p
20160112 06:14:58< Aginor> :D
20160112 06:15:11< Aginor> I am tired, I just get home from work :D
20160112 06:16:08-!- irker383 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160112 06:18:44< zookeeper> so, i guess no one objects if i just merge https://github.com/wesnoth/wesnoth/pull/563 ?
20160112 06:20:06< zookeeper> i haven't encountered any problems with it so far and i'm going to be using it myself anyway.
20160112 06:21:43< vultraz> sure, merge it
20160112 06:21:49< vultraz> Aginor: what's wrong with it being a singleton?
20160112 06:22:52< Aginor> vultraz: at the moment the class is tied to a single window, but in the future it could potentially be multiple game windows
20160112 06:23:13< Aginor> by turning it into a singleton we will expand energy to make it harder to make changes in the future
20160112 06:23:32< Aginor> s/expand/expend/
20160112 06:25:11< Aginor> longer term I'm thinking that it'd be nice to have the video class disappear altogether and be replaced with the window class
20160112 06:25:21< vultraz> We really should make a decision on that multiple windows thing
20160112 06:25:39< Aginor> vultraz: we don't need to
20160112 06:25:55< Aginor> vultraz: I just don't think we should spend energy on that at this point :)
20160112 06:26:30< Aginor> but having the window class replace video is probably desirable in the longer run
20160112 06:26:31< vultraz> well you'll have to talk to gfgtdf, since he made the change
20160112 06:26:50< vultraz> in the meantime, I've merge my PR, so I'm not going to get to work doing more disp -> video transitions 
20160112 06:27:02< vultraz> if we want display to actually be a singleton
20160112 06:27:10< vultraz> ok wow
20160112 06:27:21< vultraz> I've merged my PR, so I'm now going to get to work*
20160112 06:27:35< Aginor> fair enough :)
20160112 06:28:06< vultraz> Aginor: did you see my message about the redraw_everything() calls causing the dialog undraw issues?
20160112 06:28:16< vultraz> if you remove them from help the bug goes away
20160112 06:29:39< Aginor> vultraz: yes, but it breaks other stuff
20160112 06:30:09< Aginor> vultraz: (no, I didn't see your message. Roughly how long ago?)
20160112 06:30:31< vultraz> [00:50:59]	vultraz	Aginor: hey, I found a fix for the help dialog redrawing dialogs under it: remove the calls to redraw_everything() after the dialog closes
20160112 06:30:32< vultraz> [00:53:50]	vultraz	Aginor: you added them in 422ab071912b1159e67427b36c528f99d4b299e3
20160112 06:30:39< vultraz> so... ~17 hours
20160112 06:31:11< Aginor> vultraz: I think the correct solution is to add a proper draw manager and make sure that closing a window marks all underlying components as dirty and then trigger a full redraw
20160112 06:31:24< Aginor> a partial redraw would be better, but that's too hard at this point
20160112 06:32:02< Aginor> bonus: We can stop using the surface restorers (I hope), which will bring usyet another step closer to hardware acceleation
20160112 06:32:07< vultraz> shadowm: do you have a prototype of a GUI2 prefs dialog somewhere? 
20160112 06:32:16< vultraz> Aginor: ahh good 
20160112 06:32:35< vultraz> Aginor: will hw accel improve map scrolling?
20160112 06:32:48< Aginor> vultraz: is it bad for you?
20160112 06:32:51< Aginor> (yes)
20160112 06:33:04< Aginor> hw acceleration will improve everything if done right
20160112 06:33:14< vultraz> yes, map scrolling is pretty laggy
20160112 06:33:18< vultraz> but it's always been
20160112 06:33:34< Aginor> with the right kind of hardware acceleration you can even get a cup of coffee in the morning
20160112 06:35:04< Aginor> vultraz: I'd be interested in knowing more about that. It's not obviously laggy to me, so it'd be good to investigate a bit
20160112 06:35:04< vultraz> zookeeper was working on https://github.com/wesnoth/wesnoth/pull/445 last year which was a bit of an improvement, but he never finished it
20160112 06:35:04< Aginor> I'd also like ot know your CPU, RAM and video card
20160112 06:35:09< vultraz> Aginor: the biggest thing I notice is it's better at scrolling top-down
20160112 06:37:00< vultraz> Aginor: do you remember a few months back I noticed that weird text ghosting bug in the Credits?
20160112 06:37:28< vultraz> I don't know if it's the non-smooth scrolling, but to me it looks as if a similar thing happens on scroll 
20160112 06:37:39< vultraz> but I'm not sure
20160112 06:37:43< vultraz> maybe it's just the 'steps
20160112 06:37:57< Aginor> vultraz: maybe
20160112 06:38:08< Aginor> I don't think anyone ever fixed the credits thing though
20160112 06:38:13< Aginor> I completely forgot about it
20160112 06:38:30< zookeeper> vultraz, Aginor, as far as i could tell, #445 fixes the map scrolling lag, but i'm really not happy with its non-parallelized brute-force method which is really slow.
20160112 06:38:50< vultraz> No the credits were never fixed
20160112 06:39:00< vultraz> Scrolling looks a little better, though
20160112 06:39:02< vultraz> dunno what happened 
20160112 06:39:08< vultraz> effect is still there, but it's smoother
20160112 06:39:19< vultraz> s/scrolling/scrolling text in the credits
20160112 06:40:07< zookeeper> also, the map scrolling lag you get at the beginning of scenarios is all about image loading, not drawing.
20160112 06:42:16< Aginor> spritesheets :)
20160112 06:42:38< Aginor> although you still need to load them
20160112 06:43:02< Aginor> so if the images are loaded after the loading screen, what is it spending all the time on?
20160112 06:43:31< vultraz> we wanted to implement spritesheets years ago, but there were issues with getting the segments in a timely matter..
20160112 06:43:53< zookeeper> Aginor, i don't understand the question
20160112 06:44:21< shadowm> vultraz: ... segments?
20160112 06:44:57< vultraz> shadowm: ok, that's the wrong term.... whatever it is you do with a spritehseet 
20160112 06:45:02< vultraz> we couldn't do it for some reason
20160112 06:45:08< shadowm> There... weren't such issues.
20160112 06:45:18< Aginor> zookeeper: trying to rephrase; How come the images are not loading during the loading screen? What happens during the loading screen?
20160112 06:45:28< shadowm> The issue was that either the student proposals were subpar/rejected, or the student herself quit.
20160112 06:45:43< vultraz> .... oh
20160112 06:45:54< vultraz> well ok then
20160112 06:46:06< shadowm> And no mainline developer has ever made a serious attempt at implementing spritesheets either.
20160112 06:46:10< zookeeper> Aginor, oh, okay. as far as the terrains/map goes, during the loading screen it just basically makes a big list of all the images needed by each hex, which are left to be lazy-loaded by the drawing code when needed.
20160112 06:46:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 06:46:28< shadowm> vultraz: https://github.com/wesnoth/wesnoth/compare/master...shikadilord:feature/gui2-game-preferences
20160112 06:46:29< zookeeper> and my PR adds a step which preloads all of them before exiting the loading screen
20160112 06:47:09< shadowm> PR #445 was fine AFAIAC other than the comments I posted.
20160112 06:47:19< Aginor> zookeeper: how complicated is that list-making-code? It feels like something that shouldn't take several seconds
20160112 06:47:21< vultraz> shadowm: thanks
20160112 06:47:30< shadowm> Posted back in August.
20160112 06:48:20< zookeeper> shadowm, yeah, since apparently i can't do it better, if others deem it an acceptable fix as-is then i'm fine with it too
20160112 06:48:28< shadowm> In fact I had planned to do something equivalent with unit sprites in my campaign at some point.
20160112 06:48:36< shadowm> Using Lua, though.
20160112 06:50:05< zookeeper> Aginor, the list-making code isn't slow, it's just the iteration through the list and running the image loading functions redundantly a gazillion times (even though the actual images are cached) which is slow.
20160112 06:50:21< Aginor> zookeeper: ah, that makes more sense
20160112 06:50:27< Aginor> zookeeper: thanks :)
20160112 06:50:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160112 06:51:14< shadowm> Also, just to make sure, this only loads valid images that would normally crop up in-game, right?
20160112 06:51:24< zookeeper> yes
20160112 06:51:31< shadowm> (i.e. we wouldn't want to waste cache entries on one billion empty pixmaps.)
20160112 06:51:38< zookeeper> only the images that the terrain rules dictate that appear on the map
20160112 06:52:13< zookeeper> Aginor, what i ideally wanted to do was to build a second list, a hashmap or something which would only contain each image once, and then start the preloading as soon as possible and run it in a separate thread.
20160112 06:52:34< Aginor> zookeeper: that makes a lot of sense
20160112 06:52:45< shadowm> I expect this to increase Wesnoth's RAM usage quite a lot in average. Not _significantly_ more than it would before when loading particularly complex and large maps, though.
20160112 06:52:48< Aginor> not entirely certain about the thread though :)
20160112 06:52:53< zookeeper> Aginor, unfortunately, i never got even the first part to work
20160112 06:54:01< shadowm> Hopefully some day someone will make accelerated graphics happen and all this cruft will live in VRAM instead in a compressed format instead.
20160112 06:54:40< zookeeper> shadowm, IIRC it doesn't increase the overall RAM usage, it should be the same amount as you'd normally get after you've scrolled around the whole map and gotten every image loaded
20160112 06:55:05< shadowm> Yes, with particularly complex and large maps.
20160112 06:55:28< shadowm> Or sessions that somehow get to use all the terrains in existence otherwise.
20160112 06:55:33< Aginor> solvents is looking into some of that at the moment. Supposedly :)
20160112 06:55:46< shadowm> Oh wait, does it only load terrains for the current map? Never mind then.
20160112 06:55:58< shadowm> solvents is a person I take it?
20160112 06:56:10< zookeeper> shadowm, yes
20160112 06:56:57< Aginor> has anyone heard from him in a while though?
20160112 06:57:04< Aginor> !lastseen solvents
20160112 06:57:14< shadowm> Worth noting that the image cache lasts forever during a session right now. It used to have an LRU limit but that was lifted after some shenanigans IIRC.
20160112 06:57:56< Aginor> shadowm: that explains the increasing memory usage over time
20160112 06:58:18< shadowm> Which is just as well since people these days abuse image path functions to the point where it makes no sense to have anything but an infinite cache.
20160112 06:59:24< zookeeper> Aginor, i'd expect that putting the preloader into a separate thread would in many if not most cases solve the scrolling lag without any extra waiting time in the loading screen. it'd do the bulk of the image loading while the player is reading a story screen or looking at the objectives or something.
20160112 06:59:27< shadowm> There is a separate surface cache for the legacy SDL_ttf text rendering path too, but it's incredibly small -- unless you are in the GUI1 MP lobby.
20160112 07:00:14< Aginor> zookeeper: potentially, I think there's scope for issues there
20160112 07:00:20< shadowm> (50 surfaces vs. 1000 surfaces.)
20160112 07:00:21< Aginor> zookeeper: I agree in theory though
20160112 07:02:07< zookeeper> Aginor, what kind of issues? i mean, aside from a need for a lock or two, i'd expect the drawing code and the associated image loading to remain as-is (meaning that if the preloader thread hasn't loaded an image before it's actually needed, the drawing code loads it just as it does now), and the preloader thread to simply be an addition which might or might not load a given image in time.
20160112 07:03:05< shadowm> The biggest issue is that all SDL calls must be done in the main thread, which is where all our UI logic lives too.
20160112 07:03:33< shadowm> I imagine this applies to SDL_image as well.
20160112 07:03:39< zookeeper> oh? well, i didn't know that.
20160112 07:05:11< shadowm> One way to go about it IMO would be to have the WML loading process take place in a separate thread instead.
20160112 07:06:14< shadowm> Meanwhile the main thread, somehow already aware of which resources need to be preloaded (perhaps from a previous run/developer-defined hints), can load those resources while the WML load thread somehow comes up with the Big WML Document™.
20160112 07:07:14< shadowm> s/resources/assets/g 
20160112 07:07:35< zookeeper> right, maybe. i don't know the WML loading code so can't guess how hard that would be
20160112 07:07:37< shadowm> Of course that'd require some adjustments to the parser and preprocessor to make sure they don't access resources owned by the main thread.
20160112 07:08:51< shadowm> OTOH I suspect the only such resource right now is the loading screen itself, which is guarded behind global functions anyway.
20160112 07:09:36< zookeeper> anyone happen to know whether it'd be easy to just simply adjust my PR so that those imageloading loops happen in a separate thread (without any concern for possibly resulting problems)? i don't know anything about how we currently use threading and what sort of utilities are available.
20160112 07:09:50< zookeeper> if it was simple then i could at least try it out and see what happens
20160112 07:10:02< zookeeper> and maybe iterate on it if it doesn't completely blow up
20160112 07:10:10< shadowm> Um, no, we'd hit the SDL limitation regardless.
20160112 07:10:57< zookeeper> well you didn't seem to be completely sure whether it'd be an issue in this case
20160112 07:11:11< shadowm> The most expensive part of the pipeline is the system calls that perform filesystem access to obtain the image data, and that could be parallelized safely... but they are abstracted away by SDL_image's functions, which also create SDL surfaces.
20160112 07:11:45< shadowm> And IIRC calling SDL video functions (including those required to set up surfaces) from different threads is a big no-no, at least in 1.2.
20160112 07:12:07< Aginor> shadowm: paralellising disk access will quickly degrade performacne though
20160112 07:12:43< shadowm> Potentially, that's non-deterministic territory.
20160112 07:13:19-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has joined #wesnoth-dev
20160112 07:13:26< shadowm> It depends a lot on the storage medium and block layout.
20160112 07:14:05< shadowm> And also whether the requested blocks are in the OS' filesystem cache.
20160112 07:14:14< Aginor> if we assume a spinning disk ;)
20160112 07:15:16< shadowm> Generally I don't think image preloading in a single thread would be such a bottleneck, at least as long as we know which images will actually be used.
20160112 07:15:41< shadowm> Which works for terrains just fine. Unit images, OTOH...
20160112 07:16:53< shadowm> I'd argue that preloading unit images is far more important because not doing so gets us jittery animations the first time.
20160112 07:17:41-!- Kwandulin [~Miranda@p200300760F250ADCC95AFAF35B08F38F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160112 07:17:55< shadowm> For my campaign I was just going to generate a preload hint list based on which units were initially available on every scenario (initial leaders + recall list + scenario-defined hints).
20160112 07:19:10< shadowm> But then I got lazy about figuring out how to walk through all the involved WML using Lua.
20160112 07:20:10< zookeeper> well, it's a bottleneck only because there's a gazillion separate images to load. for me IIRC the added loading screen delay was pretty substantial. like, in the ballpark of 10-40 seconds or so.
20160112 07:20:44< vultraz> O_O
20160112 07:20:50< zookeeper> or maybe that was only with a debug build
20160112 07:21:01< zookeeper> it seems i didn't save any of my benchmarks
20160112 07:21:15< shadowm> That being a side-effect of using a debug build seems unlikely but not impossible.
20160112 07:21:23< zookeeper> maybe it was just like 5-15 seconds on release
20160112 07:22:16< shadowm> Oh, never mind, it's five nested loops, not one loop.
20160112 07:22:25< shadowm> Yes, it's probably because it was a debug build.
20160112 07:22:45< zookeeper> my memory is particularly fallible, but i guess those huge figures might have only been due to debug output too
20160112 07:23:10< shadowm> As I recall Wesnoth's I/O-heavy operations have always felt slower on Windows than on Linux for some reason.
20160112 07:23:54< shadowm> At least back when I was using some shoddy entry-grade HDD on a machine with 256 MiB of RAM.
20160112 07:25:15< shadowm> Remember when web browsers had to run on only 8 MiB of RAM?
20160112 07:28:17< zookeeper> i think our first computer had a whopping 64mb ^___^ dunno how big a slice the web browser would have gotten from that though.
20160112 07:28:51< zookeeper> or maybe that was a later one
20160112 07:29:47< vultraz> shadowm: what the new attack dialog looks like, if you're interested: https://www.dropbox.com/s/ktc7btfhrmcn4b6/GUI2%20attack%20dialog2.PNG?dl=0
20160112 07:30:27< shadowm> It looks the same as before except without stupid layout issues I think?
20160112 07:31:20< vultraz> Yes
20160112 07:31:30< shadowm> (e.g. "im a gui1 widget and i have no idea what my containers max size is and how to rearrange myself accordingly in fact whats a container anyway")
20160112 07:31:37< vultraz> Yup
20160112 07:31:52< zookeeper> oh yeah, that damage calculations button touching the ok/cancel buttons...
20160112 07:31:56< shadowm> (GUI1 widgets have no notion of parenthood. It sucks to be them.)
20160112 07:32:01< zookeeper> and no one ever fixed it :>
20160112 07:32:19< shadowm> (Memory ownership doesn't count.)
20160112 07:32:30< Aginor> shadowm: I'm going to try to fix that for both gui1 and 2 :/
20160112 07:32:39< Aginor> well
20160112 07:32:44< Aginor> not really actually
20160112 07:32:48< shadowm> Aginor: Eh, GUI2 _does_ have a notion of parenthood.
20160112 07:32:54< Aginor> I'm trying to sidestep that issue
20160112 07:33:12< Aginor> shadowm: there needs to be something joint though, so you have your draw-stack
20160112 07:33:14< shadowm> It's just very overzealous and weird about the lay out process and expects everything to fit somehow.
20160112 07:33:26< shadowm> (And if it doesn't it literally explodes.)
20160112 07:34:16< shadowm> Aginor: Are we going to have layered rendering? Because that'd be a good first step towards making the UI more fluid and OpenGL-ready.
20160112 07:34:34< Aginor> shadowm: we are
20160112 07:34:59< shadowm> And by more fluid I mean solving one of our biggest UX issue: dialogs forcibly blocking the game loop.
20160112 07:35:39< Aginor> shadowm: I want to fix the current shortcomings that's hampering us
20160112 07:36:00< shadowm> It's right there beside "tooltips and map labels being the same rendering entity that fights for attention in some places".
20160112 07:36:04< Aginor> it should make most of that horrible surface_restorer thing redundant
20160112 07:36:38< Aginor> shadowm: making a GUI thread, video thread and game thread is not on my priority list at the moment :)
20160112 07:37:02< shadowm> Well, I suspect getting rid of that hack outright requires OpenGL unless you are willing to have the game waste time performing unnecessary blits in the same frame.
20160112 07:37:17< Aginor> shadowm: I'm willing to burn those cycles
20160112 07:38:18< shadowm> I don't know what to say about that. :p
20160112 07:38:19< vultraz> shadowm: I'm going to try to finish your GUI2 prefs dialog. 
20160112 07:38:50< Aginor> shadowm: it'll be a reasonably rare ocurrance so it shouldn't be too much of a problem ,)
20160112 07:39:44< shadowm> Maybe I'm thinking of something else entirely.
20160112 07:40:05< shadowm> Is it not the same thing that deals with restoring the background when a widget is hidden/relocated/destroyed?
20160112 07:40:17< Aginor> yes it is
20160112 07:40:19< shadowm> (Including dialog frames.)
20160112 07:40:53< Aginor> there's a reason I'm doing it in a branch though ;)
20160112 07:41:12< shadowm> We're thinking of 1980x1080 on Retina now.
20160112 07:41:31< shadowm> It's no longer 2005 when the most we mere mortals could aspire to was a 1280x1080 96 dpi screen.
20160112 07:41:40< shadowm> *1920x1080
20160112 07:41:50< Aginor> I'll be testing on my full widescreen desktop
20160112 07:41:52< shadowm> (multiplied by whatever Retina's factor is)
20160112 07:42:33< shadowm> I mean, back in 2006 I could run Wesnoth on an unaccelerated 1024x768 framebuffer without experiencing much of a performance drop.
20160112 07:42:46< Aginor> but I'm not sure it gives the same number of pixels as a retina display though
20160112 07:43:07< shadowm> If it's not specifically branded as a high-DPI monitor then it doesn't.
20160112 07:43:41< Aginor> 3360x1050
20160112 07:43:46< Aginor> so probably not
20160112 07:43:57< Aginor> they're getting a bit old
20160112 07:44:04< shadowm> Well, that'd a reasonable approximation I think.
20160112 07:44:35< shadowm> I don't know, they apparently go up to 5120x2880.
20160112 07:44:57< Aginor> we probably need to worry about hw accell at that point anyway
20160112 07:45:34< shadowm> Well, I can say for sure that Wesnoth runs fine at 1920x1080 on a 96 DPI screen.
20160112 07:45:56< Aginor> wait until I've de-optimised it for re-optimisation
20160112 07:45:59< shadowm> But the CPU does most of the work and it's a high-end CPU, so...
20160112 07:46:16< shadowm> Wesnoth 1.12 I mean.
20160112 07:46:41< shadowm> Reportedly, other 1920x1080 users experience poorer performance but I've never got to ask them for specs.
20160112 07:46:41< Aginor> ideally we'd only redraw the bits under the closed entity, but I'm not sure I'm ready to try to implement partial redrawing
20160112 07:47:13< Aginor> I have spent enough time trying to grot around in GUI1 as it is
20160112 07:48:18< shadowm> I still think rather than keeping GUI1 around it'd be saner if someone came up with a replacement for both that and GUI2, and used it to deploy replacements for the few GUI1 dialogs left. Once that is done it's sure to become a good replacement for GUI2 too in time.
20160112 07:48:45< shadowm> But it's research _and_ coding work that _someone_ has to do. ¬_¬
20160112 07:49:50< Aginor> I might look into that eventually, but right now I want to finish the remaining SDL2 work
20160112 07:50:04< shadowm> The reason I'd target GUI1 first? Because the few GUI1 dialogs left other than the MP lobby would be dead simple to implement if you had a existing GUI framework that's up to the task.
20160112 07:50:21< shadowm> Whereas most of the existing GUI2 dialogs are a bit more involved or rely extensively on GUI2 quirks and misfeatures.
20160112 07:50:39< shadowm> Plus GUI1 uses SDL_ttf, which honestly needs to die.
20160112 07:52:57< shadowm> And then burn in a fire and have a nuclear bomb dropped on it for good measure.
20160112 07:53:22< Aginor> a gui framework is so contentious though
20160112 07:53:35< Aginor> and without having it themed there'd be an uproar immediately
20160112 07:54:02< zookeeper> i'd rather suggest a ritual sacrifice, we could at least gain some divine buffs from that
20160112 07:54:11< shadowm> Neither GUI1 nor GUI2 support themes right now so that's not important.
20160112 07:54:51< shadowm> (The themable game UI doesn't count because it's not GUI1, it's an eldritch abomination that happens to have a few GUI1 widgets hanging from its hideous tendrils.)
20160112 07:54:53-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160112 07:55:44< shadowm> (And yes, I'm aware GUI2 does _have_ the underpinnings for theming support, but it's not like there's much interest in finishing that up.)
20160112 07:57:50< Aginor> what I meant by theming is the wesnoth L&F
20160112 07:58:03-!- ancestral [~ancestral@71-220-42-226.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160112 07:58:23< shadowm> Oh yes, that's a prerequisite I'm afraid.
20160112 07:59:02-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160112 07:59:16< shadowm> Wesnoth 0.1 could do with a simple filled-rectangles UI but we've gone too far beyond that point.
20160112 07:59:21< Aginor> which rules out everything unless we can get some artist bui-in
20160112 07:59:28< Aginor> buy-in even
20160112 08:29:34-!- Rhonda [~rhonda@anguilla.noreply.org] has quit [Remote host closed the connection]
20160112 08:34:19-!- Rhonda [~rhonda@anguilla.noreply.org] has joined #wesnoth-dev
20160112 08:37:49-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 08:44:35-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds]
20160112 08:59:14-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 09:05:41< zookeeper> well surely you could skin any future GUI with the current assets (with some simple cutting if necessary).
20160112 09:07:51< zookeeper> i mean, a new GUI system wouldn't necessarily require new art at all.
20160112 09:08:32< zookeeper> maybe if you added some completely new kind of elements, but even so you ought to be able to easily recycle the vast majority of current art, i'd imagine.
20160112 09:09:41< Aginor> zookeeper: I think that all GUI frameworks bar QT that have been discussed are unskinnable
20160112 09:09:45< Aginor> but maybe I'm wrong
20160112 09:10:00< Aginor> I hope I am
20160112 09:11:33< zookeeper> sure. i thought by artist buy-in you meant that new art could be the bottleneck, not the capabilities of the chosen framework.
20160112 09:12:47-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 255 seconds]
20160112 09:12:53 * Aginor shrugs
20160112 09:13:11< Aginor> I am not going to pick that thing up for a while
20160112 09:13:19< Aginor> but it would be rather useful
20160112 09:13:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 09:13:38< vultraz> I've gone down a rabbit hole :(
20160112 09:13:51< Aginor> I wouldn't enjoy trying to redo the game screen and similar things in some third party gui framework
20160112 09:13:56< Aginor> vultraz: by converting to GUI2?
20160112 09:13:59< vultraz> I wanted to change prefs to use CVideo... which ended up makign me change the filechooser... and then now the hotkey framework
20160112 09:14:06< vultraz> Aginor: that's a different rabbit hole
20160112 09:14:31< Aginor> fair enough
20160112 09:14:44< Aginor> anyway, I'm going to take off and mooch a bit
20160112 09:14:49< Aginor> catch you guys later
20160112 09:15:00< Aginor> there's Elite Dangerous to play :D
20160112 09:15:33-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has joined #wesnoth-dev
20160112 09:18:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160112 09:50:55-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 240 seconds]
20160112 09:52:11-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160112 09:53:23-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 250 seconds]
20160112 09:56:23-!- TC01 [~quassel@london.acm.jhu.edu] has quit [Remote host closed the connection]
20160112 09:56:37-!- VultCave is now known as vultraz
20160112 09:57:01-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160112 09:57:02-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160112 09:57:02-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160112 09:59:56-!- TC01 [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20160112 10:03:22-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 10:09:19< vultraz> dammit!
20160112 10:09:27< vultraz> it looks like window handling got broken somewhere D:
20160112 10:10:24 * vultraz rolls back his branch
20160112 10:15:32-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160112 10:15:35-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 240 seconds]
20160112 10:16:17-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160112 10:21:04-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160112 10:42:56-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 276 seconds]
20160112 10:54:22< vultraz> weird...
20160112 11:17:26-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 11:22:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160112 11:33:24-!- zookeeper_ [~lmsnie@37.35.27.57] has joined #wesnoth-dev
20160112 11:34:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 276 seconds]
20160112 11:38:15-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160112 11:50:06< vultraz> why is the damn display class so deeply ingrained in EVERYTHING
20160112 11:52:34-!- irker313 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160112 11:52:34< irker313> wesnoth: Charles Dang wesnoth:master cf8ff909e10f / src/help/ (help.cpp help.hpp help_browser.cpp help_browser.hpp): Pass CVideo argument directly to certain help functions http://git.io/vzYP7
20160112 11:53:32< Aginor> vultraz: de-ingraining it is really good work though
20160112 11:54:17< vultraz> I'd use display::get_singleton() more but it's not entirely safe to use - and it's not safe to use until rafactoring is done :|
20160112 11:55:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 11:56:28< Aginor> we are better off removing the reliance on it
20160112 11:56:50< vultraz> Oh?
20160112 11:57:21< Aginor> the class's functionality is overloaded as it is
20160112 11:57:31< vultraz> T'is true
20160112 11:59:17< vultraz> ok, the gui2 prefs prototype looks nice. Now to make it actually do stuff
20160112 11:59:33< vultraz> Then I can rip out the GUI1 prefs functionality... 
20160112 11:59:38< vultraz> which is ugly
20160112 12:00:05-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds]
20160112 12:00:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160112 12:05:15< Aginor> are you making halos an advanced option in the process?
20160112 12:05:27< Aginor> I think there's an open bug for that
20160112 12:05:41< vultraz> what do you mean?
20160112 12:11:55-!- zookeeper_ is now known as zookeeper
20160112 12:11:56< Aginor> vultraz: https://gna.org/bugs/?24164
20160112 12:11:57-!- zookeeper [~lmsnie@37.35.27.57] has quit [Changing host]
20160112 12:11:57-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160112 12:12:33< vultraz> Probably 
20160112 12:15:47< vultraz> hmmm
20160112 12:16:10< vultraz> I guess the only way to make this dialog functional is to set up a callback for every single button
20160112 12:17:05< Aginor> that sounds painful
20160112 12:17:12< vultraz> Indeed
20160112 12:17:18< vultraz> but I don't see any other way
20160112 12:17:49< vultraz> they all have different things they need to do
20160112 12:29:12< Aginor> ah
20160112 12:29:16< Aginor> unfortunate
20160112 12:33:15-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 12:37:08-!- louis94 [~~louis94@163.226-246-81.adsl-dyn.isp.belgacom.be] has quit [Client Quit]
20160112 12:42:15< vultraz> weirdly, my window state handling, which was working perfectly before, suddenly decided to stop doing so :P
20160112 12:43:22< vultraz> only difference I can think of is my switching to sdl 2.0.4...
20160112 12:45:11< vultraz> (fullscreen toggling is behaving oddly again :( )
20160112 12:56:49-!- boucman_2 [~jrosen@193.56.60.161] has joined #wesnoth-dev
20160112 12:57:29-!- boucman_2 is now known as boucman
20160112 12:57:42-!- boucman [~jrosen@193.56.60.161] has quit [Changing host]
20160112 12:57:42-!- boucman [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160112 13:00:27-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 255 seconds]
20160112 13:32:10-!- Kwandulin [~Miranda@p200300760F250ADCC95AFAF35B08F38F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160112 13:46:15< vultraz> C:\Users\Charles\Documents\wesnoth-git-stable\projectfiles\CodeBlocks\cb\include_tdm_gcc\boost\core\noncopyable.hpp|38|error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable&)' is private|
20160112 13:46:21< vultraz> C:\Users\Charles\Documents\wesnoth-git-stable\projectfiles\CodeBlocks\cb\include_tdm_gcc\boost\smart_ptr\scoped_ptr.hpp|47|error: 'boost::scoped_ptr<T>::scoped_ptr(const boost::scoped_ptr<T>&) [with T = sdl::twindow]' is private|
20160112 13:46:26< vultraz> not sure what this stuff means...
20160112 13:47:24< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\dialogs\preferences_dialog.cpp|85|note: synthesized method 'CVideo::CVideo(const CVideo&)' first required here |
20160112 13:47:47< vultraz> I guess I can't pass a CVideo reference to another function that needs a CVideo reference because bind makes a copy?
20160112 13:47:51< vultraz> or something?
20160112 13:48:50-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has quit [Quit: Leaving]
20160112 13:51:15-!- Appleman1234 [~Appleman1@KD119104004065.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20160112 14:06:10-!- gfgtdf [~chatzilla@x50ab9553.dyn.telefonica.de] has joined #wesnoth-dev
20160112 14:06:20< gfgtdf> vultraz: you can tell bindnot to make a a copy
20160112 14:06:28< vultraz> gfgtdf: how?
20160112 14:06:38< gfgtdf> Aginor: i dotn realyl thign that commit makes suoport for multiple windows harder
20160112 14:06:46< gfgtdf> Aginor: (the make CVideo a singelton commit)
20160112 14:07:14< gfgtdf> Aginor: i actually thing it makes it easier since the twindow is now a memeber of the Cvdieo class instead aof a global variable
20160112 14:07:31< gfgtdf> hmm use booost::ref
20160112 14:07:39< gfgtdf> vultraz: or pass the CViudeo by pointer
20160112 14:09:45< gfgtdf> vultraz: hmm fullscreen toigelling works fine here
20160112 14:09:54< gfgtdf> vultraz: are you sure that you are on sdl 2.0.4 ?
20160112 14:10:01< vultraz> gfgtdf: it works but the maximized state doesn't get restored like before
20160112 14:11:04< gfgtdf> vultraz: hm i really wnder whether this is windows spcific
20160112 14:13:35< vultraz> was working before
20160112 14:13:37< vultraz> dunno what changed
20160112 14:21:07-!- Kwandulin [~Miranda@p200300760F250ADC5C896ECFFC04DDF4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160112 14:21:35-!- mjs-de [~mjs-de@x4db5177a.dyn.telefonica.de] has joined #wesnoth-dev
20160112 14:29:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160112 14:48:18-!- Appleman1234 [~Appleman1@KD119104005142.au-net.ne.jp] has joined #wesnoth-dev
20160112 14:52:51-!- irker313 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160112 14:52:51< gfgtdf> vultraz: i investigated the maximized fullscreen issue
20160112 14:53:27< gfgtdf> vultraz: and it seens teh the reason is that SDL ired some SDL_WINDOWEVENT_RESTORED, after the mose is set to fullscreen
20160112 14:53:51< gfgtdf> vultraz: which sets _set_maximized to false in preferences.cpp:128
20160112 14:57:13< vultraz> hmmm
20160112 14:57:26< vultraz> does it work if you remove that?
20160112 15:00:36-!- gfgtdf [~chatzilla@x50ab9553.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
20160112 15:40:04< vultraz> this is tedious 
20160112 16:01:41-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160112 16:04:19-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 245 seconds]
20160112 16:04:20-!- wedge010 is now known as wedge009
20160112 16:28:15-!- Kwandulin [~Miranda@p200300760F250ADC5C896ECFFC04DDF4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20160112 16:38:57-!- Elvish_Hunter [~elvish_hu@wesnoth/developer/elvish-hunter] has joined #wesnoth-dev
20160112 16:41:49-!- louis94 [~~louis94@16.152-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 16:42:03< Elvish_Hunter> Hi all
20160112 16:45:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 16:46:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160112 16:46:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 16:46:57< Elvish_Hunter> I just prepared a PR (#582) about the possible removal of the "wmlmove" Python script and some related functions from wmltools.
20160112 16:47:16< Elvish_Hunter> If anyone has any opinion on it, please let me know.
20160112 16:57:00-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160112 16:57:50-!- irker522 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160112 16:57:50< irker522> wesnoth: Lari Nieminen wesnoth:master 52a0bbc53151 / / (8 files in 5 dirs): Added event type "unit placed" http://git.io/vz3aO
20160112 16:57:50< irker522> wesnoth: Lari Nieminen wesnoth:master 956e86f04975 / src/actions/attack.cpp: Fixed filtered "unit placed" events not firing for plague-created units http://git.io/vz3as
20160112 16:57:50< irker522> wesnoth: Lari Nieminen wesnoth:master 80691e5685f1 / / (8 files in 5 dirs): Merge pull request #563 from ln-zookeeper/unit_placed_event http://git.io/vz3aG
20160112 16:59:18-!- boucman [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 260 seconds]
20160112 17:04:03-!- Kwandulin [~Miranda@p200300760F250ADC5C896ECFFC04DDF4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160112 17:20:00-!- gfgtdf [~chatzilla@x50ab9553.dyn.telefonica.de] has joined #wesnoth-dev
20160112 17:31:25< zookeeper> vultraz, src\video.cpp(392): error C2614: 'CVideo' : illegal member initialization: 'window' is not a base or member
20160112 17:32:37< gfgtdf> zookeeper: hmm maybe you dont build with SDL2 ?
20160112 17:49:42-!- prkc [~prkc@catv-80-98-216-55.catv.broadband.hu] has quit [Quit: Leaving]
20160112 18:02:50< zookeeper> correct
20160112 18:04:22< gfgtdf> zookeeper: its good to have someone to test the SDL1 builds i guess.
20160112 18:05:32< gfgtdf> zookeeper: this should be fixed by putting the code into an #i sdl_version_atleast... .I can do that when i push my other commits
20160112 18:05:51-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160112 18:07:12< zookeeper> i'll happily switch to this new SDL2 thing as soon as i become aware of some simple instructions of how to do so
20160112 18:10:16-!- Elvish_Hunter [~elvish_hu@wesnoth/developer/elvish-hunter] has left #wesnoth-dev ["Ciao!"]
20160112 18:10:42< gfgtdf> zookeeper: hmm whcih compiler/os your you using ?
20160112 18:11:07< zookeeper> MSVC
20160112 18:11:27< zookeeper> (2013)
20160112 18:13:12< gfgtdf> zookeeper: hmm you somehwere have an 'external' folder containing libs and header files. You must remove all sdl related libs/headers fomr there and replace then with libs/headers downaloeded from here https://www.libsdl.org/download-2.0.php and here https://www.libsdl.org/projects/
20160112 18:13:25< gfgtdf> zookeeper: i recomend to make a copy of the folder first in case something goes wrong
20160112 18:15:59< zookeeper> i guess i'll wait for aquileia to update his stuff
20160112 18:21:53< gfgtdf> vultraz: i tried to remove display form help_.. function but the rpblems seems to be this line: https://github.com/wesnoth/wesnoth/blob/master/src/help/help_button.cpp#L61 whcih passes disp to the hotkey code
20160112 18:35:02-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160112 18:44:21-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has joined #wesnoth-dev
20160112 18:48:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160112 19:13:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160112 19:13:27-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
20160112 19:19:41-!- louis94 [~~louis94@16.152-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 276 seconds]
20160112 19:24:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 19:29:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20160112 19:32:43-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160112 19:41:49-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has joined #wesnoth-dev
20160112 19:43:38-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 255 seconds]
20160112 19:45:02-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has quit [Max SendQ exceeded]
20160112 19:46:09-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has joined #wesnoth-dev
20160112 19:49:11-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has quit [Max SendQ exceeded]
20160112 19:50:28-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has joined #wesnoth-dev
20160112 19:52:30-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has quit [Max SendQ exceeded]
20160112 19:53:30-!- solvents [~quassel@69-196-152-213.dsl.teksavvy.com] has joined #wesnoth-dev
20160112 19:53:52-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has joined #wesnoth-dev
20160112 19:55:44-!- sfan786 [~sfan786@c-24-131-93-63.hsd1.pa.comcast.net] has quit [Max SendQ exceeded]
20160112 19:58:18-!- irker522 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160112 19:59:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 19:59:54-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160112 20:01:49< vultraz> gfgtdf: yes, I came up against that too. Seems the hotkey needs disp because there's a point where it performs some actions on the display
20160112 20:03:00< vultraz> execute_command()
20160112 20:03:10< gfgtdf> vultraz: y i'm currently refactoring that
20160112 20:04:56< vultraz> ann nice
20160112 20:04:58< vultraz> ahh*
20160112 20:22:49-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160112 20:32:33-!- Kwandulin [~Miranda@p200300760F250ADC5C896ECFFC04DDF4.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160112 20:32:39-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 245 seconds]
20160112 20:48:20-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160112 21:04:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 240 seconds]
20160112 21:47:19-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20160112 21:48:30-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Disconnected by services]
20160112 21:48:34-!- Necrosporus_ is now known as Necrosporus
20160112 21:51:37-!- ezr [52d3c4a8@gateway/web/freenode/ip.82.211.196.168] has joined #wesnoth-dev
20160112 21:54:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160112 21:55:00-!- ezr [52d3c4a8@gateway/web/freenode/ip.82.211.196.168] has quit [Client Quit]
20160112 21:56:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160112 21:58:52-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160112 21:59:02< vultraz> celticminstrel: boost bind doesn't evaluate each value passed to it every time does it?
20160112 21:59:36< celticminstrel> It evaluates its arguments at bind time, not at call time.
20160112 21:59:47< vultraz> like, if I has bind(&function, isFoo()), isFoo would be evaluated only once?
20160112 21:59:54< celticminstrel> Yes, that's what I said.
20160112 22:00:00< vultraz> ok, thanks
20160112 22:00:04< celticminstrel> And if you want to pass a reference you need to wrap it in boost::ref().
20160112 22:00:12< celticminstrel> (A non-const reference.)
20160112 22:00:29< vultraz> what does boost::ref do, exactly
20160112 22:00:31< celticminstrel> (Well, I guess it might be necessary sometimes for const references.)
20160112 22:00:44< celticminstrel> boost::ref returns its argument unchanged.
20160112 22:01:10< celticminstrel> When it's a reference, that prevents it from decaying.
20160112 22:01:14< celticminstrel> Or something like that.
20160112 22:02:11< celticminstrel> It's not important to understand how it works. Just use it if the function needs to take something by reference, and be very careful if using it on local variables.
20160112 22:02:31< celticminstrel> And of course don't use it for expressions like this example you just posted.
20160112 22:02:47< vultraz> right
20160112 22:05:00-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160112 22:06:03< gfgtdf> vultraz: ok i ahve teh remove display from help functiosn commit ready
20160112 22:06:47< vultraz> :D
20160112 22:12:08-!- irker325 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160112 22:12:08< irker325> wesnoth: gfgtdf wesnoth:master 51938b15ba3f / src/ (game_preferences_display.cpp preferences_display.cpp preferences_display.hpp): preferences::show_video_mode_dialog only needs CVideo http://git.io/vzGQ3
20160112 22:12:08< irker325> wesnoth: gfgtdf wesnoth:master 7d31505439af / src/game_initialization/ (multiplayer_ui.cpp multiplayer_ui.hpp): remove unused hotkey related code in multiplayer_ui http://git.io/vzGQs
20160112 22:12:09< irker325> wesnoth: gfgtdf wesnoth:master abda1dc4e264 / src/ (5 files in 2 dirs): remove some get_singleton() calls http://git.io/vzGQG
20160112 22:12:10< irker325> wesnoth: gfgtdf wesnoth:master a77cc1394fd6 / src/tests/gui/test_gui2.cpp: attempt to fix tests http://git.io/vzGQZ
20160112 22:12:11< irker325> wesnoth: gfgtdf wesnoth:master 30522e6d340f / src/ (game_launcher.cpp game_launcher.hpp): add getter for game_launcher::video_ http://git.io/vzGQn
20160112 22:12:12< irker325> wesnoth: gfgtdf wesnoth:master 0ecf4d8ab9a9 / src/ (game_launcher.cpp intro.cpp intro.hpp): the_end() only needs CVideo http://git.io/vzGQc
20160112 22:12:14< irker325> wesnoth: gfgtdf wesnoth:master bb546c17bcea / src/ (10 files in 3 dirs): remove display dependency from map_generator http://git.io/vzGQC
20160112 22:12:16< irker325> wesnoth: gfgtdf wesnoth:master 94357449377a / src/ (7 files in 3 dirs): remove display dependency from addon manager http://git.io/vzGQW
20160112 22:12:39< gfgtdf> ??
20160112 22:12:54< gfgtdf> it gave me a merging conflic so why does it commit
20160112 22:14:17< vultraz> celticminstrel: one last question, if I may: http://pastebin.com/iKex50Sh I'm trying to do something like this, but it errors.. (obviously, it's the wrong way). Is there a way to do it correctly, or can't you bind templated functions?
20160112 22:15:33< gfgtdf> vultraz: i'll rever https://github.com/wesnoth/wesnoth/commit/cf8ff909e10f90aafac945ea8819a2f9a1b4e208 ok? sicne it casues merging clichy with my conflicy which do es the same but more.
20160112 22:15:49< vultraz> gfgtdf: ok
20160112 22:18:54< irker325> wesnoth: gfgtdf wesnoth:master f7f4bc27074b / src/help/ (help.cpp help.hpp help_browser.cpp help_browser.hpp): Revert "Pass CVideo argument directly to certain help functions" http://git.io/vzG5G
20160112 22:18:56< irker325> wesnoth: gfgtdf wesnoth:master a953848dda13 / src/ (16 files in 5 dirs): remove display dependency from show_help() http://git.io/vzG5Z
20160112 22:18:58< irker325> wesnoth: gfgtdf wesnoth:master 8680ce45c6c0 / src/ (11 files in 4 dirs): remove display dependency from hotkey::command_executor http://git.io/vzG5n
20160112 22:19:00< irker325> wesnoth: gfgtdf wesnoth:master a96ca1e08b8a / src/ (addon/manager_ui.cpp dialogs.cpp help/help_button.cpp help/help_button.hpp): remove display dependency from help_button http://git.io/vzG5c
20160112 22:19:02< irker325> wesnoth: gfgtdf wesnoth:master 93c53df6d8ad / src/ (32 files in 4 dirs): remove display dependency from mp connect code. http://git.io/vzG5C
20160112 22:19:04< irker325> wesnoth: gfgtdf wesnoth:master 056298bfc7a6 / src/video.cpp: fixup SDL1 build http://git.io/vzG5W
20160112 22:20:17< vultraz> ty 
20160112 22:20:45< vultraz> I have a local commit removing the display dependency from preferences but I figure it's not worth pushing since I'm refactoring it to GUI2 anyway
20160112 22:21:23< celticminstrel> You can bind template functions.
20160112 22:21:49< celticminstrel> But you can't bind templates.
20160112 22:22:01< celticminstrel> You need to instantiate the template to produce a function.
20160112 22:22:16< celticminstrel> So, &tpreferences::simple_toggle_callback<something>
20160112 22:22:30 * celticminstrel guesses that something should be ttoggle_button but isn't quite sure.
20160112 22:23:21< vultraz> ttoggle_button is the type of widget
20160112 22:23:24< vultraz> that's not what I want
20160112 22:24:06< vultraz> instantiating it as bool works :)
20160112 22:24:12< celticminstrel> I doubt that.
20160112 22:24:18< vultraz> well, it builds at least
20160112 22:24:43< celticminstrel> What's the definition of simple_toggle_callback?
20160112 22:24:47-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160112 22:25:05< vultraz> 	template <typename T>
20160112 22:25:06< vultraz> 	void simple_toggle_callback(const std::string& widget, void (*setter) (T), twindow& window);
20160112 22:25:59< celticminstrel> So you're passing a function as the second argument. What's its definition?
20160112 22:27:29< vultraz> void set_show_floating_labels(bool value);
20160112 22:28:08< vultraz> I was using a template since I might need to pass a function requiring a int
20160112 22:30:43< gfgtdf> vultraz: im im also curently wokring to remove display from preferences, (to be able to rmeove it form multiplayer.cpp)
20160112 22:30:56< vultraz> if it turns out I only need bools I can remove the template
20160112 22:31:02< vultraz> gfgtdf: do you want me to push my commit instead?
20160112 22:31:57< gfgtdf> vultraz: sure, i hope its doesnt have merging conficy wit the commits i already pushrd
20160112 22:32:09< vultraz> it might but I think I can edit that
20160112 22:32:28< gfgtdf> vultraz: afaik one of teh main problems with the gui2 preferences dialog is teh drobox that is used for teh coimpression mode
20160112 22:32:39< gfgtdf> vultraz: well if it aork for you i think i can also do it myself
20160112 22:32:53< vultraz> I know it conflicts with 51938b15ba3f 
20160112 22:33:08< vultraz> hm
20160112 22:33:20< vultraz> actually if you're already almost done why don't you just finish 
20160112 22:33:26< celticminstrel> Okay, sorry, you were right after all. Instantiate it with bool.
20160112 22:33:32< vultraz> I added some get_singleton calls and I know you're removing them
20160112 22:34:01< vultraz> celticminstrel: your explanation the other day made bind a lot less confusing, BTW. thanks
20160112 22:34:07< celticminstrel> Yay.
20160112 22:46:40< gfgtdf> zookeeper: i pushed a commit that might fix sdl1
20160112 22:58:05-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 260 seconds]
20160112 23:01:30-!- travis-ci [~travis-ci@ec2-54-144-1-53.compute-1.amazonaws.com] has joined #wesnoth-dev
20160112 23:01:31< travis-ci> wesnoth/wesnoth#8185 (master - 9435744 : gfgtdf): The build was broken.
20160112 23:01:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/101959083
20160112 23:01:31-!- travis-ci [~travis-ci@ec2-54-144-1-53.compute-1.amazonaws.com] has left #wesnoth-dev []
20160112 23:02:29-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160112 23:07:36-!- travis-ci [~travis-ci@ec2-54-146-146-169.compute-1.amazonaws.com] has joined #wesnoth-dev
20160112 23:07:37< travis-ci> wesnoth/wesnoth#8186 (master - 056298b : gfgtdf): The build was broken.
20160112 23:07:37< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/101960911
20160112 23:07:37-!- travis-ci [~travis-ci@ec2-54-146-146-169.compute-1.amazonaws.com] has left #wesnoth-dev []
20160112 23:12:19< zookeeper> gfgtdf, compiling is taking too long for me to tell right now whether it worked, i'll try it tomorrow
20160112 23:15:37-!- louis94 [~~louis94@16.152-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160112 23:16:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20160112 23:32:39< vultraz> prefs dialog coming along nicely
20160112 23:39:45< gfgtdf> vultraz: what did you do abou the compression settings ?
20160112 23:39:55< vultraz> I haven't gotten there yet
20160112 23:40:12< vultraz> first I'm working on getting basic functionality working
20160112 23:41:30< gfgtdf> celticminstrel: did you see my message here: https://gna.org/bugs/?24304 ?
20160112 23:42:01< celticminstrel> Yeah.
20160112 23:50:38< shadowm> Aginor, aquileia, loonycyborg, gfgtdf, vultraz: What's the status of the SDL 2 transition on Windows-land in terms of packaging/build environment stuff?
20160112 23:50:55< vultraz> shadowm: 2.0.4 should be used
20160112 23:51:18< shadowm> That's not what I asked.
20160112 23:52:16< loonycyborg> shadowm: I'm capable to build against sdl2
20160112 23:52:32< shadowm> Have the Windows people (esp. loonycyborg) figured things out already so they won't be struggling at the last minute to get their SDL 2.0 builds working? zookeeper's messages earlier don't seem too encouraging.
20160112 23:52:33< gfgtdf> shadowm: it builds well. jenkins doesnt use sdl2 yet. Afaik the downloadable 'external' package alos doesnt contain sdl2 yet.
20160112 23:53:10< shadowm> Okay, if loonycyborg can build with SDL 2 then that's good enough for a release, but it'd be nice if we could get zookeeper able to run SDL 2 builds too.
20160112 23:53:32< irker325> wesnoth: gfgtdf wesnoth:master f822a0864ab5 / src/ (6 files in 3 dirs): remove display dependency form filechooser dialog https://github.com/wesnoth/wesnoth/commit/f822a0864ab546423f87cda89603cf81d046a780
20160112 23:53:32< shadowm> ancestral (who doesn't read the logs), celticminstrel: And the OS X status is good too I guess?
20160112 23:53:34< irker325> wesnoth: gfgtdf wesnoth:master 9a0037495690 / src/ (7 files in 4 dirs): partly remove the display dependency from prefernces dialog. https://github.com/wesnoth/wesnoth/commit/9a0037495690f449b8020681b68154621a742af1
20160112 23:53:36< irker325> wesnoth: gfgtdf wesnoth:master 6e3aa0836ee7 / src/ (8 files in 3 dirs): remove display depencendy from multiplayer.cpp and campaign_controller https://github.com/wesnoth/wesnoth/commit/6e3aa0836ee72dc0295b79e2c238a95cc413244a
20160112 23:53:38< irker325> wesnoth: gfgtdf wesnoth:master f9fdcb1ebb20 / src/tests/gui/test_gui2.cpp: fix unused variable. https://github.com/wesnoth/wesnoth/commit/f9fdcb1ebb209b6c4f6732bf3c0e5236714cfb96
20160112 23:53:40< irker325> wesnoth: gfgtdf wesnoth:master f73802048661 / src/ (about.cpp about.hpp game_launcher.cpp wesnoth.cpp): remove display dependency form show_about() https://github.com/wesnoth/wesnoth/commit/f738020486618f4add964f61f98597c34e9ce6a1
20160112 23:53:42< irker325> wesnoth: gfgtdf wesnoth:master 28be388d6d59 / src/ (display.cpp game_launcher.cpp game_launcher.hpp wesnoth.cpp): remove game_display instance form game_launcher https://github.com/wesnoth/wesnoth/commit/28be388d6d59783e140aeaad1f3410766212d056
20160112 23:53:44< irker325> wesnoth: gfgtdf wesnoth:master e37c8d6d2ae2 / src/ (4 files in 2 dirs): remove display dependency from game_config_manager https://github.com/wesnoth/wesnoth/commit/e37c8d6d2ae2909493267177adb657d2f2866d9f
20160112 23:53:46< irker325> wesnoth: gfgtdf wesnoth:master 8c63aff9c853 / src/hotkey/command_executor.cpp: fix unused parameter https://github.com/wesnoth/wesnoth/commit/8c63aff9c8531efd0d53fd3bffb729b54c1ee5da
20160112 23:54:28< celticminstrel> I suppose I should probably build at least once to verify that.
20160112 23:54:30< gfgtdf> hmm forgot to rebase, e37c8d6d2a should be before 28be388d6d
20160112 23:55:06< shadowm> vultraz: Is SDL 2.0.4 a hard requirement or just a recommendation?
20160112 23:55:20< vultraz> Requirement 
20160112 23:55:23< shadowm> I'm asking because scons is trying to use my system SDL 2 library, which is version 2.0.2.
20160112 23:55:29< shadowm> And it's not even complaining about it.
20160112 23:55:35< shadowm> (Aginor?)
20160112 23:55:49< shadowm> On Linux though.
20160112 23:55:50< gfgtdf> shadowm: well at lest on windows there are known bugs that effect wesnoth and are fixed on 2.0.4
20160112 23:55:56< vultraz> ^
20160112 23:56:48< gfgtdf> vultraz: will you file a bug about the fullscreen restore issue ?
20160112 23:56:59< loonycyborg> my sdl build is 2.0.3
20160112 23:57:04< loonycyborg> guess will have to update
20160112 23:57:07< shadowm> BLARGH why even Debian sid only has 2.0.2?
20160112 23:57:22< shadowm> This is preposterous.
20160112 23:57:25< loonycyborg> 2.0.4 is really new
20160112 23:57:39< shadowm> Yes but last time I checked there is a number between 2 and 4.
20160112 23:57:47< shadowm> I think most people call it a 3.
20160112 23:58:26< celticminstrel> Heh.
20160112 23:59:44< shadowm> Okay, apparently the Debian packager believes that SDL 2.0.3 didn't introduce any important changes for Linux and was waiting on 2.0.4.
--- Log closed Wed Jan 13 00:00:38 2016