--- Log opened Sun Jun 18 00:00:04 2017
20170618 01:25:45-!- gfgtdf [~chatzilla@x4e36821f.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 53.0.3/20170518000419]]
20170618 02:12:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170618 02:29:17-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170618 04:22:35-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20170618 04:43:41-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170618 04:57:59-!- irker710 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170618 04:57:59< irker710> wesnoth: Charles Dang wesnoth:accelerated_rendering f5f2b65a91c1 / src/sdl/rect.cpp: Attempt to fix travis build https://github.com/wesnoth/wesnoth/commit/f5f2b65a91c14ed217fa055246fd832534c60bca
20170618 05:25:52-!- Bonobo [~Bonobo@61.68.170.86] has joined #wesnoth-dev
20170618 05:32:21-!- Kwandulin [~Kwandulin@p200300760F7CBAEBA85E888E760D1F92.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 05:57:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170618 05:57:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170618 06:05:44-!- JyrkiVesterinen [~JyrkiVest@87-92-52-38.bb.dnainternet.fi] has joined #wesnoth-dev
20170618 06:56:06-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170618 07:33:23-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170618 07:42:18-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170618 07:56:19-!- atarocch [~atarocch@93.56.160.37] has quit [Remote host closed the connection]
20170618 08:01:47-!- irker710 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170618 08:04:39-!- irker874 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170618 08:04:39< irker874> wesnoth: Charles Dang wesnoth:accelerated_rendering e1deab174c93 / src/sdl/rect.cpp: More travis fixup https://github.com/wesnoth/wesnoth/commit/e1deab174c93cb0d1862fa58b15cf125bdeb9cd6
20170618 08:20:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170618 08:20:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170618 08:23:52-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170618 08:49:45-!- atarocch [~atarocch@93.56.160.37] has quit [Remote host closed the connection]
20170618 08:52:53-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170618 09:06:28-!- Bonobo [~Bonobo@61.68.170.86] has quit [Ping timeout: 246 seconds]
20170618 09:07:18-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has joined #wesnoth-dev
20170618 09:40:42< irker874> wesnoth: Nils Kneuper wesnoth:master ea925a39ef0c / po/ (wesnoth-lib/es.po wesnoth/es.po): updated Spanish translation https://github.com/wesnoth/wesnoth/commit/ea925a39ef0c04c0a9c9ffa876a5ff153b5185c2
20170618 09:40:44< irker874> wesnoth: Nils Kneuper wesnoth:master 5c440b87d43c / po/ (6 files in 6 dirs): updated Italian translation https://github.com/wesnoth/wesnoth/commit/5c440b87d43cf3278d5863a078a3f7cf162660c8
20170618 10:18:03-!- Kwandulin [~Kwandulin@p200300760F7CBAEBA85E888E760D1F92.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170618 10:32:54-!- Kwandulin [~Kwandulin@p200300760F7CBAEBA85E888E760D1F92.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 10:43:48-!- JyrkiVesterinen [~JyrkiVest@87-92-52-38.bb.dnainternet.fi] has quit [Quit: .]
20170618 11:21:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 11:29:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170618 11:30:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 11:37:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170618 11:37:19-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 11:48:58-!- sevu [~Shiki@141.57.60.71] has joined #wesnoth-dev
20170618 11:49:02-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170618 11:49:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 11:59:22-!- sevu [~Shiki@141.57.60.71] has quit [Remote host closed the connection]
20170618 12:22:07-!- gfgtdf [~chatzilla@x4e36377d.dyn.telefonica.de] has joined #wesnoth-dev
20170618 12:22:42-!- Kwandulin [~Kwandulin@p200300760F7CBAEBA85E888E760D1F92.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170618 12:33:15-!- sevu [~Shiki@141.57.60.71] has joined #wesnoth-dev
20170618 12:42:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170618 12:43:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 13:17:03-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170618 13:36:00-!- Kwandulin [~Kwandulin@p200300760F7CBAEBA85E888E760D1F92.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 13:38:50-!- mjs-de [~mjs-de@x4db57bfb.dyn.telefonica.de] has joined #wesnoth-dev
20170618 13:43:20-!- JyrkiVesterinen [~JyrkiVest@87-92-52-38.bb.dnainternet.fi] has joined #wesnoth-dev
20170618 13:43:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170618 13:43:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 13:54:06-!- sevu [~Shiki@141.57.60.71] has quit [Read error: Connection reset by peer]
20170618 14:25:21-!- irker874 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170618 14:35:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170618 14:36:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 14:39:12-!- travis-ci [~travis-ci@ec2-54-224-155-18.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 14:39:13< travis-ci> wesnoth/wesnoth#14270 (accelerated_rendering - e1deab1 : Charles Dang): The build failed.
20170618 14:39:13< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/244166650
20170618 14:39:13-!- travis-ci [~travis-ci@ec2-54-224-155-18.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 14:48:02-!- mjs-de [~mjs-de@x4db57bfb.dyn.telefonica.de] has quit [Remote host closed the connection]
20170618 14:56:23-!- Kwandulin [~Kwandulin@p200300760F7CBAEBA85E888E760D1F92.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170618 15:00:09-!- Kwandulin [~Kwandulin@p200300760F7CBAEB849D1F645004A38E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 15:06:07-!- Kwandulin [~Kwandulin@p200300760F7CBAEB849D1F645004A38E.dip0.t-ipconnect.de] has quit [Quit: [endlevel]]
20170618 15:07:36-!- Kwandulin [~Kwandulin@p200300760F7CBAEB849D1F645004A38E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 15:09:56-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170618 15:16:01< Ravana_> someone should close https://github.com/wesnoth/wesnoth/issues/1789
20170618 15:20:30< celmin> Done.
20170618 15:27:20-!- trewe [~trewe@2001:8a0:d11f:601:26e3:a3c9:9400:64ac] has joined #wesnoth-dev
20170618 15:28:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170618 15:29:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 15:35:23-!- gfgtdf [~chatzilla@x4e36377d.dyn.telefonica.de] has quit [Remote host closed the connection]
20170618 16:21:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170618 16:21:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 16:27:38-!- Kwandulin [~Kwandulin@p200300760F7CBAEB849D1F645004A38E.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170618 16:33:26-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170618 16:41:40< celmin> I just noticed that the "fake location" and "secondary unit" features of unit filters are only available when matching specific units, not when finding all matching units.
20170618 16:42:15< celmin> I wonder if there'd be any use for them when finding all matching units...
20170618 16:42:22< celmin> I can't think of anything though.
20170618 16:43:06< celmin> The "fake location" means you're checking if the unit would match were it to move to that location.
20170618 16:43:32< celmin> The "secondary unit" I guess basically allows you to compare it to another unit...
20170618 16:44:07< celmin> I guess it does make sense to find all units that would match a filter if they moved to a particular location, but I wonder if there's any actual use for that.
20170618 16:49:02-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has quit [Ping timeout: 255 seconds]
20170618 17:12:51< celmin> So anyway, it would probably be simple to add the ability to use these features when collecting all matching units, but I don't think I want to bother if there's no known use for it.
20170618 17:13:08< celmin> (It would really only impact people using filters from Lua, I guess.)
20170618 17:18:11< DeFender1031> What's the featuer in question?
20170618 17:18:46< DeFender1031> i see the explanation of fake location
20170618 17:19:07< DeFender1031> which strikes me as a little odd for reasons I'll elaborate upon in a moment, but what's the "secondary unit" bit?
20170618 17:57:35-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170618 18:06:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170618 18:07:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 18:09:40< celticminstrel> The "secondary unit" is basically a unit to compare to, I guess. In [filter_adjacent], it's the unit matched by the enclosing filter that the unit currently being matched is adjacent to.
20170618 18:09:59< celticminstrel> It can be referenced by the $other_unit auto-stored variable.
20170618 18:15:02-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20170618 18:19:32-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170618 18:20:45-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170618 18:21:59< celmin> So what seems odd about the fake location?
20170618 18:30:40< vultraz_iOS> celmin: the results of my survey are not encouraging :/
20170618 18:30:54< celmin> ???
20170618 18:31:03< vultraz_iOS> Literally no-one is saying 1.13 is performing well compared to 1.12.
20170618 18:31:41< vultraz_iOS> But let's wait longer to see what more respondents say
20170618 18:33:32< zookeeper> what did you expect? of course 1.13 performs worse than 1.12.
20170618 18:34:01< vultraz_iOS> Seems to have been the case since the SDL2 transition
20170618 18:36:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170618 18:40:22< zookeeper> might be worth considering whether there could be some dirty optimizations that could be made before 1.14 which would bring things back up to at least 1.12 level of performance.
20170618 18:40:53< vultraz_iOS> We've tried :/
20170618 18:41:56< zookeeper> i mean basically for example the new water could be blitted in pieces several hex in size, instead of always getting blitted one hex at a time
20170618 18:42:18< zookeeper> i just don't know whether something like that would be feasible to implement
20170618 18:43:10< vultraz_iOS> Possibly. But it would require much effort.
20170618 18:44:29< JyrkiVesterinen> I think no one has really seriously attempted to optimize 1.14 (aside from multiple attempts to implement accelerated rendering, all of which would be way too much effort).
20170618 18:44:57< JyrkiVesterinen> There may well be some low-hanging fruit that would be easy to find by just grabbing a profiler.
20170618 18:45:37< JyrkiVesterinen> (A good example is when I made switching between add-ons in the manager about ten times faster by adding ~50 lines of code.)
20170618 18:46:24< vultraz_iOS> Or when I made the UI perform better by reducing canvas copies.
20170618 18:47:50< celmin> I don't think we've really tried very hard, Vultraz.
20170618 18:48:21-!- Kwandulin [~Kwandulin@p200300760F7CBAEBB4C29FB1DCCF25BF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 18:49:27 * celmin pokes DeFender1031?
20170618 18:50:08< vultraz_iOS> I feel hesitant to, anyway. Either way, water and such on my rendering branch are already smoother than we can ever hope to make it in master.
20170618 18:52:27< celmin> Yeah, but if we merge your rendering branch, we almost certainly won't get a release out this year.
20170618 18:52:58< celmin> So, if we can get some "low-hanging fruit" that improves the performance to a reasonable level, that's probably better.
20170618 18:53:29< vultraz_iOS> Indeed, this will likely take many months of work to finish and test.
20170618 18:56:59-!- sevu [~Shiki@141.57.60.71] has joined #wesnoth-dev
20170618 19:02:52< zookeeper> as i said in the thread, a small but perceivable improvement WRT water might be attainable by simply raising the frame interval from 100ms to 150ms.
20170618 19:05:05-!- gfgtdf [~chatzilla@x4e36377d.dyn.telefonica.de] has joined #wesnoth-dev
20170618 19:05:51-!- sevu [~Shiki@141.57.60.71] has quit [Remote host closed the connection]
20170618 19:15:45< DeFender1031> hey, sotrry, had to run out for a bit, back now.
20170618 19:16:25< DeFender1031> sorry*
20170618 19:17:19< DeFender1031> celticminstrel, so secondary unit is basically so you can do "if this unit is the same type as this other arbitrary unit" without needing to know who the second unit actually is?
20170618 19:18:11< DeFender1031> vultraz_iOS, where's this survey? because i'd like to weigh in heavily on the side of "significant performance drop"
20170618 19:18:22< DeFender1031> (I've mentioned this before.)
20170618 19:18:43< vultraz_iOS> DeFender1031: https://forums.wesnoth.org/viewtopic.php?f=6&t=46442
20170618 19:19:24< celmin> Something like that.
20170618 19:20:04< DeFender1031> celmin, as for fake location, how does "would this unit match if they moved to that location" different from leaving out the location entirely?
20170618 19:20:18< celmin> Hm?
20170618 19:20:54< DeFender1031> celmin, I think I don't understand the purpose of fake location
20170618 19:21:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 19:22:09< celmin> A unit filter by default uses the unit's current location when determining a match. You can override this with the "fake location", which (I think) is entirely equivalent to moving the unit and then checking the match.
20170618 19:23:08< celmin> Used in the abilities code, possibly by the AI to consider hypothetical moves? Not entirely sure.
20170618 19:24:01< gfgtdf> i think its uses in when you want to move a unit and hover the unit over a heyx to shows the units stats on that hex.
20170618 19:24:18< gfgtdf> hover the mouse*
20170618 19:24:19< celmin> Possibly.
20170618 19:24:24< celmin> Not sure.
20170618 19:24:28< vultraz_iOS> a fake location is a location that is fake :3
20170618 19:24:31< celmin> Oh, probably used by the attack dialog?
20170618 19:24:48< celmin> To show the unit's stats at the location it'll be attacking from, rather than its current location.
20170618 19:24:53< gfgtdf> quite likeley
20170618 19:28:31< DeFender1031> celmin, so it's essentially replacing the [filter_location] subtag of the unit filter with a location where the unit is not currently located?
20170618 19:28:44< celmin> I think so, yeah.
20170618 19:35:20< DeFender1031> hmm
20170618 19:35:32< DeFender1031> hard to think of a use-case for that in general
20170618 19:35:41< DeFender1031> even for single-unit
20170618 19:36:43< DeFender1031> as for secondary unit, I could imagine it being useful in multiple as well.
20170618 19:36:48< DeFender1031> also, I'm a fan of consistency
20170618 19:36:59< DeFender1031> so if it's available for single, it ought to be available for multiple
20170618 19:46:09< celmin> Not sure why it's so hard to think of a use-case for it...
20170618 19:46:33< celmin> It's already used in a number of places, anyway.
20170618 19:48:52< DeFender1031> like what?
20170618 19:49:05< celmin> We were talking about that just a minute ago...
20170618 19:49:08< DeFender1031> vultraz_iOS, okay, I replied to your survey. I'm sorry for the negativity.
20170618 19:49:24< celmin> I don't have a list handy though.
20170618 19:50:18< celmin> One thing I think it's definitely useful for though is in the AI.
20170618 19:50:25< vultraz_iOS> DeFender1031: no problem, this is exactly the type of feedback I need
20170618 19:50:41< vultraz_iOS> that is, honest player/umc developer experiences
20170618 19:50:52< celmin> I'm not entirely sure if it's currently used there, but I'd guess it is.
20170618 19:55:32< vultraz_iOS> DeFender1031: if you have time, actually, could you see if you could build the accelerated_rendering branch at 2c650c1 (not latest commit, or you'll get a black screen), and see what the performance is in your storyscreen cutscene?
20170618 19:56:23< vultraz_iOS> (no new build requirements at that commit, don't worry)
20170618 19:56:54< DeFender1031> vultraz_iOS, if I can figure out git enough to do so, I can give it a chance.. how do I get my env state to reflect that particular branch and commit?
20170618 19:57:06< DeFender1031> s/chance/try
20170618 19:57:10< vultraz_iOS> uhhh
20170618 19:57:11< vultraz_iOS> weeell
20170618 19:57:17< gfgtdf> checkout <commit id>
20170618 19:57:20< vultraz_iOS> I only have experience using TGit's ui
20170618 19:57:43< DeFender1031> gfgtdf, that's it? I don't need to pull a branch first or something?
20170618 19:57:51< celmin> You need to fetch the branch first.
20170618 19:57:56< vultraz_iOS> you need to checkout the origin/accelerated_rendering branch
20170618 19:57:57< gfgtdf> DeFender1031: oh oh yews that assume you haev the branch locally
20170618 19:58:03< vultraz_iOS> switch to it
20170618 19:58:07< vultraz_iOS> then checkout 2c650c1
20170618 19:58:09< gfgtdf> assumes*
20170618 19:58:20< celmin> So "git fetch accelerated_rendering", then "git checkout 2c650c1" should work.
20170618 19:58:31< DeFender1031> yeah, I don't know git well enough to know how to do any of that... someone just give me the series of commands I need to run assuming that I'm currently on master from several weeks ago?
20170618 19:58:33< celmin> Assuming command-line, but it's probably pretty similar in a GUI.
20170618 19:58:55< DeFender1031> celmin, fatal: 'accelerated_rendering' does not appear to be a git repository
20170618 19:58:55< celmin> Oh right, it's "git fetch origin accelerated_rendering", whoops.
20170618 19:59:00< DeFender1031> ah
20170618 19:59:03< celmin> Sorry.
20170618 19:59:09< vultraz_iOS> doesn't he have to run that on a new branch?
20170618 19:59:10< DeFender1031> that worked.
20170618 19:59:12-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has joined #wesnoth-dev
20170618 19:59:14< celmin> What, vultraz_iOS?
20170618 19:59:21< vultraz_iOS> or will that make a new branch
20170618 19:59:33< DeFender1031> vultraz_iOS, as I understand, it'll add that branch to my local repo
20170618 19:59:35< celmin> After fetch it's at FETCH_HEAD.
20170618 19:59:42< celmin> It may also add the branch as origin/accelerated_rendering.
20170618 19:59:46< DeFender1031> and then I just switch to it by doing gfgtdf's checkout command
20170618 19:59:50< celmin> Right.
20170618 20:00:07< vultraz_iOS> just don't want him to pull all those changes into his master branch
20170618 20:00:26< DeFender1031> (once I see the commands I need, it's clear what they do, I just don't know enough yet to know what commands to use without seeing them.)
20170618 20:01:00< DeFender1031> okay, checked out. sconsing now...
20170618 20:01:15< DeFender1031> (this part usually takes 30 minutes or so, so hang tight...)
20170618 20:01:45< vultraz_iOS> FTR you will need SDL 2.0.4, but if you're already running that you should be good
20170618 20:02:08< vultraz_iOS> (that's been the soft min version for master anyway)
20170618 20:02:27< gfgtdf> vultraz_iOS: what exactly dp we need sdl 2.0.4 for? Is therea  known bugs that is fixed in sdl 2.0.4 ?
20170618 20:03:00< vultraz_iOS> well, no, but a change i added to master actually requires it
20170618 20:03:02< vultraz_iOS> the use of SDL_GetDisplayDPI
20170618 20:03:21< gfgtdf> hmm ok
20170618 20:04:17< celmin> Basically because we rely on new API additions, I guess.
20170618 20:04:33< DeFender1031> vultraz_iOS, yeah, I had to manually install 2.0.5 with some weird hack to get it compiling
20170618 20:04:59< DeFender1031> (though debian just released stretch, so devuan shouldn't be far behind, so I ought to be able to dump that and use built-in soon...)
20170618 20:05:25< DeFender1031> scons is still sconsing...
20170618 20:05:58< vultraz_iOS> debian stretch means we can bump our min compiler version \ o /
20170618 20:07:59< DeFender1031> is deb the only thing that was waiting on?
20170618 20:08:26< DeFender1031> vultraz_iOS, since this seems to be important news for you: https://www.debian.org/News/2017/20170617
20170618 20:15:51< celmin> Probably not.
20170618 20:16:15< celmin> I mean, there's really no point in bumping the min compiler version for GCC as long as you're supporting MSVC 2013.
20170618 20:17:09< DeFender1031> in other news, scons is.... still sconsing.
20170618 20:17:24< celmin> Given that MSVC 2013's C++11 support is even worse than whichever GCC is currently the minimum.
20170618 20:17:31< DeFender1031> I can't be the only one annoyed by how long it takes to compile this thing, right?
20170618 20:17:36< celmin> BTW vultraz_iOS - for 1.15 do you intend to bump to 2015 or 2017?
20170618 20:17:44< celmin> DeFender1031: Yeah, you're definitely not the only one.
20170618 20:17:49< vultraz_iOS> I was thinking 2015
20170618 20:17:57< vultraz_iOS> and GCC 5
20170618 20:17:58< celmin> I suspect the scons build is slower than the project files, actually.
20170618 20:18:23< vultraz_iOS> Though if we retarget 1.14 we might as well also upgrade the min compiler while we're at it
20170618 20:18:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170618 20:18:27< DeFender1031> celmin, what do you mean?
20170618 20:18:53< DeFender1031> vultraz_iOS, one thing that thread doesn't touch on, what would retargeting 1.14 do to the steam plan?
20170618 20:18:53< celmin> Maybe not by much, but it first builds all the .o files for each source (though I think project files do that too), then builds various static libraries, and then finally links it all together.
20170618 20:18:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170618 20:19:14< celmin> It would push it back, probably to next year.
20170618 20:19:22< DeFender1031> eesh...
20170618 20:19:22< celmin> Maybe late this year, if lucky.
20170618 20:19:24< vultraz_iOS> I have said that
20170618 20:19:27< vultraz_iOS> repeatedly :P
20170618 20:19:31< celmin> That
20170618 20:19:37< vultraz_iOS> We will operate on Valve time
20170618 20:19:40< DeFender1031> so basically, no 1.14, no steam release?
20170618 20:20:00< celmin> That's why it's better if we can find some quick-fixes for the performance issues, rather than merging Vultraz's branch.
20170618 20:20:05< DeFender1031> right.
20170618 20:20:37-!- Kwandulin [~Kwandulin@p200300760F7CBAEBB4C29FB1DCCF25BF.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170618 20:20:51< DeFender1031> erg... stuck between a rock and a hard place.
20170618 20:20:52< vultraz_iOS> celmin: there are two questions I'm considering: 1: how bad are player experiences? 2: how much work would it take to fix these performance issues *without* committing to accelerated rendering?
20170618 20:21:12< celmin> My guess is that #2 is easier than you think.
20170618 20:21:31< celmin> Though that doesn't mean it's easy.
20170618 20:21:58< DeFender1031> I have to believe that even without accelleration, there has to be something that changed between 1.12 and 1.13 that can be rectified simply
20170618 20:22:11< celmin> There are lots of things.
20170618 20:22:29< vultraz_iOS> If this were Congress I could delegate the info gathering to a subcommittee :P
20170618 20:22:38< DeFender1031> oh, btw, celmin, did you make any progress on migrating redraws to only points which matched the criteria I outlined?
20170618 20:22:47< celmin> I think what you'd need to do is follow Jyrki's advice and use an actual profiler.
20170618 20:22:53< celmin> I have not made progress on that yet, sorry.
20170618 20:23:07< celmin> I might have a stash related to it.
20170618 20:23:12< vultraz_iOS> Basically though, I've already made so much progress on this end I don't want to go back and work on master
20170618 20:23:15< vultraz_iOS> :P
20170618 20:23:21< DeFender1031> vultraz_iOS, if this were congress, it'd take four years to get anything done, and then it'd immediately be undone once the next administration was voted in.
20170618 20:23:36< vultraz_iOS> So Real It Hurts :(
20170618 20:24:07< DeFender1031> celmin, no worries and no pressure, just wanted to check in since i've been somewhat less present for the past couple of weeks.
20170618 20:24:22< DeFender1031> vultraz_iOS, remember, pro is to con as progress is to congress.
20170618 20:24:53< vultraz_iOS> And the next administration would spout some grandiose promises for getting it done and then do something complete orthogonal to do doing it.
20170618 20:25:09< vultraz_iOS> They would also say we need to bring back 1.12
20170618 20:25:13< DeFender1031> scons, y u no finish sconsing yet?
20170618 20:25:25< vultraz_iOS> Because SDL2 is a unnecessary regulation 
20170618 20:25:28< vultraz_iOS> s/a//
20170618 20:25:30< DeFender1031> vultraz_iOS, make wesnoth great again? :P
20170618 20:25:57< vultraz_iOS> MWGA
20170618 20:26:01< vultraz_iOS> mmmwaaga
20170618 20:26:45< DeFender1031> on the other hand, my comment was not directed at any one party or any one administration. I meant that in general, they all suck.
20170618 20:27:01< vultraz_iOS> suckiness is a spectrum :P
20170618 20:28:48< DeFender1031> ah, spectrum. a beautiful array of color! A gradient of possibilities!
20170618 20:28:49< celmin> Undoing what the previous administration did is not unique to Republicans, after all.
20170618 20:29:06< vultraz_iOS> Sure
20170618 20:29:09< celmin> Both sides of the political spectrum do it.
20170618 20:29:12-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Quit: Caught sigterm, terminating...]
20170618 20:29:13< vultraz_iOS> But you can't look at that in the abstract
20170618 20:29:19< vultraz_iOS> You must look at what is being undone
20170618 20:29:34< celmin> Well sure, but it should also be taken as a sign of deeper problems.
20170618 20:29:36-!- Ivanovic [~ivanovic@p4FC534A6.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 20:30:02-!- Ivanovic [~ivanovic@p4FC534A6.dip0.t-ipconnect.de] has quit [Changing host]
20170618 20:30:02-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20170618 20:30:33< vultraz_iOS> Yes, I'm sure you Canadians bask in the glorious ways of your handsome PM and never have partisan struggles :(
20170618 20:31:20< DeFender1031> "what's being undone" being good or bad is going to be very... well... political. It's in the eye of the beholder. My point was just that, good or bad, they end up going nowhere.
20170618 20:31:34< DeFender1031> Ah, canadians.
20170618 20:31:43< celmin> That's not true at all.
20170618 20:32:06< celmin> Don't forget the previous PM.
20170618 20:32:26< vultraz_iOS> I have no idea who the previous PM even was except that he did some racist stuff
20170618 20:32:34< celmin> And while I might agree with some of what Trudeau is undoing of Harper's regime, the fact that he can easily do it is still a problem.
20170618 20:32:53< celmin> And the fact that Harper could so easily undo what the PM before him did is also a problem.
20170618 20:33:29< DeFender1031> Can we all agree that governments tend to suck?
20170618 20:33:30< celmin> It's a problem not because the policies are objectively good or bad but because they keep flip-flopping.
20170618 20:33:44< DeFender1031> celmin, exactly my point.
20170618 20:33:58< celmin> So not much gets done because too much effort is being put into undoing things.
20170618 20:34:06< vultraz_iOS> Well, in the US that's why we have executive orders vs laws passed by congress. Easy to enact, easy to repeal vs hard to enact, hard to repeal
20170618 20:35:02< vultraz_iOS> You can see that with Obamacare
20170618 20:35:08< vultraz_iOS> the GOP is trying sooo hard to get rid of it
20170618 20:35:09< vultraz_iOS> but they cant
20170618 20:35:15< vultraz_iOS> at least, not easily
20170618 20:35:33< JyrkiVesterinen> It helps if political parties aren't as extreme in the US, especially if there is a multi-party system.
20170618 20:35:56< JyrkiVesterinen> In the US, the parties disagree about everything and try their hardest to drag the country to opposite directions.
20170618 20:36:11< vultraz_iOS> It does make it easier to pick a side
20170618 20:36:27< JyrkiVesterinen> Here in Finland, all parties of notable size are much more moderate and can work together.
20170618 20:36:53< vultraz_iOS> Yes, well in Europe your republicans are basically our democrats
20170618 20:36:56< JyrkiVesterinen> We have nine parties in the parliament (one of them just split to two last week -.-), and three of them are in the government.
20170618 20:37:03< DeFender1031> celmin, I have had this idea for a political cartoon for a while, which I'd do if I was a better artist than I am, where basically there's two paths, one labeled "the conservative approach", one labeled "the liberal approach", that both lead to a place labeled "progress". The paths are separated by a tree. There are a donkey and an elephant pulling on opposite ends of a rope down their respective paths, and the rope is bent 
20170618 20:37:05< DeFender1031> around the tree preventing either from getting anywhere. The rope is labeled "the two-party system".
20170618 20:37:10< vultraz_iOS> So liberal even your right is our left
20170618 20:37:51< vultraz_iOS> DeFender1031: good one 
20170618 20:38:09< JyrkiVesterinen> That's also true. US politics are extremely right-wing from our perspective.
20170618 20:38:25-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 246 seconds]
20170618 20:38:29< celmin> Having more parties is better because it means you can't get anything done without cooperating with another party, which in turn means that the policies won't flip-flop so much every time a government changes. It's more stable.
20170618 20:39:43< vultraz_iOS> JyrkiVesterinen: plus in the US there is a deep ideological divide. It's not just people disagreeing on approaches to tackle issues
20170618 20:40:14< DeFender1031> celmin, true, but it also limits progress in its own way. You can't do anything significant, because no matter what your party believes, if the rest of the coalition doesn't agree, you can't do it.
20170618 20:40:31-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170618 20:40:48< DeFender1031> sconsing: 40 minutes and counting...
20170618 20:41:30< JyrkiVesterinen> IMHO, even inability to make significant changes is better than constant flip-flopping.
20170618 20:41:34< DeFender1031> (btw, this is another part of the reason that I haven't made much progress on developing wesnoth itself. The development feedback loop is too long to be coherent.)
20170618 20:42:25< DeFender1031> JyrkiVesterinen, most likely true. Stability to the point of stagnation is probably better than violent and radical shifts slamming from one end to the other.
20170618 20:42:44< DeFender1031> Then again, it might be a false dichotomy. There must be a better system.
20170618 20:43:56< DeFender1031> anyway, back to more relevant discussion: is there any way to address the amount of bloat in the wesnoth source to cut down compile times? this is really a nightmare to work on.
20170618 20:44:56< JyrkiVesterinen> It's quite difficult to do anything. Code isn't exactly unused, there just is so much of it.
20170618 20:45:25< JyrkiVesterinen> Forward declaring things instead of #including would help, but it would be a pretty big task.
20170618 20:46:07< celmin> I recall doing a little of that awhile ago. With gfgtdf's config changes there's probably more that could be done - I remember being unable to forward include config in some places where config::attribute_value was needed.
20170618 20:52:51< DeFender1031> ah, finally, compile done.
20170618 20:53:53< vultraz_iOS> Gud. Gud
20170618 20:54:38< DeFender1031> vultraz_iOS, good news and bad news: the good news is the fade no longer lags. the bad news is that, in fact, the fade does not occur at all, instead it just jumps to the full image immediately.
20170618 20:55:01< vultraz_iOS> ...WELL THEN XD
20170618 20:55:27< DeFender1031> This means that it's not actually respecting the delay...
20170618 20:55:39< DeFender1031> or not performing the IPF
20170618 20:55:42< DeFender1031> or something else similar.
20170618 20:56:59< DeFender1031> looks like IPF may be broken in general. I'm noticing that TCs are not happening either. (Both auto, and manual)
20170618 20:57:30< DeFender1031> I also don't notice any in-game improvement
20170618 20:57:44< vultraz_iOS> Oh right
20170618 20:57:55< vultraz_iOS> IPFs are broken
20170618 20:58:06< DeFender1031> and layering is broken.
20170618 20:58:13< vultraz_iOS> But how do you not notice any in-game improvement
20170618 20:58:28< DeFender1031> units are appearing underneath the throne on the dwarf keep.
20170618 20:58:55< DeFender1031> a lot of the in-game graphics don't work right at all, but i'm still seeing a lot of lag when there's water involved.
20170618 20:59:54< DeFender1031> anyway, since my fade is basically using IPF opacity, it makes sense that it's not showing as such and can't currently be tested.
20170618 21:00:11< DeFender1031> oh, wait.
20170618 21:00:30< DeFender1031> the first time I ran it, i noticed the same lag I usually see when water is involved.
20170618 21:00:34< DeFender1031> the second time, no lag.
20170618 21:00:44< DeFender1031> some kind of caching thing?
20170618 21:01:04< DeFender1031> yeah, i'm loading repeatedly and now no lag.
20170618 21:01:04< celmin> Maybe it's still caching different IPFs separately even though the IPF itself isn't working?
20170618 21:01:32< DeFender1031> celmin, two different issues, lag with water has nothing to do with IPF
20170618 21:01:44< celmin> Oh.
20170618 21:01:54< celmin> Well, caching is probably the same in both cases though...
20170618 21:03:26< vultraz_iOS> Right now my code isn't caching IPF results
20170618 21:03:44< vultraz_iOS> Must be part of the issue
20170618 21:04:05< vultraz_iOS> Anyway, that will have to be out on hold for awhile until we get OGl set up
20170618 21:04:23< celmin> Oh.
20170618 21:06:26< vultraz_iOS> It only caches plain image paths
20170618 21:07:35< vultraz_iOS> DeFender1031: also, I don't flush the texture cache between games
20170618 21:07:40< vultraz_iOS> That would also explain it
20170618 21:11:36< DeFender1031> phone call, bbiab
20170618 21:20:47-!- Waste [~Cracker@blk-138-74-119.eastlink.ca] has joined #wesnoth-dev
20170618 21:21:55-!- trewe [~trewe@2001:8a0:d11f:601:26e3:a3c9:9400:64ac] has quit [Quit: quit]
20170618 21:25:14-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has quit [Remote host closed the connection]
20170618 21:31:31-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170618 21:32:10-!- travis-ci [~travis-ci@ec2-54-224-155-18.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 21:32:11< travis-ci> gfgtdf/wesnoth#876 (fix_1436 - 059a012 : gfgtdf): The build failed.
20170618 21:32:11< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/244316401
20170618 21:32:11-!- travis-ci [~travis-ci@ec2-54-224-155-18.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 21:34:03-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170618 21:36:43-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170618 21:39:41-!- sevu [~Shiki@p548577C2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170618 21:47:00-!- JyrkiVesterinen [~JyrkiVest@87-92-52-38.bb.dnainternet.fi] has quit [Quit: .]
20170618 21:48:15< celmin> There may be some optimization that could be done with SLFs.
20170618 21:48:42< celmin> The SUF seems to build any subfilters at construction time and store them to be used every time the filter is called. The SLF, however, does not do this.
20170618 21:49:08< celmin> Does anyone think it would be worth going for some optimization here? Like, have there been reported performance issues with location filters?
20170618 21:52:44< gfgtdf> celmin: is 'building' really an imporvement? Most processing happens inside the ::matches function actually. It'd be faster of for example the unit filter would store all filter attributes in member variables at construction time.
20170618 21:53:03< celmin> I'm not sure.
20170618 21:53:22< gfgtdf> celmin: iirc his was already done once, but it had problems with variable subsutution. But this doesn't mean it  cannot be done without variable substitution.
20170618 21:53:22< celmin> Storing all the filter attributes at construction time seems to be impossible.
20170618 21:53:28< celmin> Yeah, maybe.
20170618 21:53:44< gfgtdf> wthiout supporting varaible subsutution*
20170618 21:53:57< celmin> I think you'd need some new stuff in vconfig for that to work.
20170618 21:54:22< celmin> Like a get_delayed() function that returns a wrapper of config_attribute_value that will substitute only when the value is actually fetched.
20170618 21:54:43< celmin> I guess for child tags this already exists, but not for attributes.
20170618 21:54:48< gfgtdf> hmm my idea was:
20170618 21:55:07< gfgtdf> you'd just need some 'variant' type for the filter member attributes like variane<int, std::string> where the later i used when it contains a '$' symbol
20170618 21:55:22< gfgtdf> so that the constructore checks whether they contain a $ symbol
20170618 21:55:38< celmin> I'm not sure why you'd need a new variant type when the attribtue value is a variant already.
20170618 21:55:48< celmin> ^attribtue
20170618 21:55:50< celmin> ^attribute
20170618 21:56:38< gfgtdf> hm yxe true, so just ause config::attrobute_value as unit folters members then.
20170618 21:57:13< celmin> Well, that won't work either, because getting a config_attribute_value out of the vconfig currently requires that substitution occur.
20170618 21:57:32< celmin> That's why I said something new would be needed in vconfig and perhaps an attribute value wrapper.
20170618 21:58:11< gfgtdf> celmin: hmm you'd need to call it witout substitution, in the worst case you can use vcfg.get_config()[<key>]
20170618 21:58:34< celmin> True, you could save it from the unparsed config instead of the parsed one...
20170618 21:59:02< celmin> That seems like it'd be a little more awkward, but I guess it'd work out.
20170618 21:59:16< celmin> Anyway, I'm working in that area ATM, so please hold off on trying it.
20170618 22:00:45< gfgtdf> my second thought was: instead of using one big filter struct we have a 'filter_attribute' base class with many derived classes for each attribute so that the filter class basically becomes some vector<unique_ptr<filter_attribute>> that is build in the constructor.
20170618 22:02:26< celmin> Hmm, looking at the code, it seems like there should be situations where a [teleport] ability is not accounted for properly...
20170618 22:03:09< celmin> (That second thought sounds kind of interesting but is a pretty huge rework.)
20170618 22:04:32< celmin> Basically, attempting to check a teleport ability on a unit using the "fake location" thing I was talking about earlier shouldn't work.
20170618 22:04:50< celmin> Because the "fake location" is used for the auto-stored variable.
20170618 22:05:18< celmin> Maybe this was never noticed only because teleport abilities are never checked on other locations?
20170618 22:05:32< celmin> Oh, wait. That is indeed the case.
20170618 22:05:52< celmin> Because the loc variable here is a local. Passing it to the filter is in fact redundant.
20170618 22:05:54< celmin> Okay then!
20170618 22:11:32< DeFender1031> vultraz_iOS, then yeah, it must be that the water images were loading slow on the first time through, but then subsequently were cached and worked fine.
20170618 22:12:19< DeFender1031> yeah, okay, the behavior is consistent.
20170618 22:12:42< DeFender1031> First time I run after starting up the program, lags on water. Subsequent, perfectly fine.
20170618 22:17:22-!- travis-ci [~travis-ci@ec2-54-204-179-230.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 22:17:23< travis-ci> gfgtdf/wesnoth#877 (fix_1436 - 0e40e0b : gfgtdf): The build is still failing.
20170618 22:17:23< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/244325491
20170618 22:17:23-!- travis-ci [~travis-ci@ec2-54-204-179-230.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 22:18:01-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170618 22:19:41< gfgtdf> celmin: how do i convert a wfl::variant toa  double ? It doesn't deen to have a 'as_double' membert
20170618 22:20:05< celmin> to_decimal() / 1000.0 IIRC
20170618 22:20:27< gfgtdf> celmin: ok thy will try
20170618 22:20:28< celmin> Oh, as_decimal I guess.
20170618 22:36:27-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has joined #wesnoth-dev
20170618 22:38:18< celmin> So my work on filters seems to be coming along...
20170618 22:38:51< celmin> I think the only thing left now is to move some formula functions out of FormulaAI so I can use them in the filters.
20170618 22:40:10< celmin> And then all the testing.
20170618 22:40:26< celmin> Which might take some time, so I don't expect to finish today.
20170618 22:43:35< DeFender1031> vultraz_iOS, would it be possible for the image cache to build at parse-time rather than at first-use time? In theory, when parsing WML it should be possible to know which keys are images and pull those into the cache accordingly, no?
20170618 22:43:53< celmin> In theory, maybe...
20170618 22:44:12< celmin> But there's no unique identifying factor to recognize a value as an image AFAIK.
20170618 22:44:53-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has quit [Remote host closed the connection]
20170618 22:45:52< celmin> Basically what you'd be doing is adding code in a lot of different places that does "Oh, I know this is an image, let's preload it".
20170618 22:46:00< DeFender1031> yeah, either the parser would have to have some knowledge of what each tag does, or else there would have to be an extra pass between parsing and game load which does.
20170618 22:46:30< celmin> WML as a format is pretty generic, like JSON.
20170618 22:46:40< celmin> It doesn't care about the structure of the data.
20170618 22:46:48< DeFender1031> I know
20170618 22:46:48-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has joined #wesnoth-dev
20170618 22:46:53-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170618 22:47:37-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has quit [Remote host closed the connection]
20170618 22:52:40-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has joined #wesnoth-dev
20170618 22:54:11< DeFender1031> But what the tags actually do once loaded is well defined
20170618 22:56:41< celmin> Defined by the program, yeah.
20170618 22:56:49< celmin> The parser is not involved in the slightest.
20170618 22:56:54< celmin> Except for translatable strings, I guess.
20170618 22:58:10-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20170618 23:00:54< DeFender1031> Right, so then the second option I mentioned would make more sense. Something which looks at the data between parsing and game load and caches images.
20170618 23:01:15-!- atarocch [~atarocch@93.56.160.37] has quit [Ping timeout: 268 seconds]
20170618 23:01:35-!- travis-ci [~travis-ci@ec2-54-224-155-18.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 23:01:35< travis-ci> gfgtdf/wesnoth#878 (fix_1436 - 2e4b7b3 : gfgtdf): The build is still failing.
20170618 23:01:35< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/244328521
20170618 23:01:35-!- travis-ci [~travis-ci@ec2-54-224-155-18.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 23:01:36< vultraz_iOS> or we simple pre-load everything
20170618 23:01:47< celmin> That won't work for IPFs. :P
20170618 23:01:52< vultraz_iOS> why?
20170618 23:01:53< celmin> Also is inefficient in a different way.
20170618 23:02:03< celmin> Because you can't enumerate every possible IPF?
20170618 23:02:14< vultraz_iOS> ah, true
20170618 23:02:29< vultraz_iOS> but keep in mind IPFs are going to become shaders
20170618 23:02:34< vultraz_iOS> so that doesn't matter
20170618 23:04:06< celmin> Uh.
20170618 23:04:49< celmin> I wonder how possible that actually is...
20170618 23:05:05< vultraz_iOS> Very possible
20170618 23:05:32< celmin> I'm not too sure.
20170618 23:06:02< celmin> Most of the specific IPFs individually could definitely be implemented as shaders.
20170618 23:07:54< vultraz_iOS> as opposed to?
20170618 23:08:42< celmin> Well, you can't apply multiple shaders to one quad.
20170618 23:08:53< celmin> Every render has exactly one fragment shader.
20170618 23:09:09< celmin> So if you have multiple IPFs, they would need to be compiled into a single shader.
20170618 23:09:23< celmin> I think ~BLIT() is the main possibly-problematic one.
20170618 23:09:35< vultraz_iOS> meh
20170618 23:09:39< vultraz_iOS> we'll figure something out
20170618 23:10:11< celmin> I guess if you're using shaders for IPFs you'd end up needing to do exactly what I just said: compile each IPF sequence into a different shader.
20170618 23:10:25< celmin> Not sure if that's practical (there's probably a limit on number of shaders?)
20170618 23:10:44< celmin> There'd probably be ways to use the same shader for similar IPFs, at least.
20170618 23:11:11< celmin> Still, ~BLIT() (and anything else that takes an actual image as argument) could be particularly difficult to handle...
20170618 23:12:25-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20170618 23:12:39-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has quit [Remote host closed the connection]
20170618 23:13:04-!- travis-ci [~travis-ci@ec2-54-204-179-230.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 23:13:05< travis-ci> gfgtdf/wesnoth#880 (fix_1436 - e3f0a7f : gfgtdf): The build failed.
20170618 23:13:05< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/244335028
20170618 23:13:05-!- travis-ci [~travis-ci@ec2-54-204-179-230.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 23:13:15-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has joined #wesnoth-dev
20170618 23:14:29-!- irker312 [~irker@109.237.213.40] has joined #wesnoth-dev
20170618 23:14:29< irker312> wesnoth: Charles Dang wesnoth:accelerated_rendering e1e85fa922e4 / / (14 files in 6 dirs): Split OGL context creation into its own wrapper class https://github.com/wesnoth/wesnoth/commit/e1e85fa922e4308e46d2e16d9f44c101d308da0b
20170618 23:14:30< irker312> wesnoth: Charles Dang wesnoth:accelerated_rendering 3dcdd857823b / src/video.cpp: Removed SDL_INIT_NOPARACHUTE from SDL_InitSubSystem https://github.com/wesnoth/wesnoth/commit/3dcdd857823b5904bb42ba9ccefd93458c4a483b
20170618 23:14:40< vultraz_iOS> ah fuck
20170618 23:14:51< vultraz_iOS> committed an extraneous change to the cb projfile
20170618 23:17:31-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:1dc1:637b:7859:a8f9] has quit [Ping timeout: 258 seconds]
20170618 23:19:05< irker312> wesnoth: Charles Dang wesnoth:accelerated_rendering 7a19b9eb39cd / src/video.cpp: Where the hell did this bit go... (do squash later) https://github.com/wesnoth/wesnoth/commit/7a19b9eb39cd3e6696a0d8a7c7927e6b88510fba
20170618 23:19:20< celticminstrel> Of course, it's totally possible for a shader to take an image as argument...
20170618 23:19:34< celticminstrel> Though I think there might be a limit on how many...
20170618 23:20:07< vultraz_iOS> it's rather unfortunate I now have to replace my nice SDL code with complex OGL code
20170618 23:20:08< vultraz_iOS> but oh well
20170618 23:20:13< vultraz_iOS> I should have done this from the get-go
20170618 23:20:39< celticminstrel> Barring ~BLIT() and ~CHAN(), I think you'd need a different shader for any possible combination of IPFs.
20170618 23:21:06< celticminstrel> So ~O() would be one shader, ~O()~TC() another, ~TC()~O() another, etc.
20170618 23:21:12< vultraz_iOS> oh come on
20170618 23:21:15< vultraz_iOS> that's ridiculous 
20170618 23:21:30< celticminstrel> The presence of a ~CHAN() or ~ADJUST_ALPHA() would instantly mean another shader needed.
20170618 23:21:57< celticminstrel> And for ~BLIT() you'd likely need to first render its argument to a texture, then pass that as a texture argument to the shader.
20170618 23:22:29< vultraz_iOS> this cannot be true :(
20170618 23:23:08< celticminstrel> I dunno, maybe there's a way to combine all those shaders (excepting ones involving ~BLIT(), ~CHAN(), ~ADJUST_ALPHA()) into one by using additional shader parameters.
20170618 23:23:22< celticminstrel> (Maybe even including ones involving ~BLIT(), not sure.)
20170618 23:24:16< celticminstrel> For example, assign each possible IPF a number (probably dynamically at startup), and when calling the shader, pass an int array as parameter which determines in what order the IPFs are executed.
20170618 23:25:06< celticminstrel> It'd be kinda like passing IPF bytecode into the IPF shader.
20170618 23:25:58< celticminstrel> I don't know if this is possible though. Depends on the limitations.
20170618 23:26:46< vultraz_iOS> This sounds very complicated
20170618 23:26:57< celticminstrel> According to this, GL2 guarantees only 64 parameters.  https://stackoverflow.com/a/1792882/1502810
20170618 23:27:05-!- travis-ci [~travis-ci@ec2-54-226-197-47.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 23:27:06< travis-ci> wesnoth/wesnoth#14277 (accelerated_rendering - 3dcdd85 : Charles Dang): The build is still failing.
20170618 23:27:06< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/244337501
20170618 23:27:06-!- travis-ci [~travis-ci@ec2-54-226-197-47.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 23:27:26< vultraz_iOS> Aren't we using gl3
20170618 23:27:41< celticminstrel> Yes, I dunno if that makes a difference in this respect though.
20170618 23:27:58< celticminstrel> But note that 64 parameters means 64 4-vectors.
20170618 23:28:07< celticminstrel> So it's quadruple that if you're only passing numbers.
20170618 23:29:08< vultraz_iOS> If it's that complex I might as well stick to the surface manipulation for most IPFs :|
20170618 23:29:17< celticminstrel> Well.
20170618 23:29:44< celticminstrel> I dunno if that's a good idea though.
20170618 23:30:01-!- travis-ci [~travis-ci@ec2-54-226-197-47.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 23:30:02< travis-ci> gfgtdf/wesnoth#881 (fix_1436 - dc5a952 : gfgtdf): The build is still failing.
20170618 23:30:02< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/244337889
20170618 23:30:02-!- travis-ci [~travis-ci@ec2-54-226-197-47.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 23:31:17< celticminstrel> There's also the fact that some IPFs are probably better implemented as a vertex shader...
20170618 23:31:30< celticminstrel> Though they can definitely still be done as a fragment shader...
20170618 23:31:55< celticminstrel> Actually it might be impossible in the general case to relegate them to a vertex shader, since they can in principle follow IPFs that must be done in a fragment shader.
20170618 23:32:15< vultraz_iOS> :|
20170618 23:32:25< celticminstrel> I imagine we'd wrap all this complexity in a class or something.
20170618 23:33:12< vultraz_iOS> The whole point of using OGL is for the shaders
20170618 23:33:46< celticminstrel> Ah, apparently there is no actual upper limit on the number of shaders.
20170618 23:34:36< celticminstrel> So you could totally have one shader for every possible simple IPF combination, plus one for every IPF involving ~CHAN() or ~ADJUST_ALPHA(), without much of a problem. It might not be quite optimal, mind you...
20170618 23:35:09< celticminstrel> I'd still expect it to be faster than doing the IPFs in software, but I can't be certain.
20170618 23:35:26< celticminstrel> In any case, doing it that way is probably a good start, I guess?
20170618 23:35:53< vultraz_iOS> Do you realize how many shaders that is
20170618 23:36:07< celticminstrel> Yup. It could easily be hundreds or even thousands.
20170618 23:36:42< celticminstrel> BTW, when I say "for every possible combination", that's excluding arguments; so ~O(20%) and ~O(30%) use the same shader.
20170618 23:36:54< vultraz_iOS>  28 base shaders
20170618 23:37:05< celticminstrel> 28 what now?
20170618 23:37:10< vultraz_iOS> IPFs
20170618 23:37:13< celticminstrel> Ignore CHAN and ADJUST_ALPHA.
20170618 23:37:14< vultraz_iOS> sorry
20170618 23:37:21< celticminstrel> So 26 IPFs, I guess.
20170618 23:37:22< vultraz_iOS> and ~NOP
20170618 23:37:25< vultraz_iOS> ok, 26
20170618 23:37:29< celticminstrel> Ah, yeah. so 25 then?
20170618 23:38:04< vultraz_iOS> no i was already excluding nop
20170618 23:38:34< celticminstrel> I count 28 excluding ADJUST_ALPHA and CHAN, actually...
20170618 23:38:41< celticminstrel> From the wiki page.
20170618 23:38:58< vultraz_iOS> Unless I'm failing math that means 26x25x24x23....x1 shaders :|
20170618 23:39:20< celticminstrel> Some of them can probable be merged for the purposes of generating shader code.
20170618 23:39:31< celticminstrel> For example, SCALE() and SCALE_INTO().
20170618 23:39:46< celticminstrel> Or TC() and RC()
20170618 23:40:03< vultraz_iOS> 4.032914611266056e+26
20170618 23:40:04< celticminstrel> Anyway, let's say we have 25 truly unique IPFs.
20170618 23:40:19< celticminstrel> And they get chained up to four long.
20170618 23:40:53< vultraz_iOS> uh
20170618 23:40:54< vultraz_iOS> no
20170618 23:40:55< celticminstrel> That's 25 single-IPF shaders, 625 two-IPF shaders, etc.
20170618 23:40:57< vultraz_iOS> there is no limit
20170618 23:41:13< celticminstrel> Yeah, there's no limit, but you'd only generate the shader for combinations that are actually used.
20170618 23:41:49< celticminstrel> If you limit it to chains of up to four, you get 406,900 shaders with 25 base IPFs.
20170618 23:42:05< celticminstrel> So optimizing it further probably is a good idea.
20170618 23:42:42< vultraz_iOS> We are not writing 400 thousand shaders
20170618 23:42:51< celticminstrel> Uh, obviously.
20170618 23:43:00< celticminstrel> You don't write these shaders, you generate them.
20170618 23:43:17< celticminstrel> You write templates for them, and dynamically fill them in, or something.
20170618 23:44:00< celticminstrel> You need to write the shader code once for each IPF, pretty much. Then you have C++ code that somehow combines that in whatever way needed to produce the desired shader for a given chain.
20170618 23:45:14< celticminstrel> I guess ~MASK() would offer the same problem that ~BLIT() does.
20170618 23:45:47-!- travis-ci [~travis-ci@ec2-54-226-197-47.compute-1.amazonaws.com] has joined #wesnoth-dev
20170618 23:45:48< travis-ci> wesnoth/wesnoth#14280 (accelerated_rendering - 7a19b9e : Charles Dang): The build is still failing.
20170618 23:45:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/244338286
20170618 23:45:48-!- travis-ci [~travis-ci@ec2-54-226-197-47.compute-1.amazonaws.com] has left #wesnoth-dev []
20170618 23:46:00< celticminstrel> Which is probably at least solvable. I'm not sure whether you'd first render the argument to a separate texture first, or actually integrate the nested IPF as part of the final shader.
20170618 23:47:10< celticminstrel> For ~CHAN() and ~ADJUST_ALPHA(), you don't write the shader code directly. You instead write something that compiles the formula code into shader code. This is why the presence of a ~CHAN() or ~ADJUST_ALPHA() instantly means you need a new shader (unless two of them actually use the same formula).
20170618 23:49:02< celticminstrel> It's probably possible to do the thing I described earlier of passing IPF "bytecode" as the argument to a super-IPF-shader, but this might require limiting the supported length of IPF chains. Probably a fairly high limit, but still different from the current limitless implementation.
20170618 23:49:37< celticminstrel> I suppose you could use the super-shader for any chains for which the parameters fit, and generate new shaders that just take the actual IPF parameters if you encouter a longer IPF chain.
20170618 23:50:12< celticminstrel> Also, I mentioned a few days ago the possibility of implementing a WFL interpreter in the shader... but I no longer thing this is practical due to the limitation of 64 parameters.
20170618 23:50:16< celticminstrel> ^think
20170618 23:50:24< celticminstrel> So I wouldn't recommend attempting it at this point.
20170618 23:51:45< celticminstrel> If you want to start working on the IPFs, for now what I'd recommend is simply generating a new shader for every possible combination of IPFs, ignoring any CHAN or ADJUST_ALPHA for now.
20170618 23:52:06< celticminstrel> Get it working first. Then we can look at optimizing the number of shaders if it seems necessary.
20170618 23:53:14< vultraz_iOS> FTR we need to be able to load shaders from WML
20170618 23:53:18< celticminstrel> (Maybe include some debugging feature that outputs the number of shaders currently in use.)
20170618 23:53:22< celticminstrel> From WML?
20170618 23:53:30< vultraz_iOS> Or at least cfg files
20170618 23:53:37< celticminstrel> I'm not quite sure what you're getting at here.
20170618 23:54:31< vultraz_iOS> Shader code is just passed in as a string before parsing is it not
20170618 23:54:41< celticminstrel> ???
20170618 23:54:59< vultraz_iOS> Oh never mind
20170618 23:55:12< vultraz_iOS> <_<
20170618 23:55:22< celticminstrel> We need to be able to compile IPFs into shaders, basically.
20170618 23:55:29< celticminstrel> The IPFs are loaded from WML, I guess?
20170618 23:55:56< vultraz_iOS> I don't want the shader definitions themselves to be in the source code
20170618 23:56:17< vultraz_iOS> In Anura you have them in the config files
20170618 23:56:37< celticminstrel> If it were me I'd probably store them in standalone text files in a shaders directory.
20170618 23:56:49< celticminstrel> Though in this case they wouldn't be shaders, really. They'd be shader fragments, or maybe templates.
20170618 23:56:51< vultraz_iOS> Yes that's what I'm getting at :|
20170618 23:57:11< vultraz_iOS> Since wed want umm authors to be able to provide their own shaders for things
20170618 23:57:14< celticminstrel> But I guess you could store them in WML if you reallt wanted to.
20170618 23:57:16< vultraz_iOS> We'd*
20170618 23:57:23< vultraz_iOS> Umc*
20170618 23:57:34< celticminstrel> I'm not sure that's a good idea, TBH.
20170618 23:57:46< celticminstrel> ^really
20170618 23:58:01< vultraz_iOS> Of course you don't
20170618 23:58:18< celticminstrel> Anything that allows UMC authors to execute arbitrary code is something that should be carefully considered.
20170618 23:58:31< vultraz_iOS> Anura does it
20170618 23:59:07< celticminstrel> I also wonder if there's really anything they could do with custom shaders in shader language that they can't do with ~CHAN().
20170618 23:59:51< celticminstrel> Anura doing it does not mean it's a good idea. :P
--- Log closed Mon Jun 19 00:00:05 2017