--- Log opened Mon Apr 09 00:00:37 2018 20180409 00:09:47< irker257> wesnoth/wesnoth:1.14 Celtic Minstrel c26c61b629 WML Unit Tests: Fix issues found by the AppVeyor: All builds passed 20180409 01:01:51<+discordbot> just how many extensions do you want to add 😐 20180409 01:07:28<+discordbot> why not just let UMC authors do it in Lua. 20180409 01:08:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 245 seconds] 20180409 01:09:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180409 01:11:24< celticminstrel> @Vultraz Say what now. 20180409 01:12:14<+discordbot> let authors do what you do with lua and format_conjunct_list 20180409 01:12:38< celticminstrel> So you're advocating against making things easier for addon authors. Got it. 20180409 01:13:00<+discordbot> or, more broadly, I don't like adding stuff like prefix and suffix, when BOTH can be done with lua, the formula= key, or probably just value = foo + $current_value 20180409 01:13:34< celticminstrel> No, I'll admit that prefix/suffix aren't actually that useful once I actually sit down to think about it. 20180409 01:14:28< celticminstrel> There's nothing inherently wrong with them being there, but in retrospect there was no need to add them. 20180409 01:15:39<+discordbot> in the list case, perhaps it's reasonable to have, but I wish we would remember that WML is, above all, a language best suited for data and not scripting or functions in general, and we should encourage more use of Lua. 20180409 01:16:25<+discordbot> We can' add a new key to s_v every time we think up a new behavior case 20180409 01:16:36<+discordbot> for example, what of the dejunct list 20180409 01:16:52< celticminstrel> What about it? 20180409 01:17:07< celticminstrel> If your supporting conjunct obviously you'd also support disjunct. 20180409 01:17:10< celticminstrel> ^you're 20180409 01:18:30<+discordbot> exactly 20180409 01:18:38<+discordbot> just like that, two more keys 20180409 01:18:47< celticminstrel> Well, it could be done in one. 20180409 01:19:14<+discordbot> and the proliferation of so many ways to do the same thing makes it harder to ever remove something because there's not just one thing to remove. 20180409 01:19:21<+discordbot> not specifically this, but in general 20180409 01:19:29< celticminstrel> I don't really understand what you're getting at there. 20180409 01:21:56<+discordbot> mostly that we consider carefully how to support each feature instead of automatically figuring out a WML counterpart. 20180409 01:22:07<+discordbot> Modders aren't stupid. 20180409 01:22:16<+discordbot> again points to Skyrim modding 20180409 01:23:27< celticminstrel> So when should we merge schema_fixes? 20180409 01:23:43< celticminstrel> Just before 1.13.14 is probably not a good idea. 20180409 01:23:53<+discordbot> Now 20180409 01:24:00< celticminstrel> That's so sudden. 20180409 01:24:11<+discordbot> You said you were done 😦 20180409 01:24:17< celticminstrel> True. 20180409 01:24:35< celticminstrel> AFAIK gfgtdf only noticed one potential OOS issue which I fixed. 20180409 01:24:53< celticminstrel> However, I'm not 100% confident in all of my changes to [side] tags in particular. 20180409 01:25:06< celticminstrel> Like removing no_leader or removing unit data or whatever. 20180409 01:25:56<+discordbot> test a few 20180409 01:26:02<+discordbot> then merge 20180409 01:27:14< celticminstrel> I don't want to test campaign stuff because I'd rather avoid too many spoilers before I've actually played them. I may have a vague idea of the events of most of the campaigns, but that's no excuse for increasing the level of spoilage. 20180409 01:27:29<+discordbot> heh 20180409 01:27:30<+discordbot> true 20180409 01:27:31<+discordbot> though 20180409 01:27:38< celticminstrel> If HTTT or DW or the beginner campaigns are among the ones that have those problems, maaaybe I could test, but... 20180409 01:27:54< celticminstrel> (FTR, the ones I class as "beginner" are TB, AOI, TSG.) 20180409 01:27:57<+discordbot> I've found once you work on the inner workings on a game you can no longer be immersed in its world and story 20180409 01:28:10< celticminstrel> (IIRC those are the only ones I've played.) 20180409 01:28:19< celticminstrel> Well, that's your problem, nothing to do with me. 20180409 01:29:18<+discordbot> 😛 20180409 01:29:23<+discordbot> well, good for you 20180409 01:29:25<+discordbot> (really) 20180409 01:43:22-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180409 01:43:28-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180409 01:48:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180409 01:48:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180409 01:58:30< irker257> wesnoth: Iris Morelle wesmere:develop a79cc1243763 / static/docroot/addons/index.xml: static: Add 1.14 add-ons index entry https://github.com/wesnoth/wesmere/commit/a79cc1243763d730565649d02ac11df980b78a54 20180409 01:58:32< irker257> wesnoth: Charles Dang wesmere:develop 8272b087aba4 / static/docroot/index.php: Updated frontpage links for 1.13.12 https://github.com/wesnoth/wesmere/commit/8272b087aba43df55a017bc0d79efb61c9c0a11f 20180409 01:58:34< irker257> wesnoth: Charles Dang wesmere:develop 56d81926b898 / static/docroot/index.php: Updated frontpage links for 1.13.13 https://github.com/wesnoth/wesmere/commit/56d81926b898c434694c7e4de69453a30381df15 20180409 02:06:39< irker257> wesnoth/wesnoth:master Celtic Minstrel 81b4ef1d7c Update changelog AppVeyor: 1/4 builds failed 20180409 02:06:40< irker257> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-2257 20180409 02:12:24< irker257> wesnoth: Iris Morelle wesmere:develop cdb027c07e76 / static/docroot/index.php wesmere/mw/skin.json wesmere/sass/_version.scss: Bump version https://github.com/wesnoth/wesmere/commit/cdb027c07e7695edd2f06a34934de6b426845abe 20180409 02:12:26< irker257> wesnoth: Iris Morelle wesmere:develop 2aa7f136408f / wesmere/sass/mw/_ui.scss: sass/mw: Hide username on the user menu when logged in on tiny viewports https://github.com/wesnoth/wesmere/commit/2aa7f136408f055693b4107aac8e7555a7b81ae4 20180409 02:17:26-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180409 02:17:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180409 02:32:28< celticminstrel> I thought something else was missing from vn971's documentation of remove_modifications (which BTW has an S on the end!) - the third parameter! 20180409 02:32:36< celticminstrel> I've updated it to add that. 20180409 02:48:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180409 03:02:31<+discordbot> celmin: but really, merge soon 20180409 03:02:34<+discordbot> it's 1 week until 1.13.14 20180409 03:04:09<+discordbot> Hm 20180409 03:04:26<+discordbot> I guess all the images need to be added to the sheet in their appropriate order... 20180409 03:04:28<+discordbot> er 20180409 03:04:42<+discordbot> appropriate size 20180409 03:41:03<+discordbot> celmin: i see nothing in the code that should cause share_vision to fail 20180409 03:43:39<+discordbot> yes, sapient? 20180409 03:45:34<+discordbot> ok then 20180409 03:45:43< celticminstrel> ??? 20180409 03:45:43<+discordbot> People typing doesn't necessarily mean anything, Vultraz. 20180409 03:45:56<+discordbot> he was typing for a long time 20180409 03:45:57<+discordbot> He's looking at Discord saying "sapient_n3t is typing" and assuming things. 20180409 03:45:59< celticminstrel> Oh, Discord has the "XYZ is typing" feature? 20180409 03:46:05<+discordbot> yes 20180409 03:46:14<+discordbot> I do it sometimes to annoy people. 20180409 03:46:17<+discordbot> :> 20180409 03:46:19< celticminstrel> Haha. 20180409 03:46:23<+discordbot> "Typing", that is. 20180409 03:46:25<+discordbot> 😊 of course I was typing because you wrote something about encouraging people to use Lua over WML 20180409 03:46:40<+discordbot> Vultraz I need to point out something with regards to #2847. 20180409 03:46:43<+discordbot> Although I agree WML tags should be extended with care since changing them later presents a maintenance burden. I don't necessarily agree with this line: "we should encourage more use of Lua" 20180409 03:47:07<+discordbot> Like I just said, I'd prefer to wait until 1.14.0 is released before looking into it because of you-know-what keeping me busy. 20180409 03:47:21<+discordbot> If someone else wants to take up the task I don't have a problem with that. 20180409 03:47:24<+discordbot> However 20180409 03:47:25< celticminstrel> Looking into what now? 20180409 03:47:39<+discordbot> I don't want anyone making major code changes after RC 3. 20180409 03:48:25<+discordbot> The period between RC 3 and gold should be as quiet as possible. If a bug fix has the slightest chance of causing issues it ought to sit in master for a while and wait for 1.14.0 to be tagged and announced before being merged into 1.14. 20180409 03:48:56<+discordbot> This is where master being completely broken works against us, because it is not possible to test a lot of things with it in that state. 20180409 03:49:13<+discordbot> the only changes I expect after RC3 are art-related 20180409 03:49:17< celticminstrel> So what about the schema_fixes branch? Do you feel it's fine to merge it now? 20180409 03:50:03< celticminstrel> And what things need to be tested on master? 20180409 03:50:13<+discordbot> Anything that needs to be tested. 20180409 03:50:16< celticminstrel> Oh, right, things that want to be merged to 1.14, right. 20180409 03:50:23< celticminstrel> <_< 20180409 03:50:33< celticminstrel> So anyway, what do you think about the schema_fixes branch? 20180409 03:50:57<+discordbot> It's a bit unfortunate that 1.14 has to bear the brunt of the master breakage but hopefully it won't be for long. 20180409 03:51:09< celticminstrel> Hopefully. 20180409 03:52:34<+discordbot> you'll probably get master back to working order within 6 months 20180409 03:52:37<+discordbot> like I said 20180409 03:52:45<+discordbot> Uhhh. 20180409 03:52:52< celticminstrel> Isn't that too long 20180409 03:52:56<+discordbot> 1.14.1 should be expected to come out in June. 20180409 03:53:10<+discordbot> Unless 1.14.0 is miraculously bug-free (unlikely). 20180409 03:53:13<+discordbot> If you want it fixed sooner than you do the work. 20180409 03:53:18<+discordbot> (celmin) 20180409 03:53:30<+discordbot> That is not a very nice thing to say. 20180409 03:53:58< celticminstrel> I was trying to decide how to say that. 20180409 03:53:59<+discordbot> Don't make me pick apart that statement because you won't like the results. 20180409 03:54:35<+discordbot> (That's for Vultraz, not celmin. It came out in the wrong order at the IRC end.) 20180409 03:55:14<+discordbot> I'm saying I can't dedicate every waking moment to fixing these issues, especially if I want to do them right and not half-assed. 20180409 03:55:44<+discordbot> So if it takes 6 months to get master in working order, then it takes 6 months. 20180409 03:55:45<+discordbot> You can put it in more polite terms that do not involve shifting onto someone else responsibility for other people's code. 20180409 03:56:01<+discordbot> *the responsibility 20180409 03:56:14<+discordbot> I suppose. 20180409 03:56:17<+discordbot> Master didn't magically become broken overnight. 20180409 03:56:19<+discordbot> Apologies. 20180409 03:56:29< celticminstrel> Yeah well, Vultraz, I'm pretty sure you have more time on your hands than most of us. 20180409 03:56:49< celticminstrel> And don't forget that it's almost entirely your fault that master was broken (a_r probably should not have been merged so soon). 20180409 03:56:50<+discordbot> In some ways. 20180409 03:59:42<+discordbot> And again, breaking maser was a deliberate decision 20180409 03:59:55< celticminstrel> I know. I still think it was the wrong decision. 20180409 04:00:36<+discordbot> I wanted to avoid dealing with worrying about compatibility with existing subsystems. 20180409 04:00:44< celticminstrel> Uh. What? 20180409 04:01:06<+discordbot> Oh, you're saying I should have done all the ripping out on a separate branch 20180409 04:01:15< celticminstrel> Normally, yes. 20180409 04:01:51<+discordbot> (You know that the fact that you simply wanted to not have to rebase a_r in parallel all the time is pretty transparent, right?) 20180409 04:02:01<+discordbot> that too. 20180409 04:02:05<+discordbot> it was so difficult. 20180409 04:03:08<+discordbot> The silver lining is that you're forcing developers to use 1.14 for the time being, which means it's better tested. 20180409 04:03:22<+discordbot> The problem is that the people working on WML and Lua API changes cannot use 1.14. 20180409 04:03:23< celticminstrel> This is true. 20180409 04:03:43< celticminstrel> Well, we can technically, as long as it's not pushed to 1.14. 20180409 04:04:03<+discordbot> Besides that, I really wanted everyone to work on this giant engine refactor 20180409 04:04:25<+discordbot> Not sit back and wait for singular devs to finish the refactor 20180409 04:04:34< celticminstrel> I don't think that's the way to get people to work on things. 20180409 04:04:45< celticminstrel> And as you can see it's not really working too well? 20180409 04:04:57<+discordbot> Yes 20180409 04:05:09<+discordbot> It's ended up as singular devs working on the refactor 😐 20180409 04:05:11<+discordbot> BUT 20180409 04:05:14<+discordbot> in fairness 20180409 04:05:41<+discordbot> you and gfgtdf are basically the only very active engine devs right now besides me and jyrki. and you're busy 20180409 04:05:42<+discordbot> so 20180409 04:06:11<+discordbot> and you did the IPF stuff 20180409 04:06:13<+discordbot> which si very good 20180409 04:06:24<+discordbot> and you're doing the schemmmmmmmmmmmma 20180409 04:06:28< celticminstrel> It's not finished though. 20180409 04:06:31< celticminstrel> The IPF stuff. 20180409 04:06:36< celticminstrel> Still need to handle texture parameters. 20180409 04:06:40<+discordbot> yes but you're working on it 20180409 04:06:42<+discordbot> I couldn't do it 20180409 04:06:49<+discordbot> that's advanced as fuck 20180409 04:06:51<+discordbot> 😛 20180409 04:07:19<+discordbot> it is a level to which I hope to one day reach but am currently not at 20180409 04:07:56<+discordbot> so technically 20180409 04:08:02<+discordbot> we're all working on the refactor 20180409 04:08:12<+discordbot> (excluding gfgtdf) 20180409 04:08:35<+discordbot> I mean, what big changes did you want to implement on master anyway that requires its stability 20180409 04:09:25< celticminstrel> [damage_type], [range], possibly [alignment] 20180409 04:09:35< celticminstrel> [special_note] / special_note= 20180409 04:10:49<+discordbot> eh? 20180409 04:10:56<+discordbot> in what context 20180409 04:10:58<+discordbot> specials? 20180409 04:11:01<+discordbot> unit types? 20180409 04:11:25< celticminstrel> All in service of allowing special notes in the unit description to be automatically generated. 20180409 04:11:43<+discordbot> huh 20180409 04:12:02< celticminstrel> This requires [damage_type] because there's a special note for arcane. 20180409 04:12:23< celticminstrel> It doesn't specifically require [range] or [alignment], admittedly, though it might be nice to have a special note for liminal. 20180409 04:15:31<+discordbot> well, all of that can be done late in the cycle 20180409 04:15:55< celticminstrel> Basically, [special_note] would go in [unit_type] in case you want to add a special note that wouldn't be automatically generated. 20180409 04:16:27< celticminstrel> special_note= would go in abilities, specials, [damage_type], [movetype], [range], [alignment], and possibly a couple of other places. 20180409 05:13:46-!- irker257 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180409 05:35:34-!- gallaecio [~quassel@57.99.79.188.dynamic.jazztel.es] has joined #wesnoth-dev 20180409 05:35:45-!- hrubymar10 [~textual@193.85.203.186] has joined #wesnoth-dev 20180409 05:40:48<+discordbot> reading that rectangle packing paper.... it looks like not all images are meant to be stored in their original orientations? 20180409 05:43:47<+discordbot> It seems the method I mentally came up with was the shelf algorithm in reverse 20180409 05:46:09-!- hrubymar10 [~textual@193.85.203.186] has quit [Quit: hrubymar10] 20180409 05:48:11-!- irker018 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180409 05:48:11< irker018> wesnoth/wesnoth:1.14 Celtic Minstrel c086f0c47f LoW: Fix translation error in conjunct l AppVeyor: All builds passed 20180409 05:49:40< celticminstrel> Well, rotation is trivial in OpenGL, so yeah it'd totally be possible to rotate them if it helped them to fit. 20180409 05:50:20<+discordbot> but then I'd need to store rotation data 20180409 05:50:27< celticminstrel> Rotation or transposition. 20180409 05:50:36< celticminstrel> Rotation is mathematically more complex, admittedly. 20180409 05:50:41<+discordbot> transposition? 20180409 05:50:47< celticminstrel> Transposition is simply switching x and y coordinates. 20180409 05:51:08<+discordbot> How in hell have I not heard this term before. 20180409 05:51:26< celticminstrel> If you place the origin in the centre of the image, transposition is a reflection through y = -x. 20180409 05:51:56< celticminstrel> Now, the origin in OpenGL is not in the centre of the image, so in OpenGL it's actually a reflection through y = 1 - x, I think. 20180409 05:52:10<+discordbot> well... 20180409 05:52:29<+discordbot> in terms of packing, the only possible rotation you would need is 90 degrees clockwise 20180409 05:52:33< celticminstrel> The term transposition is more commonly used in discrete contexts, not so often in a continuous context. 20180409 05:52:39< celticminstrel> For example, you transpose a matrix. 20180409 05:52:51< celticminstrel> Right. 20180409 05:53:08<+discordbot> so I guess a simple bool flag stored alongside its rect is enough 20180409 05:53:15< celticminstrel> And the only reason you would need that is to swap the width and height, which transposition serves equally well. Pretty sure they're not equivalent though. 20180409 05:53:40<+discordbot> I'm not covering the OGL drawing bits. 20180409 05:54:10<+discordbot> I guess I'll try Shelf Next Fit 20180409 06:02:02-!- Ivanovic [~ivanovic@p4FC53504.dip0.t-ipconnect.de] has quit [Changing host] 20180409 06:02:02-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20180409 06:14:10-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180409 06:29:53<+discordbot> @jyrkive actually, would it be more efficient to NOT rotate surfaces when packing? 20180409 06:30:10<+discordbot> it means an extra temp surface. 20180409 06:30:43<+discordbot> Packing performance shouldn't be a problem. It's the actual rendering that needs to be fast. 20180409 06:30:53<+discordbot> ok 20180409 06:31:20<+discordbot> BTW, I assume you intend to use something better than Shelf Next Fit at some point? 20180409 06:31:44<+discordbot> If you're going to implement texture packing, then I won't rewrite the algorithm. 20180409 06:32:03<+discordbot> I'm trying to. I might fail 😛 20180409 06:32:04<+discordbot> I might improve it (in particular, by sorting the rectangles first), but that's it. 20180409 07:02:27-!- vn971 [~vasya@94.158.103.15] has quit [Ping timeout: 240 seconds] 20180409 07:03:33-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev 20180409 07:33:12-!- vladimirslavik [vslavik@nat/redhat/x-hzwhxdzhxmhivwgw] has joined #wesnoth-dev 20180409 07:42:39<+discordbot> There's a grammar tag for tickets? 20180409 07:43:07<+discordbot> And it's being used in lieu of a more general prose tag. 20180409 07:46:25-!- vladimirslavik [vslavik@nat/redhat/x-hzwhxdzhxmhivwgw] has quit [Quit: Leaving] 20180409 07:46:31<+discordbot> it's new 20180409 07:46:36<+discordbot> someone must have added it today 20180409 07:47:07<+discordbot> Well I hope that someone isn't the same person who used it. 20180409 07:47:44<+discordbot> Otherwise someone's going to need to ask them to reconsider their definition of the word "grammar". 20180409 07:47:56<+discordbot> Huh, I didn't even know that non-admins can create new labels. 20180409 07:50:23<+discordbot> I added a few travis related ones a while ago 20180409 07:51:23-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has joined #wesnoth-dev 20180409 07:53:05<+discordbot> Interestingly the GH organisation audit log displays issue comment posts and edits but not the creation or editing of tags. 20180409 07:53:51<+discordbot> (Went sufficiently far back so I should've found tags I created or edited recently but nope.) 20180409 08:27:21<+discordbot> @jyrkive here's the preliminary logic: https://pastebin.com/GEAbpdYT 20180409 08:27:27<+discordbot> haven't tested yet 20180409 08:27:31<+discordbot> I just got done writing it 20180409 08:29:11<+discordbot> but would like to know what you think of it so far 20180409 08:32:26<+discordbot> Regarding "rotate the first element in row": I think the paper was supposed to say "store the first element so that the longer side is horizontal". 20180409 08:32:43<+discordbot> It doesn't make much sense to just rotate the first element unconditionally. 20180409 08:33:01<+discordbot> ...ah 20180409 08:33:02<+discordbot> true 20180409 08:33:41<+discordbot> std::max() in line 79 doesn't need to be conditional. 20180409 08:34:52< irker018> wesnoth: Sofartin wesnoth:1.14 323121d8f499 / data/core/about.cfg: Add new packager https://github.com/wesnoth/wesnoth/commit/323121d8f49951b81f9212e6e7e6efa8250025fe 20180409 08:35:05<+discordbot> Regarding the number of elements per row, the Shelf algorithm isn't supposed to limit it to the same number in each row. 20180409 08:35:24<+discordbot> Just store as many rectangles as you can, and move on to the next line when you run out of space. 20180409 08:35:49<+discordbot> I have a meeting now. I'll read the rest later. 20180409 08:35:53< irker018> wesnoth: Sofartin wesnoth:master 769f102f2ec0 / data/core/about.cfg: Add new packager https://github.com/wesnoth/wesnoth/commit/769f102f2ec0438eec714cc2d541b5d46ac3113e 20180409 08:36:29<+discordbot> well, I thought we wanted to keep them generally square 20180409 08:39:14<+discordbot> Hmmmm 20180409 08:39:22<+discordbot> Actually, just realized a few things, 20180409 08:40:04<+discordbot> Since I sort by area, the first row should usually be longest... 20180409 08:40:11<+discordbot> Ah, but I guess not necessarily 20180409 08:40:31<+discordbot> It might have really tall but narrow images 20180409 08:46:52<+discordbot> One more thing: the texture class doesn't have a constructor from a surface. The idea is to create the texture, set its size, and upload the content in separate operations. 20180409 08:47:39<+discordbot> (I'm afraid we can't fully remove support for dynamic image loading, it's just used too much. Thus, in the worst case it may be necessary to repack an already existing texture atlas.) 20180409 08:52:52-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20180409 08:55:51<+discordbot> The idea I had about "keeping texture atlas generally square" was calculating the expected size ahead of time and rounding it up. 20180409 08:58:00<+discordbot> grzywacz : https://github.com/wesnoth/wesnoth/issues/2855 20180409 08:58:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180409 09:28:50< grzywacz> noted 20180409 09:43:13<+discordbot> The Grammar tag was created before February 4th. 20180409 09:43:24<+discordbot> https://github.com/wesnoth/wesnoth/issues/2435 20180409 09:43:49<+discordbot> @jyrkive the texture class I have does have a ctor from surface... 20180409 09:43:52<+discordbot> I've renamed it to Prose. 20180409 09:48:05< Soliton> perhaps it shouldn't be red like bugs? 20180409 09:54:25<+discordbot> I was going to ask, do we have a colour-coding system for these tags, or they were just chosen randomly? 20180409 09:55:29<+discordbot> not a specific system 20180409 09:56:49-!- atarocch [~atarocch@37.177.112.57] has joined #wesnoth-dev 20180409 10:02:08<+discordbot> @Vultraz Okay, but even in that case, the texture packing system needs to be able to work with an existing texture (fully replacing its content, if necessary). 20180409 10:02:54<+discordbot> Reading the images and actual repacking can be done as a follow-up, but it doesn't make sense to create the texture in the packing code. 20180409 10:03:17<+discordbot> aghhh 20180409 10:04:51<+discordbot> I don't understand why it doesn't make sense 20180409 10:05:04<+discordbot> I'm loading all the images in any one directory into one sheet 20180409 10:05:29<+discordbot> I think loading an entire directory is quite wasteful. 20180409 10:05:57<+discordbot> It doesn't really work with UMC content, either (because they can mix mainline assets and custom assets). 20180409 10:07:01<+discordbot> wait 20180409 10:07:03<+discordbot> Also, it's possible for content to use a new IPF, and as long as we don't have the IPF-to-shader compiler, we need to add the new IPF variant of the image to the texture atlas. 20180409 10:07:11<+discordbot> ........ 20180409 10:07:20<+discordbot> ok that is way beyond what I set out to do here 😐 20180409 10:11:05<+discordbot> I was imagining constructing sheets like these at runtime: https://github.com/anura-engine/wesnoth2/blob/master/images/terrain/castle.png 20180409 10:11:35<+discordbot> So was I. 20180409 10:11:47<+discordbot> But our use case for sprite sheets is more complex. 20180409 10:12:21<+discordbot> Most games can get away with static sprite sheets, but we can't. 20180409 10:12:59<+discordbot> I'm almost tempted... 20180409 10:13:01<+discordbot> ugh 20180409 10:14:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds] 20180409 10:14:46<+discordbot> Does anyone else find it maddening that we need to jump through all these hoops 😐 20180409 10:15:37<+discordbot> As far as I'm concerned, the implementation of the low-level wrappers (out of which texture_atlas is the last and the most complex) is the easy part. 20180409 10:16:44<+discordbot> The difficult part is stopping the rendering pipeline from using assumptions which are no longer valid for hardware rendering. 20180409 10:16:54<+discordbot> I honestly wonder more and more if at some point we should say, ok, this version of wesnoth is going to use a brand new API, and everyone is going to need to adopt to it. 20180409 10:17:55<+discordbot> I think abandoning efforts of existing developers like that would be unacceptable. 20180409 10:21:07<+discordbot> I mean in reference to the UMC APIs 20180409 10:21:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180409 10:21:23<+discordbot> That's what I meant, too. 20180409 10:21:30<+discordbot> UMC developers are still developers. 20180409 10:22:43< zookeeper> scrap existing APIs and thus invalidate all existing content and you run a very real risk of basically killing the game. impossible to say how big that risk would be, of course. 20180409 10:23:40<+discordbot> It's not as if it hasn't been done. Modders had to port all their content over from Skyrim to Skyrim: Special Edition, for example 20180409 10:24:10<+discordbot> It was backed with a marketing budget of... tens of millions of dollars, I think? 20180409 10:24:40<+discordbot> Fair enough 20180409 10:25:21<+discordbot> TBH, I would not direct us down that road unless we could come up with an across-the-board, 200% better in every way, UMC dev experience. 20180409 10:25:42<+discordbot> the average user would not see the benefit of static sheets vs individual image 20180409 10:25:43<+discordbot> s 20180409 10:25:52<+discordbot> and might even find them more cumbersome to work with 20180409 10:26:15<+discordbot> For developers, individual images are easier to work with. No need to run some kind of tool to pack them. 20180409 10:26:40<+discordbot> And for users, runtime texture packing means lower VRAM usage. 20180409 10:26:53<+discordbot> The only real disadvantage is longer loading times. 20180409 10:27:32<+discordbot> but if it were coupled with other stuff like improved WML syntax, instant loading of WML changes, etc, then it could perhaps be done. 20180409 10:28:07<+discordbot> a total API switchover would be do it once, do it right, or don't do it at all 20180409 10:29:05< zookeeper> sounds a lot like that wesnoth2 thing that happened, or, well, didn't after all. 20180409 10:29:23<+discordbot> that failed for many reasons 20180409 10:29:50<+discordbot> among them discouragement on the part of dave by the largely negative reactions on the forums, especially from parties like dugi 20180409 10:29:54< zookeeper> anyway, i'm not sure what the current technical problem you were discussing seems to be 20180409 10:30:38<+discordbot> Two things in the API complicate sprite sheet handling, in particular. 20180409 10:31:16<+discordbot> First is that there is no way to know ahead of time with 100% certainty which images a scenario is going to show. 20180409 10:31:37<+discordbot> It can spawn an unexpected item in [event], for example. 20180409 10:31:46<+discordbot> The second problem is IPFs. 20180409 10:32:51<+discordbot> Even if we had the IPF-to-shader compiler, compiling a shader takes some time. There may be a notable pause when UMC uses a previously unseen IPF chain. 20180409 10:33:48<+discordbot> And as long as we don't have it, we need to cache the results of IPFs in sprite sheets - and since it's possible to run a new IPF out of nowhere, that requires support to add new images to an existing sprite sheet. 20180409 10:36:16<+discordbot> finally got my prototype in running order 20180409 10:36:45<+discordbot> it.... did not work at ALL 20180409 10:37:41<+discordbot> jesus 20180409 10:38:34<+discordbot> ah, I think I see the problem 20180409 10:40:17<+discordbot> for some reason it's creating images with MASSIVE HEIGHT 20180409 10:40:33<+discordbot> line 144x5904 😐 20180409 10:40:39<+discordbot> the hell... 20180409 10:41:24-!- atarocch [~atarocch@37.177.112.57] has quit [Remote host closed the connection] 20180409 10:42:33<+discordbot> 342x47970 P__P 20180409 10:42:48-!- atarocch [~atarocch@37.177.112.57] has joined #wesnoth-dev 20180409 10:42:58<+discordbot> how is it possible to fuck this up THAT badly 20180409 10:45:23<+discordbot> (I didn't make a typo there. It really generated an image almost 48,000 pixels high) 20180409 10:51:34<+discordbot> AH 20180409 10:51:35<+discordbot> I see the problem 20180409 10:51:45<+discordbot> I was adding up the heights of ALL the surfaces 20180409 10:52:03<+discordbot> geez 20180409 10:52:04<+discordbot> no wonder 20180409 10:53:07<+discordbot> still, not successful 20180409 10:53:28<+discordbot> What's the problem now? 20180409 10:53:36<+discordbot> example output 20180409 10:53:36<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/432855593905160203/sheet_test_1.png 20180409 10:54:11<+discordbot> lot of images seem missing.... 20180409 10:54:32<+discordbot> and it looks like I need to adopt your idea of squaring by size and not elements 20180409 10:57:58-!- atarocch [~atarocch@37.177.112.57] has quit [Ping timeout: 260 seconds] 20180409 10:58:01<+discordbot> the code finds 212 images in terrain/bridges 20180409 10:58:08<+discordbot> that does not look like 212 images in the sheet 20180409 11:02:02-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20180409 11:07:37< zookeeper> @jyrkive, those constraints of course make the sheet-related logic less efficient, but does it really make it more complicated? i mean, sounds like it'd still be a separate module that takes an image/path/IPFchain as input, loads/blits it to a suitable sheet, and spits out the resulting sheet+coordinates pair. 20180409 11:08:32<+discordbot> Those two things are why we need ability to expand sprite sheets afterwards. 20180409 11:09:01<+discordbot> It gets the most complicated if the dynamic image load causes us to exceed the sprite sheet size. 20180409 11:09:40< grzywacz> Sorry to intrude knowing so little about it, but is it possible to maintain multiple spritesheets, add images wherever there's space or add a new sprite sheet to the collection otherwise? As opposed to resizing spritesheets? 20180409 11:10:10<+discordbot> The problem is that switching between spritesheets during rendering is slow. 20180409 11:10:17< grzywacz> Ok. 20180409 11:10:32<+discordbot> Related images (e.g. all background images) should be in the same sheet if at all possible. 20180409 11:10:33< grzywacz> Is it slow in practical terms for a game like wesnoth? 20180409 11:10:37< zookeeper> would that act... yeah 20180409 11:11:10<+discordbot> Yeah, it may be that worrying about this is overkill. 20180409 11:11:38<+discordbot> In any case, I'd rather do it in the right way. Ability to resize sprite sheets isn't that much work. 20180409 11:12:07< grzywacz> thanks for context :) 20180409 11:12:12<+discordbot> And fortunately OpenGL textures are resizable. Resizing a sprite sheet doesn't even require changing texture references in sprite objects. 20180409 11:12:14<+discordbot> even with the current 1 texture per image the performance is pretty good 20180409 11:12:26<+discordbot> i doubt switching between a few sheets will be too bad 20180409 11:13:33<+discordbot> I bet it's horribly inefficient, though. 20180409 11:13:59< grzywacz> Let's not forget many people have slower GPUs than GTX 1060. ;-) 20180409 11:14:00<+discordbot> Most likely, the only reason why accelerated_rendering improved performance relative to 1.13 is because it removed the FPS cap. 20180409 11:14:20<+discordbot> yes 20180409 11:15:08<+discordbot> ahhhh here we go 20180409 11:15:09<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/432861014866788372/sheet_test_1.png 20180409 11:15:14<+discordbot> my max_width_for_this_row calculations were wrong 20180409 11:15:16<+discordbot> now it works 20180409 11:15:18<+discordbot> \o/ 20180409 11:15:35<+discordbot> Are you still using fixed number of sprites per row? 20180409 11:15:55<+discordbot> yes. I really don't know how to get rid of that. 20180409 11:16:08< grzywacz> Looks like a triangular matrix. 20180409 11:16:41<+discordbot> we don't want to keep adding sprites until we get to 8192.... 20180409 11:18:11<+discordbot> That spritesheet of yours is about 4,3 megapixels. The limit is 64 megapixels, or about 15 times the size of that sheet. 20180409 11:18:19< grzywacz> We have so many fully transparent pixels in these images.... 20180409 11:18:35<+discordbot> If necessary, we can always split things to more sheets. 20180409 11:19:33< zookeeper> added context switches because of unit sprites getting split into different sheets sounds like it wouldn't be a problem because for a single unit, you only draw one frame per turn anyway (and i'm pretty sure we discussed this before). for terrains it might be different, but considering how many terrain images you can fit into one big sheet, it sounds unlikely that it would have a measurable 20180409 11:19:33< zookeeper> performance hit. 20180409 11:20:21<+discordbot> Unit sprites at least shouldn't be a problem. They're pixel art. We should be able to easily stuff all unit sprites we need into a single sheet. 20180409 11:20:41< zookeeper> that too. 20180409 11:20:42< grzywacz> I wonder how much space would be saved (with added complexity) if we could crop the fully transparent pixels around each sprite. 20180409 11:20:52<+discordbot> (Only for the units we can encounter in the scenario. No point in loading all of Ageless Era or whatever.) 20180409 11:21:07< zookeeper> grzywacz, a lot. 20180409 11:21:21<+discordbot> Transparent pixels can't be fully cropped, but sharing them would be an option. 20180409 11:21:34<+discordbot> the anura sheets are cropped 20180409 11:21:35<+discordbot> That way the sprites would partially overlap each other. 20180409 11:21:47< grzywacz> Why they cannot be cropped? Other than positioning complexity? 20180409 11:21:52<+discordbot> but I don't know how cropping it would affect drawing 20180409 11:22:12<+discordbot> because I'm sure there some bs assumption in the code wherein the image size determines drawing origin 20180409 11:22:14<+discordbot> >_< 20180409 11:22:30< grzywacz> I don't know, like, store the x,y offset to apply for drawing on the cropped sprite? 20180409 11:22:47< grzywacz> s/on/of/ 20180409 11:23:10< grzywacz> Basically to reverse the changed caused by cropping. 20180409 11:23:12< zookeeper> letting transparent parts overlap sounds like a clever idea, though. 20180409 11:23:20< grzywacz> Note: I'm thinking out loud, not saying this should be done. ;) 20180409 11:25:24< zookeeper> anyway, also sounds a bit like premature optimization 20180409 11:25:45< grzywacz> heh, that could help even with the current 2d engine... 20180409 11:25:53<+discordbot> Right. I figure there is no need to implement it yet. 20180409 11:27:00<+discordbot> On the other hand, using the same width for every line (instead of fixed number of sprites) would be a simple optimization, and I think it's worthwhile to do immediately. 20180409 11:27:52<+discordbot> bridge sheet, transparent areas cropped 20180409 11:27:52<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/432864217930924045/sheet_test_1.png 20180409 11:28:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180409 11:29:09<+discordbot> @jyrkive ok, how do I get the right width to use per line 😐 20180409 11:29:44<+discordbot> Calculate the total area of all sprites. 20180409 11:29:50<+discordbot> Take a square root. 20180409 11:30:10<+discordbot> And finally multiply by some constant (I suggest 1,3). 20180409 11:30:48<+discordbot> 1.3? 20180409 11:31:38<+discordbot> The Shelf algorithm wastes quite a bit of space according to the paper. 20180409 11:32:21<+discordbot> Their result was that it used about 1,4 times as much space as it needed (and it was with better sorting). 20180409 11:32:49<+discordbot> On top of that, it's a good idea to reserve some more space than we initially need because sprite sheets can grow afterwards. 20180409 11:33:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20180409 11:33:15<+discordbot> Multiplying side length by 1,3 multiplies total area by 1,69, which sounds like a reasonably good multiplier to me. 20180409 11:33:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180409 11:35:55<+discordbot> list of possible side lengths for all 51 sheets I'm currently generating: possible res: 418 possible res: 2165 possible res: 3181 possible res: 817 possible res: 1547 possible res: 1220 possible res: 1469 possible res: 1398 possible res: 785 possible res: 1220 possible res: 1800 possible res: 1225 possible res: 906 possible res: 1203 possible res: 1682 possible res: 1431 possible res: 2444 possible res: 1060 possible res: 1904 20180409 11:35:55<+discordbot> possible res: 468 possible res: 1840 possible res: 2044 possible res: 842 possible res: 1202 possible res: 963 possible res: 731 possible res: 1146 possible res: 1146 possible res: 1146 possible res: 620 possible res: 529 possible res: 407 possible res: 1202 possible res: 949 possible res: 681 possible res: 3534 possible res: 916 possible res: 1310 possible res: 1554 possible res: 855 possible res: 351 possible res: 2335 possible res: 1503 20180409 11:35:56<+discordbot> possible res: 428 possible res: 835 possible res: 1503 possible res: 594 possible res: 93 possible res: 931 possible res: 420 possible res: 871 possible res: 3174 20180409 11:36:01<+discordbot> looks reasonable 20180409 11:36:07-!- irker018 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180409 11:39:19<+discordbot> 51 sheets is way too many. 20180409 11:39:38<+discordbot> But it's not really a problem right now, we can write the code to generate the sheets later. 20180409 11:39:54<+discordbot> it's generating one sheet per folder under terrains/ 20180409 11:41:04<+discordbot> The final way to generate the spritesheet (singular) would be to just look at the map and generate one sheet for all terrains which are used in it. 20180409 11:41:13<+discordbot> (Including all ToD variants.) 20180409 11:42:07<+discordbot> ToD will be handled by a shader 20180409 11:42:35<+discordbot> you forgot there's manual color adjust 20180409 11:42:51<+discordbot> I need to look closer at how ToDs are currently implemented. 20180409 11:43:21<+discordbot> But if a shader can be written with small enough effort, great. It makes it even easier to fit all necessary terrains to one sheet. 20180409 11:43:28<+discordbot> new bridge sheet, fixed width, dynamic height, transparent cropped 20180409 11:43:29<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/432868145947213834/sheet_test_1.png 20180409 11:43:47<+discordbot> (also rotation disabled) 20180409 11:43:49< grzywacz> ToD variants? Can't tod be applied as a shader pass or sth? 20180409 11:43:57< grzywacz> ah, yes, sorry 20180409 11:44:22<+discordbot> now I have a problem that it's too damn wide 😛 20180409 11:44:58< zookeeper> well you also have a problem with the images overlapping... 20180409 11:45:14<+discordbot> Well, 2165 pixels isn't really a problem. It becomes problematic if you start to approach 8192 pixels. 20180409 11:45:37<+discordbot> @zookeeper they're not overlapping? 20180409 11:45:59< zookeeper> what's that at 1700,400? 20180409 11:46:37<+discordbot> ..... 20180409 11:46:40<+discordbot> ok they'r eoverlapping 20180409 11:46:46<+discordbot> what in hell 20180409 11:49:35<+discordbot> well, at least the basic algorithm is working 20180409 11:49:57<+discordbot> I'll clean up my code and commit it (won't be wired in yet anywhere) 20180409 12:05:35-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180409 12:06:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20180409 12:30:34-!- stikonas_ is now known as stikonas 20180409 12:38:31<+discordbot> @shadowm You might want to weigh in on this: https://github.com/wesnoth/wesnoth/issues/2856 20180409 12:39:43<+discordbot> off topic: looks like that's a readme I missed when I made them all mds 20180409 12:40:09<+discordbot> I can just as well convert it to Markdown when I'm editing it anyway. 20180409 12:40:30<+discordbot> please do 20180409 12:44:18<+discordbot> but yeah, the screenshots should definitely be in png 20180409 12:44:26<+discordbot> they're small enugh 20180409 12:44:28<+discordbot> enough 20180409 12:44:37<+discordbot> I used PNG for the smaller screenshots, JPEG for larger ones. 20180409 12:44:39<+discordbot> GD DAMIT THIS O KEY >_> 20180409 12:44:45<+discordbot> pos keyboard 20180409 12:45:17<+discordbot> In desktops you can replace the keyboard without buying a whole new PC. 😛 20180409 12:45:38<+discordbot> 😒 20180409 12:46:25<+discordbot> anyway, I don't know what I did, but the overlap issue appears to be gone 20180409 12:47:31<+discordbot> No one sees any overlap? 20180409 12:47:31<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/432884263445200896/sheet_test_1.png 20180409 12:48:00<+discordbot> oh, looks like stuff's being cut off... 20180409 12:48:04<+discordbot> on the edge.. 20180409 12:48:06<+discordbot> let me check... 20180409 12:48:46<+discordbot> yeah, that's definitely cutoff.. 20180409 12:48:55<+discordbot> AGH 20180409 12:48:59<+discordbot> ok, how do I fix this... 20180409 12:49:33<+discordbot> looks like it's a 1-line fix 20180409 12:49:52<+discordbot> A quick guess: you're checking that the right edge fits to the current line, not the left, right? 20180409 12:50:54<+discordbot> yes 20180409 12:59:39-!- irker436 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180409 12:59:39< irker436> wesnoth/wesnoth:master Sofartin 769f102f2e Add new packager AppVeyor: vs2015/Release Failed 20180409 12:59:39< irker436> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-2552 20180409 13:03:17<+discordbot> ok, I see the problem 20180409 13:03:20<+discordbot> just need to shuffle some logic 20180409 13:13:40<+discordbot> drat 20180409 13:14:01<+discordbot> thaaatttt's not what I wanted to do 20180409 13:22:20<+discordbot> well. Now I can't figure out what I messed up 20180409 13:24:10<+discordbot> OH 20180409 13:24:11<+discordbot> of course 20180409 13:24:13<+discordbot> DUH 20180409 13:24:21<+discordbot> set a variable to 0 before using it 20180409 13:24:24<+discordbot> brilliant >_> 20180409 13:25:53<+discordbot> (I decided to drop the rotation completely) 20180409 13:25:54<+discordbot> Here we go 20180409 13:25:54<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/432893921782136832/sheet_test_1.png 20180409 13:26:48<+discordbot> Looks good. 👍 20180409 13:27:55<+discordbot> @jyrkive now, one last thing... I had originally intended to have largest images first, but intentionally put them last. for some reason, having them first seems to increase the final image filesize slightly. Alright if I leave them last? 20180409 13:29:10<+discordbot> (basically, for some reason my algorithm seems slightly more efficient with largest last) 20180409 13:30:23-!- vn971 [~vasya@94.158.103.15] has quit [Ping timeout: 256 seconds] 20180409 13:31:15<+discordbot> In the benchmark in that paper, the Shelf Next Fit algorithm with largest image first (SHELF-NF-DESCA-BNF) got a packing ratio of 1,465, whereas with smallest image first (SHELF-NF-ASCA-BNF) they got 1,516 (smaller is better). 20180409 13:31:32<+discordbot> But if smallest image first works better in our case, sure, go ahead. 20180409 13:33:10< Soliton> i'd check that it's not just a property of the bridge images. 20180409 13:34:32< Soliton> if i had to pack manually i'd certainly start with the big stuff so intuitively that seems like the better way to me. 20180409 13:35:32<+discordbot> It's not, I don't think. In earlier testing (with albeit buggy behavior, but with it the only variable), the > 8192 assertion would trigger on some image (not the bridge one, I think) with greater first, whilst less first would not 20180409 13:39:48<+discordbot> ok, now I just need to finalize the logic for the filepath saving... 20180409 13:43:54-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev 20180409 13:48:02<+discordbot> I think I'll use a surface -> path map, then convert that to the path -> texture/rect map 20180409 13:49:01<+discordbot> (instead of the temp surface vector) 20180409 13:49:51<+discordbot> My intention was to store the path -> sprite map as a member variable of texture_atlas, to allow looking up images by path (even though it's discouraged because it's slower than just storing a reference to the sprite directly). 20180409 13:51:15<+discordbot> We can improve upon it later. Right now these are just free-standing functions I have, after all, not even a class or integrated into the loading process. 20180409 13:53:38<+discordbot> I'm mostly doing this so you have a framework to work with 20180409 13:56:54<+discordbot> oh, hm, but I needed the vector to share the index... 20180409 13:58:17<+discordbot> ah, I see a solution 20180409 14:02:16-!- vladimirslavik [vslavik@nat/redhat/x-rhrizubuomehvnit] has joined #wesnoth-dev 20180409 14:03:33<+discordbot> ...heh. I assumed one could directly insert a pair into a map, but that's c++17 20180409 14:03:37<+discordbot> oh well, I can work around it 20180409 14:15:13-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180409 14:23:01-!- vn971 [~vasya@94.158.103.15] has quit [Quit: Leaving.] 20180409 14:24:54<+discordbot> welllllll that just broke everything again 20180409 14:26:21<+discordbot> How the hell do I keep doing this 20180409 14:50:49< irker436> wesnoth/wesnoth:1.14 Sofartin 323121d8f4 Add new packager AppVeyor: All builds passed 20180409 15:18:31<+discordbot> ah 20180409 15:21:24<+discordbot> needed a multimpa 20180409 15:30:48-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180409 15:31:39<+discordbot> sheet generation takes around 4 seconds for all the terrain images 20180409 16:01:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180409 16:02:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180409 16:04:12< irker436> wesnoth: Charles Dang wesnoth:master f7d2924b2770 / / (4 files in 3 dirs): Added initial implementation of a dynamic spritesheet generator https://github.com/wesnoth/wesnoth/commit/f7d2924b2770afbde409bb5ab17de67f95b13834 20180409 16:04:15<+discordbot> @jyrkive ^ feedback on the code appreciated 20180409 16:46:37-!- vladimirslavik [vslavik@nat/redhat/x-rhrizubuomehvnit] has quit [Quit: Leaving] 20180409 16:50:05-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has quit [Ping timeout: 265 seconds] 20180409 16:51:16<+discordbot> @jyrkive I don’t understand what you mean about a sprite, surface, string struct. Why would a sprite object be needed for an intermediate conversion type? 20180409 16:54:17-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev 20180409 16:54:18-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host] 20180409 16:54:18-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev 20180409 16:55:51<+discordbot> also, I think we both have different ideas for how this system should work... What I imagined your sprite object as as basically (optionally) a string (the path), a rect, and a texture object pointing to the sheet in memory. 20180409 16:56:15<+discordbot> Or that drawing could happen simply with the string path, due to the path/[rect, texture] map I set up 20180409 16:57:04<+discordbot> But, putting that aside for a second 20180409 16:57:07<+discordbot> That's internal 20180409 16:58:42<+discordbot> @jyrkive From the perspective of someone working with images, it seems you want no deviation from the current workflow - ie, all images are stored individually, and then the sheets become continuous pages of sprites in the order they're encountered by the game. Correct. 20180409 16:59:07<+discordbot> (and image paths continue to refer to individual images) 20180409 17:01:28<+discordbot> What confuses me (and I guess I'm not fully sure what I mean when I talk about it), is what exactly a "paradigm shift" when we talk about image management 20180409 17:02:18<+discordbot> Ie, what is is that we're thinking of that would disrupt the UMC ecosystem 20180409 17:02:28<+discordbot> you said we cannot rely on static sheets 20180409 17:02:29<+discordbot> why so? 20180409 17:03:04<+discordbot> Something the W2 demo did was construct path/rect alias maps in FSON. 20180409 17:03:18<+discordbot> wherein a string path would refer to a portion of a sheet 20180409 17:03:40<+discordbot> Why can't we do something like that? 20180409 17:04:02<+discordbot> Ie, why cannot all mainline image paths be handled by a path/rect map? 20180409 17:04:09<+discordbot> That would not break UMC 20180409 17:05:29<+discordbot> what's preventing us from using static sheets for core images 20180409 17:05:45<+discordbot> and what's preventing us from providing the tools for umc authors to generate their own sheets - ie, the tool I just wrote 20180409 17:06:00<+discordbot> wire it up to a command-line argument and bam, sheet generator 20180409 17:06:03< Soliton> i don't think he said that. what he was refering to was that it's very difficult to know what images will be needed in the texture atlas(es) for a given scenario. 20180409 17:06:45< Soliton> the spritesheet idea for image storage is an independent thing. 20180409 17:06:47<+discordbot> But isn't that impossible no matter what type of game you have? 20180409 17:07:22< Soliton> why would it be? you can just design it so you have to register all images you want to use upfront. 20180409 17:07:54<+discordbot> but that implies the sheets would be reshuffled and redesigned when a scenario changes 20180409 17:08:53< Soliton> for a different scenario you may have to create a new texture atlas, sure. 20180409 17:09:55<+discordbot> but why would you do that for static images. Just load everything via static sheets. 20180409 17:09:58< Soliton> if it'd be clear upfront you wouldn't even need to dynamically generate it though. 20180409 17:10:13<+discordbot> IPFs are a thing, yes, but they only work on static images 20180409 17:10:30<+discordbot> if you load all the static images - via sheets, you have everything you need and can cache the damn IPFs 20180409 17:10:40<+discordbot> but he says we cannot use static sheets 20180409 17:10:55<+discordbot> but I've been lying in bed pondering it and I don't understand why that is so 20180409 17:11:09< Soliton> not sure you could do that especially with some addons installed. 20180409 17:11:33< Soliton> because of the amount of images involved. 20180409 17:11:42<+discordbot> what I am proposing is giving UMC authors the tools to make their own sheets 20180409 17:12:12-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Read error: Connection reset by peer] 20180409 17:12:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180409 17:12:19<+discordbot> again, I point to skyrim or any other modded game with mesh textures. The modders have to pack them. 20180409 17:12:52<+discordbot> Why would it be unreasonable to say to UMC authors, here, use this to make your sheets, but if you don't make sheets, performance will be worse when playing your addon 20180409 17:12:53< Soliton> and that is similar to the sprite sheets you're talking about? 20180409 17:13:14< Soliton> then you have 20 addons installed now what? 20180409 17:14:55<+discordbot> yes, mesh textures are packed together in a single sheet from what I know. 20180409 17:15:00<+discordbot> what do you mean now what? 20180409 17:15:25< Soliton> do you load the sprite sheets of all addons? 20180409 17:15:50< Soliton> i can imagine that won't work. though no idea about specific numbers. 20180409 17:16:20<+discordbot> we do as we do now and load the sheets of the currently active addon 20180409 17:16:43<+discordbot> I mean, right now, we flush the image cache and reload it when reloading the cache 20180409 17:17:01<+discordbot> how is doing that to a static sheet image different? 20180409 17:17:14< Soliton> we don't use only images from the "active" addon whatever that even means. 20180409 17:17:46< Soliton> perhaps we're fairly near that with campaigns. certainly not for mp addons. 20180409 17:18:02<+discordbot> that's something that needs to be rectified. 20180409 17:18:08<+discordbot> MP basically loads everything 20180409 17:18:16<+discordbot> It's a design oversight. 20180409 17:18:32< Soliton> sure. that's not trivial to change though. 20180409 17:18:48<+discordbot> But it can be done. 20180409 17:18:54<+discordbot> But even say you don't 20180409 17:19:03<+discordbot> and you load all the sheets in the mp addon you have 20180409 17:19:13< irker436> wesnoth/wesnoth:master Sofartin 769f102f2e Add new packager AppVeyor: 1/4 builds failed 20180409 17:19:14< irker436> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-2552 20180409 17:19:29<+discordbot> say you have 50, or even 100 new sheets loaded. How is that worse than 1000 individual images I'm sure something like Ageless has? 20180409 17:20:09< Soliton> you need to compile either into a texture atlas. 20180409 17:20:44-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev 20180409 17:21:26<+discordbot> I think perhaps I've misunderstood what a "texture atlas" is... 😐 When you guys say "texture atlas" I think it's talking about individual spritesheets all loaded independently 20180409 17:21:47<+discordbot> That, ie, the bridge terrain image sheet is one "atlas" 20180409 17:21:48< Soliton> sprite sheets may make it easier to do the packing though maybe not really compared to imagebase_1,2,3,....png. 20180409 17:22:27< Soliton> is that bridge image what you mean with sprite sheets? 20180409 17:22:33<+discordbot> Yes 20180409 17:22:43< Soliton> who's going to work with that? 20180409 17:23:26< Soliton> i thought you mean sprite sheets as in the gsoc task we had or how i think frogatto for example does it. 20180409 17:23:52<+discordbot> I don't know what ashiko did or did not do. 20180409 17:24:42<+discordbot> and as for anura-related reference, I've been drawing from Wesnoth 2, which uses Anura same as Frogatto 20180409 17:25:12<+discordbot> both W2 and Frogatto have different sheet formats for units and terrains 20180409 17:25:23<+discordbot> this is an Anura unit-format sheet: https://github.com/anura-engine/wesnoth2/blob/master/images/units/drakesarbiter.png 20180409 17:25:41< Soliton> and surely neither is the same as the resulting texture atlas? 20180409 17:25:48<+discordbot> And here's W2's bridge sheet: https://github.com/anura-engine/wesnoth2/blob/master/images/terrain/bridge.png 20180409 17:26:09<+discordbot> (which I tried to emulate. Interestingly enough my result is smaller) 20180409 17:26:14<+discordbot> Maybe 20180409 17:26:24<+discordbot> That's why I'm asking what you mean when you say atlas 20180409 17:26:34<+discordbot> I thought you and jyrki meant these sheets 20180409 17:26:46< Soliton> well, the bridge image looks more like a texture atlas. 20180409 17:27:03< Soliton> but surely no artist is going to work with that. 20180409 17:27:15< zookeeper> wouldn't manual spritesheets be basically independent from the texture atlasing thing you're now working on? a manual spritesheet would still be just one image in the atlas, and individual sprites would be referenced with something very similar to ~CROP. 20180409 17:27:37< Soliton> that is what i'm trying to say, yes. 20180409 17:27:42<+discordbot> Of course not. Just as I doubt any 3D artist works directly with the final mesh texture sheets 20180409 17:27:45< zookeeper> doesn't sound like those two systems would even need to know about each other 20180409 17:28:07<+discordbot> the workflow I imagine is you work with individual images, but package them as a sheet before publishing your addon 20180409 17:28:47<+discordbot> @zookeeper if an atlas is a compilation of sheets, then yes. If that's what solition and jyrki are referring to, then I had not considered that 20180409 17:29:17< Soliton> the atlas is for efficient in memory storage. 20180409 17:29:21<+discordbot> ie, part of my confusion would then be explained. By "regenerating the atlas" you don't mean regenerating the individual sheet images. 20180409 17:29:44< Soliton> a sprite sheet would for perhaps more efficient filesystem storage and perhaps ease of use. 20180409 17:29:50< zookeeper> yes, i'm pretty sure the idea is that an atlas is a compilation of the contents of physical image files. 20180409 17:30:16<+discordbot> well, the point of the sheet is also performance-based since you avoid 1 texture per image 20180409 17:30:18< zookeeper> one image file -> one image in the atlas 20180409 17:30:25<+discordbot> yeah 20180409 17:30:31<+discordbot> so 1 big file is better than many small files 20180409 17:30:52< Soliton> you will compile a texture atlas either way. 20180409 17:30:57<+discordbot> ok 20180409 17:30:59<+discordbot> now I get it 20180409 17:31:08<+discordbot> sheets != atlas 20180409 17:31:34<+discordbot> in which case, to be clear, what I wrote today was not the atlas, but a sheet generator 20180409 17:31:38< zookeeper> depends on how the image was packed. that arbiter sheet is ridiculously inefficiently packed, for instance, and would (probably) take more space in the atlas than the frames individually. 20180409 17:31:46<+discordbot> I assume @jyrkive is working on the atlas part? 20180409 17:32:04< Soliton> that's how we use it anyway. not sure those are the exact technical terms in general. 20180409 17:32:51< Soliton> well, you did the atlas part with what you pushed today, no? 20180409 17:32:57<+discordbot> @zookeeper well, it's packed that way for a reason. In Anura, you don't specify all animation frames. You just specify the image the first frame is in, the first frame's its rectangle, the pixel padding between frames, and the number of frames 20180409 17:33:38< zookeeper> sure 20180409 17:33:46<+discordbot> @zookeeper the engine then automatically takes the contents in the rect for frame 1, shifts over the width + the padding for frame 2, and so on 20180409 17:33:56<+discordbot> each animation is therefor in one row 20180409 17:34:45< zookeeper> of course even inefficiently packed sheets are probably more efficient in terms of how much filesystem space they take up. 20180409 17:35:13< Soliton> yeah, compression should be better for related images. 20180409 17:35:40<+discordbot> Soliton: did I? What I did was gather all images in a directory, combine them into one surface (which can be written back to disk here if you want), change that image to a texture, and register the original image's file path in a map pointing to the texture (a reference to the actual texture in memory) and its rectangle in that texture 20180409 17:35:41< zookeeper> and more importantly, big blotches of empty space compress pretty well 20180409 17:36:29<+discordbot> It's a set of multiple singular sheets all indexed by their filename 20180409 17:36:55<+discordbot> in practice, there are 51 textures loaded in memory. One for each sheet 20180409 17:36:59<+discordbot> But the map I set up doesn't care 20180409 17:37:07<+discordbot> you just access it with the same filepath you always did. 20180409 17:37:33<+discordbot> (51 under the current impl for just the core terrain foldr) 20180409 17:38:22<+discordbot> So did I make both a sheet generator and a texture atlas? 20180409 17:38:49< Soliton> @Vultraz: right, that's what i'd call a texture atlas. you're trying to pack the images as best you can to save (GPU) memory. 20180409 17:39:26< Soliton> and whether those images come from individual files or sprite sheets doesn't matter. 20180409 17:40:00<+discordbot> It’s still inefficient. They’re packed in different textures by folder and many could be further combined 20180409 17:40:15< Soliton> you could also call it a sprite sheet but what we usually mean with that is what you explained above in anura. something that is convenient to use for artists. 20180409 17:40:48< Soliton> i'm sure it can be improved, yes. but it's a first step. 20180409 17:41:42< zookeeper> how is it still inefficient? just because you have 51 textures? 20180409 17:41:46<+discordbot> In any case, the idea I had was dynamically loading only the images we need, and constructing a spritesheet out of them at runtime. 20180409 17:42:05<+discordbot> It would use significantly less memory than static spritesheets constructed at build time. 20180409 17:42:19<+discordbot> Only the currently needed images would be loaded. 20180409 17:42:42< Soliton> would you load anything upfront or just as needed? 20180409 17:42:55<+discordbot> Upfront, it's much faster. 20180409 17:42:56<+discordbot> What I am proposing is not constructing the sheets at build time but relying on umc authors to optimize their work by generating them using a command line option 20180409 17:43:31<+discordbot> Your proposal was allowing optional spritesheets, right? 20180409 17:43:32< Soliton> i could imagine stuff like terrain images wouldn't be so bad to load unconditionally. 20180409 17:44:20< Soliton> you could of course also look at the map but then people do [replace_map] or whatever in a scenario... 20180409 17:44:37<+discordbot> @jyrkive optional? 20180409 17:44:41<+discordbot> In what way 20180409 17:45:00<+discordbot> I think [replace_map] is rare. Loading a couple of images in a rare situation wouldn't be a problem. 20180409 17:45:22<+discordbot> @Vultraz You seemed to mention that it wouldn't break compatibility with existing UMC. 20180409 17:45:24< Soliton> IMO the question with pre-generating the atlases is if that is really feasable or it just gets too large. 20180409 17:45:53<+discordbot> In other words, that a UMC author can pregenerate the spritesheet if he/she wants (for a faster load time), but isn't forced to. 20180409 17:46:06<+discordbot> It takes 4 or 5 seconds at startup to load all the terrain images, build the sheets, and upload the sheets to the atlas, soliton 20180409 17:46:07< Soliton> pretty sure for frogatto it's just feasable because every image does fit into one big atlas. 20180409 17:46:29<+discordbot> I think a large reason why it takes so long is that it's single-threaded. 20180409 17:46:31< Soliton> i'm not particularly uptodate on that though. 20180409 17:46:48<+discordbot> I was planning to implement multithreaded image loading soon. 20180409 17:46:57<+discordbot> @jyrkive well, yes, that’s what I was thinking, with the extra caveat that we strongly encourage them to do so because otherwise performance will be bad 20180409 17:47:30<+discordbot> The main problem with that proposal is that it's additional work. 20180409 17:47:37<+discordbot> Other than that, I have no objections. 20180409 17:47:54<+discordbot> (Additional work for us engine developers, to clarify.) 20180409 17:48:46< zookeeper> performance would only be bad if the engine didn't do any of this automatic atlasing 20180409 17:49:15<+discordbot> zookeeper: Vultraz just said "It takes 4 or 5 seconds at startup to load all the terrain images, build the sheets, and upload the sheets to the atlas" 20180409 17:49:28< zookeeper> oh right, he meant the loading, not render-time performance 20180409 17:49:43<+discordbot> I... don’t follow. I just implemented code that can be used to provide authors a tool to generate their sheets. If we then stick to 1 image 1 texture, meaning providing a static chest equals better performance, why is that more work for us? It seems like LESS work for us 20180409 17:49:55<+discordbot> ....where did chest come from 20180409 17:49:55<+discordbot> Sheet 20180409 17:50:03<+discordbot> DYAC 20180409 17:50:23< Soliton> @jyrkive: oh missed your answer.. so how do you determine what to load upfront? 20180409 17:51:42<+discordbot> That tool still hasn't been written. There would still be the task of determining the spritesheet file format, writing the code that saves sprite rectangles, and parsing that spritesheet specification. 20180409 17:52:24<+discordbot> Sure, it's not that much work. If someone else™ is willing to do it, great. 20180409 17:52:36<+discordbot> The tool isn’t written fully, yes, itd not be too hard. 20180409 17:52:43<+discordbot> ....but it’d * 20180409 17:52:49<+discordbot> I’d be willing to finish it 20180409 17:53:00<+discordbot> Soliton: it's somewhat hard, but shouldn't be impossible. 20180409 17:53:12<+discordbot> The terrain we can just see in the map. 20180409 17:53:18<+discordbot> I mean, I wrote it in the first place to save you the work of doing it 😐 20180409 17:53:41< Soliton> sure, terrain is the easy part. :-P 20180409 17:53:41< zookeeper> ...so what would happen to core images? you'd have to keep the core images in their sheeted form, and then working with them would be hellish. 20180409 17:53:54<+discordbot> Units? Look at what already exists, what can be recruited, to which units they can advance, and what's in the recall list. 20180409 17:54:50<+discordbot> Then there are also harder cases such as images, but missing something isn't the end of the world. Having to load a couple more images at runtime won't kill performance. 20180409 17:54:51<+discordbot> @zookeeper no. We’d keep the individual images, but we’d manually pack them as sheets. 20180409 17:55:07< Soliton> yeah, sounds good. 20180409 17:55:31<+discordbot> (meant "such as items") 20180409 17:57:29< zookeeper> @Vultraz, keep both in the repo, and whenever you change a single image you have to remember to run the tool to regenerate the sheet it belongs to? keep only originals in the repo, but pack them as sheets for releases? 20180409 17:58:37<+discordbot> @jyrkive IIIC this part you’re talking about is different from the storage of sheets? That is, I’m assuming you mean now assembling all the necessary images from the atlas, regardless of how they were loaded into the game? 20180409 17:58:56<+discordbot> @zookeeper I’m not sure yet. It’s something we’d have to consider. 20180409 17:59:01< zookeeper> i'd think the only realistic way is to start with all the atlasing being done transparently by the engine behind the scenes, and _then_ see what kind of performance and loading times you get in practise (couldn't the atlases be cached on disk anyway, just like configs?) and if it's not good enough, think of ways to speed it up. 20180409 17:59:27<+discordbot> @Vultraz I was answering Soliton's question "how to determine which images to load with runtime spritesheet generation" 20180409 18:00:08<+discordbot> Hmmmmmmm 20180409 18:00:17<+discordbot> OH, 20180409 18:00:22<+discordbot> zookeeper: Indeed, it would be good to see what kind of performance we'd get with multithreaded image loading. 20180409 18:00:37<+discordbot> Oh, wait. 20180409 18:00:45< zookeeper> implementing the automatic atlasing doesn't close off any doors, as that's a system you're going to have anyway. 20180409 18:00:48<+discordbot> To start with, it should be no worse than 1.14, which isn't using spritesheets either. 20180409 18:01:10<+discordbot> Ok, just let me clarify something 20180409 18:04:14<+discordbot> Under the system we have now, the first time an image is needed it is loaded from disk and added to the surface cache. There is no pre-caching. You’re proposing that all the necessary images be pre-cached at various times, but NOT to have all images loaded at game launch, and also NOT to load each image as it’s encountered, and NOT to store each image as one texture. Correct? 20180409 18:04:51<+discordbot> I probably sound dense as hell right now 20180409 18:04:55<+discordbot> >_< 20180409 18:05:54<+discordbot> Images loaded at game launch (more specifically, when loading a scenario): we load the images we believe we may need. 20180409 18:06:16<+discordbot> As images are encountered: most of them are already loaded. If something is not loaded, then we load it. 20180409 18:07:22<+discordbot> Image storage: we store images in a few sprite sheets, organized like "sprite sheet for terrains", "sprite sheet for units", etc. A texture of one image is avoided like the plague. 20180409 18:08:20<+discordbot> Ok, good. Now, about that loading. Most of the load time probably comes from loading each image and blitting them into one sheet surface. But if the images were already in a pre-compiled sheet, does that not massively sleep up loading? Because there’s no blitting, and by loading the one images you get dozens more too? 20180409 18:09:01<+discordbot> Most likely the bottleneck at loading multiple tiny images is reading them from disk. 20180409 18:09:26<+discordbot> Using a pre-compiled sheet would significantly speed up that step, yes. 20180409 18:09:38<+discordbot> Ok, great 20180409 18:09:53< Ravana_> btw, ageless has 11k image files, not 1k. If performance difference is vital enough, then I would use sheets. Currently I upload preprocessed version of its wml to performance reasons so I need to run tools on it anyways 20180409 18:10:28<+discordbot> @Ravana you could probably load improve performance by using lua 20180409 18:11:49<+discordbot> @jyrkive ok, so now let’s say we have several static sheets for various terrain types we just loaded. Would we, internally, ever want to combine those smaller sheets info a single giant sheet as a single texture? Or would each sheet remain it’s own texture 20180409 18:11:53< irker436> wesnoth: Nils Kneuper wesnoth:master fd4f36e3c93e / / (30 files in 30 dirs): updated Chinese (Simplified) translation https://github.com/wesnoth/wesnoth/commit/fd4f36e3c93ea91fb020cff998f6bf7df97eee9d 20180409 18:11:59< irker436> wesnoth: Nils Kneuper wesnoth:1.14 62ae1af4cb61 / / (32 files in 31 dirs): updated Chinese (Simplified) translation https://github.com/wesnoth/wesnoth/commit/62ae1af4cb61aa0f3927ed80ac4100582dadbff6 20180409 18:12:19< Ravana_> I don't think Lua affects loading speed enough to be useful to change 20180409 18:12:41<+discordbot> Combining smaller spritesheets into a larger one might indeed make sense depending on the circumstances. 20180409 18:13:05<+discordbot> Alright 20180409 18:13:08<+discordbot> A static spritesheet has the problem that it contains a lot of stuff you're not using, wasting memory. 20180409 18:13:32<+discordbot> If there are smaller spritesheets and you only load those you need, you use less memory. 20180409 18:13:40<+discordbot> When it comes to terrain, that’s not likely 20180409 18:13:48<+discordbot> Since those extra images are transitions and stuff 20180409 18:14:03<+discordbot> And for unit sheets, you’ll definitely want the animations... 20180409 18:14:05<+discordbot> And if you combine them together, you get rid of the cost of switching between them. 20180409 18:14:28<+discordbot> Honestly, I think we should unconditionally load all terrain sheets upfront 20180409 18:15:39<+discordbot> If you're writing a tool to generate spritesheets at build time, and we have enough memory to keep all terrains in one sheet, then it sounds good to me. 20180409 18:15:57<+discordbot> It would allow nice fast load times. 20180409 18:17:24<+discordbot> To be clear, we would certainly provide static, in-repo sheets for various terrain types. We would not construct them entirely from the single images every time you launched the game. 20180409 18:17:47<+discordbot> But I guess that’s what..... 20180409 18:17:56<+discordbot> Wamt me to close 2858? 20180409 18:17:57<+discordbot> What the hell is that issue 20180409 18:18:08<+discordbot> College kid looking for a class project, is my bet 20180409 18:18:25<+discordbot> Close it 20180409 18:18:48<+discordbot> Anyway, I was saying 20180409 18:19:13<+discordbot> Yes, I can use the code I wrote to combine the smaller sheets into larger ones 20180409 18:21:21<+discordbot> @jyrkive should we account for drivers that allow 2^14 sized textures? 20180409 18:21:33<+discordbot> Or should we always consider 2^13 the max 20180409 18:21:46<+discordbot> A fixed maximum size is best. 20180409 18:22:37<+discordbot> Otherwise we're too likely to make something that works fine with a huge texture, but crashes on PCs that don't support >8192x8192 textures. 20180409 18:24:10<+discordbot> A maximum size is also a minimum. The UMC designer will ask, "What size should I use?" and the maximum will be the answer. 20180409 18:24:32<+discordbot> Fair point 20180409 18:53:36< irker436> wesnoth: Jyrki Vesterinen wesnoth:master 134a51204b73 / doc/manual/images/ (README.md README.txt): Convert README for manual images to Markdown https://github.com/wesnoth/wesnoth/commit/134a51204b730ff2123e2af5b19f1fae58aa0515 20180409 18:54:17< irker436> wesnoth: Jyrki Vesterinen wesnoth:1.14 6ce6c89b704d / doc/manual/images/ (README.md README.txt): Convert README for manual images to Markdown https://github.com/wesnoth/wesnoth/commit/6ce6c89b704d49ccc0625f88cdc951048390dccf 20180409 18:59:48-!- gfg [~androirc@tmo-106-10.customers.d1-online.com] has joined #wesnoth-dev 20180409 20:02:06-!- octalot [~steve@213-225-13-31.nat.highway.a1.net] has joined #wesnoth-dev 20180409 20:14:20-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev 20180409 21:07:02-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180409 21:07:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds] 20180409 21:15:13-!- gallaecio_ [~quassel@57.99.79.188.dynamic.jazztel.es] has joined #wesnoth-dev 20180409 21:15:26-!- gallaecio [~quassel@57.99.79.188.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 20180409 21:33:37-!- gallaecio_ [~quassel@57.99.79.188.dynamic.jazztel.es] has quit [Remote host closed the connection] 20180409 21:54:24-!- irker436 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180409 22:18:26-!- gfg [~androirc@tmo-106-10.customers.d1-online.com] has quit [Read error: Connection reset by peer] 20180409 22:22:11-!- gfg [~androirc@134.76.63.8] has joined #wesnoth-dev 20180409 22:23:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180409 22:31:45-!- irker617 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180409 22:31:45< irker617> wesnoth/wesnoth:master Charles Dang f7d2924b27 Added initial implementation of a dynami AppVeyor: All builds passed 20180409 22:32:07-!- gfg [~androirc@134.76.63.8] has quit [Ping timeout: 256 seconds] 20180409 22:37:36-!- octalot [~steve@213-225-13-31.nat.highway.a1.net] has quit [Ping timeout: 265 seconds] 20180409 22:41:19-!- gfg [~androirc@134.76.63.8] has joined #wesnoth-dev 20180409 22:43:04-!- gfgt [~androirc@134.76.63.8] has joined #wesnoth-dev 20180409 22:46:37-!- gfg [~androirc@134.76.63.8] has quit [Ping timeout: 260 seconds] 20180409 22:48:14-!- gfgt [~androirc@134.76.63.8] has quit [Ping timeout: 265 seconds] 20180409 22:52:21-!- gfgt [~androirc@134.76.63.8] has joined #wesnoth-dev 20180409 22:56:57-!- gfgt [~androirc@134.76.63.8] has quit [Ping timeout: 240 seconds] 20180409 23:00:24-!- gfgt [~androirc@tmo-106-10.customers.d1-online.com] has joined #wesnoth-dev 20180409 23:05:40<+discordbot> I'd rather not be asked to weigh in on issues that are about to be closed @jyrkive 20180409 23:14:10-!- gfgt [~androirc@tmo-106-10.customers.d1-online.com] has quit [Remote host closed the connection] 20180409 23:15:14-!- gfgt [~androirc@tmo-106-10.customers.d1-online.com] has joined #wesnoth-dev 20180409 23:48:47-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180409 23:49:32-!- gfgt [~androirc@tmo-106-10.customers.d1-online.com] has quit [Read error: Connection reset by peer] 20180409 23:54:25-!- octalot [~steve@213-225-13-31.nat.highway.a1.net] has joined #wesnoth-dev --- Log closed Tue Apr 10 00:00:38 2018