--- Log opened Sat Sep 10 00:00:16 2016
--- Day changed Sat Sep 10 2016
20160910 00:00:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 00:06:59-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 00:08:37< tad_> celmin: I can't get wesnoth to compile early 1.13 versions. The problem with type="" appeared before 1.13.3 and after 1.12.6 but that's all I know.
20160910 00:11:25< celmin> Well that's annoying.
20160910 00:11:31 * tad_ nods
20160910 00:11:45< tad_> Mostly Boost issues. But it varies
20160910 00:12:17< celmin> So you can't even build the 1.13.0 tag?
20160910 00:13:15-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 00:13:16< travis-ci> wesnoth/wesnoth#10794 (master - 3a9caf7 : Charles Dang): The build is still failing.
20160910 00:13:16< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158884957
20160910 00:13:16-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 00:14:05< tad_> I tried 1.13.0 .1 and .2 bisect had problems immediately between 1.12.6 and 1.13.3 and I tried stepping 50 commits toward 1.12.6 a couple times. Can'
20160910 00:14:17< tad_> can't find a version which compiles.
20160910 00:14:45< celmin> So, again, 1.13.0 does not compile?
20160910 00:14:51< tad_> Not for me
20160910 00:14:59< celmin> And that's CMake, right?
20160910 00:15:03< tad_> correct
20160910 00:15:44< gfgtdf> tad_: which bug exactly are you invastigating ?
20160910 00:16:11< celmin> gfgtdf: [modify_unit]type="" appears to fail if the unit was created using [base_unit].
20160910 00:16:18< celmin> It's supposed to advance the unit.
20160910 00:16:19< tad_> [modify_unit]type="" .. should advance the unit. It does but using the wrong unit_type
20160910 00:16:39< tad_> Delfador on DM goes from Journeyman Mage to Red Mage for example
20160910 00:17:05< gfgtdf> tad_: do i need your prp reddurce it on DM ?
20160910 00:17:07< gfgtdf> pr*
20160910 00:17:16< gfgtdf> reproduce*
20160910 00:17:29< tad_> I just add a [modify ... to S02 in prestart
20160910 00:18:55< tad_> [modify_unit][filter]id=Delfador[/filter]type=""[/modify_unit] (adding /n as needed) On 1.12.6 he goes to Mage Leader (correct) on 1.13.3 and later (dunno where the bug appeared) he goes ot Red Mage
20160910 00:21:07< gfgtdf> tad_ but you coudl just use [transform_unit] right ?
20160910 00:22:19< tad_> Dunno. I need to bump current level + 1 and was told to use type="" .. which used to work.
20160910 00:22:40< celmin> gfgtdf: Yes he could use transform_unit, but the point is that both are supposed to do the same thing.
20160910 00:23:15< celmin> I suppose this would be fixed if I ever rewrote modify_unit as I was considering… but I haven't even decided whether to do that.
20160910 00:23:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160910 00:23:32< tad_> I'll test transform. It's possible it's broken, too.
20160910 00:24:01< tad_> Of course, it'll be a hour or two because I need to clean up the mess I made ..
20160910 00:26:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20160910 00:28:03< vultraz> just realized something... all the gui2 canvas stuff is editing a giant surface :/
20160910 00:29:36< vultraz> ie, one cannot use, say SDL_RenderDrawLine
20160910 00:30:03< vultraz> im rather curious how spixi got it to work in his graph...
20160910 00:30:25< vultraz> hm..
20160910 00:30:49< gfgtdf> actuall i just tested, in DM 02 and i couldn't repduce.
20160910 00:32:28< gfgtdf> vultraz: when i try to load a save i get thrown to the titltescreen
20160910 00:32:34< vultraz> wha?
20160910 00:32:39< vultraz> that's not what happens to me..
20160910 00:32:47< tad_> I'm rebuilding against current master and can't re-test for a couple hours.
20160910 00:32:59< tad_> 'make all' effectively
20160910 00:34:30< gfgtdf> vultraz: start a game, then load a save form it. (but it might be possible that im ~1-2 days behind master)
20160910 00:35:24< celmin> vultraz: Maybe he didn't?
20160910 00:35:31< vultraz> ?
20160910 00:35:40< celmin> I have no idea what spixi did.
20160910 00:35:50< celmin> It's entirely possible he doesn't use the canvas at all.
20160910 00:36:43< vultraz> I think he did
20160910 00:36:49< vultraz> I'm trying his general method
20160910 00:37:16 * celmin shrug
20160910 00:37:21< celmin> What are you doing?
20160910 00:37:45< gfgtdf> an  i the only one who canot has problems with loading a gem wile playing another game ?
20160910 00:37:52< vultraz> trying to simplify canvas::draw_line
20160910 00:38:18< mattsc> tad_: in case that helps you narrow it down, he already advances to Red Mage with that method in 1.13.0
20160910 00:38:55< tad_> mattsc: So it's between 1.12.6 and 1.13.0 ? How much space it that?
20160910 00:39:04< vultraz> hmm
20160910 00:39:14< vultraz> how to get the rgba values from a SDL_MapRGBA
20160910 00:39:17< irker261> wesnoth: Celtic Minstrel wesnoth:CelticMinstrel-travis-fix 44466f675849 / src/storyscreen/render.cpp: Fix a Travis compile error https://github.com/wesnoth/wesnoth/commit/44466f675849a21d4ede7d4b38b2ce6b5c855530
20160910 00:39:22< vultraz> which is Uint32..
20160910 00:39:52< vultraz> and the draw line takes..
20160910 00:39:56< vultraz> 4 Uint8's
20160910 00:39:58< vultraz> hm
20160910 00:40:00< celmin> There's no single general method, unless there's an SDL function that reverses MapRGBA.
20160910 00:40:04-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160910 00:40:32< mattsc> tad_: don’t know; but the 1.13.0 changelog is huge
20160910 00:41:06< vultraz> i tried using the input parameters that went into SDL_MapRGBA, but that doesn't work..
20160910 00:41:13< celmin> Note that "between 1.12.6 and 1.13.0" doesn't actually exist.
20160910 00:41:19< vultraz> oh wait
20160910 00:41:32< celmin> vultraz: Should work, as long as you pass them in the correct order.
20160910 00:41:37< vultraz> oh hey
20160910 00:41:40< vultraz> I got it working :O
20160910 00:42:04-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160910 00:42:11< vultraz> it does seem to break the 'alpha point overload' I use for buttons, though
20160910 00:42:27< celmin> Huh?
20160910 00:43:03< vultraz> doesn't seem to consider alpha
20160910 00:43:08< vultraz> anyway, code: http://pastebin.com/kGGEhg50
20160910 00:44:05< celmin> Incidentally, the return value of SDL_MapRGBA is very similar to your "color" variable there.
20160910 00:44:16< celmin> (Though might have components in a different order.)
20160910 00:44:28< mattsc> right; it’s been 1.11.11 and 1.13.0, really; I figured that was implied here
20160910 00:44:36< tad_> Personally, I'd use (N>>24)&0x0FF but that's probably not the issue
20160910 00:44:57< vultraz> draw_line is passed a Uint32 color
20160910 00:45:01< celmin> vultraz: My first guess would be that you need to explicitly enable alpha processing somewhere.
20160910 00:45:04< vultraz> 'color
20160910 00:45:25< vultraz> was then processed as-so: http://pastebin.com/upaLyvzs
20160910 00:46:41< vultraz> hm..
20160910 00:47:19< vultraz> SDL_SetRenderDrawColor expects colors in RGBA format...
20160910 00:47:30< vultraz> ie 0 - 255
20160910 00:47:35< vultraz> so alpha should work..
20160910 00:48:38< celmin> See my above comment.
20160910 00:48:57< celmin> You might have to set the blend mode to process alpha.
20160910 00:49:04< celmin> The default blend mode might be to ignore it.
20160910 00:51:21< vultraz> hm
20160910 00:51:26< vultraz> SDL_SetRenderDrawBlendMode(renderer, SDL_BLENDMODE_BLEND); doesn't fix it
20160910 01:00:06< vultraz> this is puzzling
20160910 01:00:25< celmin> Is SDL_BLENDMODE_BLEND the alpha mode?
20160910 01:00:55< vultraz> yes
20160910 01:04:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 01:08:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160910 01:15:35-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 01:15:36< travis-ci> wesnoth/wesnoth#10795 (CelticMinstrel-travis-fix - 44466f6 : Celtic Minstrel): The build is still failing.
20160910 01:15:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158894096
20160910 01:15:36-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 01:16:16< mattsc> tad_: git log 1.11.1..1.13.0 --pretty=oneline | wc -l : 9847
20160910 01:16:39< mattsc> That’s a lot.
20160910 01:17:20< mattsc> I wonder if that counts the 1.12 branch also ...
20160910 01:17:46< mattsc> oops, I didn’t mean 1.11.1
20160910 01:18:10< mattsc> Still 5199 from 1.11.11 though.
20160910 01:18:45< celmin> mattsc: I don't think that would count the 1.12 branch.
20160910 01:20:19< vultraz> why did mordante put *all* of the canvas subclasses in one file :|
20160910 01:20:41< celmin> I'd consider it fine if they're all fairly small.
20160910 01:21:09< vultraz> makes it quite hard to work with, though
20160910 01:21:22< irker261> wesnoth: Celtic Minstrel wesnoth:CelticMinstrel-travis-fix 496c3f883045 / src/sdl/utils.cpp: Fix a Travis compile error https://github.com/wesnoth/wesnoth/commit/496c3f883045f555039d7dfc9dd95617d9048566
20160910 01:21:28< celmin> Just how many are there, anyway?
20160910 01:21:40< vultraz> especially since the definitions AND implementations of all the subclasses are in the .cpp file
20160910 01:21:49< vultraz> declaration 
20160910 01:21:54-!- gfgtdf_ [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160910 01:21:56< vultraz> 5
20160910 01:22:02< celmin> That's not all that many...
20160910 01:23:18< vultraz> 1600 line file
20160910 01:23:53< celmin> 1600 lines isn't even that bad for Wesnoth.
20160910 01:23:55-!- gfgtdf [~chatzilla@x4e36343d.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160910 01:24:02< celmin> I wouldn't object to at least splitting implementations to a cpp file if it makes a significant difference, though.
20160910 01:24:03-!- gfgtdf_ is now known as gfgtdf
20160910 01:24:32< celmin> (Actually, it might even be possible to move all the subclass declarations there, if they're not referenced externally.)
20160910 01:24:46< vultraz> hm?
20160910 01:25:06< vultraz> I'll do such cleanup later
20160910 01:25:12< vultraz> right now I'm doing some refactoring
20160910 01:25:49< vultraz> I shall be very happy if I can get rid of put_pixel
20160910 01:26:00< celmin> put_pixel is an abomination.
20160910 01:26:45< vultraz> so, what I'm doing is giving the canvas an SDL renderer context generated from the canvas surface 
20160910 01:27:19< vultraz> I shall then use standard SDL_Render* functions
20160910 01:28:23< vultraz> Not sure how i'll handle circles, though
20160910 01:28:45< vultraz> SDL_RenderDrawPoints, maybe
20160910 01:30:27< celmin> How are circles handled now?
20160910 01:31:12< vultraz> loop with put_pixe;
20160910 01:31:16< celmin> Ah.
20160910 01:31:16< vultraz> pixel
20160910 01:31:46< celmin> What are the functions available in the rendered>
20160910 01:31:47< celmin> ^?
20160910 01:32:16< vultraz> rendered?
20160910 01:32:31< vultraz> you mean renderer?
20160910 01:32:49< celmin> Yes.
20160910 01:36:48< vultraz> https://wiki.libsdl.org/CategoryRender
20160910 01:37:51< celmin> So for a circle I think you'll want SDL_RenderDrawLines.
20160910 01:38:14< celmin> Generate 100 or so points evenly spaced out around the circle, and pass those in.
20160910 01:38:44< celmin> (You can even put them in std::vector if you want.)
20160910 01:39:00< vultraz> perhaps
20160910 01:39:25< celmin> That's the normal way of drawing circles.
20160910 01:49:44-!- Bonobo [~Bonobo@2001:44b8:254:3200:40a5:71fa:b2e2:c976] has joined #wesnoth-dev
20160910 01:49:57< vultraz> blah
20160910 01:50:36< vultraz> converting draw_line to use a renderer worked, alone, but using it for other still isn't as sucessful
20160910 01:53:47-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160910 01:59:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160910 02:01:29-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 02:02:57-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 02:02:58< travis-ci> wesnoth/wesnoth#10797 (CelticMinstrel-travis-fix - 496c3f8 : Celtic Minstrel): The build is still failing.
20160910 02:02:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158898788
20160910 02:02:58-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 02:03:48< vultraz> heh
20160910 02:04:50< tad_> OK. Tested [transform_unit] and instead of getting a max_hp Red Mage I get a 29/48HP Red Mage.
20160910 02:04:57< celmin> ...
20160910 02:05:13< tad_> So [transform_unit] is a bit more buggy than [modify_unit]
20160910 02:05:32< tad_> Or not. Depends on how we define them.
20160910 02:05:33< irker261> wesnoth: Celtic Minstrel wesnoth:CelticMinstrel-travis-fix dac9bcc9b248 / src/sdl/utils.cpp: Fix a Travis compile error https://github.com/wesnoth/wesnoth/commit/dac9bcc9b2486cb92b785b3ae1596d9c7ca5b10b
20160910 02:06:33< celmin> But advancing with ;unit advances=1 works correctly?
20160910 02:06:42< tad_> One moment.
20160910 02:07:37< tad_> No. Red Mage, 48/48 HP
20160910 02:07:40< celmin> ...
20160910 02:07:45< celmin> What...
20160910 02:08:06< celmin> Okay, so...
20160910 02:08:44< celmin> Does it even work correctly during normal play?
20160910 02:08:45< tad_> So, how about I reload and set XP to max and take a kill to see what happens
20160910 02:08:55< celmin> Yeah, I was about to suggest that.
20160910 02:09:04< celmin> Not even a kill, just attack a L1 or something.
20160910 02:09:29 * tad_ nods
20160910 02:10:15< tad_> Red Mage
20160910 02:10:44< celmin> So it sounds like something is broken with the handling of [base_unit].
20160910 02:10:46< tad_> How about I clear cache/etc and check one more time.
20160910 02:10:53< celmin> If you think that might help.
20160910 02:11:15< tad_> If nothing else, it's a clean, known and reproducable state
20160910 02:14:26< tad_> OK. old bug, noting again. On last run wesnoth was maximized window. After clearing ~/.cache/wesnoth ~/.config/wesnoth and ~/.local/share/wesnoth/1.13 the program opens maximized window but only paints default (800x600?) and leaves remainder garbage.
20160910 02:14:48< mattsc> tad_: in 1.13.0 he becomes a Mage Leader when advancing normally.
20160910 02:15:16< celmin> So 1.13.0 is known good and 1.13. …3? …is known bad.
20160910 02:15:19< tad_> OK. Wait one while I test clean state for 1.13.5+dev
20160910 02:15:41< celmin> No idea who would be able to bisect this though, given that the CMake build is broken.
20160910 02:15:58< celmin> I mean, if the CMake build is broken, maybe other builds are too.
20160910 02:16:19< tad_> I can bisect jsut not that far back.
20160910 02:16:29< celmin> Which is the problem here. :P
20160910 02:17:27< mattsc> celmin, tad_: works for me as expected (Mage Leader) in 1.13.5 as well
20160910 02:17:36< celmin> Huh...
20160910 02:17:41< vultraz> ugh
20160910 02:17:46< vultraz> narrowing conversion warnings
20160910 02:17:51< vultraz> what do these even mean
20160910 02:17:56< celmin> Context.
20160910 02:17:59< mattsc> This is when attacking a unit and being 1 XP from max
20160910 02:18:11< vultraz> warning: narrowing conversion of '(((unsigned int)x) + ((unsigned int)i))' from 'unsigned int' to 'int' inside { } [-Wnarrowing]|
20160910 02:18:18< vultraz> initializing an SDL_Rect
20160910 02:18:18< tad_> Grr. Can't get DM to come up. Hangs after painting map for S01.
20160910 02:18:25< mattsc> By contrast, [modify_unit] did not work in 1.13.0 already.
20160910 02:18:32< celmin> Why is that casting to unsigned?
20160910 02:18:50< vultraz> no idea
20160910 02:18:56< vultraz> I guess I'll just make the variables int
20160910 02:19:00< celmin> mattsc: Meaning that he becomes Red Mage?
20160910 02:19:10< mattsc> yes
20160910 02:19:11< celmin> vultraz: Well, my first guess would be just removing the cast.
20160910 02:19:21< vultraz> im not casting to anything
20160910 02:19:38< celmin> What?
20160910 02:19:43< vultraz> it seems SDL_Rect implicitly casts to int
20160910 02:19:54< celmin> No, it doesn't implicitly cast. That's the problem.
20160910 02:20:05< celmin> What was the actual code line>
20160910 02:20:07< celmin> ^?
20160910 02:20:14< celmin> And what are x and y really?
20160910 02:20:34< vultraz> http://pastebin.com/TyHDVR7H
20160910 02:20:37< tad_> OK. I'm having real problems with wesnoth after clearing cache/config and saves
20160910 02:20:52< vultraz> I'm thinking just making x/y/w/h ints
20160910 02:21:06-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160910 02:21:39< celmin> Yeah, I guess that works.
20160910 02:21:52< mattsc> Ah, now this is funny…
20160910 02:21:52< celmin> Changing unsigned to signed isn't as dangerous as the reverse, anyway.
20160910 02:22:22< mattsc> If I do [modify_unit] in scenario 2, it results in Mage Leader as well.  Previously I had tried it in scenario 1.
20160910 02:24:08< mattsc> tad_, celmin: so, yes, at least in 1.13.0 with [modify_unit] he advances to Red Mage if I do that in S1, and to Make Leader in S2.
20160910 02:24:22< celmin> :|
20160910 02:24:40< mattsc> It’s almost a Heisenbug ...
20160910 02:25:42< mattsc> For reference, I am doing this in the start event in both cases.
20160910 02:27:38< vultraz> celmin: as far as I can tell this shouldn't be needed now? http://pastebin.com/sbbBi80m
20160910 02:28:01< vultraz> likely needed because draw_line worked from left to right, I think...
20160910 02:29:15-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160910 02:31:58-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Ping timeout: 255 seconds]
20160910 02:33:25-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 02:33:39< tad_> Seems like it's NOT my night ... 
20160910 02:33:48< tad_> src/gui/widgets/chatbox.hpp:128:50: error: declaration of ‘lobby_info& gui2::tchatbox::lobby_info()’
20160910 02:33:58< tad_> src/gui/dialogs/lobby/info.hpp:25:7: error: changes meaning of ‘lobby_info’ from ‘class lobby_info’ 
20160910 02:34:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160910 02:34:37< celmin> Ah, I should have those fixed very soon.
20160910 02:34:42< tad_> OK.
20160910 02:34:47< vultraz> celmin: put_pixel has been purged :D
20160910 02:34:51< celmin> If you can't wait, then merge CelticMinstrel-travis-fix.
20160910 02:35:27< mattsc> tad_: I think you check the logs, but just in case, I only get the bug in DM-S1, not in scenario 2.
20160910 02:35:35< celmin> vultraz: That check does seem probably unnecessary with a proper line drawing implementation.
20160910 02:35:59< celmin> (If the algorithm relies on it, then it should be handled within draw_line.)
20160910 02:36:30< tad_> I get it in S02 and S03. But I can't get the game to start and, now, can't compile.
20160910 02:36:46< mattsc> :(
20160910 02:36:48< celmin> I'm waiting on Travis to finish. :/
20160910 02:37:24< vultraz> the only problem is the alpha point hack is broken
20160910 02:37:30< vultraz> otherwise everything seems to be working perfectly
20160910 02:37:41< celmin> What's the alpha point hack?
20160910 02:38:08< vultraz> drawing a 1-pixel line with the color 0 0 0 0
20160910 02:40:18< celmin> Why would you want that?
20160910 02:40:42< vultraz> we use it in the buttons to give them a rounded look
20160910 02:40:45< vultraz> by masking certain pixels
20160910 02:42:39< vultraz> hm
20160910 02:42:48< vultraz> ok, I got it to handle single-pixels again..
20160910 02:42:52< vultraz> but not pure-alpha ons
20160910 02:43:14< celmin> Obviously.
20160910 02:43:24< celmin> Drawing a pure-alpha pixel should be a no-op.
20160910 02:43:47< vultraz> yeah..
20160910 02:43:52< vultraz> it *is* a hack, anyway
20160910 02:44:08< vultraz> if only we had rounded rectangle drawing..
20160910 02:44:09< celmin> I guess we really need the rounded rect now.
20160910 02:44:14< celmin> Heh, timing
20160910 02:44:30< vultraz> I can rework the button drawing
20160910 02:44:35< vultraz> to not use the hack
20160910 02:45:17< vultraz> I guess you're right, it shouldn't be used anyway
20160910 02:45:59< vultraz> I'll commit now
20160910 02:46:21< celmin> Hurry up, Travis. :|
20160910 02:46:45< irker261> wesnoth: Charles Dang wesnoth:master e993e2820b26 / src/gui/core/ (canvas.cpp canvas.hpp): Refactored GUI2 canvas to use an SDL_Renderer context https://github.com/wesnoth/wesnoth/commit/e993e2820b26e244ee0fa1f8df0f5c16d2bad763
20160910 02:46:45< tad_> The chatbox fix in celmin's branch worked.
20160910 02:46:49< vultraz> Aginor: ^ I think you'll like this commit
20160910 02:47:10< celmin> Ah, good to know. Hopefully that'll mean that Travis also passes on the GCC builds now.
20160910 02:47:28< celmin> Or at least, only fails due to the unit test segfault.
20160910 02:47:29< vultraz> (credit to spixi and his graph widget for showing me that it was actually possible)
20160910 02:47:40< vultraz> now, lunch ahoy!
20160910 02:47:53< celmin> vultraz: Was it using a renderer before?
20160910 02:47:56< tad_> I didn't do the SDL stuff .. couldn't get yoru branch to merge (lack of git knowledge I guess) so I hand-applied
20160910 02:47:59< vultraz> celmin: no
20160910 02:48:03< celmin> Excellent.
20160910 02:48:13< vultraz> celmin: direct single-pixel surface manipulation
20160910 02:48:25< celmin> Using a renderer everywhere would likely help with getting OpenGL supported.
20160910 02:48:37< vultraz> except for rectangle filling, which I had converted to use one of our hacky alpha rectangle fill functions
20160910 02:49:00< celmin> tad_: You can't just do "git merge branch-name"?
20160910 02:49:17< celmin> Or maybe "git fetch origin branch-name; git merge FETCH_HEAD"?
20160910 02:49:23< vultraz> celmin: indeed.
20160910 02:49:27< vultraz> hopefully Aginor is also pleased
20160910 02:49:49< tad_> celmin: tried a few times, gave up and hand edited. I'll clean up when you merge on master
20160910 02:50:07< celmin> Just out of curiosity, does it seem to make any difference in performance?
20160910 02:50:18< celmin> Obviously you'd need proper timing tests to be sure, but...
20160910 02:50:57< celmin> Also also, do diagonal lines look any different?
20160910 02:51:02< celmin> (Again, just out of curiosity.)
20160910 02:51:56< celmin> Aw, you used DrawPoint for the circle. :/
20160910 02:51:59-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 02:52:00< travis-ci> wesnoth/wesnoth#10799 (CelticMinstrel-travis-fix - dac9bcc : Celtic Minstrel): The build is still failing.
20160910 02:52:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158903534
20160910 02:52:00-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 02:52:05< vultraz> celmin: honestly, it does
20160910 02:52:14< vultraz> opening dialogs feels a lot snappier 
20160910 02:52:27< vultraz> especially small ones
20160910 02:52:51< celmin> …
20160910 02:52:52< vultraz> i haven't tested diagonal lines
20160910 02:54:40-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160910 02:54:53< celmin> Ugh, no idea how to fix the latest error… probably need to edit the SConstruct
20160910 02:55:09< celmin> Well, I'll merge the fixes I have.
20160910 02:55:44< irker261> wesnoth: Celtic Minstrel wesnoth:master 5e750b008366 / src/ (gui/widgets/chatbox.hpp sdl/utils.cpp storyscreen/render.cpp): Fix some Travis compile errors (#768) https://github.com/wesnoth/wesnoth/commit/5e750b008366748c7927a2e92f64277bf8d39082
20160910 02:56:25< celmin> Still two issues to work out with Travis - the -Wold-style-cast and the bad_alloc.
20160910 02:58:58< celmin> Does SDL support setting line thickness?
20160910 03:09:13< celmin> BTW vultraz, I really do not like the way you handled circles. That's no better than using put_pixel.
20160910 03:10:30< celmin> vultraz: Also, why is the renderer created on every draw?
20160910 03:10:55< celmin> Isn't that a memory leak?
20160910 03:14:16< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 5945c7cb7115 / src/tests/gui/test_gui2.cpp: Travis test https://github.com/wesnoth/wesnoth/commit/5945c7cb7115ae62fbd966a642482219d70badf7
20160910 03:27:36-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160910 03:35:12-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 03:35:13< travis-ci> wesnoth/wesnoth#10801 (master - e993e28 : Charles Dang): The build is still failing.
20160910 03:35:13< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158906997
20160910 03:35:13-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 03:35:29-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 03:37:27< tad_> OK. Found the error hanging the game .. no sound support. Disabled all sounds and it's working.
20160910 03:37:48< tad_> Re-tested unit advances=1 and it's going to Mage Leader
20160910 03:38:01< tad_> I'm going to repeat the modify and transform tests 
20160910 03:42:00< tad_> OK. I'm declaring the problem solved by clearing cache/etc.
20160910 03:43:50< celmin> :/
20160910 03:44:08< celmin> It's nice that it's fixed, but the fact that it ever happened still feels like a lurking problem...
20160910 03:44:43< tad_> [transform_unit] now takes it to Mage Leader, too.  HP still 29/48. 
20160910 03:45:17< celmin> Odd that transform_unit seems to preserve hp
20160910 03:45:28< celmin> Unless that's optional
20160910 03:45:41< celmin> Though I still wouldn't expect it to be the default
20160910 03:45:47 * tad_ nods. IT was 29/29 and became 29/48. So it's simply changing the max.
20160910 03:45:55< celmin> I see.
20160910 03:47:56< tad_> The issues which I hit were clearing config reset sounds on and that hung the game; clearing config reset resolution and did not query window size or set window size; and there seems to be something going on with cache sync (dont thing it's corruption) but this is -dev so some sync issues should be expected.
20160910 03:48:25< celmin> You're getting the cache corruption errors too then?
20160910 03:48:45< vultraz> celmin: yes, I need to redo circles
20160910 03:49:02< vultraz> celmin: I'm not entirely sure what method you meant
20160910 03:49:04< tad_> No errors. But clearing cache was my vote for what fixed the advancement issue
20160910 03:49:08< celmin> The second thing I said is probably far more important.
20160910 03:49:15-!- enchi139 is now known as enchi
20160910 03:49:25< celmin> And I meant DrawPoints / DrawLines.
20160910 03:49:36< vultraz> celmin: it needs to be refreshed/created after the surface is assigned
20160910 03:49:37< celmin> Rather than DrawPoint
20160910 03:50:10< celmin> And where are you destroying it?
20160910 03:50:25< vultraz> hm
20160910 03:50:30< vultraz> good question
20160910 03:50:35< celmin> Nowhere.
20160910 03:50:39< celmin> And how many times is draw(bool) called for a given canvas?
20160910 03:50:58< vultraz> I am unsure
20160910 03:50:59< celmin> For that matter, why is the surface created in draw?
20160910 03:51:10< vultraz> again, unsure.
20160910 03:51:18< vultraz> it still needs work, and I shall work on it now
20160910 03:51:24< celmin> Anyway, if you're unsure, at least:
20160910 03:51:49< celmin> 1. Delete it in the destructor.
20160910 03:51:56< vultraz> yeah I was going to suggest that
20160910 03:52:02< celmin> 2. Delete it before creating it (if not null).
20160910 03:52:31< vultraz> do both>
20160910 03:52:32< vultraz> ?
20160910 03:53:09< vultraz> what if I use a unique_ptr
20160910 03:53:32< celmin> You can, but you need a custom deleter for that.
20160910 03:53:50< vultraz> hm..
20160910 03:53:52< vultraz> maybe not
20160910 03:54:04< celmin> (It's not hard to do a custom deleter.)
20160910 03:54:12< celmin> (Might not even need to write one yourself.)
20160910 03:54:44 * celmin checks the SDL docs
20160910 03:54:54< celmin> Well, that's useless.
20160910 03:55:14< celmin> Anyway, if SDL_DestroyRenderer checks for null, then it would be sufficient to pass it as the deleter.
20160910 03:55:28< celmin> If not, you'd need a custom deleter that checks for null and calls it.
20160910 03:55:43< vultraz> does it?
20160910 03:56:04< celmin> No idea. The docs don't say, so I think the only way to tell would be to check the source.
20160910 03:56:38< tad_> If you do that remember if it aint in the docs it can change at any time
20160910 03:57:09< celmin> Well, true, but surely it's unlikely that someone would remove a null check?
20160910 03:57:26-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 03:57:27< travis-ci> wesnoth/wesnoth#10802 (master - 5e750b0 : Celtic Minstrel): The build is still failing.
20160910 03:57:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158907583
20160910 03:57:28-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 03:57:36< vultraz> so do you want me to use a unique_ptr or not?
20160910 03:57:41< celmin> Up to you?
20160910 03:57:51< celmin> I have no problem with the idea.
20160910 03:58:09< tad_> Easy enough to wrap it yourself
20160910 03:58:28< celmin> Yeah, true enough.
20160910 04:00:08< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 727346d462f2 / src/tests/gui/test_gui2.cpp: Travis test https://github.com/wesnoth/wesnoth/commit/727346d462f22048aafa6405a76afb1e9bdb8db0
20160910 04:02:01< vultraz> how do I pass a deleter?
20160910 04:02:30< celmin> In the constructor, as the second parameter.
20160910 04:02:53< celmin> (The first can be nullptr when you don't have the actual pointer yet.)
20160910 04:05:19< vultraz> hm. |error: invalid application of 'sizeof' to incomplete type 'SDL_Renderer'|
20160910 04:05:55< celmin> That means you need to include SDL.
20160910 04:06:11< vultraz> I did
20160910 04:06:51-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160910 04:07:26< celmin> This is in the source file, not the header, right?
20160910 04:07:30< celmin> Oh.
20160910 04:07:36< celmin> I think I remember this error before.
20160910 04:07:57< vultraz> advice?
20160910 04:08:11< celmin> unique_ptr doesn't work with incomplete types (which kinda strikes me as a bug though), so you might have to settle for shared_ptr, or something.
20160910 04:08:27< vultraz> blah
20160910 04:08:36< vultraz> I'll just stick with the pointer for now
20160910 04:09:11< celmin> What?
20160910 04:09:28< celmin> That seems like a weird conclusion, considering that shared_ptr does almost the exact same thing.
20160910 04:09:43< vultraz> alright...
20160910 04:11:21< vultraz> I don't know why canvas is recreated on draw(), btw
20160910 04:13:15< vultraz> blah!
20160910 04:13:37< vultraz> let's hope an include works this time..
20160910 04:15:14< vultraz> it does not
20160910 04:18:38-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 04:18:39< travis-ci> wesnoth/wesnoth#10803 (travis-fix - 5945c7c : Celtic Minstrel): The build failed.
20160910 04:18:39< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158909184
20160910 04:18:39-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 04:21:41< vultraz> man, travis is bitchy today
20160910 04:22:59< vultraz> hm...
20160910 04:23:06< vultraz> how would I generate the array of points..
20160910 04:23:07< vultraz> or lines..
20160910 04:23:37< celmin> You can generate it exactly as you already do
20160910 04:23:48< celmin> Just push them in a vector and draw them all at once.
20160910 04:23:58< vultraz> oh
20160910 04:24:00< vultraz> ah
20160910 04:24:24< celmin> And Travis is complaining because I'm trying to fix it.
20160910 04:24:51< celmin> Hmm...
20160910 04:25:05< celmin> I was hoping that I could narrow the cause to one of the recently-added dialogs...
20160910 04:26:54< irker261> wesnoth: Celtic Minstrel wesnoth:master 5945c7cb7115 / src/tests/gui/test_gui2.cpp: Travis test https://github.com/wesnoth/wesnoth/commit/5945c7cb7115ae62fbd966a642482219d70badf7
20160910 04:26:56< irker261> wesnoth: Celtic Minstrel wesnoth:master 727346d462f2 / src/tests/gui/test_gui2.cpp: Travis test https://github.com/wesnoth/wesnoth/commit/727346d462f22048aafa6405a76afb1e9bdb8db0
20160910 04:26:59< irker261> wesnoth: Celtic Minstrel wesnoth:master add46bc36766 / src/tests/gui/test_gui2.cpp: Travis test https://github.com/wesnoth/wesnoth/commit/add46bc3676634ba2b6843241a4c7b69c159503f
20160910 04:27:06< celmin> ...whoops.
20160910 04:27:15< vultraz> uh...
20160910 04:27:18< vultraz> "an array of SDL_Point structures that represent the points to draw"
20160910 04:27:30< vultraz> but the type is const SDL_Point*?
20160910 04:27:32< vultraz> what?
20160910 04:27:34< vultraz> I'm confused :|
20160910 04:27:44< celmin> Arrays decay to pointers.
20160910 04:29:05< vultraz> but don't arrays have to be fixed-size
20160910 04:29:16< celmin> Yes they do.
20160910 04:29:21< vultraz> so...
20160910 04:29:53< vultraz> I need to pre-calculate how many points I need?
20160910 04:30:40< celmin> No.
20160910 04:30:47< celmin> You can use a vector.
20160910 04:30:55< vultraz> ...
20160910 04:30:59< vultraz> wha..??
20160910 04:31:18< celmin> A vector knows its size, and you can get the data in the format SDL expects with .data()
20160910 04:31:18< vultraz> then how do I get an array from a vector
20160910 04:31:47< celmin> Which is basically a pointer to the first element, but is intended just for this sort of thing.
20160910 04:32:11< celmin> I wish we could force-push master to get rid of those three commits I just pushed...
20160910 04:32:12< celmin> :/
20160910 04:32:34< vultraz> do you want me to enable force-pushing for a moment?
20160910 04:33:03< celmin> Well, if you want to...
20160910 04:33:15< celmin> It's generally a bad idea (not that that stops me with BoE).
20160910 04:33:34< celmin> I can also just push a revert though.
20160910 04:34:32< vultraz> celmin: you have 5 minutes
20160910 04:34:35< celmin> (Clearly I should actually make a local branch for this sort of thing instead of doing it on master and just pushing it to a different remote.)
20160910 04:35:09< vultraz> tell me when you're done
20160910 04:35:29< celmin> Done.
20160910 04:36:09< celmin> I guess irker didn't say anything because there were no new commits.
20160910 04:36:19< vultraz> Renabled branch protection
20160910 04:37:29< celmin> Oh hey, I can git checkout -f to tell it to ignore the fact that files are changed.
20160910 04:37:59< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix add46bc36766 / src/tests/gui/test_gui2.cpp: Travis test https://github.com/wesnoth/wesnoth/commit/add46bc3676634ba2b6843241a4c7b69c159503f
20160910 04:38:07< celmin> I'm starting to get annoyed at typing my password every time.
20160910 04:38:16< celmin> Maybe I should change the URL to ssh so it uses my key,
20160910 04:38:17< celmin> >_>
20160910 04:38:27< vultraz> duh? :P
20160910 04:38:46< celmin> Well, I was kinda treating it as an extra level of protection, but that clearly didn't help this time.
20160910 04:39:46-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160910 04:41:52< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 604591c826a5 / src/tests/gui/test_gui2.cpp: Test disabling chat_log https://github.com/wesnoth/wesnoth/commit/604591c826a5b06577a7d6883e9a34ea3a805d22
20160910 04:42:17< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 52ff6c9a37a3 / src/tests/gui/test_gui2.cpp: Test disabling game_stats https://github.com/wesnoth/wesnoth/commit/52ff6c9a37a3611656d0294a751ce3bf6ba6e0f1
20160910 04:43:09< celmin> Ahhhh, I just realized what I was missing.
20160910 04:43:28-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 04:43:29< travis-ci> wesnoth/wesnoth#10804 (travis-fix - 727346d : Celtic Minstrel): The build failed.
20160910 04:43:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158912341
20160910 04:43:29-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 04:43:34< celmin> I need to start over now.
20160910 04:45:28< celmin> vultraz: Do you have Travis access?
20160910 04:45:35< vultraz> no
20160910 04:45:46< celmin> Oh well, I guess we'll just let those builds fail.
20160910 04:46:13< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 0f286e0770a9 / src/tests/gui/test_gui2.cpp: Test disabling chat_log https://github.com/wesnoth/wesnoth/commit/0f286e0770a91e244f4703973c9494f19c5ef20f
20160910 04:47:01< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 2f323f12fabc / src/tests/gui/test_gui2.cpp: Test disabling game_load https://github.com/wesnoth/wesnoth/commit/2f323f12fabc1923080bf40f8af57d83b3a96e6d
20160910 04:47:43< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix f95c9bed2588 / src/tests/gui/test_gui2.cpp: Test disabling game_stats https://github.com/wesnoth/wesnoth/commit/f95c9bed25886189bb6ceaf008b967e90accbedd
20160910 04:48:15< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix 8498bbc1c5e1 / src/tests/gui/test_gui2.cpp: Test disabling generator_settings https://github.com/wesnoth/wesnoth/commit/8498bbc1c5e16e8cfc5526028fceb58a041dbab8
20160910 04:48:39< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix f4b2bc276979 / src/tests/gui/test_gui2.cpp: Test disabling title_screen https://github.com/wesnoth/wesnoth/commit/f4b2bc2769794d48c7c20cb5819608f7339785cd
20160910 04:48:55< irker261> wesnoth: Celtic Minstrel wesnoth:travis-fix ca8f356ccffd / src/tests/gui/test_gui2.cpp: Test disabling tooltips https://github.com/wesnoth/wesnoth/commit/ca8f356ccffd1de954cebe5205671eca7ca0b65a
20160910 04:49:10< celmin> There. Hopefully at least one of those will succeed, and then I'll know which dialog is causing bad_alloc.
20160910 04:50:02< celmin> So, starting at build 10810, I need to pay attention.
20160910 04:50:07< celmin> Might have to check logs tomorrow.
20160910 04:52:58< celmin> (Mind you, all of them are going to report failure, IIRC.)
20160910 04:53:35< celmin> (Due to GCC builds.)
20160910 04:54:03< celmin> (But if at least all clang builds can pass, that would be progress.)
20160910 04:59:26< tad_> I don't get that. I'm running GCC and get a clean (enough) build. The only messages I get are the Boost deprecated headers #pragma messages we can't fix.
20160910 04:59:57< tad_> $ gcc --version gcc (GCC) 6.1.1 20160802
20160910 05:00:42< celmin> Don't get what?
20160910 05:00:51< celmin> The -Wold-style-cast error?
20160910 05:03:01< tad_> No. I don't get why Travis has a problem in the gcc build at all.
20160910 05:03:41< celmin> The specific error is something like "-Wold-style-cast does not apply to C".
20160910 05:05:32< tad_> Oh! It's not a compile error. It's GCC telling you that C++ does not have "old K&R C cast syntax" at all, you can only do old K&R-style casts in C.
20160910 05:05:41< tad_> So the -W option is meaninless
20160910 05:05:56< celmin> Yes.
20160910 05:06:04-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 05:06:05< travis-ci> wesnoth/wesnoth#10805 (master - add46bc : Celtic Minstrel): The build has errored.
20160910 05:06:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158914094
20160910 05:06:05-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 05:06:09< celmin> But it's causing the build to report failure on Travis.
20160910 05:06:10< tad_> Now I see.
20160910 05:06:32< celmin> Probably due to -Werror or something.
20160910 05:06:43< celmin> Since it's normally reported as a warning, I think.
20160910 05:07:18< tad_> Yes. -Werror says to treat ALL warnings as errors, even warnings about compiler options.
20160910 05:07:39-!- Netsplit *.net <-> *.split quits: higgins, abruanese, vincent_c, irker261, Rhonda, Bonobo, nurupo, enchi, oldlaptop, aidanhs,  (+11 more, use /NETSPLIT to show all of them)
20160910 05:08:00< celmin> Exactly.
20160910 05:08:18< vultraz> dat netsplit
20160910 05:10:04< tad_> Obvious solution is to find what added -Wold-style-cast as a specific warning on the command line. Which I suppose is what's beating you up.
20160910 05:10:37< tad_> Well, it's late and I wasted the day on an cache synchronization issue. 
20160910 05:10:45 * tad_ laterZ.
20160910 05:10:49-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160910 05:12:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 05:12:54< celmin> No, that's not what's beating me up at all. I haven't even looked at that yet. :/
20160910 05:14:42-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 05:14:43< travis-ci> wesnoth/wesnoth#10807 (travis-fix - add46bc : Celtic Minstrel): The build has errored.
20160910 05:14:43< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158914614
20160910 05:14:43-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 05:16:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160910 05:20:39-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 05:20:40< travis-ci> wesnoth/wesnoth#10808 (travis-fix - 604591c : Celtic Minstrel): The build has errored.
20160910 05:20:40< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158914949
20160910 05:20:40-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 05:22:03< celmin> Ah, they're erroring because the commits have vanished.
20160910 05:22:38< vultraz> just found a nice cleanup task I can do
20160910 05:22:42< vultraz> get rid of create_rect 
20160910 05:22:47< celmin> Next one will too, then they'll go back to failing.
20160910 05:22:49< celmin> create_rect?
20160910 05:22:52< celmin> I dunno about that...
20160910 05:23:35< vultraz> it's literally a wrapper for SDL_Rect r; r.x =x; r.y = y; r.h = h; r.w = w; return r
20160910 05:24:04< celmin> Well, I suppose you could use {} notation instead, though using a wrapper is more convenient sometimes.
20160910 05:24:15< celmin> Because {} doesn't allow implicit narrowing.
20160910 05:24:33-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160910 05:25:10-!- Netsplit over, joins: Bonobo, Appleman1234, Jetrel, Aginor, nurupo, higgins
20160910 05:25:20-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 05:25:21< travis-ci> wesnoth/wesnoth#10809 (travis-fix - 52ff6c9 : Celtic Minstrel): The build has errored.
20160910 05:25:21< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158914963
20160910 05:25:21-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 05:26:27-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160910 05:38:25< vultraz> hmm
20160910 05:38:31< vultraz> I have a rather... interesting idea
20160910 05:38:35 * vultraz experiements
20160910 05:38:39< vultraz> experiments 
20160910 06:00:18-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 06:00:19< travis-ci> wesnoth/wesnoth#10810 (travis-fix - 0f286e0 : Celtic Minstrel): The build is still failing.
20160910 06:00:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158915224
20160910 06:00:19-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 06:09:09< vultraz> hm.
20160910 06:09:17< vultraz> how would one get a path string from image::locator
20160910 06:09:35< vultraz> ah
20160910 06:23:29-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160910 06:24:00-!- aeonchild is now known as enchi
20160910 06:25:07< vultraz> blah
20160910 06:25:09< vultraz> not working, sadly
20160910 06:25:47-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 06:25:48< travis-ci> wesnoth/wesnoth#10811 (travis-fix - 2f323f1 : Celtic Minstrel): The build is still failing.
20160910 06:25:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158915272
20160910 06:25:48-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 06:26:06-!- JyrkiVesterinen [~JyrkiVest@87-100-213-150.bb.dnainternet.fi] has joined #wesnoth-dev
20160910 06:27:29< vultraz> so I had thought I could maybe load each image as a texture and copy it to the render context, instead of blitting to the canvas every time an image was loaded 
20160910 06:27:50< vultraz> which works, except I can't get it to load every image correctly
20160910 06:27:55< vultraz> and it ends up with black borders
20160910 06:28:11< vultraz> or, well, black area
20160910 06:28:36< vultraz> on partially-transparent areas
20160910 06:29:37< vultraz> that won't do at all
20160910 06:31:51< vultraz> otherwise it works
20160910 06:33:53< vultraz> hm..
20160910 06:35:24< vultraz> ok, just realized something..
20160910 06:35:31< vultraz> what... is surface 
20160910 06:35:35< vultraz> the type
20160910 06:38:38< vultraz> oh, I see
20160910 06:38:40< vultraz> it is a struct
20160910 06:40:04-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160910 06:41:24< vultraz> curious why SDL_CreateTextureFromSurface accepted it as an argument
20160910 06:41:29< vultraz> no matter, though.
20160910 06:44:42< vultraz> let's try converting the surface alpha to premultipled..
20160910 06:47:47-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 06:47:48< travis-ci> wesnoth/wesnoth#10812 (travis-fix - f95c9be : Celtic Minstrel): The build is still failing.
20160910 06:47:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158915319
20160910 06:47:48-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 07:00:16 * vultraz cannot figure out how to do that
20160910 07:00:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 07:04:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160910 07:12:17-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 07:12:18< travis-ci> wesnoth/wesnoth#10813 (travis-fix - 8498bbc : Celtic Minstrel): The build is still failing.
20160910 07:12:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158915342
20160910 07:12:18-!- travis-ci [~travis-ci@ec2-54-242-230-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 07:16:49-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has joined #wesnoth-dev
20160910 07:16:49-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Changing host]
20160910 07:16:49-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20160910 07:16:59 * vultraz pokers irker
20160910 07:17:03< mordante> servus
20160910 07:17:04< vultraz> ah, hello, mordante 
20160910 07:17:15< mordante> hi vultraz 
20160910 07:19:37< vultraz> ok, so I'm abandoning the use of textures in canvas::timage for now
20160910 07:19:49-!- Kwandulin [~Miranda@p200300760F2C71B8E151E119B3E8E03C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160910 07:20:10< vultraz> the performance gain from converting the canvas to use a renderer context is enough reason to be happy for today
20160910 07:22:51< vultraz> the problem seems to be in the partial alpha channels of the loaded surface 
20160910 07:25:52< vultraz> mordante: have you returned to finish GUI2? :D
20160910 07:30:31< mordante> vultraz, not at the moment, maybe later
20160910 07:31:04< mordante> I saw we moved towards C++11 :-)
20160910 07:32:30< vultraz> Yes
20160910 07:32:34-!- Duthlet [~Duthlet@dslb-188-104-255-138.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160910 07:32:35< vultraz> We now use SDL2 and C++11
20160910 07:33:00< mordante> C++11 is a lot of fun :-
20160910 07:33:03< mordante> :-)*
20160910 07:33:20< vultraz> Indeed
20160910 07:33:26< vultraz> Praise lambdas 
20160910 07:34:54-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 07:34:55< travis-ci> wesnoth/wesnoth#10814 (travis-fix - f4b2bc2 : Celtic Minstrel): The build is still failing.
20160910 07:34:55< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158915356
20160910 07:34:55-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 07:35:40< vultraz> celtisminstrel: btw, I committed that change to draw_circle you wanted
20160910 07:35:43< vultraz> irker just didn't report it
20160910 07:39:18< vultraz> blah..
20160910 07:39:26< vultraz> Back To Turn N is broken :|
20160910 07:39:35< vultraz> it just crashes to titlescreen
20160910 07:50:39-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160910 08:00:01-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 08:00:02< travis-ci> wesnoth/wesnoth#10815 (travis-fix - ca8f356 : Celtic Minstrel): The build is still failing.
20160910 08:00:02< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158915365
20160910 08:00:02-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 08:04:29-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160910 08:04:29-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160910 08:04:29-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160910 08:04:29-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev
20160910 08:04:29-!- Sirp_ [~Sirp@u17402953.onlinehome-server.com] has joined #wesnoth-dev
20160910 08:04:29-!- Rhonda [~rhonda@anguilla.debian.or.at] has joined #wesnoth-dev
20160910 08:04:29-!- aidanhs [~aidanhs@2a00:d880:6:1ad::8e27] has joined #wesnoth-dev
20160910 08:04:29-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20160910 08:05:07-!- irker261 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160910 08:05:07-!- fabi_ [~fabi@176.0.92.30] has joined #wesnoth-dev
20160910 08:05:11-!- abruanese [~a@45.63.97.181] has joined #wesnoth-dev
20160910 08:05:11-!- APic [apic@apic.name] has joined #wesnoth-dev
20160910 08:05:11-!- kidneb [~kidneb@178.79.173.107] has joined #wesnoth-dev
20160910 08:05:11-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20160910 08:05:11-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20160910 08:05:25-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160910 08:46:19< Sirp_> Aginor: I have not received a reply to my message on the wesnoth forums. Please reply and let me know if you accept or decline your nomination to the Wesnoth, inc board.
20160910 08:46:57< Sirp_> Celticminstrel, doofus, gfgtdf, Horus2, Jetrel, shadowm, and zookeeper also need to reply.
20160910 08:48:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 08:53:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160910 09:09:15-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160910 09:22:07-!- horus2 [~1@91.83.190.35.pool.invitel.hu] has joined #wesnoth-dev
20160910 09:32:48-!- mjs-de [~mjs-de@x4e311528.dyn.telefonica.de] has joined #wesnoth-dev
20160910 09:47:19-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160910 09:50:23-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160910 09:50:23-!- wedge010 is now known as wedge009
20160910 09:57:01-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160910 09:57:09-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has joined #wesnoth-dev
20160910 10:09:54-!- JyrkiVesterinen [~JyrkiVest@87-100-213-150.bb.dnainternet.fi] has quit [Quit: .]
20160910 10:11:52-!- Bonobo [~Bonobo@2001:44b8:254:3200:40a5:71fa:b2e2:c976] has quit [Ping timeout: 255 seconds]
20160910 10:12:12-!- Bonobo [~Bonobo@2001:44b8:254:3200:24b4:c986:295b:5ca9] has joined #wesnoth-dev
20160910 10:33:55-!- horus2 [~1@91.83.190.35.pool.invitel.hu] has left #wesnoth-dev []
20160910 10:36:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 10:41:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160910 10:45:00< irker261> wesnoth: Charles Dang wesnoth:master eaf5ef96ed7a / data/gui/widget/button_default.cfg: Buttons: refactored procedural drawing to avid alpha-corner hack https://github.com/wesnoth/wesnoth/commit/eaf5ef96ed7a20048ef17e7dea0fa3a251bfbf1b
20160910 10:45:16< vultraz> celticminstrel ^
20160910 10:46:53< vultraz> rounded buttons are back, now with 100% less alpha hack
20160910 10:53:16-!- Kwandulin [~Miranda@p200300760F2C71B8E151E119B3E8E03C.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160910 10:58:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160910 11:04:58-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Read error: Connection reset by peer]
20160910 11:12:05-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160910 11:20:22-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 11:20:23< travis-ci> wesnoth/wesnoth#10817 (master - eaf5ef9 : Charles Dang): The build is still failing.
20160910 11:20:23< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158944455
20160910 11:20:23-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 11:32:50< vultraz> well now it's complaining about -Wold-style-cast
20160910 11:33:54-!- horus2 [~1@91.83.190.35.pool.invitel.hu] has joined #wesnoth-dev
20160910 11:34:34< vultraz> on savepng.c
20160910 11:37:10-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160910 11:49:37-!- Kwandulin [~Miranda@p200300760F2C71B8353C765F7981F6BB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160910 12:03:21-!- Kwandulin_2 [~Miranda@p200300760F2C71B8F10177E98D318AF8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160910 12:06:10-!- Kwandulin [~Miranda@p200300760F2C71B8353C765F7981F6BB.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160910 12:17:20-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160910 12:18:33< gfgtdf> vultraz: i just updated master and i still cannot load game while playing another game.
20160910 12:18:48< gfgtdf> vultraz: the loadgame dialogs opos up but after its closed i get thrown to tiltescreen
20160910 12:19:58< gfgtdf> celmin: this migth eb related to you titlescreen refctor ?
20160910 12:24:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160910 12:29:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160910 12:30:08< vultraz> gfgtdf: confirmed
20160910 12:30:17< vultraz> gfgtdf: likely, since it worked after my loadgame fixes...
20160910 12:30:24< vultraz> (also celmin did the titlescreen refactor)
20160910 12:31:26< gfgtdf> celmin: i dont reall understand this line:  https://github.com/wesnoth/wesnoth/blob/master/src/wesnoth.cpp#L773 shouldnt break and continue do exactly the same thing here ?
20160910 12:32:22< gfgtdf> (break escapes form the switch, 'continue' continues the outer loop) which shoudlbe teh same since teh switch is teh last thing in that loop
20160910 12:33:07< vultraz> i guess...
20160910 12:33:10< vultraz> not sure
20160910 12:34:45< vultraz> i think what happens is the game quits but we get caught in the titlescreen
20160910 12:34:49< vultraz> or something..
20160910 12:34:49< gfgtdf> celmin i think the issue this is caused  by your removal of these lines: https://github.com/wesnoth/wesnoth/commit/d0906ceac57c21edd380f41b28507dc6cf4ed18e#diff-fce7a1e6525522f3e4ab47349051a806L760
20160910 12:35:09< gfgtdf> (and the following 'if(res == gui2::ttitle_screen::NOTHING) {')
20160910 12:35:29< vultraz> hm looks likely
20160910 12:39:26< vultraz> yeah, that looks like the cause
20160910 12:39:53< vultraz> still buggy, though..
20160910 12:42:03< vultraz> ie, if you restore the check for is_loading() when you try to load a game it will go right to the end
20160910 12:42:13< vultraz> s/you/i
20160910 12:46:14< gfgtdf> hmm what do you mean by 'go right to the end'
20160910 12:46:35< vultraz> I get the "The End" screen + credits
20160910 12:47:32< gfgtdf> hmm
20160910 12:47:35< gfgtdf> will test
20160910 12:55:57< gfgtdf> vultraz: did happen to me, but its possible that my fix is differetn than yours.
20160910 12:56:24< vultraz> I think I have a fix
20160910 12:57:08< vultraz> well, part of one
20160910 12:58:46< vultraz> hmmm
20160910 13:00:39< vultraz> it has something to do with the check for if(!game->load_game())...
20160910 13:01:32< vultraz> or lack thereof
20160910 13:02:58< vultraz> game->clear_loaded_game(); clears the load_game_exception 
20160910 13:05:03< gfgtdf> vultraz: this is my curretn fix: http://pastebin.com/53sGtXhi
20160910 13:05:15< gfgtdf> vultraz: in wesnoth.cpp
20160910 13:05:24< vultraz> hm
20160910 13:06:01< gfgtdf> i think logs game exception coudl need some refactor.
20160910 13:06:13< gfgtdf> load_*
20160910 13:06:21< gfgtdf> though*
20160910 13:06:34< vultraz> yes
20160910 13:06:38< vultraz> it's ugly as sin :|
20160910 13:07:06< vultraz> there should be a way to just say 'exit game, load one with data, either from a save or elsewhere'.
20160910 13:07:15< vultraz> even if it uses game quit exception or something
20160910 13:07:56< gfgtdf> vultraz: well i think it makes sense to ahv 2 different types of those exceptions.
20160910 13:07:58< vultraz> gfgtdf: your fix causes an assertion if you use F5 from the titlescreen after loading a game and reutnring
20160910 13:08:08< gfgtdf> vultraz: we coudle ven make load_game exceptio derive from guit_game_exception
20160910 13:08:35< vultraz> optimally we wouldn't use exceptions at all
20160910 13:08:43< vultraz> just signal the gameloop to terminate
20160910 13:09:42< gfgtdf> hmm looks liek somehing isn't cleared as it should
20160910 13:10:01< vultraz> well RELOAD_GAME_DATA does call 	config_manager.reload_changed_game_config();
20160910 13:12:05-!- horus2 [~1@91.83.190.35.pool.invitel.hu] has left #wesnoth-dev []
20160910 13:14:15< vultraz> gfgtdf: ok I have a fix that doesn't crash
20160910 13:15:09< vultraz> should I commit?
20160910 13:16:33< gfgtdf> vultraz: ok
20160910 13:19:34< irker261> wesnoth: Charles Dang wesnoth:master 54e879b18344 / src/wesnoth.cpp: Fix not being able to load a game from within a game https://github.com/wesnoth/wesnoth/commit/54e879b18344bf38b58d7d8fe2fb7a2dba415d60
20160910 13:19:37< vultraz> gfgtdf: ^
20160910 13:20:19< gfgtdf> vultraz: thx
20160910 13:21:05< vultraz> well you found the bug :)
20160910 13:21:27-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has quit [Quit: Leaving]
20160910 13:22:42< vultraz> (and gave me code)
20160910 13:24:55-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160910 13:28:51-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160910 13:39:18-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160910 13:52:29< gfgtdf> vultraz: do you know why ew store the loadgame data things in stastic variables instead of the exception object ?
20160910 13:55:02-!- travis-ci [~travis-ci@ec2-54-161-180-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 13:55:03< travis-ci> wesnoth/wesnoth#10818 (master - 54e879b : Charles Dang): The build is still failing.
20160910 13:55:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158960007
20160910 13:55:03-!- travis-ci [~travis-ci@ec2-54-161-180-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 13:55:20-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160910 14:02:25-!- Kwandulin_2 [~Miranda@p200300760F2C71B8F10177E98D318AF8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160910 14:07:16< mattsc> gfgtdf: hi; are you familiar with the [tunnel] code?
20160910 14:07:32< gfgtdf> mattsc: not really
20160910 14:08:05< mattsc> gfgtdf: okay; I’ll have a look into it then sometime.
20160910 14:13:17< mattsc> At the very least we need to do something about the fact that own units on the exit hex act as ambushers (that is, that the range given by the pathfinder and that achievable are different, and that that is caused by units that are well known).  There are a couple other things I have in mind too.
20160910 14:28:25-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160910 14:30:19< gfgtdf> vultraz: what exactly was the reason for adding the load_game_metadata struct? i want toi use load_game_exception the same struct (instad of those loadgame_exception::game.. etc) and might want move the load_config out of that struct for that.
20160910 14:41:25-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160910 14:46:40-!- Duthlet [~Duthlet@dslb-188-104-255-138.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20160910 14:50:48< celmin> So it was the titlescreen.
20160910 14:51:23< celmin> The build disabling it had all but one green job.
20160910 14:52:30-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20160910 14:53:29-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160910 14:55:42< celmin> vultraz: So, I assume you tested that that does not throw errors because you're destroying a null renderer?
20160910 14:56:01< celmin> Hehe, you missed the O in "avoid".
20160910 14:56:45< celmin> So does this mean buttons are (temporarily?) pointy again?
20160910 14:57:13< celmin> Or did you manage to retain the slightly rounded corners without the alpha hack?
20160910 14:58:54-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20160910 14:59:08-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160910 14:59:17< celmin> Bah, SDL_RenderDrawLines is misnamed. It should be called SDL_RenderDrawPolygon. :(
20160910 14:59:35< celmin> The distinction means I won't be able to use it for the rounded rectangle.
20160910 15:00:04< celmin> Well, unless I treat the corners as a polygon.
20160910 15:01:01 * celmin would have expected a DrawLines function to draw disconnected lines, ie instead of n-1 lines it should draw n/2 lines.
20160910 15:02:08< celmin> vultraz: Thanks for that fix BTW. Clearly I did not sufficiently understand the logic of the main game loop.
20160910 15:25:42-!- Kwandulin [~Miranda@p200300760F2C71B86002C4EAD4CB50EE.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160910 15:33:23< celmin> So for some reason breakpoint aren't working in the unit tests, making it impossible to debug the titlescreen bad_alloc…  :(
20160910 15:34:09-!- Bonobo [~Bonobo@2001:44b8:254:3200:24b4:c986:295b:5ca9] has quit [Quit: Leaving]
20160910 15:37:03< celmin> Aha, I think I found the problem.
20160910 15:43:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160910 15:43:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160910 15:53:16-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160910 16:16:00-!- edgrey [~edgrey@178.204.109.246] has joined #wesnoth-dev
20160910 16:16:38-!- edgrey [~edgrey@178.204.109.246] has quit [Client Quit]
20160910 16:17:00-!- edgrey [~edgrey@178.204.109.246] has joined #wesnoth-dev
20160910 16:19:42-!- irker261 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160910 16:25:12-!- irker886 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160910 16:25:12< irker886> wesnoth: Celtic Minstrel wesnoth:travis-fix 9826d197fb73 / src/gui/dialogs/lobby/ (lobby.cpp lobby.hpp): Remove an unused variable https://github.com/wesnoth/wesnoth/commit/9826d197fb7342e1434908acdb76e613fdf68b96
20160910 16:25:12< irker886> wesnoth: Celtic Minstrel wesnoth:travis-fix 45c72faa2668 / src/ (game_launcher.cpp game_launcher.hpp tests/gui/test_gui2.cpp): Fix Travis unit tests https://github.com/wesnoth/wesnoth/commit/45c72faa266879f2cd466b1c6ae928a542d5ecdf
20160910 16:35:00-!- Kwandulin [~Miranda@p200300760F2C71B86002C4EAD4CB50EE.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160910 16:44:20-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160910 16:44:57-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160910 16:45:14-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160910 16:45:14-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160910 16:48:37 * celmin poke vultraz 
20160910 16:57:33< celmin> Anyone know why are preferences.?pp and game_preferences.?pp are separate?
20160910 17:00:02-!- travis-ci [~travis-ci@ec2-54-161-180-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 17:00:03< travis-ci> wesnoth/wesnoth#10819 (travis-fix - 45c72fa : Celtic Minstrel): The build is still failing.
20160910 17:00:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158985909
20160910 17:00:03-!- travis-ci [~travis-ci@ec2-54-161-180-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 17:00:24< celmin> :(
20160910 17:01:20< gfgtdf> celmin: i'd say we can merge them , i usually never know which to include for a given preferences:: function.
20160910 17:01:27< gfgtdf> celmin: its rathe annoing
20160910 17:01:48< celmin> There's also preferences_display.?pp IIRC
20160910 17:02:34< gfgtdf> celmin: that thought thats mainly abotu hsoign dialoges related to preferences?
20160910 17:02:41< gfgtdf> showing*
20160910 17:03:03-!- mjs-de [~mjs-de@x4e311528.dyn.telefonica.de] has quit [Remote host closed the connection]
20160910 17:03:26< celmin> It has a handful of set_* functions though...
20160910 17:04:20< celmin> Why are some of the prefs set functions prefixed with an underscore?
20160910 17:04:39< gfgtdf> maybe those are haleper function for other preferences functions ?
20160910 17:04:53< celmin> They don't look like helpers.
20160910 17:04:58< gfgtdf> just a guess though
20160910 17:05:21< celmin> Oh interesting, so set_turbo() calls _set_turbo() and also display_context::set_turbo()...
20160910 17:07:26-!- DeFender1031 [~DeFender1@46-116-114-128.bb.netvision.net.il] has joined #wesnoth-dev
20160910 17:20:43< celmin> Okay, so if I'm not mistaken, Travis is configured to give a stack trace in the event of a segfault or similar?
20160910 17:20:50-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160910 17:21:01< celmin> Not entirely sure if it works, but the problem here is probably that Boost is catching the bad_alloc.
20160910 17:22:09< celmin> gfgtdf: Any idea how the title screen might be triggering a bad_alloc? Or it might possibly be occurring in the construction of the game_launcher...
20160910 17:25:48-!- Kwandulin [~Miranda@p200300760F2C71B809E4C34E6D6D107F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160910 17:26:12-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20160910 17:32:37-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160910 17:36:03< gfgtdf> celmin: hmm no idae
20160910 17:36:34< celmin> Presumably the only way to trigger it is with "new", right?
20160910 17:37:57< gfgtdf> hmm yes
20160910 17:38:38< gfgtdf> not sure though
20160910 17:39:17< gfgtdf> i think it possbile that there are some other libs that use malloc directly internally and still throw that exception.
20160910 17:39:48< celmin> You mean like "void* p = malloc(…); if(!p) throw bad_alloc"?
20160910 17:39:55< gfgtdf> in any case you cannot always see from outside whether some function needs to  dynamically allocate meoery or not.
20160910 17:40:02< celmin> True.
20160910 17:42:06< gfgtdf> celmin: you kknow which commit indtroduced that bad_alloc error?
20160910 17:42:30< celmin> It's probably my titlescreen refactor commit combined with the subsequent "fix unit tests" commit.
20160910 17:42:31< gfgtdf> celmin: also it could also be an error on travis side.
20160910 17:42:41< celmin> It's pretty consistent though.
20160910 17:42:54-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 17:43:12< celmin> Worst case, we might have to just disable the titlescreen test.
20160910 17:44:32< tad_> Looking at HttT Flaming Sword and allowing the Paladin: so I should remove the type=blade and add name=sword,sabre for the effect filters?
20160910 17:44:55< celmin> Well, that's what zookeeper said.
20160910 17:45:41< tad_> I suppose I should run through *all* the acceptable unit types and check that does not cause other unintended changes.
20160910 17:47:55< celmin> Heh, it's kinda strange that the flaming sword's damage depends on the unit's original sword.
20160910 17:48:32-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160910 17:50:21< tad_> That's not how I read it. What it looks like to me is trying to ensure it only applies to swords and not lances, clubs, or what-have-you
20160910 17:50:46< tad_> And "increase damage 25%"
20160910 17:50:46< celmin> What I just said was an observation unrelated to the filter.
20160910 17:50:55< celmin> Yeah, that.
20160910 17:51:22< celmin> If they're picking up a sword to replace their existing one, I'd expect set_damage instead of increase_damage. (Not that I'm suggesting it be changed.)
20160910 17:51:31< tad_> Ah.
20160910 17:52:50< tad_> I can see your point. I could solve it by the sword remaining stuck but the flame running up your arm and settling on your existing sword :)
20160910 17:52:51< gfgtdf> celmin: the damange doesnt only depend on the swords quality though.
20160910 17:53:21< celmin> I'd check with zookeeper before changing that, I guess.
20160910 17:53:49< tad_> Oh you bet. At this point all I care about is getting Paladin back on the list of users.
20160910 17:54:22-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160910 17:54:24< tad_> And not causing another issue in the process.
20160910 18:00:26< zookeeper> tad_, yes, remove range= and type= and replace with name=sword,saber. that should work and cover everything it should.
20160910 18:01:00< zookeeper> (everyone else's but li'sar's weapon is called "sword")
20160910 18:02:00< gfgtdf> vultraz: hmm youlc you please test whether loading replay saved works for you? I'm doing a loadgame refactor here and it doesnt work here, so i want to know ehther its casued by my refactor or not
20160910 18:06:07< gfgtdf> or could anyone else ?
20160910 18:08:24< zookeeper> tad_, so testing that change should be as simple as checking that it works for li'sar and <literally anyone else from the list>.
20160910 18:14:24< tad_> zookeeper: Done and testing now.
20160910 18:21:14-!- Kwandulin [~Miranda@p200300760F2C71B809E4C34E6D6D107F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160910 18:23:12< tad_> Screen does not reformat if you change window size while [message] is up?
20160910 18:24:51< tad_> Recall panel does not ensure it fits in a small window.
20160910 18:25:49< tad_> Usually I run full-screen but I'm trying to watch something else so I'm windowed and there's some hiccups in layout if you make the window small
20160910 18:29:06< tad_> Wow. The units ZIP! around when you're using a small window.
20160910 18:31:23-!- TC01 [~quassel@london.acm.jhu.edu] has quit [Read error: Connection reset by peer]
20160910 18:42:15 * tad_ sighs
20160910 18:43:17< tad_> "attempt to index a local 'text' (a nil value)" .. gee, I hope I just added that error and it's not something missed in earlier testing
20160910 18:45:52< irker886> wesnoth: gfgtdf wesnoth:master dcd037e53021 / src/ (20 files in 8 dirs): small load_game_exception refactor https://github.com/wesnoth/wesnoth/commit/dcd037e5302109d5943607173dff2c0684ffa38f
20160910 18:45:54< irker886> wesnoth: gfgtdf wesnoth:master eb3e27b81903 / src/generators/default_map_generator.cpp: clena some includes. https://github.com/wesnoth/wesnoth/commit/eb3e27b81903d96630e355f7209388d50ade1fcb
20160910 18:51:11< tad_> When I click on "Back to Turn 1" from the Menu it goes back to the title screen. If I then click "Load" it loaded the saved turn and continues as normal.
20160910 18:52:52< tad_> And "Drat" I need to find that bad text it's not new .. just a path through the code I'd never hit before.
20160910 18:55:18< gfgtdf> tad_: that sound liek what vultaz just fixed in his last commit
20160910 18:55:24< gfgtdf> the laong issue i meant
20160910 18:55:42< gfgtdf> loading*
20160910 18:55:45< tad_> ok.
20160910 18:55:49< tad_> I'll resync
20160910 18:56:08< tad_> First I wanna find the nil string in the Flaming Sword ...
20160910 19:00:34< tad_> celmin Is [object] in Lua? Can you take a quick look at see if you see why trying to get to cannot_use_message gives a nil error?
20160910 19:10:34-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20160910 19:12:05-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160910 19:12:13-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160910 19:15:23-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20160910 19:16:05-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160910 19:16:42 * tad_ sighs. Someone added "silent" to [object] and it does not work. I think I see what the intention was and can fix it.
20160910 19:16:55-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160910 19:20:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20160910 19:20:32-!- wedge010 is now known as wedge009
20160910 19:23:26< zookeeper> hmh?
20160910 19:27:45< tad_> An old change in 1.13.2 adding "silent" attribute to [object] which I, apparently, never ran across before. A variable in the Lua was read before it was set. PR in a moment.
20160910 19:29:22-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160910 19:29:32< tad_> Merge 769 and HttT S19a and S19b will behave themselves when a unit which cannot use the Sword or Armor tries to take it.
20160910 19:29:46< gfgtdf> tad_: im quite sure that wesnoth 1.12.x also supports siltent=yes/no in [object]
20160910 19:29:57-!- travis-ci [~travis-ci@ec2-54-161-180-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20160910 19:29:58< travis-ci> wesnoth/wesnoth#10820 (master - eb3e27b : gfgtdf): The build has errored.
20160910 19:29:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/159005433
20160910 19:29:58-!- travis-ci [~travis-ci@ec2-54-161-180-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20160910 19:30:00< zookeeper> it's an ages old feature
20160910 19:30:02< tad_> According to wiki it came in 1.13.2
20160910 19:30:09 * zookeeper blinks
20160910 19:30:17< tad_> Maybe I misread.
20160910 19:30:20 * tad_ does that
20160910 19:30:38< zookeeper> yeah
20160910 19:30:50< zookeeper> that bit only refers to the following sentence
20160910 19:30:57< tad_> Anyway. It was a read-before-write bug and PR 769 fixes it.
20160910 19:31:29-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160910 19:32:04< tad_> No, maybe, I can test that change to get Paladin working again :)
20160910 19:32:44< tad_> ^now
20160910 19:36:19-!- ancestral [~ancestral@209.181.254.220] has quit [Ping timeout: 252 seconds]
20160910 19:39:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160910 19:39:42-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160910 19:40:14< tad_> Yeah! Paladin (not strong) takes the Flaming Sword and its damage goes from 8x5 to 10x5 .. 25% increase as intended. Delfador and Swordsman get the cannot use message.
20160910 19:41:54< tad_> So, it's usable by Konrad, Li'sar, Kalenz, Paladins, and advanced Elvish Fighters.
20160910 19:46:17-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160910 19:51:39-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160910 19:52:31< gfgtdf> i doesnt relly make sense to me that swordsmans cannot use it.
20160910 19:53:06-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160910 19:55:17< tad_> They're not recruitable so it's not an issue. But they were convenient because they could but they're not available in HttT.
20160910 20:09:05< tad_> An Elvish Fighter also cannot use the Flaming Sword, but its advancements can. And the cannot_use_message says "Only the leader of an army .." which seems a bit clunky. Your average player, however, will probably want Konrad or Li'sar to take the sword, so they'll never see the message.
20160910 20:10:23< tad_> src/game_launcher.cpp:184:77: warning: missing initializer for member ‘savegame::load_game_metadata::difficulty’
20160910 20:10:40< tad_> + several more in the same vein
20160910 20:19:00-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20160910 20:22:13< tad_> src/hotkey/hotkey_handler.cpp:534:50: warning: missing initializer for member ‘savegame::load_game_metadata::difficulty’
20160910 20:22:25< tad_> + a few more of the same
20160910 20:35:35-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160910 20:40:54-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160910 20:41:30-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160910 20:43:50-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 20:47:15< celmin> Sorry, you asked me to do something while I was away.
20160910 20:47:43< tad_> zookeeper: Question on Flaming Sword and Void Armor in HttT: gfgtdf said he does not see why Swordsman cannot use the sword. I fixed it so Paladin can and am now looking at the Armor. I see a number of Dwarf units can use the Armor but don't think there are any drawf in HttT Konrad can have. So why are they there?
20160910 20:48:05< tad_> celmin: See PR 769 and commit, please, if it's good.
20160910 20:48:13< celmin> I forget, is it possible to have duellists, or do Li'sar's loyalists get left behind?
20160910 20:48:50< zookeeper> tad_, uh, you get to recruit dwarves, so...
20160910 20:50:10< celmin> Oh, theirs is called saber, so I guess sword,saber would still include them if they're available.
20160910 20:50:12< tad_> zookeeper: Oh! Right. Duh. And they don't use swords so the Sword isn't an issue.
20160910 20:50:29< celmin> They use axes instead.
20160910 20:50:34< tad_> OK.
20160910 20:50:57< celmin> What was that about the recall window?
20160910 20:51:07< celmin> Is it a scrollbar in the left panel?
20160910 20:51:10< tad_> On the Flaming Sword, there is a unit_type check (type=) for Konrad, Li'sar, Kalenz, Paladin and advanced Elvish Fighters.
20160910 20:51:50< celmin> I generally do everything in 800x600 so I can catch layout issues, but that doesn't mean I notice everything.
20160910 20:51:51< tad_> celmin: on the recall window .. I didn't notice there were two scroll bars and the right-most scrolled down so I could get to the buttons.
20160910 20:51:58< celmin> Ah.
20160910 20:52:10< celmin> If you need to scroll for buttons, that's bad.
20160910 20:52:45< celmin> That problem is in the new MP Create at 1024x768, too.
20160910 20:52:49< tad_> celmin: I don't know how small I made it. Larger than a cell-phone screen but smaller than 600 high, I'll bet.
20160910 20:52:55< celmin> (Though at 1024x768 it's a horizontal bar.(
20160910 20:52:59< celmin> ^)
20160910 20:53:20< tad_> celmin: What amazed me was how much FASTER things run with a small window
20160910 20:53:25< celmin> I think the game won't allow you to size below 600 high.
20160910 20:53:27< celmin> Really?
20160910 20:54:14< tad_> Yeah. Units just seem to zip along. Could be subjective, because it's scrolling so often, but sure seems smoother and faster.
20160910 20:54:36< celmin> Well, I guess it doesn't have to draw as much if the window is smaller.
20160910 20:54:42 * tad_ nods.
20160910 20:55:02< celmin> That shouldn't make such a difference, but I doubt Wesnoth's drawing routines are optimized.
20160910 20:55:06< tad_> And there is less water or other tile animations to do
20160910 20:55:27< celmin> That too.
20160910 20:56:10< celmin> Why can't EH take the sword?
20160910 20:56:14< tad_> But it's something else for my mind to cycle over as I try to fall asleep. Maybe it'll displace the memory leaks and startup issues I've been mulling over the past few nights :P
20160910 20:56:24< tad_> eh?
20160910 20:56:33< celmin> Flaming sword.
20160910 20:56:38< celmin> EF not H
20160910 20:56:43< celmin> Elvish Fighter.
20160910 20:56:47< celmin> No idea how I got EH from that.
20160910 20:57:06< tad_> My guess: he's not a "leader of armies"
20160910 20:57:17< celmin> Because he's L1?
20160910 20:57:24 * tad_ nods.
20160910 20:57:41< celmin> So it excludes L1, or just EF?
20160910 20:57:50< tad_> That's a design issue. I'm trying to avoid those and just work with what's there unless Zookeeper points me elsewheere.
20160910 20:58:11< tad_> No. It lists unit type=
20160910 20:58:19< celmin> I see.
20160910 20:58:37< tad_> type_tree would make it more clear but I didn't change to use it.
20160910 20:58:53< tad_> L1 isn't the issue. Konrad at L1 can take the sword
20160910 21:05:36-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has joined #wesnoth-dev
20160910 21:11:40< celmin> I'm confused at how tad_'s change makes any difference...
20160910 21:11:47< celmin> (to [object])
20160910 21:13:06< tad_> The 'text' variable was tested before being set .. which is why I moved the else clause up
20160910 21:13:30< celmin> Ohhh, line 34|37.
20160910 21:13:42< celmin> Okay.
20160910 21:14:00< irker886> wesnoth: Gregory A Lundberg wesnoth:master 6af699fdf3bc / data/lua/wml/object.lua: Fix bug: 'text' is nil https://github.com/wesnoth/wesnoth/commit/6af699fdf3bcd8e5364996aeefc996403f104a9f
20160910 21:14:02< irker886> wesnoth: Celtic Minstrel wesnoth:master 6baee82e9c19 / data/lua/wml/object.lua: Merge pull request #769 from GregoryLundberg/GL_fix_object_silent https://github.com/wesnoth/wesnoth/commit/6baee82e9c19c8b71f4d643a07b819c6041130a4
20160910 21:14:21< tad_> TY
20160910 21:15:18< tad_> zookeeper: I pushed changes for Flaming Sword and Void Armor to the HttT general improvements PR (et al).
20160910 21:19:34< vultraz> celmin: pref setters with _ are usually wrappers that do more than just set a flag
20160910 21:19:53< celmin> vultraz: Isn't it the other way around?
20160910 21:20:22< vultraz> [01:57:07]	celmin	Or did you manage to retain the slightly rounded corners without the alpha hack? <- yes
20160910 21:20:39< zookeeper> tad_, oh, something i missed earlier: the great tree hint message isn't translatable.
20160910 21:20:57< zookeeper> i wish i had noticed before you re-pushed that stuff
20160910 21:21:22< tad_> OK. I'll fix that. I have a script to update the PRs so it's not a lot of work. Just a bunch of network traffic
20160910 21:21:30< vultraz> [01:55:36]	celmin	vultraz: So, I assume you tested that that does not throw errors because you're destroying a null renderer? <- if it was an issue it would have crashed on first run, since it'd be niil
20160910 21:21:31< vultraz> nil
20160910 21:21:45< celmin> Naive!
20160910 21:22:04< iceiceice> +1 celmin
20160910 21:22:08< celmin> But I guess it's hard to do better… :|
20160910 21:22:27< vultraz> oh hey icecube
20160910 21:22:31< iceiceice> assuming that it would have crashed because a pointer would have been null...
20160910 21:22:39< iceiceice> sometimes you can get suprrised
20160910 21:22:53< iceiceice> compiler is allowed to *assume* that nothing you ever deference is null
20160910 21:23:09< iceiceice> if it can see that there is like, only one other logical value it could have
20160910 21:23:20< iceiceice> it may ignore the "true" value and assume it has the non-null one
20160910 21:24:04< celmin> That said, "delete nullptr" is said to be safe. I'm not sure if "free(NULL)" is safe though.
20160910 21:24:40< iceiceice> yeah i dont know about "free"
20160910 21:25:00< celmin> (And presumably SDL_DestroyRenderer calls free().)
20160910 21:25:42< iceiceice> according to this one, free(NULL) is ok also
20160910 21:25:43< iceiceice> http://www.cplusplus.com/reference/cstdlib/free/
20160910 21:25:52< celmin> I see.
20160910 21:25:53< iceiceice> i guess it might be different in C and in C++?
20160910 21:25:57< iceiceice> but probably not...
20160910 21:26:21< vultraz> C is odd
20160910 21:26:33< celmin> Why?
20160910 21:27:00< vultraz> it seems to rely on manual memory management directly more than c++
20160910 21:27:09< celmin> Well, yes...
20160910 21:27:45< vultraz> I don't really like that :P
20160910 21:27:49 * iceiceice belatedly greets vultraz
20160910 21:28:33< celmin> Hmm, when is unit_mover::sighted_stop_ true… is it only for sighted unit counts, or are there other cases?
20160910 21:31:50< tad_> Well, so much for that script. I forgot to have it make sure it was at the right startng point.. At least my $%#up only wiped out the gryphons returning so it's not a lot of work to un#$% ..
20160910 21:32:52-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160910 21:34:13< vultraz> *tries to load a replay from MP LoW S1* *gets error about "Unknown Scenario multiplayer_The_Freelands"
20160910 21:34:15< vultraz> what
20160910 21:34:22-!- edgrey [~edgrey@178.204.109.246] has quit [Remote host closed the connection]
20160910 21:34:35-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20160910 21:34:52< vultraz> other replay seem to work, though
20160910 21:35:07< celmin> What.
20160910 21:35:09< vultraz> I realized i might have broken old replays by moving that era file
20160910 21:43:07-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20160910 21:51:20-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20160910 21:52:04-!- Appleman1234 [~Appleman1@KD119104118011.au-net.ne.jp] has quit [Ping timeout: 255 seconds]
20160910 21:58:41< celmin> Hmmm… is there any way to call Lua in the middle of an animation?
20160910 21:58:59-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160910 21:59:42-!- Kwandulin [~Miranda@p200300760F2C71B815198D8C17179B72.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160910 22:02:21-!- RatArmy [~RatArmy@240f:b3:88e3:1:224:a5ff:fe23:83eb] has quit [Quit: Leaving]
20160910 22:22:28-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160910 22:25:45-!- knotwork [~markm@unaffiliated/knotwork] has quit [Ping timeout: 260 seconds]
20160910 22:26:20-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20160910 22:28:14-!- Kwandulin [~Miranda@p200300760F2C71B815198D8C17179B72.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160910 22:33:31< vultraz> hmm..
20160910 22:38:36< vultraz> so unless I am much mistaken, the more we move away from gui1 the closer we can get to OGL
20160910 22:39:27< vultraz> setting up a gl context isn't hard, except it has to be an all-or-nothing conversion once we do.
20160910 22:39:45< vultraz> and the gui2 drawing code is reliant on the canvas
20160910 22:39:58< vultraz> So it's a central place to refactor.
20160910 22:41:08-!- gfgtdf [~chatzilla@x4e36a50e.dyn.telefonica.de] has joined #wesnoth-dev
20160910 22:41:50< vultraz> the big challenge for both gui2 and ogl support here is the game screen itself
20160910 22:41:54< vultraz> anyway..
20160910 22:42:15< vultraz> gfgtdf: I tested loading replays after your fix and they work
20160910 22:42:28< vultraz> except when loading an mp replay i got a really weird issue
20160910 22:47:33< celmin> It might be fine to stick with the SDL_Render* stuff rather than a full OGL context, too.
20160910 22:47:46< vultraz> perhaps
20160910 22:47:59< celmin> I'm pretty sure SDL_Renderer supports hardware rendering.
20160910 22:48:09< vultraz> using SDL_Texture?
20160910 22:48:15< celmin> Probably?
20160910 22:48:31-!- Appleman1234 [~Appleman1@KD119104106223.au-net.ne.jp] has joined #wesnoth-dev
20160910 22:48:40< celmin> I think the real challenge is the way Wesnoth renders and processes images and stuff.
20160910 22:49:18< vultraz> SDL_CreateSoftwareRenderer creates a rederer context specifically for surfaces
20160910 22:49:46< vultraz> SDL_CreateRenderer creates a renderer context for a window, and may have flags
20160910 22:49:57< vultraz> such as SDL_RENDERER_SOFTWARE or SDL_RENDERER_ACCELERATED
20160910 22:50:13< vultraz> also SDL_RENDERER_TARGETTEXTURE
20160910 22:50:21< vultraz> we use the first one
20160910 22:51:54< celmin> Not sure if the DrawPoint vs DrawPoints thing makes any difference in software rendering… pretty sure it'd make a difference in hardware rendering though.
20160910 22:52:12< celmin> Thus, good practice, I'd say.
20160910 22:52:42< vultraz> I did an experiment yesterday: I wanted to convert images loaded to the GUI2 canvas to textures and save them to the renderer context with SDL_RenderCopy
20160910 22:52:55< vultraz> instead of directly blitting them to the canvas surface every time
20160910 22:53:16< vultraz> it worked, except I couldn't get certain semi-transparent pixels to render right
20160910 22:53:21< vultraz> they came up as pure black
20160910 22:53:23< vultraz> :(
20160910 22:53:37< celmin> Maybe alpha blend mode was not enabled?
20160910 22:53:43< vultraz> no,it was
20160910 22:53:50< vultraz> and pure-alpha areas were fine
20160910 22:54:00< vultraz> even *some* semi-transparent areas
20160910 22:54:03< celmin> Weird.
20160910 22:54:05< vultraz> but not all
20160910 22:54:16< celmin> Very weird.
20160910 22:54:16< vultraz> likely something with premultiplied alpha vs not
20160910 22:54:24< celmin> Hmm, could be.
20160910 22:54:34< vultraz> and I cannot modify the alpha of an SDL_Texture
20160910 22:55:01< vultraz> and all the guides/answers I could find on google seem to assume OGL use
20160910 22:55:09< vultraz> perhaps Aginor has some insight
20160910 22:55:31< vultraz> since it's an issue that will plague us sooner or later
20160910 22:56:34< vultraz> if we switch to ogl/renderer contexts we'll also need to stop treating text as surfaces
20160910 22:57:38< vultraz> anura has a rather nice way of doing this with cairo and render paths drawn from glyphs...
20160910 22:57:43< celmin> Text would probably become a vertex array referencing a glyph atlas.
20160910 22:58:06< celmin> I know theoretically how to do this, at least. Still hate working with OpenGL though.
20160910 22:58:16< celmin> Might be partly because my old computer doesn't support stuff though. >_>
20160910 22:58:46< celmin> But only partly; OpenGL is just a pain to work with. Everything is global state.
20160910 22:58:51< vultraz> it's ironic, really. surfaces are "simple". anything else is.. not really.
20160910 22:59:28< celmin> And it's strict C and this not at all idiomatic for C++.
20160910 22:59:36< celmin> And all the enums are just plain ints.
20160910 22:59:43< celmin> (Even though C has enums.)
20160910 23:00:10< vultraz> the biggest problem we have is the performance with maps :/
20160910 23:00:23< vultraz> surfaces are perfectly fine for our UI
20160910 23:00:44< celmin> Maps? Huh?
20160910 23:00:50< vultraz> the game maps
20160910 23:00:58< vultraz> stuff like animated water
20160910 23:01:20< vultraz> it's way too performance-hungry for our current rendering system.
20160910 23:02:34< vultraz> also the way we handle map scrolling :/
20160910 23:02:57< vultraz> the water "works", but combine it with the scrolling it becomes unplayable
20160910 23:03:31< vultraz> have you ever notice that if you scroll and open an gui2 dialog at the same time you'll sometimes catch the gamemap "mid-scroll"
20160910 23:03:41< vultraz> where the surface hasn't correctly re-blitted
20160910 23:05:43< vultraz> sadly I cannot think of any way around that
20160910 23:05:50< vultraz> excpet not to use blit
20160910 23:06:27-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160910 23:06:42< vultraz> so then we come to textures again..
20160910 23:06:47< vultraz> and texture loading of our PNGs..
20160910 23:06:57< vultraz> and if there's an issue with semi-transparent pixels
20160910 23:07:05< vultraz> it could affect anything :)
20160910 23:09:24< vultraz> we could perhaps even improve performance in the short term by not using blit every.single.time an image is processed
20160910 23:10:45< vultraz> but we can't even begin to look into that if we cannot get PNGs loaded as textures with the right alpha
20160910 23:11:25< tad_> celmin: You're right I can't make the window smaller than 800x600. There's little display errors I note when the height get short enough. What I notice is the line showing MP and percentage gets cut off horizontally and repaints correctly if you do something (not sure what)
20160910 23:13:59< gfgtdf> vultraz: what isse exactly with mp replays ?
20160910 23:14:27-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160910 23:14:48< vultraz> gfgtdf: haven't confirmed if it's MP Replays in general, but when loading an LoW MP replayI get "Unknown Scenario: multiplayer_The_Freelands"
20160910 23:15:39< gfgtdf> vultraz: loading for tiltescrren ?
20160910 23:15:41< gfgtdf> from*
20160910 23:15:46< vultraz> yes
20160910 23:17:38< vultraz> celmin: do you think i should move eras.* back to multiplayer to not break old replays
20160910 23:17:47< vultraz> i mean, this *is* a dev series..but..
20160910 23:18:11< tad_> Confirming: created a replay, attempted to load it. asserrtion failure
20160910 23:18:23< tad_> wesnoth: /home/lundberg/wesnoth/src/replay.cpp:639: bool replay::add_start_if_not_there_yet(): Assertion `base_->get_pos() == 0' failed. Aborted (core dumped)
20160910 23:19:11< vultraz> wha
20160910 23:20:08< tad_> Battle for Wesnoth v1.13.5+dev (eb3e27b-Clean). Created a replay for Blackwater Port and attempted to load it
20160910 23:21:11< tad_> Tried from clean start and it loads.
20160910 23:21:20< celmin> [Sep 10@7:03:31pm] vultraz: have you ever notice that if you scroll and open an gui2 dialog at the same time you'll sometimes catch the gamemap "mid-scroll"
20160910 23:21:22< celmin> Never.
20160910 23:21:36< vultraz> your computer must be too good :P
20160910 23:21:40< celmin> [Sep 10@7:17:38pm] vultraz: celmin: do you think i should move eras.* back to multiplayer to not break old replays
20160910 23:21:40< celmin> Depends how old.
20160910 23:21:52< vultraz> anything before the move
20160910 23:21:52< zookeeper> vultraz, err, so how do the file locations affect replay compatibility?
20160910 23:21:57< celmin> vultraz: I wouldn't be surprised if the blitting thing is just Windows.
20160910 23:22:11< vultraz> zookeeper: it looks for the lua file in the old place
20160910 23:22:20< vultraz> dunno if it *breaks* them, per se
20160910 23:22:22< vultraz> but it's an error
20160910 23:22:29< zookeeper> right
20160910 23:22:34< celmin> As far as I know, Windows programs are still responsible for repainting their window contents if something else covered it up.
20160910 23:23:06< zookeeper> well it was a controversial enough change already, so if it causes an actual problem on top of that, reverting sounds pretty reasonable.
20160910 23:23:06< tad_> celmin: It's been ages but that sounds correct
20160910 23:23:23< celmin> This is not, however, the case on the Mac.
20160910 23:23:51< celmin> If something covers it up and you then switch back, it seems to be restored even if the program code hasn't done a redraw yet.
20160910 23:24:17-!- iceiceice [~chris@50.243.80.75] has joined #wesnoth-dev
20160910 23:24:17-!- iceiceice [~chris@50.243.80.75] has quit [Changing host]
20160910 23:24:17-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20160910 23:24:26< celmin> And yeah, reverting that era move is fine.
20160910 23:24:48< zookeeper> tad_, you tested name=sword,sabre? surely that can't work since li'sar has a saber, not sabre
20160910 23:25:06< zookeeper> which is why i double-checked every time i referred to it to make sure i got the spelling right :P
20160910 23:25:15< irker886> wesnoth: Charles Dang wesnoth:master 659e482e010e / data/ (_main.cfg eras.cfg eras.lua multiplayer/eras.cfg multiplayer/eras.lua): Moved eras files back to multiplayer/ since its movement caused errors in replay https://github.com/wesnoth/wesnoth/commit/659e482e010eddeee315613f6319976ec5551fc5
20160910 23:25:27< celmin> zookeeper: The comment had the spelling wrong though, as I recall. :P
20160910 23:26:12< tad_> zookeeper: I tested everyone EXCEPT her. Duh. I was so bummed at having to re-create the S22 gryphons return commit .. OK, I'll fix it. This is NOT my day.
20160910 23:26:39< zookeeper> it happens
20160910 23:26:59< celmin> If you lost a commit, can't you recover it from the reflog
20160910 23:27:01< celmin> ^?
20160910 23:27:29< tad_> It's fine. I just needed to calm down and fix it.
20160910 23:27:48< tad_> But today is my day for dumb mistakes.
20160910 23:29:04< zookeeper> anyway i think those were the only remaining issues with the PR
20160910 23:30:04< tad_> zookeeper: As far as I know, that is correct. Now, if I can fix it without adding another dumb mistake ...
20160910 23:30:56< tad_> wesnoth: /home/lundberg/wesnoth/src/replay.cpp:639: bool replay::add_start_if_not_there_yet(): Assertion `base_->get_pos() == 0' failed.
20160910 23:31:42< tad_> To reproduce: load a scene, go to Load (I used Ctrl-o) and do NOT check the replay option when you load the replay.gz
20160910 23:32:53< vultraz> tad_: uh... you should not be able to not check the replay option when loading a replay
20160910 23:33:48< tad_> vultraz: I loaded Blackwater, played to get a replay saved. Ctrl-o to load it once I was at the next scene and did not check the option when I attempted to load the replay.
20160910 23:34:13< zookeeper> tad_, i'm off to bed but i can merge it tomorrow if it's all good to go from your side
20160910 23:34:16< vultraz> no, I mean Show Replay is automatically selected and disabled
20160910 23:34:21< vultraz> if the game you're loading is a replay
20160910 23:34:33< tad_> zookeeper: OK. I want to take it slow and be sure I don't mess up YET AGAIN!!
20160910 23:34:36-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160910 23:34:41< celmin> vultraz: Did you test that?
20160910 23:34:47< vultraz> yes
20160910 23:35:05< celmin> I see...
20160910 23:35:13< tad_> Give me a minute to clean up the saber/sabre issue and I'll run through it again.
20160910 23:36:16< tad_> zookeeper: Tested and it works for Li'sar without change.
20160910 23:36:26< zookeeper> tad_, if it's easy for you to do, maybe squash the relevant sword and armor commits together, respectively? doesn't matter much but you seem to have the workflow figured out
20160910 23:37:01< tad_> My workflow is fine if I remember to checkout the correct branch.
20160910 23:37:21< tad_> If I don't I have a bug in my script which blows away the S22 gryphons commit.
20160910 23:37:53< tad_> zookeeper: I just tested and Li'sar takes the sword and gets the buff as committed.
20160910 23:38:09< tad_> But leave it and I'll check AGAIN.
20160910 23:38:26< celmin> What is this script you speak of...
20160910 23:39:43< tad_> Because I'm in such a state 
20160910 23:40:26< tad_> The script is a bash shell script I wrote to handle all those HttT PRs becuase I was making errors doing it by hand. And, of course, it's fine if I checkout the right branch to work on but messes up when I do.
20160910 23:40:44< zookeeper> ok, i'm off, but as said leave me a note in the log saying it's ready and i'll do one more check and merge it tomorrow
20160910 23:40:59< tad_> zookeeper: ok. will do.
20160910 23:41:26< tad_> Life will get a LOT easier once general_improvements merges.
20160910 23:41:53 * tad_ rolls his eyes.
20160910 23:42:18< tad_> I need to do something to make the current branch checked out more apparent on my screen.
20160910 23:45:27-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20160910 23:58:10< celmin> Every time I want to write a Lua iterator, I need to look up how they work again.
20160910 23:58:37-!- fabi [~fabi@176.7.54.239] has joined #wesnoth-dev
20160910 23:58:56< celmin> I think iterators might be the one thing I like least about Lua.
20160910 23:59:49< tad_> vultraz: You are correct. It's checked and I cannot uncheck it. I load a normal turn save, then attempt to load a replay and I get the assert failure/crash. I am syncing and making and will retest.
--- Log closed Sun Sep 11 00:00:33 2016