--- Log opened Sun Jun 11 00:00:55 2017
20170611 00:15:19-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170611 00:40:06-!- travis-ci [~travis-ci@ec2-54-224-215-74.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 00:40:07< travis-ci> gfgtdf/wesnoth#831 (fix_1674 - 8c738e3 : gfgtdf): The build is still failing.
20170611 00:40:07< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241627616
20170611 00:40:07-!- travis-ci [~travis-ci@ec2-54-224-215-74.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 00:42:27-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170611 00:45:01-!- trewe [~trewe@2001:8a0:d12e:7b01:3559:d9de:b747:81b0] has quit [Quit: quit]
20170611 00:45:54-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170611 01:00:45-!- mjs-de [~mjs-de@x4db68d94.dyn.telefonica.de] has quit [Remote host closed the connection]
20170611 01:03:31-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170611 01:13:29-!- irker644 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170611 01:25:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170611 01:25:53-!- janebot [~Gambot@grickit.us] has joined #wesnoth-dev
20170611 01:26:00-!- janebot [~Gambot@grickit.us] has quit [Changing host]
20170611 01:26:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170611 01:39:49-!- sevu [~Shiki@p548555E9.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170611 01:40:11-!- travis-ci [~travis-ci@ec2-54-224-215-74.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 01:40:12< travis-ci> gfgtdf/wesnoth#832 (fix_1674 - 7e2f7d1 : gfgtdf): The build is still failing.
20170611 01:40:12< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241634499
20170611 01:40:12-!- travis-ci [~travis-ci@ec2-54-224-215-74.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 01:51:07-!- gfgtdf_ [~chatzilla@x4e369845.dyn.telefonica.de] has joined #wesnoth-dev
20170611 01:53:05-!- gfgtdf [~chatzilla@x4e368e2f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170611 01:53:06-!- gfgtdf_ is now known as gfgtdf
20170611 01:58:58-!- clavi [~clavi@v22017034422546657.goodsrv.de] has joined #wesnoth-dev
20170611 02:03:36-!- gfgtdf [~chatzilla@x4e369845.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 53.0.3/20170518000419]]
20170611 02:06:49-!- Bonobo [~Bonobo@61.68.170.86] has joined #wesnoth-dev
20170611 02:10:15-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170611 02:15:05-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Ping timeout: 240 seconds]
20170611 02:21:47-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 02:21:48< travis-ci> gfgtdf/wesnoth#833 (fix_1674 - 03cab6f : gfgtdf): The build is still failing.
20170611 02:21:48< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241639776
20170611 02:21:48-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 02:25:44< vultraz_iOS> so, on further pondering, I realized there's a small problem
20170611 02:25:56< vultraz_iOS> and I'm not sure how one is supposed to solve it
20170611 02:26:12< vultraz_iOS> So, the old rendering method is cumulative rendering
20170611 02:26:30< vultraz_iOS> it renders the entire map and then adds things to the drawing buffer at locations
20170611 02:26:39< vultraz_iOS> and renders those changes
20170611 02:27:00< celmin> Yeah, and?
20170611 02:27:26< vultraz_iOS> If I want to switch to per-frame rendering, the renderer is always cleared before starting
20170611 02:27:54< celmin> Pretty sure you don't have to do that.
20170611 02:28:43< vultraz_iOS> Also, I think to implement a proper viewport you're supposed to load the entire map and just move the camera, I think
20170611 02:29:03< celmin> Sure.
20170611 02:29:26< vultraz_iOS> So, the first obvious solution is use a giant texture for the entire map and render a different source rect of that every frame based on camera position
20170611 02:29:29< vultraz_iOS> Seems reasonable
20170611 02:29:39< celmin> Unfortunately, that doesn't actually seem that reasonable.
20170611 02:29:42< vultraz_iOS> But the max texture size is 2^13 x 2^13
20170611 02:29:45< celmin> There's a maximum texture size.
20170611 02:30:17< celmin> I think at minimum its 4096x4096 (same as what you just said), though it could be higher (depending on the hardware).
20170611 02:30:19< celmin> ^it's
20170611 02:30:32< shadowm> It's certainly hardware-dependent.
20170611 02:31:16< vultraz_iOS> hat's 2^12
20170611 02:31:18< vultraz_iOS> that's*
20170611 02:31:33< celmin> Ah, you're right.
20170611 02:31:33< vultraz_iOS> oh you said minimum
20170611 02:31:45< celmin> But I think that's the most you can absolutely depend on.
20170611 02:32:05< vultraz_iOS> I've already run into that limit with the credits
20170611 02:32:16< vultraz_iOS> You can't load the giant-ass surface into a comparable giant-ass texture
20170611 02:32:19< vultraz_iOS> :P
20170611 02:33:43< vultraz_iOS> so, the question is: how do I cache render output, and how do I deal with the viewport
20170611 02:34:03< vultraz_iOS> if I can't rely on one giant texture
20170611 02:34:13< vultraz_iOS> I've been pondering this for a few hours now
20170611 02:35:02< vultraz_iOS> do I create a texture only the size of the viewport?
20170611 02:36:24-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 02:36:25< travis-ci> gfgtdf/wesnoth#834 (fix_1674 - b880087 : gfgtdf): The build is still failing.
20170611 02:36:25< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241640182
20170611 02:36:25-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 02:37:05< vultraz_iOS> I mean, these *are* static textures 
20170611 02:37:23< celmin> Uh.
20170611 02:37:30< vultraz_iOS> and I'm not going between cpu and gpu memory...
20170611 02:37:41< celmin> Define "static textures", because I don't see how what you're talking about can be described by that phrase...
20170611 02:38:15< vultraz_iOS> a static texture is a specific type of texture access
20170611 02:38:23< vultraz_iOS> technically it means "changes rarely, not lockable"
20170611 02:38:46< vultraz_iOS> if you create a steaming texture, it means "changes frequently, lockable"
20170611 02:38:50< celmin> But you've been talking about render textures.
20170611 02:39:14< vultraz_iOS> I mean all the terrain images and stuff
20170611 02:39:23< vultraz_iOS> would be individually loaded as static textures
20170611 02:39:26 * celmin is admittedly speaking from experience with SFML / OpenGL here.
20170611 02:39:50< vultraz_iOS> if I composited them to a master texture that texture would need to be of type SDL_TEXTUREACCESS_TARGET
20170611 02:40:08< vultraz_iOS> or at least SDL_TEXTUREACCESS_STREAMING
20170611 02:40:39< celmin> Sounds confucian.
20170611 02:41:58< vultraz_iOS> so, what do you think
20170611 02:42:45< celmin> I think the standard practice for hardware rendering is to push the entire scene and let the GPU figure out which part to actually draw.
20170611 02:43:22< vultraz_iOS> hmmm
20170611 02:43:33< vultraz_iOS> well
20170611 02:43:41< vultraz_iOS> anything outside the clipping rect is just discarded I assume
20170611 02:43:50< celmin> Based on the camera position, depth test, and so forth.
20170611 02:44:24< vultraz_iOS> so I wonder if I could just...
20170611 02:44:49< vultraz_iOS> draw everything and let the clip rect discard 9%% of it
20170611 02:44:54< vultraz_iOS> 95%
20170611 02:45:05< celmin> I'm not sure.
20170611 02:45:26< celmin> I think that's standard practice for hardware rendering, but… I'm not exactly an expert on hardware rendering or anything.
20170611 02:45:59< vultraz_iOS> "it just means that anything rendered to the window that falls within that rectangle will be rendered, and anything outside of that rectangle will be discarded."
20170611 02:46:58< vultraz_iOS> I see
20170611 02:47:05< vultraz_iOS> maybe it's Just That Simple
20170611 02:47:29< celmin> Probably worth a try, at least.
20170611 02:47:56< celmin> I'd suggest also trying it on a huge map, though. Maybe ask aeth to send you his map.
20170611 02:48:09< celmin> (Pretty sure that's the biggest map anyone's ever made.)
20170611 02:48:19< vultraz_iOS> there is a max size to maps 
20170611 02:48:36< vultraz_iOS> probably the best test would be a 200x200 water-only map :P
20170611 02:48:49< vultraz_iOS> U N L I M I T E D W A T  E R
20170611 02:48:56< celmin> Uh...
20170611 02:49:08< celmin> Pretty sure aeth's map is bigger than 200x200?
20170611 02:49:17< celmin> I don't remember the size though.
20170611 02:49:56< vultraz_iOS> ok before I try anything in need to change the buffer storage to textures
20170611 02:50:54< vultraz_iOS> then there's the problem that nothing might draw in GUI2 since the buffer is never populated :P
20170611 02:50:58< shadowm> Someone asked for unlimited water?
20170611 02:51:10< vultraz_iOS> nein!
20170611 02:51:11< shadowm> Just place two diagonally-adjacent water source blocks.
20170611 02:51:21< celmin> ...heh.
20170611 02:51:24< vultraz_iOS> heh
20170611 03:09:45< pydsigner> Would it take two or just one?
20170611 03:21:36-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20170611 03:21:47< vultraz_iOS> ohhhh kaayyy...
20170611 03:22:00< vultraz_iOS> doesn't work at all in gui2
20170611 03:22:09< vultraz_iOS> does something in gui1 but not what I want
20170611 03:24:36< vultraz_iOS> ponder
20170611 03:26:11< vultraz_iOS> how should I handle this....
20170611 03:36:26< vultraz_iOS> ok I should definitely be loading the map terrains once.
20170611 03:51:15< celticminstrel> Pretty sure this can still be simplified further...
20170611 03:51:33< celticminstrel> !(mods & KMOD_CTRL) && !(mods & KMOD_ALT) && !(mods & KMOD_GUI)
20170611 03:52:19< celticminstrel> ...actually the original can probably also be simplified (mods & KMOD_CTRL || mods & KMOD_ALT || mods & KMOD_GUI)...
20170611 03:52:47< celticminstrel> That should be equivalent to mods & (KMOD_ALT | KMOD_CTRL | KMOD_GUI), right?
20170611 03:53:07< celticminstrel> And to negate that...
20170611 03:54:14< celticminstrel> Does adding a ~ after & do it?
20170611 04:00:48< vultraz_iOS> Dunno
20170611 04:01:04< vultraz_iOS> Should
20170611 04:02:54< vultraz_iOS> Hmm I see a problem with the drawing buffer model for this ...
20170611 04:03:18< vultraz_iOS> So, I can draw the buffer every turn but
20170611 04:04:10< vultraz_iOS> Ok, say I go through the map at start and add all the foreground and background terrain images to the buffer with a flag not to clear them automatically
20170611 04:04:34< vultraz_iOS> Then draw that every turn
20170611 04:04:56-!- celticminstrel is now known as celmin|sleep
20170611 04:05:06< vultraz_iOS> But, then, how the hell would I deal with cases where the map changes
20170611 04:05:28< celmin|sleep> Redraw it in that case?
20170611 04:05:32< celmin|sleep> Or at least the part that changed.
20170611 04:06:31< vultraz_iOS> Everything is drawing per frame, that's not the problem. The problem is removing things/changing things from/in the buffer cache
20170611 04:06:41< vultraz_iOS> Likewise with moving units and stuff
20170611 04:06:51< vultraz_iOS> Need to rethink some stuff
20170611 04:14:14< celmin|sleep> If everything is drawing per frame, there shouldn't be a problem at all?
20170611 04:14:54< vultraz_iOS> The problem is the interaction between drawing and the mechanisms that say what to draw
20170611 04:15:25< vultraz_iOS> And where
20170611 04:15:36< celmin|sleep> If everything is drawn every frame, there's no need to worry about stuff being changed.
20170611 04:17:18< vultraz_iOS> Yes
20170611 04:17:21< vultraz_iOS> That is correct
20170611 04:18:12< vultraz_iOS> I mean I'm pondering the best way to get the actual stuff to draw every frame.
20170611 04:19:15-!- oldlaptop [~quassel@45.63.78.126] has quit [Quit: No Ping reply in 180 seconds.]
20170611 04:22:57-!- oldlaptop [~quassel@45.63.78.126] has joined #wesnoth-dev
20170611 04:24:07-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170611 04:28:28-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Ping timeout: 260 seconds]
20170611 04:49:40-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has joined #wesnoth-dev
20170611 04:49:54-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has quit [Client Quit]
20170611 05:59:32-!- JyrkiVesterinen [~JyrkiVest@87-100-192-139.bb.dnainternet.fi] has joined #wesnoth-dev
20170611 06:15:41-!- Kwandulin [~Kwandulin@p5DDD0E2F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 07:04:03-!- oldlaptop [~quassel@45.63.78.126] has quit [Quit: No Ping reply in 180 seconds.]
20170611 07:06:55-!- oldlaptop [~quassel@45.63.78.126] has joined #wesnoth-dev
20170611 07:16:36-!- oldlaptop [~quassel@45.63.78.126] has quit [Quit: No Ping reply in 180 seconds.]
20170611 07:19:20-!- oldlaptop [~quassel@45.63.78.126] has joined #wesnoth-dev
20170611 07:23:37-!- RatArmy_ [~ratarmy@om126212088024.11.openmobile.ne.jp] has joined #wesnoth-dev
20170611 07:30:36-!- JyrkiVesterinen [~JyrkiVest@87-100-192-139.bb.dnainternet.fi] has quit [Quit: .]
20170611 07:40:14-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170611 07:43:13< zookeeper> vultraz_iOS, i hope you're consulting with someone who actually has experience with hardware rendering
20170611 07:43:29< vultraz_iOS> does jyrki count
20170611 07:43:37< zookeeper> i wouldn't know
20170611 07:43:49-!- oldlaptop [~quassel@45.63.78.126] has quit [Quit: No Ping reply in 180 seconds.]
20170611 07:45:33< vultraz_iOS> well, he does have ogl experience
20170611 07:45:37< vultraz_iOS> but im not working with ogl yet
20170611 07:45:47< zookeeper> anyway, i'm pretty sure you can't do it by greating one giant texture for the entire map and rendering it every frame and just clipping to the viewport rect, that's madness.
20170611 07:45:51< vultraz_iOS> right now i want to throw the display class out the window
20170611 07:46:14< vultraz_iOS> not madness, I don't think
20170611 07:46:24< zookeeper> yes it is
20170611 07:46:26< vultraz_iOS> since anything outside the viewport isn't rendered
20170611 07:46:48-!- oldlaptop [~quassel@45.63.78.126] has joined #wesnoth-dev
20170611 07:47:28< zookeeper> you'd still have a giant texture that a lot of hardware wouldn't be able to support
20170611 07:48:07< vultraz_iOS> im not using a giant texture
20170611 07:48:27< vultraz_iOS> i can't use a giant texture
20170611 07:48:30< zookeeper> okay, great
20170611 07:53:53< zookeeper> as to whether it's performance-wise feasible to just push everything to the GPU and let it figure out what to cull and what to actually render, i don't know. you'd immediately be looking at some >100k+ objects on a 200x200 map.
20170611 07:59:43-!- oldlaptop [~quassel@45.63.78.126] has quit [Quit: No Ping reply in 180 seconds.]
20170611 08:05:25-!- oldlaptop [~quassel@45.63.78.126] has joined #wesnoth-dev
20170611 08:21:21< vultraz_iOS> ok... i have terrains drawing in GUI1
20170611 08:21:25< vultraz_iOS> albeit inefficiently
20170611 08:21:34< vultraz_iOS> and static terrains drawing in GUI@
20170611 08:21:35< vultraz_iOS> GUI2
20170611 08:21:56-!- mjs-de [~mjs-de@x4db68d94.dyn.telefonica.de] has joined #wesnoth-dev
20170611 08:23:48-!- RatArmy_ [~ratarmy@om126212088024.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170611 08:54:57-!- JyrkiVesterinen [~JyrkiVest@87-100-192-139.bb.dnainternet.fi] has joined #wesnoth-dev
20170611 09:15:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170611 09:55:25-!- Duthlet [~Duthlet@dslb-188-105-125-191.188.105.pools.vodafone-ip.de] has joined #wesnoth-dev
20170611 10:10:53-!- JyrkiVesterinen [~JyrkiVest@87-100-192-139.bb.dnainternet.fi] has quit [Quit: .]
20170611 11:08:48-!- markus_ [~mjs-de@x4e3110bc.dyn.telefonica.de] has joined #wesnoth-dev
20170611 11:11:57-!- mjs-de [~mjs-de@x4db68d94.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170611 11:41:37-!- Kwandulin [~Kwandulin@p5DDD0E2F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170611 11:53:10-!- JyrkiVesterinen [~JyrkiVest@87-100-192-139.bb.dnainternet.fi] has joined #wesnoth-dev
20170611 12:00:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170611 12:49:25-!- sevu [~Shiki@p54857EA1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 13:09:20-!- gfgtdf [~chatzilla@x4e369845.dyn.telefonica.de] has joined #wesnoth-dev
20170611 13:22:23-!- markus_ [~mjs-de@x4e3110bc.dyn.telefonica.de] has quit [Remote host closed the connection]
20170611 13:54:06-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 13:54:07< travis-ci> gfgtdf/wesnoth#835 (fix_1674 - 1b3dfc7 : gfgtdf): The build is still failing.
20170611 13:54:07< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241724968
20170611 13:54:07-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 14:11:36-!- gfgtdf [~chatzilla@x4e369845.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 53.0.3/20170518000419]]
20170611 14:14:18-!- celmin|sleep is now known as celticminstrel
20170611 14:26:43-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 14:26:44< travis-ci> gfgtdf/wesnoth#836 (fix_1674 - facd5a2 : gfgtdf): The build is still failing.
20170611 14:26:44< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241730696
20170611 14:26:44-!- travis-ci [~travis-ci@ec2-54-158-45-37.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 14:31:52-!- Bonobo [~Bonobo@61.68.170.86] has quit [Ping timeout: 260 seconds]
20170611 14:46:33-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 15:04:31-!- travis-ci [~travis-ci@ec2-107-21-64-21.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 15:04:32< travis-ci> gfgtdf/wesnoth#837 (fix_1674 - f296057 : gfgtdf): The build has errored.
20170611 15:04:32< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241734249
20170611 15:04:32-!- travis-ci [~travis-ci@ec2-107-21-64-21.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 15:05:35-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20170611 15:12:51-!- sevu [~Shiki@p54857EA1.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170611 15:14:24-!- sevu [~Shiki@p54857EA1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 15:15:48-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170611 15:25:39-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170611 15:27:40-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170611 15:29:58< celticminstrel> Sooo I'll be going back to leaving the channel while asleep now.
20170611 15:30:30-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170611 15:34:08-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 15:37:42< vultraz_iOS> Terrain, village flags, unit bars, crowns, and overlays all drawing w/ accelerated rendering
20170611 15:39:03< celticminstrel> :O
20170611 15:39:13< celticminstrel> I assume you're still aware that this won't be in 1.14 right.
20170611 15:39:24< celticminstrel> Unless of course you want to push its release to next year.
20170611 15:39:41< vultraz_iOS> hey, I'm not even near done :P
20170611 15:39:45< celticminstrel> 'kay
20170611 15:40:30< vultraz_iOS> but yes, I don't think this will be in 1.14
20170611 15:41:24-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170611 15:42:40-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 15:57:24-!- mjs-de [~mjs-de@x4e3110bc.dyn.telefonica.de] has joined #wesnoth-dev
20170611 16:19:14< vultraz_iOS> IPFs will be a big problem
20170611 16:20:35< celticminstrel> I'm thinking maybe the hotkey issues should be promoted to blocker (meaning they need to be resolved by 1.14).
20170611 16:21:06< celticminstrel> I'm also suddenly suspicious of Aginor's assumption that any keystroke with ctrl, alt, or gui modifiers automatically must be uncomposable.
20170611 16:21:27< celticminstrel> Then again, I'm not even really sure what uncomposable means.
20170611 16:22:15< celticminstrel> If it means the keystroke can't generate text, then that's wrong - alt+key combinations can generate text on the Mac, and even on Windows you can get text from ctrl+alt+key combinations.
20170611 16:22:52< celticminstrel> But on the other hand, maybe that's not whats uncomposable means...
20170611 16:23:46< vultraz_iOS> i have no idea either
20170611 16:24:59< celticminstrel> Anyway I fixed the double Lua console issue by only triggering keydown events for composable keys.
20170611 16:29:08-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170611 16:43:54< celmin> Sooo what about the IME PR?
20170611 16:44:10< vultraz_iOS> no comment
20170611 16:44:36< loonycyborg> I don't know much about IMEs
20170611 16:45:11< celmin> There's some glitches, but the basics pretty much work.
20170611 16:45:53< celmin> Should we merge it, add it to release notes, and see if anyone reports problems with it in 1.13.9?
20170611 16:51:10< celmin> Technically IMEs already worked insofar as you could, in fact, type using them; you just didn't get to see any of the intermediate work.
20170611 16:51:29< vultraz_iOS> see if you can iron out some of the glitches and merge
20170611 16:51:32< celmin> So, the PR is mainly about rendering the intermediate work to the screen.
20170611 16:51:35< celmin> I see.
20170611 16:51:47< celmin> I guess I need to go googling then.
20170611 16:53:28-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170611 16:55:00< celmin> Okay, so the first glitch appears to be fixed. Maybe I just forgot to save something before recompiling.
20170611 16:56:34< celmin> (Which wouldn't be an issue if I was using an IDE, but oh well.)
20170611 17:02:55< vultraz_iOS> come to think of it, most of the IPFs don't need shaders
20170611 17:03:18< vultraz_iOS> CROP and BLIT are basically free.
20170611 17:03:34< vultraz_iOS> as are ROTATE and FLIP
20170611 17:03:38< celmin> Uhh.
20170611 17:03:57< vultraz_iOS> CROP: change source rect when rendering with RenderCopy
20170611 17:04:13< vultraz_iOS> BLIT can be done by rendering multiple textures to a single one, or on top of each other
20170611 17:04:28< vultraz_iOS> ROTATE and FLIP can use RenderCopyEx
20170611 17:04:49< vultraz_iOS> CHAN, CS...  probably SetTextureColorMod
20170611 17:05:10< celmin> No.
20170611 17:05:18< celmin> CHAN cannot be implemented with a color mod.
20170611 17:05:20< celmin> CS maybe.
20170611 17:05:28< celmin> Though I'd be dubious of that, too.
20170611 17:05:29< vultraz_iOS> alright
20170611 17:05:46< vultraz_iOS> i guess those *would* need shaders...
20170611 17:06:06< vultraz_iOS> MASK is harder too
20170611 17:06:16< celmin> CHAN executes formula code, so… you'd need to convert the formula into shader code.
20170611 17:06:39< vultraz_iOS> currently don't have access to shaders 
20170611 17:06:44< vultraz_iOS> never got that OGL context set up
20170611 17:06:54< vultraz_iOS> i started looking at the OGL documentation and it was goddamn complicated as hell
20170611 17:08:47< vultraz_iOS> i at least think i can implement ToD coloring as-is with a color mod
20170611 17:08:55< zookeeper> why do you need to change how IPFs work?
20170611 17:09:10< vultraz_iOS> because of the nature of my refactor
20170611 17:09:20< zookeeper> indeed
20170611 17:09:23-!- StephenKing[m] [stephenkin@gateway/shell/matrix.org/x-wintjmnluiielfpl] has joined #wesnoth-dev
20170611 17:09:38< vultraz_iOS> right now everything is implemented with surfaces
20170611 17:09:46< zookeeper> i know
20170611 17:09:50< vultraz_iOS> you can directly manipulate the pixel data there
20170611 17:09:55< vultraz_iOS> you can't with textures
20170611 17:10:12< vultraz_iOS> i can convert from a surface *to* a texture, though
20170611 17:10:13< celmin> Okay, so where do keyboard chain events get fired...
20170611 17:10:19< celmin> Presumably someplace in distributor...
20170611 17:10:35< vultraz_iOS> look in handler.cpp somewhere
20170611 17:10:55< vultraz_iOS> zookeeper: with textures the focus is supposed to be more on changes happening as stuff is rendered
20170611 17:11:12< vultraz_iOS> not editing the raw pixel data
20170611 17:13:07< zookeeper> why would you not just edit the raw pixel data if it would be a lot simple to implement?
20170611 17:13:13< zookeeper> simpler, even
20170611 17:13:40< vultraz_iOS> it's slower
20170611 17:14:05< zookeeper> yes, obviously, but would that be a problem?
20170611 17:14:29< vultraz_iOS> do you want the extremely smooth map scrolling i have locally now or not :P
20170611 17:15:20-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 17:15:29< vultraz_iOS> for the record this does mean wesnoth will start to actually generate H E A T
20170611 17:15:41< zookeeper> you can just say "it's too complicated to explain" or "i don't know" or whatever
20170611 17:16:10< vultraz_iOS> it's rather slow to constantly hand things off between the CPU/RAM and the GPU
20170611 17:16:20< vultraz_iOS> that's what happens if i do surfaces -> textures too much
20170611 17:16:34< celmin> TBH the best way to implement CHAN is to have an actual WFL interpreter on the GPU.
20170611 17:16:46< vultraz_iOS> say whaaa :o
20170611 17:17:01< celmin> But it would probably be easier to produce a new shader for each use of CHAN.
20170611 17:17:10< celmin> Not sure if that would run into problems though.
20170611 17:17:24< shadowm> Don't break vultraz's head, it's bad enough as it is.
20170611 17:17:35< shadowm> Also Wesnoth has always generated heat.
20170611 17:17:36< celmin> Actually, can you pass strings as arguments to a shader? I've never seen it done...
20170611 17:17:45< vultraz_iOS> as i said
20170611 17:17:52< vultraz_iOS> *i don't have shaders here right now*
20170611 17:18:05< celmin> I heard that the first time. :P
20170611 17:18:34< vultraz_iOS> and i have no idea how shaders work
20170611 17:18:44< celmin> It's literally a program run on the GPU. :P
20170611 17:19:11< celmin> There are different types.
20170611 17:19:18< zookeeper> vultraz_iOS, my point is that even if you do texture->surface->edit->texture for IPF's, it's not entirely obvious why that would result in noticeable slowness especially if you just preload for example all the terrain images/textures and stuff them in texture memory, instead of loading them on demand as is currently done.
20170611 17:19:40< celmin> IIRC, vertex shaders take a world-space point as input and must output a screen coordinate.
20170611 17:19:40< vultraz_iOS> i don't think you can even do texture->surface
20170611 17:19:44< vultraz_iOS> not without being hacky
20170611 17:19:56< zookeeper> well whatever you call it
20170611 17:20:02< celmin> Fragment shaders take a color as input and output a color, and are called for every pixel.
20170611 17:20:03< vultraz_iOS> I'll see what i can do
20170611 17:20:18< celmin> You can definitely do texture->surface.
20170611 17:20:19< vultraz_iOS> but for the ones that don't *need* a surface I'd rather not use it
20170611 17:20:30< vultraz_iOS> ah right
20170611 17:20:37< vultraz_iOS> i forgot SDL_UpdateTexture
20170611 17:20:40< vultraz_iOS> yes, that is a thing
20170611 17:21:45< celmin> If you're doing IPFs on the CPU, then you probably want to cache the results in a texture - basically like the current image cache, except now you're somehow stuffing everything onto one gigantic texture (as much as possible).
20170611 17:22:01< zookeeper> it just seems like it'd be a lot easier to do what you're doing if you don't include refactoring the entire way IPFs work in it, but just let them work more or less the old way even if it's slower.
20170611 17:23:00< vultraz_iOS> refactor ALL THE THINGS
20170611 17:23:08< celmin> Well, refactoring IPFs probably has to happen at some point, but… if you can do it totally separately from the main accelerated rendering work, that might make some things easier.
20170611 17:23:15< celmin> IMO it's better to refactor one thing at a time.
20170611 17:23:15< vultraz_iOS> perhaps
20170611 17:23:18< vultraz_iOS> we'll see
20170611 17:23:39< vultraz_iOS> right now im just focusing on loading unscaled and unedited textures and drawing to screen
20170611 17:24:00< vultraz_iOS> end up with stuff like this which i need to fix: https://cdn.discordapp.com/attachments/259976436490829825/323434473012199425/masking_issue.PNG
20170611 17:24:34< vultraz_iOS> celmin: do you happen to know how to mask a texture (additive blending w/ pure white/black or somehing?)
20170611 17:24:36< vultraz_iOS> something*
20170611 17:26:51< celmin> Not entirely sure what you're asking.
20170611 17:28:02< vultraz_iOS> can you mask something with additive blending and a pure black/white image
20170611 17:28:41< zookeeper> "additive blending" shouldn't have anything to do with masking
20170611 17:30:52< zookeeper> there ought to be all sorts of alpha blending modes you can use when blitting textures with each other
20170611 17:31:03< vultraz_iOS> There are
20170611 17:31:15< vultraz_iOS> There's none, add, mod, and blend
20170611 17:32:39< celmin> There's a lot more than just that.
20170611 17:33:22-!- StephenKing[m] [stephenkin@gateway/shell/matrix.org/x-wintjmnluiielfpl] has left #wesnoth-dev ["User left"]
20170611 17:34:47< vultraz_iOS> Um
20170611 17:34:49< vultraz_iOS> https://wiki.libsdl.org/SDL_BlendMode
20170611 17:35:56< vultraz_iOS> I just see those
20170611 17:37:07< celmin> …why is that called "modulate"?
20170611 17:39:42< vultraz_iOS> what is it?
20170611 17:40:25< celmin> I think it's what I'd call multiplicative blending.
20170611 17:40:43< celmin> Though I'm not quite sure.
20170611 17:41:08-!- moongazer [~moongazer@59.94.241.142] has joined #wesnoth-dev
20170611 17:46:04< vultraz_iOS> still, can any of those beused for mask erasure :/
20170611 17:47:15< vultraz_iOS> I know I'm gimp you can erase areas by applying s fully black mask
20170611 17:47:17< celmin> Not sure.
20170611 17:50:27< vultraz_iOS> But it's tautological to say i can mask something by using the masking method
20170611 17:50:30-!- vn971 [~vasya@213.87.133.126] has joined #wesnoth-dev
20170611 17:50:36< celmin> :P
20170611 17:50:50< vn971> Hi all. I've raised a yet another issue, this time a big one: https://github.com/wesnoth/wesnoth/issues/1777
20170611 17:51:09< vn971> In short, I propose to redesign the game creation dialog a bit.
20170611 17:51:40< celmin> So do I need to find where events get passed to the distributor…? I thought I already blocked that when I fixed enter closing the dialog though...
20170611 17:52:14< vultraz_iOS> That's all in handler.cpp
20170611 17:52:28< celmin> I'm not sure about that...
20170611 17:52:41< vultraz_iOS> Or distributor.cpp
20170611 17:52:43< vultraz_iOS> One of those
20170611 17:53:50-!- moongazer [~moongazer@59.94.241.142] has quit [Ping timeout: 255 seconds]
20170611 17:54:58-!- moongazer [~moongazer@2405:204:918e:386b:54b:8b10:63db:74cc] has joined #wesnoth-dev
20170611 17:55:27< vultraz_iOS> I mean dispatcher
20170611 17:55:31< vultraz_iOS> Not distributor
20170611 17:56:00< celmin> Okay.
20170611 17:56:16< celmin> Still not sure that's the right place, but I can look there.
20170611 17:57:31< zookeeper> looks like SDL_BLENDMODE_BLEND would be the right one for masking src according to the alpha of dst, assuming that the mask is appropriately black or white so there won't be any rgb changes.
20170611 17:57:41< celmin> The distributor is an event dispatcher owned by the window.
20170611 17:58:21< vultraz_iOS> Hmm
20170611 17:58:31-!- sevu [~Shiki@p54857EA1.dip0.t-ipconnect.de] has left #wesnoth-dev ["Verlassend"]
20170611 17:58:57< celmin> Its purpose seems to be to forward any events received by the window to the currently focused widget.
20170611 17:59:54< celmin> I guess it's bound as a separate event handler in the queue, so basically the event is sent to the window and then to the distributor...
20170611 18:00:45< vultraz_iOS> What are you trying to do
20170611 18:01:03-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170611 18:02:16< vultraz_iOS> Or looking for
20170611 18:03:17< celmin> If composition is in progress the keyboard chain should be skipped. Only the focused widget should receive events.
20170611 18:03:32< celmin> BTW, never add a textbox to the keyboard chain, I guess?
20170611 18:04:55< celmin> Currently testing a change in the distributor.
20170611 18:06:38< moongazer> hi
20170611 18:06:50< celmin> 'lo
20170611 18:09:07< moongazer> What's going on 
20170611 18:09:14< celmin> Who knows!
20170611 18:10:11< celmin> I guess the distributor's handler are actually connected first, though that doesn't mean they're called first.
20170611 18:10:15< celmin> ^+s
20170611 18:23:49-!- Kwandulin [~Kwandulin@p200300760F7CBA1D38C0E7D9D4E5C639.dip0.t-ipconnect.de] has quit [Quit: [endlevel]]
20170611 18:32:44< celmin> So it works, yay.
20170611 18:34:25-!- irker137 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170611 18:34:25< irker137> wesnoth: Celtic Minstrel wesnoth:keyboard_issues d5aca0091a41 / src/gui/ (core/event/distributor.cpp widgets/text_box_base.cpp): Fix keyboard chain receiving events meant for the IME https://github.com/wesnoth/wesnoth/commit/d5aca0091a41064f32fbbb105c87c9145d558ed1
20170611 18:34:39< celmin> Okay vultraz_iOS, that fixes it, so do you want to merge now or wait for Travis?
20170611 18:34:53< celmin> Probably a squash-merge, since my plans for reusing the branch probably won't happen.
20170611 18:51:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170611 18:51:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170611 18:54:03< vultraz_iOS> see if travis passes then squash
20170611 18:56:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170611 19:02:44< vultraz_iOS> health/xp bars now drawing procedurally instead of with an image \ o /
20170611 19:04:25< celmin> Sure, but does it actually look good?
20170611 19:04:27 * celmin doubts it.
20170611 19:05:27< vultraz_iOS> of course
20170611 19:05:45< vultraz_iOS> it will look better when zoomed in now too
20170611 19:06:05< vultraz_iOS> the image is literally just a semi-transparent rectangle
20170611 19:06:15< vultraz_iOS> a few pixels slightly moreso than others
20170611 19:10:06 * celmin is not about to take your word on whether it looks good.
20170611 19:13:25< vultraz_iOS> celmin: https://1drv.ms/i/s!As9hRC_GxjKKpXYqqjWWe6pTW_ZI
20170611 19:13:40< vultraz_iOS> and yes, they're drawing under the units but that's a separate issue 
20170611 19:14:16< vultraz_iOS> can you tell any difference from master
20170611 19:14:16< celmin> Yup, looks fine.
20170611 19:14:21< celmin> Uh, not sure.
20170611 19:14:36< celmin> I feel like something is different, but not sure what...
20170611 19:14:46< vultraz_iOS> color is probably slightly different
20170611 19:15:10< vultraz_iOS> but only slightly
20170611 19:15:49-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 19:15:50< travis-ci> gfgtdf/wesnoth#838 (fix_1674 - 22b3887 : gfgtdf): The build failed.
20170611 19:15:50< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241788112
20170611 19:15:50-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 19:16:45< vultraz_iOS> also the new code is only ~40 lines
20170611 19:16:48< vultraz_iOS> down from ~120
20170611 19:16:52< vultraz_iOS> (for the bars)
20170611 19:21:26-!- vn971 [~vasya@213.87.133.126] has quit [Quit: Leaving.]
20170611 19:21:42-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170611 19:24:35-!- gfgtdf [~chatzilla@x4e369845.dyn.telefonica.de] has joined #wesnoth-dev
20170611 19:29:36-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170611 19:29:42-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170611 19:44:31-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 19:44:32< travis-ci> gfgtdf/wesnoth#839 (fix_1674 - 3c549e2 : gfgtdf): The build failed.
20170611 19:44:32< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241792003
20170611 19:44:32-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 19:46:54-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170611 19:59:38-!- Greg-Bog_ [~greg_bogg@2601:1c2:f00:9780:f163:f97:1638:5d16] has joined #wesnoth-dev
20170611 20:02:05-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Ping timeout: 240 seconds]
20170611 20:04:29-!- JyrkiVesterinen [~JyrkiVest@87-100-192-139.bb.dnainternet.fi] has quit [Quit: .]
20170611 20:04:51-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Quit: Leaving]
20170611 20:05:17-!- sevu [~Shiki@p54857EA1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170611 20:05:46-!- DeFender1031 [~DeFender1@46-116-209-76.bb.netvision.net.il] has quit [Ping timeout: 255 seconds]
20170611 20:06:14-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170611 20:06:29-!- DeFender1031 [~DeFender1@93-173-5-53.bb.netvision.net.il] has joined #wesnoth-dev
20170611 20:06:29-!- DeFender1031 [~DeFender1@93-173-5-53.bb.netvision.net.il] has quit [Read error: Connection reset by peer]
20170611 20:06:46< celmin> Apparently I never pushed the user_config enabling for lua mapgen.
20170611 20:06:52< celmin> It's sitting in a stash on my Mac.
20170611 20:07:39< celmin> But there's a bit more to it than just changing that return value, I think.
20170611 20:08:54-!- Greg-Bog_ [~greg_bogg@2601:1c2:f00:9780:f163:f97:1638:5d16] has quit [Remote host closed the connection]
20170611 20:09:15< celmin> Because user_config can't really take a const config& parameter.
20170611 20:09:32< celmin> gfgtdf: ^
20170611 20:09:44-!- DeFender1031 [~DeFender1@93-173-5-53.bb.netvision.net.il] has joined #wesnoth-dev
20170611 20:12:10< gfgtdf> celmin: why that fomr looksing at the source it seems liek it just does tht
20170611 20:12:12< gfgtdf> that*
20170611 20:12:19< celmin> ?
20170611 20:12:42< gfgtdf> celmin: why that? from looking at the source it seems like it just does that
20170611 20:13:06< vultraz_iOS> ah, and then there's ~RC...
20170611 20:13:10< vultraz_iOS> that's a hard once...
20170611 20:13:11< vultraz_iOS> one*
20170611 20:13:12< celmin> Well, how to you expect the user-chosen settings to be communicated back to the generator?
20170611 20:13:19< celmin> ^do
20170611 20:13:38< celmin> ATM it doesn't look like there's any way to do it.
20170611 20:13:41< gfgtdf> celmin: to be stored in the lua state (read: global variable)
20170611 20:13:49< celmin> …that seems pretty terrible.
20170611 20:14:07< celmin> How long does this Lua state persist?
20170611 20:14:36< celmin> When you click "regenerate", is a new state created, the generator invoked, and the state then destroyed>
20170611 20:14:38< celmin> ^?
20170611 20:14:49< gfgtdf> celmin: i don't think so
20170611 20:15:26< gfgtdf> celmin: the lua state i a member of lua_map_generator class
20170611 20:15:39< celmin> If you switch to a different random map in MP Create, will it make a new Lua state?
20170611 20:16:09< gfgtdf> celmin: each map_generatoe has it own state
20170611 20:16:15< gfgtdf> celmin: just liek the default map_genereator
20170611 20:16:26< celmin> I'm not entirely sure how to interpret that statement.
20170611 20:16:52< gfgtdf> celmin: the default map genrerator also stored the generator_data (the dialog result) in the map_generator object
20170611 20:17:08< celmin> Okay sure.
20170611 20:17:29< celmin> So how does this work?
20170611 20:18:02< celmin> In MP Create specifically.
20170611 20:18:09< celmin> What's the lifetime of the Lua state?
20170611 20:20:34< vultraz_iOS> hmm
20170611 20:20:50< vultraz_iOS> I'm pondering scrapping the drawing layers interface and doing layered drawing by code order
20170611 20:20:50< celmin> vultraz_iOS: Please tell me?
20170611 20:20:57< vultraz_iOS> celmin: what?
20170611 20:20:59< vultraz_iOS> what does what work
20170611 20:21:10< gfgtdf> celmin: the mp cereate dialog has a list of (lua_)map_genereator
20170611 20:21:21< vultraz_iOS> I don't know anything about the lua map generators
20170611 20:21:22< gfgtdf> celmin: each lua_map_genereator own its own lua state
20170611 20:23:06-!- DeFender [~DeFender1@dsl217-132-1-187.bb.netvision.net.il] has joined #wesnoth-dev
20170611 20:23:07-!- DeFender [~DeFender1@dsl217-132-1-187.bb.netvision.net.il] has quit [Read error: Connection reset by peer]
20170611 20:23:27-!- DeFender [~DeFender1@dsl217-132-1-187.bb.netvision.net.il] has joined #wesnoth-dev
20170611 20:23:31< gfgtdf> celmin: hmm wait
20170611 20:23:41< celmin> gfgtdf: So if you switch away from the Lua mapgen scenario and back, the map won't be regenerated and the Lua state is the same?
20170611 20:23:55< celmin> vultraz_iOS: Well, you do know about MP Create though.
20170611 20:23:58-!- DeFender1031 [~DeFender1@93-173-5-53.bb.netvision.net.il] has quit [Ping timeout: 268 seconds]
20170611 20:24:01< vultraz_iOS> i do
20170611 20:24:29< gfgtdf> celmin: i think i may have remembered wrong
20170611 20:24:42< gfgtdf> celmin: have to look at the source
20170611 20:25:26< gfgtdf> celmin: ye seems liek rememberd it wrong
20170611 20:25:50< gfgtdf> celmin: the map_gerrnator object gets created whne you select a map generator in the list
20170611 20:26:16< gfgtdf> celmin: so settings it will not poersist if you select andother map generator and thne siwtch back
20170611 20:26:42< celmin> And what about when you click create or whatever? Does it reuse the existing object or make a new one?
20170611 20:27:04< celmin> But if you click Regenerate it does use the existing one?
20170611 20:27:07< celmin> ^reuse
20170611 20:27:17< gfgtdf> celmin: it reuses
20170611 20:27:45< celmin> Okay, so from that it almost sounds like your global variable idea would work.
20170611 20:28:01< celmin> There is still one problem I can see though… if the user never clicks settings, the variable would remain unset.
20170611 20:28:06< celmin> I guess that's solvable.
20170611 20:28:13< celmin> Still seems kinda ugly TBH.
20170611 20:28:23< celmin> But I guess it'd work.
20170611 20:28:52< gfgtdf> celmin: the lua code usr the given cfg parmaeter as a default, also note that the parmaeters woudl always be stored in a wml table object.
20170611 20:29:13< celmin> My assumption was that the user_config() call would in fact mutate the settings specified in the WML.
20170611 20:29:13< gfgtdf> or just use use other defaults when getting the prameters
20170611 20:29:30< vultraz_iOS> wait
20170611 20:29:31< vultraz_iOS> ...
20170611 20:29:38< vultraz_iOS> ~RC *is* working
20170611 20:29:43< celmin> Yay?
20170611 20:29:45< vultraz_iOS> ponder ponder
20170611 20:29:53< vultraz_iOS> perhaps this is due to my design of the texture cache
20170611 20:29:54< celmin> BTW gfgtdf 
20170611 20:30:05< celmin> We need a way to persist the mapgen settings too, I think.
20170611 20:30:10< vultraz_iOS> ponder ponder ponder
20170611 20:30:15< celmin> I think there might be an issue about that?
20170611 20:30:48< celmin> Oh BTW vultraz_iOS, does MP Create remember custom map settings?
20170611 20:30:51< gfgtdf> celmin: not that i know of sounds lieka good idea though
20170611 20:30:54< vultraz_iOS> no
20170611 20:30:57< vultraz_iOS> t that I know of
20170611 20:31:11< celmin> That's something we should do too...
20170611 20:44:28< celmin> Hmm, I thought I saw an issue about that, but I can't find it now. Maybe it was a forum post.
20170611 20:47:49< irker137> wesnoth: Celtic Minstrel wesnoth:master 5d43078ba43c / / (14 files in 4 dirs): [WIP] Implement IME support for GUI2 textboxes (#1758) https://github.com/wesnoth/wesnoth/commit/5d43078ba43c3120daddf1f07a628cffdc195b5b
20170611 20:59:21< vultraz_iOS> WIP?
20170611 21:00:01< celmin> ..
20170611 21:00:02< celmin> ...
20170611 21:00:16< celmin> I thought I removed that bit from the title, but I guess that didn't quite work.
20170611 21:00:17< celmin> Oops.
20170611 21:09:00< vultraz_iOS> S O M U H C T O D O 
20170611 21:11:04< celmin> ^C H
20170611 21:19:33< irker137> wesnoth: Charles Dang wesnoth:accelerated_rendering 77533ced0a62 / src/units/unit.cpp: Unit: fixed hp and xp colors having 0 alpha https://github.com/wesnoth/wesnoth/commit/77533ced0a623e7f93e416a6121a9cf6b50b4554
20170611 21:19:36< irker137> wesnoth: Charles Dang wesnoth:accelerated_rendering f759f67431d4 / src/ (12 files in 5 dirs): Initial refactor for main-screen accelerated rendering https://github.com/wesnoth/wesnoth/commit/f759f67431d43a8b76c576b83be321e0291973bd
20170611 21:19:46< vultraz_iOS> absolute mess :P
20170611 21:19:54< vultraz_iOS> don't bother crituquing 
20170611 21:19:57< vultraz_iOS> critiquing 
20170611 21:26:16< celmin> I wasn't planning to look at your branch at all in the near future, so...
20170611 21:37:15-!- atarocch [~atarocch@93.56.160.31] has quit [Remote host closed the connection]
20170611 21:38:44-!- moongazer [~moongazer@2405:204:918e:386b:54b:8b10:63db:74cc] has quit [Ping timeout: 246 seconds]
20170611 21:40:51< gfgtdf> celmin: do you intend to add a setting dialog to the lua cave mapgenerator ?
20170611 21:41:47-!- travis-ci [~travis-ci@ec2-54-162-102-103.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 21:41:48< travis-ci> gfgtdf/wesnoth#841 (fix_1674 - 18c6805 : gfgtdf): The build was canceled.
20170611 21:41:48< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241826100
20170611 21:41:48-!- travis-ci [~travis-ci@ec2-54-162-102-103.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 21:43:41< celmin> gfgtdf: I haven't decided if I'll add a generic cave settings dialog. I had planned to originally, but I think settings for a cave generator are more dependent on other things.
20170611 21:45:17< gfgtdf> celmin: in your pr you say you get assertion faule when your map is invalid? You remember form where? usualyl invalid mapos shouldnt give assertion failures
20170611 21:45:37< celmin> IIRC it was a Lua assertion that was failing.
20170611 21:45:48< celmin> So it doesn't crash the program or anything.
20170611 21:46:00< gfgtdf> celmin: ah ok
20170611 21:46:57< celmin> Okay, so I think [set_menu_item] needs a new key or two.
20170611 21:47:26< gfgtdf> celmin: really ?
20170611 21:47:32< gfgtdf> celmin: what did you think of ?
20170611 21:47:35< celmin> Basically, whether to trigger on keydown or keyup.
20170611 21:47:44< celmin> Or perhaps, whether to allow key-repeat.
20170611 21:48:07< celmin> Maybe both. Not entirely sure.
20170611 21:48:13< celmin> zookeeper: Any suggestiosn?
20170611 21:48:15< celmin> ^suggestiosn
20170611 21:48:18< celmin> ^suggestions
20170611 21:52:55< zookeeper> is it possible to make a menu item that only works through a hotkey? as in, doesn't show up in the context menu? if not (and i'm not entirely sure if it should be possible) then allowing key-repeat might not be a good idea.
20170611 21:53:15< celmin> Not as far as I know.
20170611 21:54:14< gfgtdf> it is posibel to have [set_menu_item] gotkey only
20170611 21:54:32< zookeeper> as for keydown or keyup, is there some legit reason why you'd want one item to work on keydown and another on keyup? in a turn-based setting it doesn't seem like something that should make a difference.
20170611 21:55:06< gfgtdf> you can iirc also for example add a new button in themewml and make that call your hotkey item.
20170611 21:55:46< zookeeper> right
20170611 21:55:48< celmin> I'm not sure, but I think there could be reasons.
20170611 21:56:11< zookeeper> well "there could be reasons but i can't think of any" sounds like a rather flimsy reason to add features
20170611 21:56:49< zookeeper> if no one's ever asked for it and no one can think of any reason to add it, then... maybe wait for either of the aforementioned to change, first? :p
20170611 21:59:14< gfgtdf> can i use make_shared from a member function if ctor is private? I mena i do have aces to it but make_shared might not have
20170611 22:00:18< celmin> Try it?
20170611 22:00:39< celmin> Could probably friend make_shared if needed.
20170611 22:17:07< gfgtdf> doen't seem to ba allowed, i'll revert that to use new
20170611 22:20:48-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 22:20:49< travis-ci> wesnoth/wesnoth#14158 (accelerated_rendering - f759f67 : Charles Dang): The build failed.
20170611 22:20:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/241822085
20170611 22:20:49-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 22:21:54-!- mjs-de [~mjs-de@x4e3110bc.dyn.telefonica.de] has quit [Remote host closed the connection]
20170611 22:22:31< vultraz_iOS> no surprise there
20170611 22:22:48< celmin> ?
20170611 22:23:04< vultraz_iOS> my branch failed
20170611 22:25:23< celmin> No, why isn't it a surprise though.
20170611 22:25:41< vultraz_iOS> everything's a mess
20170611 22:25:48< vultraz_iOS> unused parameters everywhere
20170611 22:27:09-!- vn971 [~vasya@213.87.148.247] has joined #wesnoth-dev
20170611 22:27:43< celmin> Ah.
20170611 22:32:30-!- vn971 [~vasya@213.87.148.247] has quit [Quit: Leaving.]
20170611 22:43:46< gfgtdf> is std::cout threadsafe ? maning can i use cout << somting form 2 differnt threads ?
20170611 22:45:37< celmin> I have no clue whatsoever.
20170611 22:58:40-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170611 23:03:20< irker137> wesnoth: Celtic Minstrel wesnoth:master c274e6569d01 / src/hotkey/command_executor.cpp: Fix double-showing of Lua console (addresses #1601 and #1736) https://github.com/wesnoth/wesnoth/commit/c274e6569d01b988d58a8215075b3f5c536cbc47
20170611 23:03:21< irker137> wesnoth: Celtic Minstrel wesnoth:master 5d9cd6d4851d / src/gui/core/event/handler.cpp: Fix some hotkeys not working at titlescreen (fixes #1737) https://github.com/wesnoth/wesnoth/commit/5d9cd6d4851de73e1691ea563f86ace3693a0595
20170611 23:03:23< irker137> wesnoth: Celtic Minstrel wesnoth:master 55e93059d246 / src/hotkey/hotkey_handler.cpp: Process WML menuitems only on key release (addresses #1711) https://github.com/wesnoth/wesnoth/commit/55e93059d246902f5db353a8d4346926f295d94c
20170611 23:03:26< irker137> wesnoth: Celtic Minstrel wesnoth:master ee111dbfc219 / src/generators/lua_map_generator.hpp: Fix user_config key for Lua map generators https://github.com/wesnoth/wesnoth/commit/ee111dbfc219639b069de76e4bf7343d46798dce
20170611 23:03:27< irker137> wesnoth: Celtic Minstrel wesnoth:master ea47206fc9c7 / src/gui/dialogs/story_viewer.hpp: Fix [story] not showing if all parts are conditional https://github.com/wesnoth/wesnoth/commit/ea47206fc9c7cc8d329597e83f127a7a1f20036a
20170611 23:03:29< irker137> wesnoth: Celtic Minstrel wesnoth:master 728f2972086f / src/units/unit.cpp: Fix missing XP in trait descriptions (fixes #1776) https://github.com/wesnoth/wesnoth/commit/728f2972086fd8ea53f5abdd9f23461ac708d7b4
20170611 23:03:32< irker137> wesnoth: Celtic Minstrel wesnoth:master 38b9b6dd588f / RELEASE_NOTES changelog: Update changelog and release notes https://github.com/wesnoth/wesnoth/commit/38b9b6dd588ffb188c04950ba182207a093fca53
20170611 23:03:37< celmin> Wheeee...
20170611 23:14:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20170611 23:15:47-!- Duthlet [~Duthlet@dslb-188-105-125-191.188.105.pools.vodafone-ip.de] has quit [Quit: leaving]
20170611 23:23:15< celmin> So I closed two issues and marked four ready for testing. \o/
20170611 23:29:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170611 23:29:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170611 23:42:02-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20170611 23:42:03< travis-ci> gfgtdf/wesnoth#845 (fix_1674 - 0422091 : gfgtdf): The build was canceled.
20170611 23:42:03< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/241839828
20170611 23:42:03-!- travis-ci [~travis-ci@ec2-54-204-157-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20170611 23:59:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
--- Log closed Mon Jun 12 00:00:56 2017