--- Log opened Tue May 28 00:00:41 2019 20190528 00:42:06-!- celmin|away is now known as celticminstrel 20190528 01:12:43< irker200> wesnoth/wesnoth:1.14 Steve Cotton 04482f313f wmllint: Handle nested events and other AppVeyor: All builds passed 20190528 03:18:42-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] 20190528 03:25:52-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20190528 04:12:56-!- irker200 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190528 04:31:14-!- irker068 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190528 04:31:14< irker068> wesnoth/wesnoth:1.14 doofus-01 695070acad portrait for mounted version of walking AppVeyor: All builds passed 20190528 04:49:52-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20190528 07:24:59<+wesdiscordbot> @Bitron are there design docs on the choice of Godot? it's more heavyweight than pure SDL, after all 20190528 07:32:11-!- irker068 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190528 07:37:36<+wesdiscordbot> does it make more sense to contribute toward Wesnoth or the rewrite? 20190528 07:47:30<+wesdiscordbot> depends on you really 20190528 07:53:57<+wesdiscordbot> @Yumi, with whom do I coordinate for a SDL2 rewrite? 20190528 07:54:43<+wesdiscordbot> shaders can be added as well after there are no more regressions 20190528 07:56:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190528 07:58:04<+wesdiscordbot> I'm also thinking about HiDPI but there's no point in adding it to the sdl1 code :| 20190528 08:03:01-!- irker828 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190528 08:03:01< irker828> wesnoth/wesnoth:1.14 doofus-01 e9e1404304 some quick image clean-up AppVeyor: All builds passed 20190528 08:08:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190528 08:38:43< Soliton> what do you mean with sdl1 code? 20190528 08:40:29<+wesdiscordbot> just wondering if anyone has been on the forum and seen this thread https://forums.wesnoth.org/viewtopic.php?f=9&t=49376 if you have any suggestions for sprites that need a new one entirely, just ask. I also need more opinions in general 20190528 08:51:58<+wesdiscordbot> Soliton, it was written that sdl1 needs to go due to being obsolete 20190528 08:52:19<+wesdiscordbot> and something about the inability to use shaders, IIRC 20190528 08:55:16< Soliton> wesnoth depends on sdl2 for a while now. 20190528 08:58:03<+wesdiscordbot> I dont work on the engine so I don't really know what sdl2 is 20190528 08:58:39< Soliton> the successor of sdl1. :-P 20190528 08:58:47<+wesdiscordbot> 😂 20190528 08:59:19<+wesdiscordbot> @Lordlewis give me a few days and I'll try to find some things for you 20190528 08:59:31<+wesdiscordbot> some day XD 20190528 09:00:32<+wesdiscordbot> the thing is I'm definitely not nearly as good as jetrel or doofus or lordbob at sprites so I dont feel comfortable going for adding core unit sprites 20190528 09:01:15<+wesdiscordbot> however for campaigns, theres probably some sprites that we can add (e.g. the masked dwarves that you did) that I feel fine making the decision on 20190528 09:01:28<+wesdiscordbot> yeah I know how you feel 20190528 09:01:41<+wesdiscordbot> cause for mainline it has to be very good 20190528 09:04:10<+wesdiscordbot> certainly mainline has dated sprites, but some of the newer ones are actually crazy good 20190528 09:04:26<+wesdiscordbot> and I think that's the new quality we're going for 20190528 09:04:35<+wesdiscordbot> so yeah, not easy to do at all 20190528 09:04:38-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20190528 09:05:05< Soliton> @sthalik if you want to work on moving wesnoth to opengl you could look at the opengl branch and talk to jyrkive. otherwise if you want to work on opengl/shaders look at the rewrite. 20190528 09:10:38<+wesdiscordbot> yeah I'd agree, I need to up my game 20190528 10:34:53<+wesdiscordbot> mad respect for doing sprites in present times 20190528 11:00:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190528 11:03:02-!- irker828 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190528 11:47:01<+wesdiscordbot> @sthalik indeed, Godot does have a few downsides (lest of all that sadly its own source code is an absolute horrific mess), but continuing with a completely custom engine has a lot of maintenance costs. 20190528 11:47:38<+wesdiscordbot> at what point does it become worth it to reimplement the same basic stuff every game engine can already do? 20190528 11:48:10<+wesdiscordbot> Godot also has a great front-end editor (great front-end, shitty backend, go figure 😂 : ) 20190528 11:48:32<+wesdiscordbot> @Vultraz there's the possibility of using an "engine" for UI and other minutiae, while keeping traditional logic and game viewport 20190528 11:48:49<+wesdiscordbot> traditional logic? 20190528 11:49:05<+wesdiscordbot> I've read some godot renderer backend code, it's horrible 20190528 11:49:28<+wesdiscordbot> in what way? 20190528 11:49:37<+wesdiscordbot> inefficient 20190528 11:49:39<+wesdiscordbot> some underscore-prefixed functions that really don't belong there 20190528 11:50:17<+wesdiscordbot> because of shitty design decisions like copy-on-write vectors and not using the STL. 20190528 11:50:30<+wesdiscordbot> oh, and linked lists all over the place 20190528 11:50:34<+wesdiscordbot> 🙄 20190528 11:50:43<+wesdiscordbot> so many linked lists 20190528 11:50:57<+wesdiscordbot> core container types implemented with mutable 20190528 11:51:04<+wesdiscordbot> reinterpret_cast thrown around like 500 times 20190528 11:51:56<+wesdiscordbot> sounds gnarly 20190528 11:52:07<+wesdiscordbot> though mutable might be warranted 20190528 11:52:15<+wesdiscordbot> if you're implementing something like caching 20190528 11:52:59<+wesdiscordbot> cpp _FORCE_INLINE_ uint32_t *_get_size() const { if (!_ptr) return NULL; return reinterpret_cast(_ptr) - 1; } 20190528 11:52:59<+wesdiscordbot> like 20190528 11:53:00<+wesdiscordbot> like if you know for sure that particular member exists only to cache some result 20190528 11:53:01<+wesdiscordbot> what even is this 20190528 11:53:52<+wesdiscordbot> subtracting 1 from a pointer sounds dangerous 20190528 11:54:27<+wesdiscordbot> ah, but it's proceeded by... 20190528 11:54:31<+wesdiscordbot> cpp _FORCE_INLINE_ uint32_t *_get_refcount() const { if (!_ptr) return NULL; return reinterpret_cast(_ptr) - 2; } 20190528 11:54:32<+wesdiscordbot> ^_^ 20190528 11:54:52<+wesdiscordbot> probably ptr _ - 1 has a size, like operator new[] 20190528 11:54:56<+wesdiscordbot> minus two 20190528 11:55:21<+wesdiscordbot> I have nothing against COW strings 20190528 11:55:27<+wesdiscordbot> anyway I agree that doing pointer arithmetic like that is a cowboy way of doing things 😛 20190528 11:55:56<+wesdiscordbot> I'm told the use of linked lists everywhere in the engine is a cause of massive performance loss 20190528 11:56:04<+wesdiscordbot> I'm more concerned about the leading underscore being UB than anything else in this code 🐱 20190528 11:56:15<+wesdiscordbot> hm? 20190528 11:56:21<+wesdiscordbot> what about leading underscores? 20190528 11:56:37<+wesdiscordbot> identifier cannot begin with an underscore or contain twice in a row 20190528 11:56:54<+wesdiscordbot> twice of what? 20190528 11:57:02<+wesdiscordbot> two* underscores in a row 20190528 11:57:08<+wesdiscordbot> since when 20190528 11:57:10<+wesdiscordbot> :thonk: 20190528 11:57:18<+wesdiscordbot> macro identifier? or a variable identifier 20190528 11:57:19<+wesdiscordbot> ? 20190528 11:57:22<+wesdiscordbot> thou spoketh The Language Spec 20190528 11:57:25<+wesdiscordbot> I vaguely remember something about that 20190528 11:57:33<+wesdiscordbot> any arbitrary identifier 20190528 11:57:39<+wesdiscordbot> ....huh 20190528 11:57:54<+wesdiscordbot> didn't know this 20190528 11:58:02<+wesdiscordbot> I think things with _ were reserved for compiler intrinsics and stuff 20190528 11:58:39<+wesdiscordbot> le facepalm 2x combo 20190528 11:59:13<+wesdiscordbot> why does godot's editor have to be so good while the implementation so bad 😦 20190528 11:59:25<+wesdiscordbot> is unity's code so messy? just for reference 20190528 11:59:46<+wesdiscordbot> I'd go for a pointer to c++ struct foo { unsigned char tag; unsigned char data[0]; }; 20190528 11:59:54<+wesdiscordbot> and before asks, it's perfectly correct code :) 20190528 12:00:08<+wesdiscordbot> how do you indicate a language in discord markdown? 20190528 12:00:48<+wesdiscordbot> triple ` are reserved for code blocks 20190528 12:00:53<+wesdiscordbot> did you use this? 20190528 12:01:07<+wesdiscordbot> I kinda expect it to have autodetection 20190528 12:01:37<+wesdiscordbot> yeah 20190528 12:01:42<+wesdiscordbot> it's cpp 20190528 12:01:57<+wesdiscordbot> thanks! 20190528 12:02:07<+wesdiscordbot> lousy discord, "cpp" is the preprocessor 20190528 12:03:01<+wesdiscordbot> im not sure what that code of yours does 20190528 12:03:26<+wesdiscordbot> array of size 0? 20190528 12:03:33<+wesdiscordbot> works around the pointer arithmetic issue you discossed 20190528 12:03:33<+wesdiscordbot> that's for bitfields 20190528 12:04:06<+wesdiscordbot> size 0 is to refer to its address 20190528 12:04:23<+wesdiscordbot> it will be address past the end? 20190528 12:04:30<+wesdiscordbot> yes, no indirection 20190528 12:04:51<+wesdiscordbot> and with size 0 the compiler "knows" not to mess around with strict aliasing 20190528 12:05:12<+wesdiscordbot> Anyway I wouldn't ever make my own linked list 20190528 12:05:19<+wesdiscordbot> would use std::set etc 20190528 12:05:22<+wesdiscordbot> or use them everywhere 20190528 12:05:26<+wesdiscordbot> for everything 20190528 12:05:39<+wesdiscordbot> evil std::set and std::unordered_map are slow 20190528 12:05:41<+wesdiscordbot> I was told linked lists as dynamic arrays were very common 20190528 12:05:54<+wesdiscordbot> Like I have more fun things to do than to debug my derps with pointer arithmetic 20190528 12:06:05<+wesdiscordbot> there are several thousand uses of the custom linked list 20190528 12:06:15<+wesdiscordbot> (though that code above was from the custom vector impl) 20190528 12:06:26<+wesdiscordbot> anyway, they don't use the STL 20190528 12:06:28<+wesdiscordbot> I bet you're gonna maintain a godot fork for haldric 20190528 12:06:37<+wesdiscordbot> because the lead dev has some weird hangup about it making binary sizes larger 20190528 12:06:38<+wesdiscordbot> I think 20190528 12:06:46<+wesdiscordbot> like openmw does with osg 20190528 12:07:01<+wesdiscordbot> it does? 20190528 12:07:01<+wesdiscordbot> meh, just use -flto on stdlib 20190528 12:07:04<+wesdiscordbot> that's not optimal 20190528 12:07:14<+wesdiscordbot> a fork 20190528 12:07:15<+wesdiscordbot> why did they fork osg? 20190528 12:07:26<+wesdiscordbot> yes, also a lead osg fork-dev quit and it takes forever to do anything osg-related 20190528 12:07:54<+wesdiscordbot> perf-related, they do insane draw distances 20190528 12:08:26<+wesdiscordbot> It seems you are a very experienced C++ dev 20190528 12:08:33<+wesdiscordbot> (I say this with no sarcasm ftr) 20190528 12:08:42<+wesdiscordbot> once you use an "engine" you're gonna mess around its clunky abstractions rather than do the right thing 20190528 12:09:17<+wesdiscordbot> though openmw is special case 20190528 12:09:23<+wesdiscordbot> well, thanks. hopefully I'm gonna do something fun with your project! 20190528 12:09:24<+wesdiscordbot> they have an existing game to implement 20190528 12:09:42<+wesdiscordbot> I talked to a dev for closed-source AOD 20190528 12:10:04<+wesdiscordbot> completely new game would have an option of scaling down with draw distance and scene complexity 😛 20190528 12:10:24<+wesdiscordbot> he had the same "engine" problems. I said, "why not downsample the rendertarget and blur it" for simple soft shadows... he said that in the "engine" it's all different and he can't do that 20190528 12:10:37< Soliton> (leading underscore is not UB. leading underscore + upper case letter is reserved though.) 20190528 12:10:50<+wesdiscordbot> @loonycyborg then try do that in OSG 20190528 12:10:57-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20190528 12:11:47<+wesdiscordbot> thing is 20190528 12:11:49<+wesdiscordbot> I remember about them changing ogre to osg 20190528 12:11:57<+wesdiscordbot> as bad as godot's code is stuff does get implemented quickly 20190528 12:11:57<+wesdiscordbot> due to performance considerations 20190528 12:12:03<+wesdiscordbot> seems even that wasn't enough 20190528 12:12:12<+wesdiscordbot> and they have a very large and growing community of contributors 20190528 12:12:37<+wesdiscordbot> trying to constantly sync a fork with upstream would be madness 20190528 12:12:47-!- celticminstrel is now known as celmin|away 20190528 12:12:48<+wesdiscordbot> and any significant alteration to the mess would make that impossible 20190528 12:13:01<+wesdiscordbot> for me it's scary having an untyped scripting language designed specifically within Godot 20190528 12:13:15< celmin|away> "as bad as godot's code is" ... ... ... 20190528 12:14:29<+wesdiscordbot> yes celmin 20190528 12:14:32<+wesdiscordbot> have your laughs 20190528 12:14:38<+wesdiscordbot> har har har 20190528 12:14:47<+wesdiscordbot> meh people really like to get nitpicky about code 20190528 12:15:10< celmin|away> On a different note, why so much hate for untyped scripting languages? 20190528 12:15:17<+wesdiscordbot> @sthalik we were planning on switching to C# down the line a bit 20190528 12:15:31< celmin|away> There are genuine advantages to duck-typing. 20190528 12:15:38<+wesdiscordbot> over gdscript 20190528 12:15:54<+wesdiscordbot> yes you can do something like 5 + "foo" and not get a compile error 20190528 12:16:09<+wesdiscordbot> also gdscript got optional static typing in 3.1 20190528 12:16:12< celmin|away> I mean, I think godot is silly for inventing their own language, but that's on a "reinventing the wheel" reasoning, not the fact that it's untyped. 20190528 12:16:52< celmin|away> (Also on a wild tangent, why don't more languages implement transitive comparison operators like Python does!?) 20190528 12:17:06<+wesdiscordbot> I'm scared here of the language's accessibility and what it does to correctness. it sounds very elitist but there should be some barrier of entry 20190528 12:18:00< celmin|away> 5 + "foo" would still be an error (unless it's like JavaScript with implicit coercions) 20190528 12:18:00<+wesdiscordbot> raises eyebrow 20190528 12:18:05< celmin|away> Just not at compile time. 20190528 12:18:17<+wesdiscordbot> iirc that could be done in lua 20190528 12:18:22<+wesdiscordbot> wish Python had user-defined operators 20190528 12:18:30< celmin|away> ... 20190528 12:18:35< celmin|away> Uh sthalik 20190528 12:18:44< celmin|away> Python does have operator overloading 20190528 12:18:52<+wesdiscordbot> yup 20190528 12:18:54< celmin|away> ...or wait 20190528 12:18:56<+wesdiscordbot> yes, but only predefined operators 20190528 12:19:01< celmin|away> Do you mean defining... ah, right, right 20190528 12:19:06< celmin|away> Yeah that would be cool. 20190528 12:19:13<+wesdiscordbot> you mean like in haskell? 20190528 12:19:22<+wesdiscordbot> you can easily make operator $$$ there 20190528 12:19:36< celmin|away> Python does at least have a variadic indexing operator, unlike C++ >_> 20190528 12:19:51<+wesdiscordbot> @loonycyborg yeah 20190528 12:20:17<+wesdiscordbot> I thought you could do variadic indexing 20190528 12:20:19<+wesdiscordbot> 🤔 20190528 12:20:20<+wesdiscordbot> but most of all I wish C++ had pattern matching 20190528 12:20:20<+wesdiscordbot> this is cool but mostly useful for obfuscated code contests 20190528 12:20:31< celmin|away> @Vultraz I mean like a[x,y] 20190528 12:20:55< celmin|away> You can do it in C++ using the function-call operator, as a(x,y), but not with the indexing operator. 20190528 12:21:14< celmin|away> @loonycyborg - No it's required for numpy 20190528 12:21:20<+wesdiscordbot> technically you can return a constexpr rvalue ref and it's gonna get optimized to nothing in xy 20190528 12:22:04< celmin|away> Which even allows constructs like a[x1, x2, ..., xn] IIRC, though I've not used it much so I could be remembering wrong 20190528 12:22:04<+wesdiscordbot> I mean haskell's fully custom operators 20190528 12:22:16< celmin|away> Oh, right. 20190528 12:22:25< celmin|away> Well, it'd prolly also be useful for something like numpy tho 20190528 12:22:39< celmin|away> You could define various matrix multiplications as different operators, for example. 20190528 12:22:56<+wesdiscordbot> hmm maybe 20190528 12:23:01< celmin|away> Usually I see people overloading the bitwise operators for that kinda thing. 20190528 12:23:50<+wesdiscordbot> what do you think of people having a non-static "dot" member function? 20190528 12:23:58< celmin|away> ??? 20190528 12:24:21<+wesdiscordbot> or better yet, Mat::multiply(const Mat& rhs) 20190528 12:24:29< celmin|away> Ugly 20190528 12:27:38<+wesdiscordbot> thought with great power comes great responsibility 20190528 12:27:49<+wesdiscordbot> people can do really silly stuff with custom operators 20190528 12:40:32<+wesdiscordbot> any of you present work on the opengl branch? 20190528 12:41:31< celmin|away> IIRC, that's jyrkive's branch 20190528 12:41:54< celmin|away> He's definitely on Discord, no idea if he's around atm tho 20190528 12:52:59<+wesdiscordbot> @sthalik I still don't think it'd be very productive to try and implement our own renderer. 20190528 12:53:14<+wesdiscordbot> Especially since we'll need someone who knowns Vulkan too since OGL will go away eventually 20190528 12:53:39< celmin|away> I honestly don't think OpenGL will go away anytime soon. 20190528 12:53:52< celmin|away> Maybe never, in fact. 20190528 12:54:20<+wesdiscordbot> still 20190528 12:56:23<+wesdiscordbot> godot's already working on their vulkan renderer for 4.0 20190528 12:57:49<+wesdiscordbot> how feature-complete is haldric? 20190528 12:58:13<+wesdiscordbot> not nearly. 20190528 12:58:19<+wesdiscordbot> still a long way to go 20190528 12:58:27<+wesdiscordbot> are you able to see the map at least? 20190528 12:58:30<+wesdiscordbot> yes 20190528 12:59:09<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/576763377045602305/haldric.jpg this was the current state as of the 12th 20190528 12:59:34<+wesdiscordbot> we're still figuring out terrain transitons 20190528 12:59:47<+wesdiscordbot> those are a hard problem 20190528 13:01:17<+wesdiscordbot> also apparently godot 4.0 will have https://twitter.com/reduzio/status/1132703757601525760 20190528 13:02:04<+wesdiscordbot> hard problem logic-wise or asset-wise? 20190528 13:02:21<+wesdiscordbot> logic 20190528 13:02:42<+wesdiscordbot> we have it somewhat working by using 6 stacked tilemaps 20190528 13:02:50<+wesdiscordbot> but haven't attempted more complex terrains 20190528 13:02:52<+wesdiscordbot> like castles 20190528 13:02:59<+wesdiscordbot> though i think castles are probably simpler than we think 20190528 13:03:08<+wesdiscordbot> but then there are multihex terrains like moutains 20190528 13:04:53<+wesdiscordbot> it's normal to stack them with painter's algorithm, isn't it? 20190528 13:06:20<+wesdiscordbot> with....what? 20190528 13:06:47<+wesdiscordbot> draw the bottommost layer first, then the next one, to cover the parts that shouldn't show up 20190528 13:07:23<+wesdiscordbot> that....would be the general idea yes 20190528 13:07:43<+wesdiscordbot> @Bitron implemented something where hidden parts won't draw IIRC 20190528 13:07:46<+wesdiscordbot> but it's not complete 20190528 13:07:58<+wesdiscordbot> transitions are only one-way 20190528 13:08:00<+wesdiscordbot> not two-way 20190528 13:08:01<+wesdiscordbot> right now 20190528 13:08:52<+wesdiscordbot> I should probably build it now 20190528 13:09:11<+wesdiscordbot> no compilation needed for haldric right now 20190528 13:09:47<+wesdiscordbot> just download godot, clone the repo (https://github.com/wesnoth/haldric) and open the project in godot 20190528 13:10:45<+wesdiscordbot> what hidden parts? 20190528 13:10:52<+wesdiscordbot> the same-layer thing 20190528 13:15:29<+wesdiscordbot> Erm. If you mean that transitions are only drawn when visible, then yes, that's the case. 20190528 13:22:54<+wesdiscordbot> do you intend for the project to be mostly written in godotscript? 20190528 13:23:05<+wesdiscordbot> yes. 20190528 13:33:22<+wesdiscordbot> but we're considering a switch to C# 20190528 15:17:30-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20190528 15:22:48-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20190528 15:51:38<+wesdiscordbot> Assuming C# becomes stable, IIRC. C# was what was used first, and it ended up still having multiple issues at the time. 20190528 16:03:35<+wesdiscordbot> Yes 20190528 16:03:46<+wesdiscordbot> And iOS support for C# in godot is pending 20190528 16:51:48<+wesdiscordbot> Maybe instead wait and jump straight for kotlin support? 😛 20190528 16:54:39<+wesdiscordbot> Anyway such languages aren't my favorite, I think they try to achieve two contradictory goals at same time 20190528 16:59:23<+wesdiscordbot> In terms of programming languages found Rust to be interesting lately. 20190528 17:22:58<+wesdiscordbot> rust is nice once you get used to the compiler, especially coming from something like java. 20190528 17:52:51<+wesdiscordbot> I just started looking into it so I haven't been doing much with it yet. It's quite a lot to take in compared to other languages. 20190528 17:53:47<+wesdiscordbot> they've got a tutorial for it that was pretty helpful: https://doc.rust-lang.org/book/ 20190528 18:03:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190528 18:08:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20190528 18:10:32<+wesdiscordbot> i've heard good things about rust from jetrel 20190528 18:53:32<+wesdiscordbot> the rust borrow checker still makes a fuss. I keep reading on their progress and the borrowck saga never ends 20190528 18:54:20<+wesdiscordbot> I'd be halfway interested in rust without any of that lifetime stuff 20190528 18:54:43<+wesdiscordbot> it's not like it allows for better optimization or anything, just gets in the way 20190528 18:55:23<+wesdiscordbot> The lifetime stuff is Rust's primary feature. It guarantees that memory safety issues don't occur if unsafe code isn't used. 20190528 18:56:16<+wesdiscordbot> it still allows for leaks though 20190528 18:57:10<+wesdiscordbot> borrowck complains in mutable borrows across patterns, or in some if/else blocks 20190528 18:58:13<+wesdiscordbot> @jyrkive you're the person behind the opengl fork, correct? I'd like to help. 20190528 18:58:38<+wesdiscordbot> Sure, help with it would be welcome. 20190528 18:59:17<+wesdiscordbot> The new stuff in that branch is in this folder: https://github.com/wesnoth/wesnoth/tree/opengl/src/ogl 20190528 19:00:16<+wesdiscordbot> The idea in the branch is that most parts of rendering pipeline would generate draw_op objects, and the draw operations would then be batched, and carried out all at once. 20190528 19:43:03-!- irker119 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190528 19:43:03< irker119> wesnoth/wesnoth:master newfrenchy83 106e9bf248 resolve color active/inactive colors sim AppVeyor: All builds passed 20190528 19:44:53<+wesdiscordbot> @jyrkive are you able to start it at all? I'm getting a .png load failure, followed by display size {0, 0} related failure 20190528 21:11:35-!- smiley- is now known as smiley` 20190528 21:13:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds] 20190528 21:21:53<+wesdiscordbot> I see that SDL_Renderer isn't being created anywhere 20190528 21:36:17<+wesdiscordbot> this is strange approach, I'd go for a minimum-effort migration before doing anything more meaningful 20190528 22:36:20< irker119> wesnoth/wesnoth:master newfrenchy83 60d7353bb4 Update attack.cpp AppVeyor: All builds passed 20190528 22:38:11-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20190528 22:59:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20190528 23:33:07-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20190528 23:36:32-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] --- Log closed Wed May 29 00:00:42 2019