--- Log opened Sun Jul 02 00:00:22 2017
20170702 00:12:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20170702 00:41:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 00:41:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 00:51:59-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170702 01:11:09-!- vincent_c [~bip@vcheng.org] has quit [Quit: Coyote finally caught me]
20170702 01:18:53-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20170702 01:55:00-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170702 02:22:14-!- markus_ [~mjs-de@x4e306ac2.dyn.telefonica.de] has joined #wesnoth-dev
20170702 02:23:33-!- Bonobo [~Bonobo@61.68.203.58] has joined #wesnoth-dev
20170702 02:25:19-!- mjs-de [~mjs-de@x4e3142f7.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170702 02:35:57-!- irker867 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170702 03:08:47-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170702 03:10:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170702 03:17:17-!- RatArmy_ [~ratarmy@om126161124063.8.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 03:26:16-!- RatArmy_ [~ratarmy@om126161124063.8.openmobile.ne.jp] has joined #wesnoth-dev
20170702 03:42:36-!- RatArmy_ [~ratarmy@om126161124063.8.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 03:44:41-!- RatArmy_ [~ratarmy@om126161124063.8.openmobile.ne.jp] has joined #wesnoth-dev
20170702 03:52:59-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170702 04:03:19-!- RatArmy_ [~ratarmy@om126161124063.8.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 04:12:38-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170702 05:13:43-!- aidanhs [~aidanhs@2a00:d880:6:1ad::8e27] has quit [Ping timeout: 246 seconds]
20170702 05:15:25-!- RatArmy_ [~ratarmy@om126211117180.13.openmobile.ne.jp] has joined #wesnoth-dev
20170702 05:25:13-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20170702 05:32:20-!- RatArmy_ [~ratarmy@om126211117180.13.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 05:42:43-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170702 05:53:19-!- Kwandulin [~Kwandulin@p200300760F21421E28720B72E80C7CDA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170702 07:12:36-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 07:29:06-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 08:02:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170702 08:06:56-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 08:21:58-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 08:23:34-!- moongazer [~moongazer@117.198.75.33] has joined #wesnoth-dev
20170702 08:32:48-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170702 08:32:54-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170702 08:56:41-!- markus_ is now known as mjs-de
20170702 09:22:38-!- iwaim [~iwaim@2001:2c0:40e:2002:4c30:8165:d094:3b7d] has quit [Ping timeout: 255 seconds]
20170702 09:28:19-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 09:35:46-!- iwaim [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20170702 09:52:39< DeFender1031> zookeeper, hahahaha, luck of the RNG. Personally, I tend to just change chance to hit to 100% when doing those kinds of tests.
20170702 10:06:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 10:34:52-!- universecoder [~moongazer@117.222.45.26] has joined #wesnoth-dev
20170702 10:38:05-!- moongazer [~moongazer@117.198.75.33] has quit [Ping timeout: 240 seconds]
20170702 10:38:49-!- rs_muted|2 [~kvirc@203.94.48.121] has joined #wesnoth-dev
20170702 10:46:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 10:46:38< rs_muted|2> Hello, I want to write an addon to utilize players' luck. Could please anyone tell me is it possible to read [statistics] information in save files during a game?
20170702 10:46:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 10:50:00< zookeeper> rs_muted|2, i don't think so. if you want to track players' luck, then you need to do it manually by writing events that check what the chance to hit was when there was a hit/miss, etc.
20170702 10:50:54< rs_muted|2> so you mean save files are not readable during game?
20170702 10:51:16< zookeeper> yes
20170702 10:51:48< rs_muted|2> ok, thx zookeeper.
20170702 11:01:54-!- rs_muted|2 [~kvirc@203.94.48.121] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20170702 11:08:41-!- rs_muted [~kvirc@203.94.48.121] has joined #wesnoth-dev
20170702 11:11:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 11:12:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 11:14:38-!- rs_muted [~kvirc@203.94.48.121] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20170702 11:21:42-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170702 11:49:29-!- Kwandulin [~Kwandulin@p200300760F21421E28720B72E80C7CDA.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170702 12:07:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 12:07:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 12:09:32-!- universecoder [~moongazer@117.222.45.26] has quit [Quit: Leaving]
20170702 12:30:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 12:31:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 12:41:51-!- Coffee_irc [~david@61.68.203.58] has quit [Quit: Konversation terminated!]
20170702 13:15:59-!- Kwandulin [~Kwandulin@p200300760F21421E28720B72E80C7CDA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170702 13:22:13-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170702 13:22:50< celmin> So I have ~PAL() and ~RC() working! \o/
20170702 13:22:57< celmin> Seems to be kinda inefficient though.
20170702 13:23:37< celmin> Possibly it's just slow transferring an array of 256 colors to the GPU. Might consider passing the palette as a 1D texture instead, but that makes the search a little more complicated, I think.
20170702 13:23:39< vultraz_iOS> well per-pixel checking against a palette is
20170702 13:24:01< celmin> I think it's probably not that.
20170702 13:24:10< celmin> Given that the lag occurs at startup.
20170702 13:24:40< vultraz_iOS> which do you think is a better design for a drawing queue?
20170702 13:24:43< vultraz_iOS> A: a "thing to draw" data struct that gets pushed to the queue, and the things in that object are drawn with those parameters
20170702 13:24:43< vultraz_iOS> B: Leave the drawing to individual areas of the game but pass callbacks to the queue which are called in a specific order
20170702 13:24:48< celmin> That said, there's literally nothing happening in the event loop, so who knows, maybe it could be inefficient there too.
20170702 13:25:26< celmin> (Mind you, though I say 256 colours, the magenta palette is the most commonly used and is far fewer than 256 colours.)
20170702 13:26:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 13:26:32< vultraz_iOS> been pondering this queue design for a week
20170702 13:26:36< vultraz_iOS> maybe DeFender1031 has some thoughts
20170702 13:26:48< celmin> I'm kinda unsure.
20170702 13:26:57< celmin> What would be in this "thing to draw" struct anyway?
20170702 13:27:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 13:27:39< vultraz_iOS> well, it would be a struct with at least the zorder, texture (or vector of), a source rect, a dst rect, maybe a clipping rect, maybe a viewport rect
20170702 13:28:36< vultraz_iOS> but it seems inefficient to create a new one of these every draw cycle...
20170702 13:28:43< celmin> I bet z order can be handled by passing it as the vertex z coordinate and letting OpenGL automatically determine what's hidden.
20170702 13:29:12< vultraz_iOS> not using GL right now
20170702 13:29:25< celmin> Why would it be a vector of textures?
20170702 13:29:49< celmin> BTW we really do need a texture atlas for hardware rendering, whether that's built on the fly (with a packing algorithm) or manually.
20170702 13:29:50< vultraz_iOS> probably no reason...
20170702 13:30:05< celmin> What are all these rects?
20170702 13:30:19< vultraz_iOS> the old drawing buffer thing had vector of surfaces
20170702 13:30:20< celmin> Source and dest are obvious.
20170702 13:30:40< celmin> Source is the texture coordinates, dest is the screen (vertex) coordinates. :P
20170702 13:30:49< celmin> What's the viewport rect?
20170702 13:31:25< celmin> I think having a vector of textures is a remarkably bad idea, unless you mean to bind lots of textures to the shader.
20170702 13:31:46< celmin> I know you're not using GL right now, but if the goal is to get there eventually, you should probably avoid things that would make that harder to do. :P
20170702 13:32:54< vultraz_iOS> viewport rect shifts the origin
20170702 13:33:06< celmin> Do we need that?
20170702 13:33:17< vultraz_iOS> only for GUI2 so far, and that uses drawing-to-texture
20170702 13:33:24< celmin> Hmm.
20170702 13:33:35< celmin> If all it does is shift the origin, then it doesn't need to be a rect.
20170702 13:33:38< vultraz_iOS> so that part might not go to the queue
20170702 13:33:52< celmin> Shifting the origin is a translation, and can be reduced to a single vector.
20170702 13:34:08< vultraz_iOS> well, it technically sets the drawing area
20170702 13:34:09< celmin> It only needs to be a rect if you want to also scale it.
20170702 13:34:19< celmin> Scale to fit or whatever.
20170702 13:35:00< vultraz_iOS> I feel I don't have a full grasp of the proper method of HW drawing 
20170702 13:35:26< vultraz_iOS> right now I'm using the lazy approach - call a function that calls SDL_RenderCopy a bunch of times on a bunch of things
20170702 13:35:29< vultraz_iOS> very inefficient
20170702 13:36:25< vultraz_iOS> that's done every draw cycle
20170702 13:36:44< vultraz_iOS> but I seem to have a conceptual gap when it comes to "gathering" the things to draw, and actually drawing them
20170702 13:36:47< celmin> In OpenGL you'll be drawing tons of quads, most likely. (Though for mobile support it may be preferable to use triangles; ISTR that OpenGL ES may not support quads.)
20170702 13:37:01< vultraz_iOS> I know we need to always draw everything
20170702 13:37:10< vultraz_iOS> what the hell is a quad
20170702 13:37:17< celmin> A rectangle.
20170702 13:37:23< celmin> Well.
20170702 13:37:24< vultraz_iOS> so a quadrilateral 
20170702 13:37:41< celmin> Quadrilateral, yeah. I think it works for any quad, not just rectangles.
20170702 13:37:58< celmin> Though I've never tried non-rectangles.
20170702 13:38:31< vultraz_iOS> We're getting ahead of ourselves here
20170702 13:38:36< celmin> Also, with OpenGL you probably want to use the buffer system for bulk drawing (in fact, without direct mode you probably need to do this). In theory you could probably use this to tell it to draw everything in one call.
20170702 13:38:53< vultraz_iOS> again, getting ahead of ourselves
20170702 13:38:54< celmin> Though that makes some assumptions which will probably not end up being true.
20170702 13:39:06< vultraz_iOS> can we not discuss OGL right now
20170702 13:39:19< celmin> Where were we?
20170702 13:39:36< vultraz_iOS> Ok let's back up to gathering things to draw
20170702 13:39:59< vultraz_iOS> the surface implementation of drawing drew things in a per-hex basis
20170702 13:40:06< vultraz_iOS> ie, draw the things in a hex, in a specific order
20170702 13:40:15< vultraz_iOS> Ok, set that aside.
20170702 13:40:33< vultraz_iOS> Here's something that really confuses me, especially when talking about texture atlases
20170702 13:40:41< vultraz_iOS> You have a hex map
20170702 13:40:45< vultraz_iOS> It's a bunch of hexes
20170702 13:40:50< vultraz_iOS> In a specific order
20170702 13:41:26< DeFender1031> vultraz_iOS, just popping in here for a moment, notice that you want my input, I have to run, but I'll be back in a few hours to catch up and actually chime in.
20170702 13:41:27< vultraz_iOS> Unless you have every single hex;s image in the same sheet, how do you appropriately copy the ones you need to the renderer
20170702 13:41:45< vultraz_iOS> even anura doesn't have everything in one sheet
20170702 13:42:22< celmin> I'd say you basically have two choices.
20170702 13:42:33< celmin> 1) Copy the hexes you need to one sheet.
20170702 13:42:42< celmin> 2) Do one draw operation for each sheet you have.
20170702 13:42:51< celmin> 3) Join all the sheets into one on load.
20170702 13:43:01< vultraz_iOS> 3 not viable
20170702 13:43:08< vultraz_iOS> ignore it
20170702 13:43:11< celmin> Why not? Seems viable to me.
20170702 13:43:21< vultraz_iOS> could run into max texture sizes
20170702 13:43:26< vultraz_iOS> unlikely, but still
20170702 13:43:27< celmin> Hmm, true.
20170702 13:44:17< vultraz_iOS> 2 sounds interesting...
20170702 13:44:40< vultraz_iOS> but again, how to implement that
20170702 13:44:54< vultraz_iOS> Obviosuly a sheet would need to have a record of its contents and the rects of each
20170702 13:45:03< vultraz_iOS> But how do you match those to map terrains
20170702 13:46:14< vultraz_iOS> maybe a std::map somewhere
20170702 13:46:46-!- Sp4rrowh4wk [~me@gnusrv3.epfl.ch] has left #wesnoth-dev []
20170702 13:46:53< vultraz_iOS> And then there's units
20170702 13:47:24< vultraz_iOS> do you render every single unit of a type at once?
20170702 13:47:49< celmin> Not sure. I feel like our animation system might make that difficult...
20170702 13:48:00< vultraz_iOS> how does his work with shaders?
20170702 13:48:02< vultraz_iOS> with layering?
20170702 13:48:40< vultraz_iOS> I just don't understand how this is all supposed to fit together :(
20170702 13:49:35< vultraz_iOS> you're drawing everything every frame, yes, but the backbuffer or framebuffer whatever it's called needs to be somehow composed
20170702 13:49:38< vultraz_iOS> in a certain order
20170702 13:50:01< vultraz_iOS> i thought layering meant overlapping drawing
20170702 13:50:17< celmin> Pretty much.
20170702 13:50:18< vultraz_iOS> which i guess it does with 2D 
20170702 13:50:26< vultraz_iOS> but now you say OGL can do something with it.
20170702 13:51:19< celmin> Well, admittedly this is something that I think is not typically used for 2D drawing in OpenGL, but… there's the depth buffer which it uses to eliminate primitives that are completely covered by other primitives.
20170702 13:51:38< celmin> Not sure if that works with transparency though...
20170702 13:51:45< celmin> I don't remember how it works at all.
20170702 13:52:44 * celmin is confused that the file is not being read even though it's clearly there, non-empty, and there are no errors.
20170702 13:53:11< vultraz_iOS> i just don't know where to begin here
20170702 13:53:18< vultraz_iOS> what should I be doing
20170702 13:54:00< vultraz_iOS> something tells me that creating new "drawing objects" and texture wrappers every draw cycle isn;t efficient
20170702 13:54:52< celmin> I think you should worry about functionality first and efficiency second.
20170702 13:55:19< vultraz_iOS> ..........
20170702 13:55:25< celmin> If your proposal A seems like it'll work better, implement that. Then make it efficient if necessary.
20170702 13:55:30< vultraz_iOS> I don;t know how to get the functionality 
20170702 13:55:34< vultraz_iOS> :|
20170702 13:55:36< vultraz_iOS> that's the problem
20170702 13:55:47< celmin> One example of how to make it efficient might be splice around linked lists.
20170702 13:55:51< vultraz_iOS> I need to figure out a design before i can start implementing it
20170702 13:55:55< celmin> Okay.
20170702 13:56:03< vultraz_iOS> I'm trying to talk to you to figure out a design
20170702 13:56:20< vultraz_iOS> and you're just telling me to implement the non-existent design
20170702 13:56:22< vultraz_iOS> :(
20170702 13:56:39< celmin> Passing callbacks is probably a bit less flexible… not sure if that actually matters though.
20170702 13:57:01< vultraz_iOS> I don't know,it seems like it might be more flexible...
20170702 13:57:13< vultraz_iOS> since then they could set their own clip rects or something when drawing
20170702 13:57:19< celmin> Proposals A and B both sound like the start of a design to me BTW.
20170702 13:57:42< celmin> I was thinking about flexibility in ordering, but maybe I'm wrong.
20170702 13:58:13< vultraz_iOS> well, callbacks also mean their own render calls
20170702 13:58:32< vultraz_iOS> so it won't be able to optimize with sheets later..
20170702 13:58:41< vultraz_iOS> so maybe A is better...
20170702 13:59:56< celmin> ...
20170702 14:00:06< celmin> Well. That explains that.
20170702 14:00:14< celmin> I was loading the files after they were used. >_>
20170702 14:00:52< celmin> (Which didn't error because I stored them to global variables.)
20170702 14:02:00-!- Bonobo [~Bonobo@61.68.203.58] has quit [Ping timeout: 260 seconds]
20170702 14:02:22-!- Kwandulin2 [~Kwandulin@p200300760F21425A6911B553265A06D2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170702 14:02:43-!- Kwandulin [~Kwandulin@p200300760F21421E28720B72E80C7CDA.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds]
20170702 14:05:24< vultraz_iOS> celmin: ok, so if I go with A, am I creating new queue objects every draw cycle>
20170702 14:05:26< vultraz_iOS> ?
20170702 14:05:44< celmin> I'm not sure, but it seems possible.
20170702 14:14:02< vultraz_iOS> celmin: so you think instead of calling rendercopy each time i push to queue?
20170702 14:14:11< vultraz_iOS> and then render that after everything is in
20170702 14:15:08< celmin> Rendering everything in one place doesn't seem like a bad idea, so sure?
20170702 14:17:43< zookeeper> celmin, so, i'm gonna add the delay to the [message] implementation as per https://github.com/wesnoth/wesnoth/issues/1617 unless you have better ideas.
20170702 14:18:51< zookeeper> celmin, also you seem to have touched the idle_ai-related code in the not-so-distant past, so do you have any idea whatsoever about https://forums.wesnoth.org/viewtopic.php?f=4&t=46472 ?
20170702 14:18:51< celmin> So, adding wesnoth.delay(0)?
20170702 14:19:00< celmin> That seems fine, though definitely a workaround.
20170702 14:19:01< zookeeper> yes, or 1 if 0 doesn't work
20170702 14:19:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170702 14:19:20< celmin> Does it have to be an integer?
20170702 14:19:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 14:20:10< zookeeper> of course
20170702 14:20:54< celmin> So it's broken on master?
20170702 14:21:47< zookeeper> umm... yeah that's kinda what the issue is about
20170702 14:22:21< celmin> I'm not sure why it'd be happening. I'd probably need to look at the scenario and maybe the saved game more closely.
20170702 14:23:05< zookeeper> oh you mean the other bug.
20170702 14:23:23< celmin> Oh sorry. Yeah, the idle bug.
20170702 14:23:39< zookeeper> i don't know. i think i reproduced it on master, but maybe it was 1.13.7 after all.
20170702 14:24:02< zookeeper> but now i can't reproduce it on any version, and i tried quite a few times
20170702 14:24:32< zookeeper> so, uh... <insert that one ascii smiling shrug thingy>
20170702 14:24:56< celmin> Anyway, can't talk any further right now. Heading out.
20170702 14:25:04< zookeeper> (well okay i guess it's not ascii)
20170702 14:27:41-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: Warning! 7-day exploit detected! For your health and safety, we have disabled your Internet. Please call your local Zen temple for instructions on updating your service.]
20170702 14:36:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170702 14:36:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170702 14:43:30-!- moongazer [~moongazer@117.222.45.26] has joined #wesnoth-dev
20170702 16:06:31< Ravana_> is there reason why ReplayWML tags are listed in Template:WML_Tags?
20170702 16:07:31< vultraz_iOS> hm?
20170702 16:08:06< Ravana_> I noticed that "random" links to ReplayWML page, which doesn't even have [random]
20170702 16:21:39< Ravana_> removed the 3 I noticed were not on their linked page
20170702 16:44:16-!- higgins [~higgins@68.ip-149-56-14.net] has quit [Quit: Leaving]
20170702 16:47:11-!- higgins [~higgins@68.ip-149-56-14.net] has joined #wesnoth-dev
20170702 17:05:08-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:f566:5451:dcfe:d1a] has joined #wesnoth-dev
20170702 17:10:01-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:f566:5451:dcfe:d1a] has quit [Remote host closed the connection]
20170702 17:36:04-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170702 17:46:51-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170702 17:47:50-!- Kwandulin2 [~Kwandulin@p200300760F21425A6911B553265A06D2.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170702 17:51:43-!- moongazer [~moongazer@117.222.45.26] has quit [Quit: Leaving]
20170702 18:09:43-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 276 seconds]
20170702 18:14:44-!- mjs-de [~mjs-de@x4e306ac2.dyn.telefonica.de] has quit [Remote host closed the connection]
20170702 18:44:43-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170702 19:04:05-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170702 19:08:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20170702 19:19:20-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:f566:5451:dcfe:d1a] has joined #wesnoth-dev
20170702 19:24:01-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20170702 19:28:20-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:f566:5451:dcfe:d1a] has quit [Remote host closed the connection]
20170702 19:39:38-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 19:49:34< DeFender1031> vultraz_iOS, I do, in fact, have some thoughts for you about the queue thing. Dunno if you tend to search the logs for your name, but if you do see this, ping me when you're next here. Either way, I'll try to remember to bring it up the next time you're here.
20170702 19:52:34-!- Bonobo [~Bonobo@61.68.203.58] has joined #wesnoth-dev
20170702 19:58:25-!- stikonas_ is now known as stikonas
20170702 20:18:06-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 20:24:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170702 20:25:06-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170702 20:25:15-!- mjs-de [~mjs-de@x4e306ac2.dyn.telefonica.de] has joined #wesnoth-dev
20170702 20:35:23-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 20:56:13-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 21:01:16-!- atarocch [~atarocch@93.56.160.37] has quit [Remote host closed the connection]
20170702 21:14:42-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 21:18:42-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170702 21:20:53< vultraz_iOS> *pings DeFender1031 *
20170702 21:21:10< vultraz_iOS> I don't usually check logs but I remembered to do so in this case
20170702 21:32:53< vultraz_iOS> DeFender1031: right now this is what I have for the queue item https://pastebin.com/WCzyfMtU
20170702 21:39:48-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 21:54:56-!- clavi [~clavi@185.162.248.121] has quit [Quit: ZNC - http://znc.in]
20170702 21:54:58-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 22:01:44-!- clavi [~clavi@v22017034422546657.goodsrv.de] has joined #wesnoth-dev
20170702 22:10:10-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 22:15:49< DeFender1031> hey vultraz_iOS 
20170702 22:16:44< DeFender1031> I would tend to concur with you over celmin that callbacks give you more flexibility, but sometimes it's too much and can lead to difficult to debug and fragmented code.
20170702 22:18:38< DeFender1031> Abstracting into an object can be a decent idea if all uses of whatever your abstracting share a lot of the same characteristics in ways that won't lead to essentially re-implementing the entire API you're trying to abstract badly into an object.
20170702 22:18:56< DeFender1031> Without knowing much about the specifics here, I can't tell you which method makes more sense for the moment.
20170702 22:19:35< DeFender1031> I CAN say that if you go the object route, try to keep the objects you create around in memory and re-use them as much as possible rather than recreating similar objects on each frame.
20170702 22:21:09< DeFender1031> So, for example, if you're passing an object containing texture vector as part of an animation that's happening, tie that object to the animation, and while it's running, if possible, change only the textures in the vector that have changed since the previous frame.
20170702 22:22:33< DeFender1031> Like, let's say the animation has a set of unit sprites, a projectile, and some glowy halo. if the projectile has moved since the previous frame, but the glowy halo and unit sprite are the same, then use the same object and only update the projectile's data.
20170702 22:24:01-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170702 22:25:25< DeFender1031> You may even want to build a way into the object that instead of containing a vector, you use a specially-ordered map of some sort whose keys include a name for each texture, so that they can more easily be updated in that manner.
20170702 22:29:08 * DeFender1031 isn't even sure vultraz_iOS is still actually present...
20170702 22:42:12-!- mjs-de [~mjs-de@x4e306ac2.dyn.telefonica.de] has quit [Remote host closed the connection]
20170702 22:48:23-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 22:52:25< DeFender1031> guess not. vultraz_iOS, tag! you're it!
20170702 23:01:15< vultraz_iOS> DeFender1031: back from breakfast
20170702 23:01:55< DeFender1031> Ah, time differences.
20170702 23:02:06< DeFender1031> I had midnight ice cream a couple of hours ago.
20170702 23:02:29< DeFender1031> Anyway, my thoughts so far are up there ^^^^
20170702 23:02:57< vultraz_iOS> I definitely agree I should come up with some way to keep things around
20170702 23:03:48< vultraz_iOS> Not in the old "is invalidated" system, though
20170702 23:03:58< DeFender1031> no, of course not.
20170702 23:04:10< DeFender1031> I'd reccommend one object per animation.
20170702 23:04:30< DeFender1031> (animation being loosely used here to include terrains, items, etc.)
20170702 23:04:37< DeFender1031> (even static images)
20170702 23:04:51< vultraz_iOS> That seems reasonable...
20170702 23:05:42< DeFender1031> so essentially, when you load the map, you create an object for the terrain animation for each terrain rule, and that object would stay in memory until that terrain rule no longer applied.
20170702 23:06:00< DeFender1031> or an object for each terrain rule for each hex it applies to, more likely
20170702 23:06:20< vultraz_iOS> Not sure *how* to do that, enough..
20170702 23:06:24< DeFender1031> I'd also recommend making your objects a little more opaque than they are right now.
20170702 23:06:32< DeFender1031> okay, then let's work on one issue at a time.
20170702 23:06:54< DeFender1031> somewhere in memory, there has to be some container which contains hex data, correct?
20170702 23:06:56-!- _asher_ [~asher@nat-130-245-230-152.resnet.stonybrook.edu] has joined #wesnoth-dev
20170702 23:07:01< vultraz_iOS> yes
20170702 23:07:31< DeFender1031> so I'd expand that to include, say, a vector of animation objects.
20170702 23:07:39-!- _asher_ [~asher@nat-130-245-230-152.resnet.stonybrook.edu] has quit [Client Quit]
20170702 23:07:43< DeFender1031> vector might not be the best container for that though.
20170702 23:07:52< DeFender1031> but whatever, consult the classic flowchart.
20170702 23:08:01< vultraz_iOS> the way it works right now is every frame i get a vector of images per hex
20170702 23:08:34< DeFender1031> (for reference: https://stackoverflow.com/questions/471432/in-which-scenario-do-i-use-a-particular-stl-container )
20170702 23:08:34< vultraz_iOS> if an animation advances it might give me a different image
20170702 23:08:38< vultraz_iOS> or images
20170702 23:08:40< DeFender1031> right.
20170702 23:08:58< vultraz_iOS> (that is a useful chart )
20170702 23:09:09< DeFender1031> what i'm suggesting is that instead, you have an object that represents a layer of animation.
20170702 23:09:23< DeFender1031> or not layer...
20170702 23:09:35< DeFender1031> more like... animation unit?
20170702 23:09:54< DeFender1031> not sure what the best name is, but let me try to elaborate and hopefully convey what I mean.
20170702 23:09:57< zookeeper> that's what the animated template thingy is for, surely
20170702 23:10:10< DeFender1031> zookeeper, "animated template thingy"?
20170702 23:10:16< vultraz_iOS> i know what he means
20170702 23:10:27< DeFender1031> want to explain it to me?
20170702 23:11:04< vultraz_iOS> https://github.com/wesnoth/wesnoth/blob/master/src/animated.hpp
20170702 23:11:11< vultraz_iOS> haven't really looked into functionality
20170702 23:11:47< DeFender1031> so this does appear to be a class that represents an animation unit as I described.
20170702 23:12:22< vultraz_iOS> yes
20170702 23:13:00< DeFender1031> it doesn't seem to be structured entirely sanely from an OOP point of view, but it's more or less what I'm referring to.
20170702 23:13:27< DeFender1031> Also, a lof of the stuff that's on here will have to be managed centrally from the rendering code rather than animation-by-animation.
20170702 23:13:41< vultraz_iOS> yes
20170702 23:14:31< vultraz_iOS> again, right now objects like that are just used to build image lists for terrains per frame
20170702 23:15:37< vultraz_iOS> that seems inefficient
20170702 23:17:28< DeFender1031> anyway, what I'm saying is twofold: 1. don't just create a thin struct that has raw frame data in it that every context using it will have to update manually. Instead, create a proper encapsultation. (More on that in a minute). 2. associate an instance of this encapsulation directly in memory with the relevant object to which it belongs (unit, terrain hex, item, etc.)
20170702 23:17:46< vultraz_iOS> uhhh...
20170702 23:18:26< DeFender1031> Essentially, any time you construct a unit object, or change a terrain hex, or place an item, (at least) one of these encapsulations I'm describing gets created with it.
20170702 23:18:44< DeFender1031> vultraz_iOS, I seem to have lost you somewhere. What can I clarify for you?
20170702 23:19:11< vultraz_iOS> Uh.....
20170702 23:19:26< vultraz_iOS> I'm not visualizing
20170702 23:20:04< DeFender1031> hmm... diagrams and verbal communication would definitely help here... but in the absense of that, I'll try again.
20170702 23:21:10< DeFender1031> maybe I should start first from what I'm proposing one of these encapsulations look like and work backwards?
20170702 23:22:39< vultraz_iOS> I'm not sure it's best to have different areas of the game manage their own queue objects...
20170702 23:22:45< vultraz_iOS> but i could be wrong
20170702 23:22:50< DeFender1031> I already mentioned that it seems like there should be a concept of an "animation unit". Essentially, a complete animation which is generally defined in one block of WML (so a unit [animation] would be one animation unit, as would one complete set of [terrain_graphics])
20170702 23:23:12< DeFender1031> I'm not suggesting to do that precisely.
20170702 23:23:29< vultraz_iOS> i think you misunderstand how the tg system works...
20170702 23:23:38< vultraz_iOS> but let's take the gamemap for a minute
20170702 23:23:49< DeFender1031> I'm saying that I think you need multiple layers of OOP classes here to properly encapsulate the idea.
20170702 23:23:54< vultraz_iOS> so we have our map.
20170702 23:24:01< vultraz_iOS> bunch of hexes
20170702 23:24:16< DeFender1031> right.
20170702 23:24:27< vultraz_iOS> each one has some images that need to draw there
20170702 23:24:34< vultraz_iOS> every frame
20170702 23:24:48< vultraz_iOS> let's start with "where do we get these images"
20170702 23:25:07< vultraz_iOS> by which mechanism should the renderer be told to render certain textures
20170702 23:26:54< DeFender1031> that's kind of what I'm trying to address.
20170702 23:27:21< vultraz_iOS> You
20170702 23:27:27< vultraz_iOS> Aren't really getting the point across
20170702 23:27:30< vultraz_iOS> :/
20170702 23:27:35< DeFender1031> I know. I'm sorry. I'm unused to trying to convey highly technical concepts via text-only communication...
20170702 23:27:50< vultraz_iOS> Discord has voice chat
20170702 23:28:14< vultraz_iOS> (Another reason why discord is superior! :p)
20170702 23:28:20< DeFender1031> Uh huh...
20170702 23:29:07< DeFender1031> I can't actually talk right now anyway, people sleeping.
20170702 23:30:02< DeFender1031> But let's try again. Let me describe some of what I'd think an "animation unit" encapsulation would look like, because it addresses the question you asked.
20170702 23:30:20< vultraz_iOS> The terrain builder can already return a vector of those animated<> objects
20170702 23:30:41< vultraz_iOS> Specialized for image locators
20170702 23:30:49< vultraz_iOS> Which can be used to fetch either textures or surfaces
20170702 23:31:00< DeFender1031> I would imagine that an animation unit would contain the full rules for the animation, essentially, what textures are involved, at what time interval they change, etc.
20170702 23:31:20< vultraz_iOS> So for each hex you can already get a list of those things
20170702 23:31:28< vultraz_iOS> It doesn't have the texture directly, just a locator
20170702 23:31:35< DeFender1031> same thing.
20170702 23:32:01< DeFender1031> it's essentially "the data you need to know how to display that texture"
20170702 23:32:09< vultraz_iOS> All that exists
20170702 23:32:36< DeFender1031> anyway, an animation unit would also contain the CURRENT textures being displayed.
20170702 23:32:42< vultraz_iOS> And is used to create a vector of textures every frame for every hex, foreground and background
20170702 23:33:27< vultraz_iOS> None of this is taking into account spritesheets of course :p
20170702 23:33:38< DeFender1031> what exists already may not be the best tool...
20170702 23:33:58< DeFender1031> let's not get caught in "every problem is a nail" syndrome.
20170702 23:34:06-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 23:34:10< vultraz_iOS> I'm not saying just because it exists it's best
20170702 23:35:41< DeFender1031> then can we ignore what already exists for the moment so I can attempt to explain what I'm suggesting SHOULD exist?
20170702 23:37:30< vultraz_iOS> Yes
20170702 23:37:47< vultraz_iOS> I'm just trying to explain what's there so you have a reference
20170702 23:37:51< vultraz_iOS> :(
20170702 23:37:56< DeFender1031> that's fair.
20170702 23:38:20< DeFender1031> sorry, I didn't mean that line to sound like I'm trying to shut you down.
20170702 23:38:25< DeFender1031> Just matter-of-fact.
20170702 23:40:06< vultraz_iOS> Alright let's take this from the top, then. Somehow, the renderer needs a bunch of textures to render for each hex ever frame. We've established that. We've also established there should be some sort of encapsulation of individual animations. That already exists.
20170702 23:40:31< vultraz_iOS> Now let's figure out what should exist in the middle
20170702 23:41:26< DeFender1031> anyway, I was saying, an animation unit would have the full rules for the animation, as well as a set of the textures (or texture locators for the textures) currently being displayed onscreen. Internally to that class, it would have functions which the central renderer would call, letting it know what the current timing is and passing whatever necessary data for it to update its current set of textures. The renderer would 
20170702 23:41:27< DeFender1031> know to call those because the constructor of every animation unit would send a pointer to itself to the central renderer, and likewise the destructor would remove it from the central renderer's pool. Once the update functions are complete, the renderer can then collect all the textures from all the animation units, order them properly, and render them.
20170702 23:42:25< DeFender1031> This way, things can be updated for OGL later such that there's only the update step which just updates the necessary texture and lets the graphics work themselves out.
20170702 23:42:35< vultraz_iOS> The animation unit already handles timing and everything
20170702 23:42:39< vultraz_iOS> So you're suggesting...
20170702 23:42:42< DeFender1031> Also, optimizations can be added later for ignoring offscreen hexes, etc.
20170702 23:42:57-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20170702 23:43:02< vultraz_iOS> I register these objects directly in the render queue
20170702 23:43:54< DeFender1031> Essentially yes. You'd have the handles to these objects held and accessible from the objects whose animations the represent, but you'd also register them centrally so that the renderer knows where to look.
20170702 23:44:10< vultraz_iOS> What about things like source, destination, and clip rects
20170702 23:44:39< vultraz_iOS> Those are independent of the animations themselves
20170702 23:44:55< DeFender1031> So that's what I meant by multiple levels of classes here.
20170702 23:45:15< vultraz_iOS> Ok how would that work
20170702 23:45:27< DeFender1031> I assume that each animation can exist in multiple places with a different set of rects (such as if multiple of the same kind of terrain is onscreen?)
20170702 23:45:33< vultraz_iOS> Because keep in mind destination rects are constantly changing
20170702 23:45:57< vultraz_iOS> Well the now the system is to fetch the image lists for every visible hex
20170702 23:46:52< vultraz_iOS> I probably should figure out some worldposition system...
20170702 23:47:07< vultraz_iOS> So hexes have fixed world rects and can be converted to screen rects
20170702 23:47:40< DeFender1031> Fine, but I'm trying to confirm conceptually what the current "animation unit" concept means. My current understanding is that it represents a set of animation rules for a given... something, and that multiple of those something would not each have a separate animation class created for them?
20170702 23:47:56< DeFender1031> Is that understanding correct?
20170702 23:48:36< vultraz_iOS> I don't know
20170702 23:48:42< vultraz_iOS> I think that is not true, though
20170702 23:48:55< vultraz_iOS> I'd have to check
20170702 23:49:32< DeFender1031> If not, then does it mean that every individual one of those somethings gets one of these created for it?
20170702 23:49:38-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170702 23:50:04< vultraz_iOS> It appears every single tile has its own list of animation objects
20170702 23:50:23< DeFender1031> and each one is a separate instance?
20170702 23:50:33< vultraz_iOS> Yes
20170702 23:50:37< vultraz_iOS> It looks that way
20170702 23:50:39< DeFender1031> (meaning, it's not lists with pointers to the same instance?)
20170702 23:50:41< DeFender1031> okay
20170702 23:51:20< DeFender1031> so your issue with the rects is that the animation rects will be different depending on the current scroll position of the map?
20170702 23:51:26< vultraz_iOS> I think we need to switch to a "type" system here
20170702 23:51:42< vultraz_iOS> I.e. Keep such wrappers for types of terrains
20170702 23:52:14< vultraz_iOS> But that might be problematic
20170702 23:52:25< DeFender1031> and that sticking those into the animation objects would require every single rect to have the same arithmatic operation assigned constantly to keep them up to date?
20170702 23:52:25< vultraz_iOS> Because, for example, water...
20170702 23:52:40< vultraz_iOS> If you were using one animation handler for all water the timing would look weird
20170702 23:52:56< DeFender1031> i don't think that specializing for types is a good idea... you're trying to abstract, not special case, unless I'm misunderstanding.
20170702 23:53:31< vultraz_iOS> The problem with rects is everything is in screen rects
20170702 23:53:44< vultraz_iOS> We have no world position
20170702 23:53:54-!- RatArmy_ [~ratarmy@om126212084161.11.openmobile.ne.jp] has joined #wesnoth-dev
20170702 23:54:03< DeFender1031> even without that, I think you can accomplish what you need.
20170702 23:54:04< vultraz_iOS> Besides the hex coordinates
20170702 23:54:20< vultraz_iOS> The screen coordinates for drawing a specific hex change every frame
20170702 23:54:35< DeFender1031> if there's a built-in world coordinates system, it might make sense to use that, but if not, you can emulate one.
20170702 23:55:26< DeFender1031> "The screen coordinates for drawing a specific hex change every frame" i think you mean "CAN change every frame, no? Do those coordinates change if the map's scoll position is the same as the previous frame?
20170702 23:56:20< vultraz_iOS> No
20170702 23:57:28< vultraz_iOS> But now we've getting into that camera controller I tried and failed to write
20170702 23:57:59< DeFender1031> why would the coordinates change each frame if the position is the same?
--- Log closed Mon Jul 03 00:00:23 2017