--- Log opened Wed Jul 05 00:00:26 2017
20170705 00:08:31< shadowm> The problem with fixing bugs without a clear understanding of them is that, depending on the bug's actual nature, it could resurface in the future, or even be still there.
20170705 00:09:35< vultraz_iOS> Very true
20170705 00:09:37< DeFender1031> shadowm, exactly my point.
20170705 00:09:46< shadowm> Note that's not the same as accidentally stumbling upon a fix and _then_ doing the reverse process and figuring out why the fix works.
20170705 00:09:59< DeFender1031> Also true. I've done that on occasion.
20170705 00:10:57< DeFender1031> Like "oh, this fixed that because the old code was sending this mistaken data through the stack to this point, causing that code to do this wacky thing" is different than "huh... it's gone. Okay."
20170705 00:12:56< DeFender1031> Essentially, "accidentally fixed bugs" are sometimes bugs with some underlying code, and changes to a tangential piece of code will sometimes make the bug stop being reproducable by a previously known test case, but the underlying cause will still be there...
20170705 00:13:03< DeFender1031> lurking...
20170705 00:13:08< DeFender1031> waiting in the depths for some unknowing developer to stumble into its lair...
20170705 00:13:14< DeFender1031> MUAHAHAHAHAHAHA!
20170705 00:22:15-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170705 00:22:18-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Client Quit]
20170705 00:23:12-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170705 00:32:31< irker787> wesnoth: Charles Dang wesnoth:accelerated_rendering e1b8205f7808 / src/display.cpp: Fixed halos drawing over fog and shroud (fixes #1406) https://github.com/wesnoth/wesnoth/commit/e1b8205f78086ab6c03ad81f730728556fcb778a
20170705 00:41:08-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 01:26:31< pydsigner> The way we'd put it at my workplace is that a bug isn't fixed until you know why.
20170705 01:36:02-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 01:45:10-!- travis-ci [~travis-ci@ec2-54-144-211-30.compute-1.amazonaws.com] has joined #wesnoth-dev
20170705 01:45:11< travis-ci> wesnoth/wesnoth#14396 (accelerated_rendering - e1b8205 : Charles Dang): The build has errored.
20170705 01:45:11< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/250171265
20170705 01:45:11-!- travis-ci [~travis-ci@ec2-54-144-211-30.compute-1.amazonaws.com] has left #wesnoth-dev []
20170705 01:51:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170705 01:51:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 01:54:42-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 01:55:58-!- Bonobo [~Bonobo@61.68.203.58] has joined #wesnoth-dev
20170705 02:15:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170705 02:25:01-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 02:31:24-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170705 02:51:02< irker787> wesnoth: Charles Dang wesnoth:accelerated_rendering 60d326f42605 / src/display.cpp: Restore map label position anchoring https://github.com/wesnoth/wesnoth/commit/60d326f42605af203fed21e8fb20e1b26ec46277
20170705 03:19:19-!- DeFender1031 [~DeFender1@89-138-160-34.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20170705 03:34:29-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 03:41:41-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 03:47:35-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170705 04:38:26-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 04:43:17-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 04:56:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170705 04:56:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170705 05:08:18-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 05:38:45-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 05:56:33-!- irker787 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170705 05:56:33-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 05:56:44-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 06:33:42-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 06:50:37-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 07:13:47-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 07:37:54-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 07:45:46-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170705 07:55:27-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 08:09:17-!- atarocch [~atarocch@2.46.58.255] has joined #wesnoth-dev
20170705 08:11:19-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 08:13:15-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 240 seconds]
20170705 08:21:03< vultraz_iOS> I wonder if [redraw] will become unnecessary with a_r
20170705 08:22:24< vultraz_iOS> pretty sure it will
20170705 08:26:11-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev
20170705 08:28:50< zookeeper> why would it? you still need redraws not to occur automatically between some action tags, meaning that you need a tag for forcing a redraw. unless you plan on substituting that with a tag for preventing a redraw.
20170705 08:29:56< vultraz_iOS> Pretty sure all that would be handled automatically without any user intervention
20170705 08:31:17< zookeeper> in that case you probably have an illustrative example handy, no?
20170705 08:31:47< vultraz_iOS> Not yet
20170705 08:31:53< vultraz_iOS> Not for awhile
20170705 08:32:04 * vultraz_iOS returns to ripping things out
20170705 08:32:46< vultraz_iOS> getting rid of allllll the "invalidated locations" code
20170705 08:33:31< zookeeper> hint: [terrain] should be a good example
20170705 08:34:07< vultraz_iOS> what would be the expected behavior
20170705 08:34:44< zookeeper> you can't automatically redraw between successive [terrain] tags
20170705 08:35:15< zookeeper> you have to either wait for something else to come along, or for a [redraw]
20170705 08:37:18< vultraz_iOS> blah
20170705 08:37:26< vultraz_iOS> well, I'll get to that when needed
20170705 09:01:17-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170705 09:17:38-!- Kwandulin [~Kwandulin@p200300760F6B8CE3D5BD9EFB74CCEC20.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 09:21:08-!- RatArmy_ [~ratarmy@om126204172040.6.openmobile.ne.jp] has joined #wesnoth-dev
20170705 10:22:15-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 240 seconds]
20170705 10:32:50-!- Kwandulin [~Kwandulin@p200300760F6B8CE3D5BD9EFB74CCEC20.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20170705 10:33:23< vultraz_iOS> zookeeper: what does primary_frame do?
20170705 10:41:59< zookeeper> ...the what? neverheard
20170705 10:42:13< vultraz_iOS> some animation attribute
20170705 10:42:22< zookeeper> show me
20170705 10:42:30< zookeeper> ohh
20170705 10:42:52< zookeeper> nevermind
20170705 10:42:53< zookeeper> show me
20170705 10:45:02< vultraz_iOS> undocumented, but seems to end up here https://github.com/wesnoth/wesnoth/blob/master/src/units/frame.cpp#L771
20170705 10:47:03< zookeeper> https://wiki.wesnoth.org/AnimationWML#Field_Description -> "primary: should the engine consider that frame as a primary frame (affected by visual effects like stone and poison)"
20170705 10:47:25< vultraz_iOS> stone?
20170705 10:47:28< vultraz_iOS> but ok.
20170705 10:48:10< zookeeper> that is, does the frame portray "the unit itself", and not for example projectiles or particles or whatever.
20170705 10:49:07< vultraz_iOS> alright
20170705 10:50:27< vultraz_iOS> i guess it's not actually relevant here anyway
20170705 10:51:07 * vultraz_iOS needs to now figure out why the fire dragon is being drawn with two hexes cut out of it :(
20170705 10:52:49-!- Kwandulin [~Kwandulin@p200300760F6B8C68292A9535861AFDF4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 11:04:40-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20170705 11:07:37-!- irker435 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170705 11:07:37< irker435> wesnoth: loonycyborg wesnoth:bcrypt_auth c1a5f0b956e2 / src/ (game_initialization/multiplayer.cpp server/forum_user_handler.cpp): Do comparison to substring using dedicated overload of std::string https://github.com/wesnoth/wesnoth/commit/c1a5f0b956e22ca96b3161600fc422c973f5287f
20170705 11:11:05-!- Kwandulin [~Kwandulin@p200300760F6B8C68292A9535861AFDF4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20170705 11:28:25-!- DeFender1031 [~DeFender1@89-138-160-34.bb.netvision.net.il] has joined #wesnoth-dev
20170705 11:29:01-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Quit: I'll be back!]
20170705 11:34:28-!- Kwandulin [~Kwandulin@p200300760F6B8C68693641106D002E7F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 11:37:33< DeFender1031> vultraz_iOS, There are probably still a few cases where a manual redraw would be desirable.
20170705 11:37:45< vultraz_iOS> looking at [redraw] it seems it also handled forced updates of shroud
20170705 11:38:11< vultraz_iOS> with my changes it won't directly call the drawing function anymore though
20170705 11:38:17< DeFender1031> Also true.
20170705 11:38:32< DeFender1031> (Though, that's a somewhat bad design IMO)
20170705 11:39:05< DeFender1031> (Redrawing graphics doesn't really have much to do with resetting the viewable area of the map.)
20170705 11:39:12< DeFender1031> That said, that's what it was used for.
20170705 11:39:19< DeFender1031> So those cases will stil be desirable.
20170705 11:41:11< DeFender1031> But I could also imagine some cases where some action wml runs a little long, and you want a certain graphic to be onscreen during that time...
20170705 11:41:50< vultraz_iOS> honestly I'll figure out action drawing later
20170705 11:42:28< DeFender1031> Fair.
20170705 11:42:42< DeFender1031> Was just mentioning it since you brought it up.
20170705 11:43:51< DeFender1031> Fire Dragon is an unusual unit graphics-wise.
20170705 11:44:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 11:47:29< DeFender1031> but yeah, ideally, graphics wouldn't be bound to certain hexes in a_r.
20170705 11:48:52< DeFender1031> (Like how [item]s that extend outside the hex they're on get cut off, or how [terrain_graphics] will cut off images if they extend onto hexes which are not part of the given map)
20170705 12:10:14-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev
20170705 12:15:56< irker435> wesnoth: Charles Dang wesnoth:accelerated_rendering 59581fe478c4 / src/sdl/window.cpp: SDL/Window: throw exception if render-to-texture is not enabled https://github.com/wesnoth/wesnoth/commit/59581fe478c4df64e107c66e8ec9cde697fa9ba6
20170705 12:15:59< irker435> wesnoth: Charles Dang wesnoth:accelerated_rendering e8b948beea34 / src/ (42 files in 10 dirs): Display: removed all the invalidated locations code https://github.com/wesnoth/wesnoth/commit/e8b948beea34ae4dd145bd07e57739eebb772e73
20170705 12:16:02< irker435> wesnoth: Charles Dang wesnoth:accelerated_rendering 070e1ca4f617 / src/ (7 files in 4 dirs): Removed animation invalidation code https://github.com/wesnoth/wesnoth/commit/070e1ca4f617f545b3b5dcfc21685170ad73d504
20170705 12:16:05< irker435> wesnoth: Charles Dang wesnoth:accelerated_rendering 8372f97e502e / src/ (11 files in 7 dirs): Display: removed old drawing code and external draw calls https://github.com/wesnoth/wesnoth/commit/8372f97e502e50c9bf8b78bf254e2980577f0234
20170705 12:18:00< vultraz_iOS> DeFender1031: do you recall if units of the same type are supposed to have standing anims in sync with each other..
20170705 12:19:27< zookeeper> of course not
20170705 12:19:46< vultraz_iOS> hm
20170705 12:19:51< vultraz_iOS> broke something perhaps have i must
20170705 12:21:18< vultraz_iOS> now if i start ATOTB all the spearmen are bobbing in unison 
20170705 12:21:22< vultraz_iOS> i assume that's wrong :P
20170705 12:22:14< DeFender1031> vultraz_iOS, what zookeeper said.
20170705 12:22:33< vultraz_iOS> probably 070e1ca4f617  broke it..
20170705 12:23:00< vultraz_iOS> but i don't see how :/
20170705 12:23:29< DeFender1031> It doesn't look right when things that are supposed to be essentially random movements happen in synch with each other.
20170705 12:24:05< vultraz_iOS> let me revert and see if that's the problem commit
20170705 12:24:23< DeFender1031> (For example, I added some random timing to my flag animations in my first scenario to ensure that the flags didn't all flap at the same time.)
20170705 12:29:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170705 12:29:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 12:33:52< vultraz_iOS> no, it seems the culprit is actually.. e8b948beea34 
20170705 12:38:08< DeFender1031> Darn that e8b948beea34! Always screwing things up!
20170705 12:39:35< vultraz_iOS> ah... nope
20170705 12:39:40< vultraz_iOS> still the same without that too
20170705 12:39:40< vultraz_iOS> weird..
20170705 12:41:28< DeFender1031> WAS there a point at which it didn't do that in a_r?
20170705 12:41:56< DeFender1031> Also, it's possible that if the animations are all starting at the same moment, they'd stay in synch.
20170705 12:42:20< vultraz_iOS> im not sure
20170705 12:42:40< vultraz_iOS> maybe performance is too good :P
20170705 12:42:41-!- Kwandulin [~Kwandulin@p200300760F6B8C68693641106D002E7F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170705 12:42:53< DeFender1031> So if you're testing from a save where all the units are already on screen and not moving them or recruiting any more, it's possible that there's no bug as such and that they just happen to be in synch due to tangential reasons.
20170705 12:43:30< DeFender1031> (This could also be fixed by adding some code which, upon game load, picks a random point within a standing animation at which to start rather than starting from the first frame.)
20170705 12:45:16< vultraz_iOS> peeerhaps
20170705 12:45:20< DeFender1031> I would imagine that if my theory is correct, it's happening because a_r is more efficient and therefore there's no delay between rendering the first unit and rendering the next, thus starting the animation for all of them at the same time, whereas the old code would have started each animation when the unit was created and then had a not-entirely-insignificant processing delay between them.
20170705 12:47:17< DeFender1031> And I don't consider that randomizer thing I said to be a hacky workaround, because it's actually code that makes sense. I think any time a unit is placed in such a way that it appears rather than animating its way in, the standing animation should start at a random point to break up the monotony of multiple units having the same animation.
20170705 12:54:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170705 12:55:08< vultraz_iOS> holy crap I have increase MOVEMENT ANIMATION SMOOTHNESS P_P
20170705 12:55:12< vultraz_iOS> increased*
20170705 12:55:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 12:56:07< vultraz_iOS> by iterating over the units directly and drawing each one instead of performing a "is a unit here" check for every single map location I have increased P E R F O R M A N C E
20170705 12:56:31< vultraz_iOS> oh, and this fixes le fire dragon too
20170705 12:57:38< vultraz_iOS> makes sense, reall
20170705 12:57:39< vultraz_iOS> y
20170705 12:58:17< vultraz_iOS> It's the difference between iterating over a container n times and 1 time
20170705 13:06:16-!- travis-ci [~travis-ci@ec2-54-198-105-210.compute-1.amazonaws.com] has joined #wesnoth-dev
20170705 13:06:17< travis-ci> wesnoth/wesnoth#14399 (accelerated_rendering - 8372f97 : Charles Dang): The build has errored.
20170705 13:06:17< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/250325424
20170705 13:06:17-!- travis-ci [~travis-ci@ec2-54-198-105-210.compute-1.amazonaws.com] has left #wesnoth-dev []
20170705 13:10:25-!- atarocch [~atarocch@2.46.58.255] has quit [Ping timeout: 248 seconds]
20170705 13:11:59-!- atarocch [~atarocch@2.46.58.255] has joined #wesnoth-dev
20170705 13:20:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170705 13:20:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 13:22:32< DeFender1031> well, sounds more like reducing O(n²) to O(n), but yeah.
20170705 13:25:05< DeFender1031> Actually, that's kind of what you said, just in a sort of roundabout way.
20170705 13:26:22< vultraz_iOS> going to apply similar changes to [item]s, etc
20170705 13:27:25< DeFender1031> :D
20170705 13:27:58< matthiaskrgr> sick gains, bro ! 
20170705 13:28:04< matthiaskrgr> (performance gains) 
20170705 13:30:38< DeFender1031> vultraz_iOS, I'm wondering if after all this is done, it'll make it easier for "lockstep" to actually mean "lockstep" in terms of https://wiki.wesnoth.org/InterfaceActionsWML#.5Bmove_units_fake.5D
20170705 13:31:16< vultraz_iOS> you mean each one a certain number of steps at a time or all at once
20170705 13:32:31< DeFender1031> I mean, at the moment, the way it works is that it moves the first unit one hex along their path, then when that's done, it moves the second unit one hex, then the third, etc. "Lockstep" would actually mean "all units move one hex along their path at the same time, then all units move the next hex along their path at the same time, etc."
20170705 13:32:53< DeFender1031> or SHUOLD actually mean that, at any rate.
20170705 13:33:28< vultraz_iOS> It could be done, perhaps
20170705 13:35:48-!- atarocch [~atarocch@2.46.58.255] has quit [Ping timeout: 260 seconds]
20170705 14:02:51< zookeeper> i never understood why someone implemented [move_units_fake] like that in the first place, because it's just completely useless.
20170705 14:03:59-!- Kwandulin [~Kwandulin@p200300760F6B8C68383F53698589E1CD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 14:05:38< DeFender1031> zookeeper, if it were a proper lockstep, it'd be far less useless...
20170705 14:05:50< zookeeper> exactly
20170705 14:12:40-!- Bonobo [~Bonobo@61.68.203.58] has quit [Ping timeout: 260 seconds]
20170705 14:16:28-!- sevu [~Shiki@p57803acb.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 14:48:21-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Ping timeout: 268 seconds]
20170705 14:54:12< vultraz_iOS> DeFender1031: so, actually, looking at the way I have the rendering code set up I realize I can actually seriously optimize here by applying this principle broadly. I just realized that by drawing things per-hex in a "stack", you end up switching textures internally an exponential number of times. Ie, by doing, say, for a simple example, terrain -> fog for every hex, instead of all terrains -> all fog, you end up switching between the
20170705 14:54:12< vultraz_iOS> terrain and fog textures easily hundreds of times.
20170705 14:55:04< vultraz_iOS> I'm doing some refactoring to change things to the "draw all of this thing at once" method
20170705 14:56:09< vultraz_iOS> And this is more efficient for general lookup loops, too.
20170705 14:57:16< vultraz_iOS> take this, for village flags: https://github.com/wesnoth/wesnoth/blob/accelerated_rendering/src/display.cpp#L331-L352
20170705 14:57:26< vultraz_iOS> before I was calling it *for every hex*
20170705 14:57:29-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20170705 14:57:52-!- atarocch [~atarocch@2.46.58.255] has joined #wesnoth-dev
20170705 14:57:55< vultraz_iOS> meaning for every map hex... every team was checked...
20170705 14:59:01< vultraz_iOS> that's already N(T) lookups 
20170705 14:59:18< vultraz_iOS> whereas instead I can just iterate over every team once
20170705 14:59:26< vultraz_iOS> take all its village locs
20170705 14:59:31< vultraz_iOS> and draw the damn flag on each one
20170705 15:02:25< DeFender1031> vultraz_iOS, sounds reasonable, yeah.
20170705 15:04:53< irker435> wesnoth: loonycyborg wesnoth:bcrypt_auth 416d63f9b75a / src/ (4 files in 3 dirs): Put bcrypt handling behind an abstraction and improved error handling https://github.com/wesnoth/wesnoth/commit/416d63f9b75a1b7d82d0044fd561f99bdf0ea639
20170705 15:24:26-!- Kwandulin [~Kwandulin@p200300760F6B8C68383F53698589E1CD.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20170705 15:30:50< vultraz_iOS> hm, one small hiccup... forgot i wasn't actually drawing *every* hex, but rather the visible ones. Changes still an optimization, but need to add check for if in visible hex area
20170705 15:31:47< irker435> wesnoth: loonycyborg wesnoth:bcrypt_auth 270be4fda34e / src/hash.cpp: Remove redundant size check https://github.com/wesnoth/wesnoth/commit/270be4fda34e46d45fbc0dc295853938f6e54d7c
20170705 15:33:34< DeFender1031> vultraz_iOS, since you're on that point, I'd suggest a slightly different check.
20170705 15:33:42< vultraz_iOS> hm?
20170705 15:33:50< DeFender1031> Namely, whether the graphics being rendered are in the visible window.
20170705 15:34:20< vultraz_iOS> you mean the clipping rect?
20170705 15:34:30< DeFender1031> meaning, if what's rendered is offset by 15 hexes, it can very well be offscreen despite the hex where it originates being onscreen, or vice-versa.
20170705 15:34:40< vultraz_iOS> SDL handles trimming things appropriately
20170705 15:34:52< DeFender1031> yeah, that's not what I meant.
20170705 15:35:11< DeFender1031> of course it'll trim properly, or not show at all if it's something offscreen.
20170705 15:35:28< DeFender1031> (so your check is really just an optimization, as such)
20170705 15:35:53< vultraz_iOS> right
20170705 15:36:07< vultraz_iOS> but for large maps I don't want to try to render a whole bunch of off-screen units
20170705 15:36:15< DeFender1031> but my point is that if a unit has some animation that puts a halo several hexes away, you want that animation to run if that halo ends up onscreen, even if the originating hex itself is not.
20170705 15:36:26< DeFender1031> (I've personally had this issue myself.)
20170705 15:36:29< vultraz_iOS> hmmm
20170705 15:36:39< DeFender1031> Do you remember my sparkling forest scenario?
20170705 15:36:44< vultraz_iOS> i think that should be fixed
20170705 15:36:46< DeFender1031> Where you follow the lights in the trees?
20170705 15:36:57< vultraz_iOS> yes
20170705 15:37:23< vultraz_iOS> feel free to test it again with current branch
20170705 15:37:41< DeFender1031> Originally, I had set it up as a dummy unit at one of the corners generating that animation in the necessary position, except the animation never ran because the given hex was not visible.
20170705 15:38:06< DeFender1031> So I then moved the animation to Alric himself, which was very annoying to manage.
20170705 15:38:30< DeFender1031> Would have preferred to do it the first way.
20170705 15:38:55-!- atarocch [~atarocch@2.46.58.255] has quit [Ping timeout: 268 seconds]
20170705 15:39:09< DeFender1031> There's also the question of "if there's a unit which is on a hex currently behind shroud/fog, should animations which would not end up under the fog/shroud still run?"
20170705 15:40:05< DeFender1031> Oh, and I hope your code doesn't change how layering works (at least, not in a way that can't be overridden), as I'm currently relying on halos rendering above shroud for one of my animations in the opening.
20170705 15:41:10< vultraz_iOS> I've moved halos under fog/shroud
20170705 15:41:22< DeFender1031> urgh... that'll destroy the animation I have...
20170705 15:41:54< vultraz_iOS> it was necessary to fix a bug
20170705 15:41:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170705 15:42:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 15:42:48< DeFender1031> TBH, it'd be nice if the layering values were all on the same plane, so that if you want to, for some reason, render an animation frame under a certain terrain at -400, you could put your animation at -401, and likewise, if fog were always at, say, layer 1000 and shroud were always at, say, 2000, so you could always choose whether to have them above or below.
20170705 15:43:22< DeFender1031> essentially giving full control over an animation's z-index to the animator.
20170705 15:43:35< vultraz_iOS> would be nice, yes
20170705 15:43:39< DeFender1031> (With clearly-defined rules for what z-index the built-in stuff renders at)
20170705 15:44:14< zookeeper> i believe there's a reasonably high chance that "it's not that simple".
20170705 15:44:33< vultraz_iOS> well certainly more so with a_r
20170705 15:44:59< DeFender1031> Anyway, I suspect that change would not make the animation I wanted entirely impossible, it just means that I'd have to code the image for a fake shroud into the animation itself rather than using a real shroud.
20170705 15:45:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20170705 15:45:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 15:45:32< DeFender1031> vultraz_iOS, why's that? shouldn't you have a system which has a collection of stuff ordered by z-index and then render them in order?
20170705 15:45:47< vultraz_iOS> I meant more "that simple" with a_r
20170705 15:45:58< vultraz_iOS> not not more simple
20170705 15:46:09< DeFender1031> ah
20170705 15:46:21< DeFender1031> so a_r makes it easier to do what I suggested. got it.
20170705 15:46:46< DeFender1031> and likewise, I take it that it's still not entirely simple, but just more simple than with the old version?
20170705 15:47:02< vultraz_iOS> I don't entirely know
20170705 15:47:11< DeFender1031> Fair enough.
20170705 15:47:18< vultraz_iOS> I've put aside the new drawing queue
20170705 15:47:47< vultraz_iOS> Focusing on optimizing the drawing
20170705 15:48:11< vultraz_iOS> which still isn't the most optimal but a hell of a lot better than master
20170705 15:48:23< DeFender1031> right.
20170705 15:48:56< DeFender1031> Sorry, I keep (somewhat selfishly) bringing up other concerns because I don't want what I've done ot not work anymore...
20170705 15:50:11< DeFender1031> The main point I was trying to make above though is that even offscreen units/items/whatever may have some part of them that's visible onscreen, and that therefore any optimizing check should check the actual position of what would be appearing rather than use the hex itself.
20170705 15:52:34< DeFender1031> For example a unit could have an animation with a frame that has an x offset of 2000 and a y offset of 4000. The image would render nowhere near the unit, and the two probably wouldn't ever be onscreen at the same time, but the image should ideally still render properly when you're looking 2000 pixels to the right and 4000 pixels down from where the unit is.
20170705 15:52:37< vultraz_iOS> yes, that is a good point
20170705 15:56:02< vultraz_iOS> gonna be honest, you keep suggesting things I'm not sure how to do >_>
20170705 15:56:45< DeFender1031> I'm... sorry? I guess?
20170705 15:56:59< vultraz_iOS> well, there's a simple way to do it
20170705 15:57:12< vultraz_iOS> forget visible hexes
20170705 15:57:18< vultraz_iOS> render all units/items/halos/etc
20170705 15:57:24< vultraz_iOS> and let SDL cut off what needs to be cut off
20170705 15:57:28< DeFender1031> At my day job I'm known as the one who always brings up the annoying edge cases that people haven't thought of. Guess I'm doing that here too.
20170705 15:58:15< DeFender1031> Right, the question is how much of a performance difference is there in limiting visible hexes and in not?
20170705 15:58:30< vultraz_iOS> Dunno.
20170705 15:58:56< vultraz_iOS> could be noticeable if you're playing LotI :P
20170705 15:59:04< vultraz_iOS> but maybe not
20170705 15:59:10< DeFender1031> Also be aware that in cases like this, it may even turn out that SDL does a better job than your code would, and that it would actually be a deoptimization to try to pre-filter before sending to SDL.
20170705 15:59:45< DeFender1031> I've had cases like that in the past, where I put in what I thought was a necessary optimization, and the code ran slowly until I removed the check.
20170705 15:59:58< DeFender1031> I had one recently... trying to remember where.
20170705 16:00:36< vultraz_iOS> well there's non-sdl stuff that runs
20170705 16:01:56< DeFender1031> Fair, thought that could still end up totaling less work in most cases than checking first.
20170705 16:02:21< DeFender1031> Anyway, I'd suggest skipping the optimization check for now and seeing if it's even necessary.
20170705 16:02:37< vultraz_iOS> yeah, doing so
20170705 16:02:53< vultraz_iOS> still moving things out of the hex render loop
20170705 16:03:07-!- travis-ci [~travis-ci@ec2-54-158-166-19.compute-1.amazonaws.com] has joined #wesnoth-dev
20170705 16:03:08< travis-ci> wesnoth/wesnoth#14400 (bcrypt_auth - 416d63f : loonycyborg): The build was broken.
20170705 16:03:08< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/250391269
20170705 16:03:08-!- travis-ci [~travis-ci@ec2-54-158-166-19.compute-1.amazonaws.com] has left #wesnoth-dev []
20170705 16:06:00< vultraz_iOS> ah, the beauty of long if blocks... >_<
20170705 16:06:02< vultraz_iOS> 				if((overlays.first->second.team_name == "" ||
20170705 16:06:02< vultraz_iOS> 					overlays.first->second.team_name.find(dc_->teams()[viewing_team()].team_name()) != std::string::npos)
20170705 16:06:02< vultraz_iOS> 						&& !(is_fogged && !overlays.first->second.visible_in_fog))
20170705 16:09:49-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170705 16:11:08-!- mjs-de [~mjs-de@x4e30d7bb.dyn.telefonica.de] has joined #wesnoth-dev
20170705 16:11:34< DeFender1031> Oh, I remember one example of a non-optimization from my day job. This was in the days before CSS animations were available in most browsers. I have animations for our webpages which are basically a series of sprites in a spritesheet (for example, for a spinning loading icon). I was having JS animate it by doing a setTimeout for the next frame and adjusting the offset position accordingly. To "optimize" for cases where there 
20170705 16:11:36< DeFender1031> are multiple such animations onscreen at once, I wanted to cut down on the amount of timer handles being used so I "wouldn't overload the browser". I therefore set it up that there was only one timer handle, and I had an array of callbacks to which various update calls could be added and removed as necessary, which got looped through on every frame and updated the necessary animations. Turns out that JavaScript's event queue 
20170705 16:11:37< DeFender1031> does its job very well without any help from me, and that looping that array was far slower and laggier than just letting the queue work itself out.
20170705 16:12:18< DeFender1031> vultraz_iOS, that's not just a matter of a long block, it's also formatted terribly.
20170705 16:13:26< vultraz_iOS> !(fogged(o_loc) && !item.visible_in_fog).... I think this is equivalent to... && (!fogged(o_loc) || item.visible_in_fog)?
20170705 16:14:20< DeFender1031> I can verify that in a minute, but yes, that's also very weirdly DeMorgansed.
20170705 16:14:33-!- atarocch [~atarocch@151.41.50.122] has joined #wesnoth-dev
20170705 16:15:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170705 16:15:39< DeFender1031> the formatting I was referring to though is not lining up the parens in any sane fashion, not having a consistent rule for whether the boolean operators come at the beginning or the end of a line, etc.
20170705 16:18:05< DeFender1031> and yeah, those are equivalent.
20170705 16:21:11< vultraz_iOS> thanks
20170705 16:30:05-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 258 seconds]
20170705 16:44:37-!- travis-ci [~travis-ci@ec2-54-204-132-52.compute-1.amazonaws.com] has joined #wesnoth-dev
20170705 16:44:38< travis-ci> wesnoth/wesnoth#14401 (bcrypt_auth - 270be4f : loonycyborg): The build was broken.
20170705 16:44:38< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/250402334
20170705 16:44:38-!- travis-ci [~travis-ci@ec2-54-204-132-52.compute-1.amazonaws.com] has left #wesnoth-dev []
20170705 17:01:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170705 17:02:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170705 17:05:08< zookeeper> i hope you're not implying that && (!fogged(o_loc) || item.visible_in_fog) is clearer than !(fogged(o_loc) && !item.visible_in_fog)
20170705 17:05:46< vultraz_iOS> I am
20170705 17:06:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170705 17:08:28< zookeeper> i guess the clarity depends of context, but generally i find && logic easier to immediately understand than || logic
20170705 17:15:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170705 17:24:49-!- sevu [~Shiki@p57803acb.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170705 17:48:11-!- mjs-de [~mjs-de@x4e30d7bb.dyn.telefonica.de] has quit [Remote host closed the connection]
20170705 17:55:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170705 17:55:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170705 18:02:11< irker435> wesnoth: loonycyborg wesnoth:bcrypt_auth 908468d754c5 / src/game_initialization/multiplayer.cpp: Change possibly problematic use of extended initialization syntax https://github.com/wesnoth/wesnoth/commit/908468d754c5efd80d8c38dcd5f8065b5c08233a
20170705 18:10:26-!- Kwandulin [~Kwandulin@p200300760F6B8C68383F53698589E1CD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 18:11:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170705 18:12:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170705 18:14:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170705 18:15:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170705 19:30:58-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170705 19:33:55-!- travis-ci [~travis-ci@ec2-54-204-132-52.compute-1.amazonaws.com] has joined #wesnoth-dev
20170705 19:33:56< travis-ci> wesnoth/wesnoth#14402 (bcrypt_auth - 908468d : loonycyborg): The build was fixed.
20170705 19:33:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/250457038
20170705 19:33:56-!- travis-ci [~travis-ci@ec2-54-204-132-52.compute-1.amazonaws.com] has left #wesnoth-dev []
20170705 19:35:38-!- mjs-de [~mjs-de@x4e30d7bb.dyn.telefonica.de] has joined #wesnoth-dev
20170705 19:41:32-!- Kwandulin [~Kwandulin@p200300760F6B8C68383F53698589E1CD.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
20170705 19:42:01-!- Kwandulin [~Kwandulin@p200300760F6B8C68383F53698589E1CD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 19:49:36-!- Kwandulin [~Kwandulin@p200300760F6B8C68383F53698589E1CD.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20170705 19:56:20-!- stikonas_ is now known as stikonas
20170705 20:20:46-!- horrowind [~Thunderbi@p2003008E6C0B26B3964452FFFE0220ED.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 20:23:20-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170705 20:38:29-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170705 20:39:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20170705 20:43:22-!- mjs-de [~mjs-de@x4e30d7bb.dyn.telefonica.de] has quit [Remote host closed the connection]
20170705 20:49:51-!- stikonas_ is now known as stikonas
20170705 20:51:08-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170705 21:02:17-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170705 21:02:58-!- irker435 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170705 21:12:16-!- horrowind1 [~Thunderbi@p4FFF03FC.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170705 21:13:48-!- horrowind [~Thunderbi@p2003008E6C0B26B3964452FFFE0220ED.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20170705 21:13:48-!- horrowind1 is now known as horrowind
20170705 21:35:58-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170705 21:44:03-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20170705 22:02:50-!- horrowind [~Thunderbi@p4FFF03FC.dip0.t-ipconnect.de] has quit [Quit: horrowind]
20170705 22:05:44-!- atarocch [~atarocch@151.41.50.122] has quit [Ping timeout: 246 seconds]
20170705 22:20:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170705 22:20:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170705 22:34:42-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170705 22:48:50-!- Bonobo [~Bonobo@61.68.203.58] has joined #wesnoth-dev
20170705 23:58:57-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 248 seconds]
--- Log closed Thu Jul 06 00:00:27 2017