--- Log opened Mon Aug 28 00:00:30 2017 20170828 00:00:40< aeth> OOS. Usually when someone tries to cheat they just get out of synced 20170828 00:02:10< Polsaker> aren't there cheats that don't produce OOS errors? like removing shroud/fog? 20170828 00:02:45< aeth> Yes, that's why I said usually. 20170828 00:03:07< aeth> But it's much easier to just observe with another client than it is to modify the client to remove shroud/fog. 20170828 00:03:26< aeth> So if there's cheating, that's probably how it happens. 20170828 00:03:47< aeth> It tells you when the IP of someone joining matches someone who's already there, though. 20170828 00:03:58< wesnoth-discord-> That, or save and then open the save with a second instance. 20170828 00:04:56< wesnoth-discord-> now i know why i always lose on fog maps (?) 20170828 00:06:13-!- amello [~amello@179.159.56.56] has quit [Quit: Leaving] 20170828 00:07:16< wesnoth-discord-> i haven't played this games for ages tho, im building up hype to rediscover it when it gets to steam 20170828 00:07:29< wesnoth-discord-> i guess i'll hibernate now, cya guys 20170828 00:17:12-!- Haudegen [~quassel@178.115.237.87] has quit [Remote host closed the connection] 20170828 00:19:39< DeFender> What's with all these people who are waiting for the steam release to start playing again? 20170828 00:21:35-!- Bonobo [~Bonobo@203.220.138.162] has joined #wesnoth 20170828 00:22:07< wesnoth-discord-> it makes sense less because of steam, and more because of 1.12 -> 1.14 incompatibilities, I figure 20170828 00:22:10< wesnoth-discord-> add-ons, saves, etc 20170828 00:26:35< DeFender> perhaps 20170828 00:33:46< aeth> The MP population will go way up 20170828 00:33:59< aeth> I have to brush up my map pack to be ready in time 20170828 00:48:54-!- prophile [~alynn@oftn/oswg-member/prophile] has quit [Quit: The Game] 20170828 01:06:15-!- edaq [~edaq3@h69-21-227-85.cytnin.broadband.dynamic.tds.net] has quit [Ping timeout: 240 seconds] 20170828 01:17:49-!- fortfoskett [~Jabo@209.6.194.238] has joined #wesnoth 20170828 02:24:38-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170828 02:24:44-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth 20170828 02:49:04-!- ArneBab_ [~quassel@freenet/developer/arnebab] has joined #wesnoth 20170828 02:53:12-!- ArneBab [~quassel@freenet/developer/arnebab] has quit [Ping timeout: 252 seconds] 20170828 02:53:48-!- deathisundead [~quassel@unaffiliated/the-unforgiven/x-8713611] has joined #wesnoth 20170828 03:01:34< wesnoth-discord-> zookeeper: I don't see why you'd expect new water to have the same perf 20170828 03:03:43< wesnoth-discord-> If you have a 100% water map, you have to draw every tile of the map quite often 20170828 03:04:30< wesnoth-discord-> What I'd be curious to see is a performance comparison between old water and new water on both 1.12 and master 20170828 03:06:20< wesnoth-discord-> don't forget the lava 20170828 03:06:21< wesnoth-discord-> 😛 20170828 03:07:45< celticminstrel> Hardware acceleration will probably fix the water problem when we finally get there. 20170828 03:07:59< celticminstrel> Pretty sure it's totally possible to run the entire animation on the GPU. 20170828 03:10:08< celticminstrel> So if people need to disable the water animation in 1.14, I'm not overly concerned? 20170828 04:20:17-!- ancientcc [~ancientcc@59.63.248.246] has joined #wesnoth 20170828 04:20:26-!- ancientcc [~ancientcc@59.63.248.246] has quit [Remote host closed the connection] 20170828 04:45:03-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20170828 05:40:24-!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 252 seconds] 20170828 05:42:26-!- cyphase [~cyphase@unaffiliated/cyphase] has joined #wesnoth 20170828 06:13:19-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth 20170828 06:25:53< zookeeper> @pydsigner, i'd expect similar performance (after initial caching is done) as long as the frame intervals are the same (for example 150ms). how often each hex gets redrawn and how many images are involved is what mainly determines performance. 20170828 06:31:00< zookeeper> what the engine does is that it always cuts up every terrain image into hex-sized pieces, and appends each piece to the appropriate hex's list of images, and then redrawing happens per hex. so even if the terrain rules for the new water are more fancy and complicated, that mostly only incurs a load-time penalty and the actual rendering after the engine has sorted everything out should only 20170828 06:31:00< zookeeper> depend on the number of images per hex and how often it gets redrawn. 20170828 06:32:51< zookeeper> and no, we can't (easily) test the performance of the new water in 1.12 because it requires 1.13-only features. granted, they shouldn't be that difficult to port over if one really wanted to do it. 20170828 06:36:05-!- edaq [~edaq3@h69-21-227-85.cytnin.broadband.dynamic.tds.net] has joined #wesnoth 20170828 06:40:42< shadowm> Can't you do it the other way around and test the 1.12 water on 1.13? 20170828 06:44:33< zookeeper> ...yeah, that'd be far simpler 20170828 06:59:24< zookeeper> well, actually the 1.12 water render-performs terribly worse than the new one on my system, in 1.13. a steady ~70fps with old, ~130-200 with new. 20170828 06:59:51< wesnoth-discord-> FPS isn't a meaningful measurement with the new framerate limiter. 20170828 07:00:22< wesnoth-discord-> The limiter reacts to a long frametime by shortening the time when the engine sleeps in every frame. 20170828 07:00:37< wesnoth-discord-> As a result, high FPS is a sign of *poor* performance. 20170828 07:00:45 * zookeeper blinks 20170828 07:00:58< zookeeper> well that's... highly unintuitive, don't you think? :P 20170828 07:01:36< wesnoth-discord-> FPS is a meaningful measurement in games where the frametimes are fairly constant, i.e. nearly all games. 20170828 07:02:11< zookeeper> ok, but if FPS doesn't stand for "frames per second" here, then surely it shouldn't be called that 20170828 07:02:34< wesnoth-discord-> But Wersnoth is an exception because of software rendering, which causes "the frames when the water animation updates" to take much, much longer than other frames. Up to about two orders of magnitude more IIRC. 20170828 07:02:48< wesnoth-discord-> FPS does stand for frames per second. 20170828 07:03:12< wesnoth-discord-> It's just that 500 FPS isn't very useful if ten of those 500 frames take 30 milliseconds each. 20170828 07:03:23< wesnoth-discord-> The result is still as stuttery as 30 FPS. 20170828 07:05:17< zookeeper> so, currently the FPS counter is redrawn every frame, and the value is an extrapolation based on the time between the last two frames? 20170828 07:05:58< wesnoth-discord-> The FPS counter is redrawn every 10 frames, and it calculates the FPS from the frametimes of previous 10 frames. 20170828 07:06:04< zookeeper> ah 20170828 07:06:48< zookeeper> seems easy to modify, i'll fiddle with it and see what happens to the output... 20170828 07:07:13< wesnoth-discord-> Even if you increase the window size, it wouldn't be very useful. 😦 20170828 07:07:27< wesnoth-discord-> The useful data would be the worst-case frametime. 20170828 07:07:40< shadowm> (And the CPU usage...) 20170828 07:08:28-!- shadowm is now known as zhadowm 20170828 07:09:48< wesnoth-discord-> The existing code that calculates the worst-case frametime to determine how fast to go is here: https://github.com/wesnoth/wesnoth/blob/9324349cb36df5d33843929f1fd193ffeccef247/src/display.cpp#L1690 20170828 07:09:51-!- zhadowm is now known as shadowm 20170828 07:13:29< zookeeper> ok, so... it samples a sequence of frametimes, takes the worst frametime, and determines the next delay based on that. so if there was a really long frametime, it'll use a really short delay (or none at all), leading to really high fps until there's a really slow frame again 20170828 07:13:45< wesnoth-discord-> Exactly. 20170828 07:14:52< wesnoth-discord-> I later investigated closer, and noticed that in Dead Water wait_time ends up at zero, and the limiter lets the engine operate at maximum speed. The worst-case scenario. 20170828 07:15:18< wesnoth-discord-> But much better than the old limiter that *still* slowed down the engine regardless of the performance problem. 20170828 07:17:13< zookeeper> the main render-time difference between the old and new water seems to be that the old water was not synced, meaning a screen full of water was drawing at a steady pace. the new water is synced, so each hex is redrawn at the same time. 20170828 07:17:39< wesnoth-discord-> Not syncing would be much, much better for performance. 20170828 07:17:51< zookeeper> urgh. 20170828 07:18:44-!- Haudegen [~quassel@178.115.237.87] has joined #wesnoth 20170828 07:19:11< zookeeper> the only problem with that is that it looks glitchy :p 20170828 07:19:33< wesnoth-discord-> I wonder if there could be an option? 20170828 07:20:22< zookeeper> ehh... it's too glitchy 20170828 07:20:25< zookeeper> but 20170828 07:21:43< zookeeper> i'm wondering whether it could be half-unsynced so that the redraw times would be randomized, but the animations would still never be more than 1 frame apart from each other (or at least immediate neighbours) 20170828 07:23:28< zookeeper> basically, offset the animation start time by rand 0..frame_length, instead of 0..anim_length 20170828 07:23:34< zookeeper> (i think) 20170828 07:24:20< wesnoth-discord-> Hmmm... that would help, sure. 20170828 07:24:35< wesnoth-discord-> Is it doable from WML or does it need engine support? 20170828 07:29:12< zookeeper> needs engine support 20170828 07:29:28< zookeeper> i'm thinking of just overloading random_start= to accept a numeric value 20170828 07:29:56< wesnoth-discord-> Hmm. In that case I think I'll rather add an "redraw at most N hexes/frame" option. 20170828 07:30:32< wesnoth-discord-> It would solve the *underlying* problem (too many hexes being updated in one frame) rather than the specific case of the water changing too many hexes. 20170828 07:31:04< wesnoth-discord-> And it would be configurable, so that players who use desktop computers can still keep it an unlimited hexes/frame. 20170828 07:31:11< wesnoth-discord-> *at 20170828 07:32:34< zookeeper> hrhrhm, doesn't that strike you as a grotesque spilling of very technical rendering details into the user's face? :x 20170828 07:33:32< wesnoth-discord-> Well, I guess I just personally prefer when software is configurable. 20170828 07:33:54< wesnoth-discord-> And to be fair, many games tend to expose extremely technical options such as HBAO+. 20170828 07:33:54< zookeeper> and surely you'd end up with problems similar to the flying animation glitches we just had solved? 20170828 07:34:14< zookeeper> one hex gets redrawn, the adjacent one doesn't, and it's visible 20170828 07:34:30< wesnoth-discord-> And the adjacent hex is redrawn in the very next frame... 20170828 07:35:44< zookeeper> i take it you don't mind if i try my suggestion first and see just how much it helps? :P 20170828 07:36:25< wesnoth-discord-> Sure, go ahead. Just don't expect me to implement the random_start= overloading. 😉 20170828 07:36:54< zookeeper> well implementing it myself was what i meant by trying :> 20170828 07:38:33< zookeeper> what kind of draw pattern would your option cause? a sweep from top left to bottom right, or essentially random? 20170828 07:39:10< wesnoth-discord-> A sweep, yes. The engine draws the hexes in order. 20170828 07:41:06< zookeeper> mmkay. could add a little graphical radar sweep effect and it'd be all good... :> 20170828 07:54:04< zookeeper> done, now to see whether it works as intended... 20170828 07:57:04< wesnoth-discord-> That was fast. Nice. 😃 20170828 07:57:46< zookeeper> yeah, well, it doesn't work yet :> 20170828 08:08:01< zookeeper> how hard can it be to figure out the input with a to_int and a to_bool... -.- 20170828 08:22:59< zookeeper> i think i got it 20170828 08:27:42< zookeeper> huh. well, the fps counter is the only thing i have to go by here, so: new water, synced: fps ~130-200. unsynced: ~70. my semi-synced thing: ~70. old water: ~70. 20170828 08:28:17< wesnoth-discord-> So, it looks like you reached parity with old water. 20170828 08:28:24< wesnoth-discord-> Excellent. Thank you. 😃 20170828 08:31:09< zookeeper> good thing you specifically brought up the water redraw frames (obviously) taking much longer than others, i wouldn't have thought of this otherwise 20170828 08:35:06< zookeeper> ...although i'm afraid it's not as simple as this. the above testing was with just a screen full of uniform water. once i add other types of water and there's lots of transitions, the performance goes down the drain. 20170828 08:35:56< wesnoth-discord-> Want me to implement the hexes/frame limit later? 20170828 08:36:10< zookeeper> presumably because the same hexes get excessively redrawn when there's a big pile of different animated transition tiles all drawing unsynced WRT each other 20170828 08:36:40< zookeeper> maybe? i mean i'm kinda curious how good it'd look and i'm a bit sceptical about it, but... 20170828 08:38:09< zookeeper> anyway, in theory it's clear how the transition performance problem should be avoided, but how to implement it isn't 20170828 08:39:29< zookeeper> there should be a separate clock for water animations per hex, and all water animation images on that hex should follow it (instead of each animation having its own clock). but that's... pretty orthogonal to how everything works now. 20170828 08:40:33< wesnoth-discord-> I dislike the idea of special-casing the water animations in engine code. 20170828 08:42:21< zookeeper> well, what i have now which is random_start=| has other uses too. i'd argue it even (very subtly) improves the water's aesthetics. 20170828 08:45:10< zookeeper> but whether i can come up with something to fix the transitions problem without it being a case of special-casing, i don't know :p 20170828 08:48:06< zookeeper> so, if i have a 60hz screen, am i correct in assuming that performance is fine as long as the fps counter shows ~60, but if it's much lower or higher then there's a problem? 20170828 08:48:43< zookeeper> that is, if it's lower then it just can't keep up, and if it's higher then there's frames which take longer than 16,6ms? 20170828 08:55:54< zookeeper> i just don't know what exactly i should make of the fps readings. now if i grossly raise the frame intervals, which should unambigously improve performance, the fps counter jumps to >100-200 again. which should be a sign of worse performance, except it can't be. 20170828 08:59:07< zookeeper> maybe it should extrapolate the displayed value from the worst of the sampled frametimes? fps = 1000 / longest_frametime or something. 20170828 08:59:09< wesnoth-discord-> With highly increased animation frame intervals, the animation frames drop off of the frametime log that the FPS limiter uses. It slows down the game and doesn't know that the next animation frame will cause a long game frame. 20170828 08:59:20< zookeeper> ah, right, of course 20170828 08:59:33< wesnoth-discord-> I suspect that it then ends up overcorrecting because that frame then takes very long. 20170828 09:00:43< wesnoth-discord-> Extrapolating the value from the worst-case frametime would indeed be good. In fact, if you do it, please commit it. 20170828 09:01:08< wesnoth-discord-> And make sure that you use a long enough window so that the effect of animation frames is visible. 20170828 09:01:26< zookeeper> that would be in display::update_display() only, right? 20170828 09:02:12< wesnoth-discord-> Yes. 20170828 09:02:32< zookeeper> right, i'll try 20170828 09:02:39< wesnoth-discord-> In fact, you can use the existing frametimes_ buffer for that. No need to reinvent the wheel. 20170828 09:06:44< zookeeper> -const int fps = (frames*1000)/(this_sample - last_sample); 20170828 09:06:45< zookeeper> +const int fps = 1000 / *std::max_element(frametimes_.begin(), frametimes_.end()); 20170828 09:07:00< zookeeper> (and then upped sample_freq to 60) 20170828 09:07:23< wesnoth-discord-> Looks correct to me (from what I can tell, because Discord interprets some of that as markup). 20170828 09:07:34< zookeeper> now i'd just need to have some way of seeing whether the output matches reality in any shape or form 20170828 09:08:44< wesnoth-discord-> You can just as well keep sample_freq at 10. There is no harm in updating the display more often. 20170828 09:11:03< zookeeper> right 20170828 09:21:17< zookeeper> with that counter: old water 71-76, new water 30, new water semi-synced 50, new water semi-synced with 150ms (from 100ms) frame intervals 66-76 20170828 09:22:16< wesnoth-discord-> So, locked 60 FPS. 😃 Is that in your test scenario? 20170828 09:22:48< zookeeper> ? 20170828 09:23:18< wesnoth-discord-> I was asking where you benchmarked. In a test scenario, in a certain campaign, somewhere else? 20170828 09:23:28< zookeeper> in a test map in the editor 20170828 09:35:37< zookeeper> i'll have to do a few more elaborate tests i suppose 20170828 10:20:23-!- edaq [~edaq3@h69-21-227-85.cytnin.broadband.dynamic.tds.net] has quit [Quit: Leaving] 20170828 10:32:35-!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 240 seconds] 20170828 10:57:05< zookeeper> hmh. another optimization that could be done: draw transitions with less fidelity, for example drawing only every 2nd or 3rd frame. visually almost indistinguishable to me. 20170828 10:59:40< zookeeper> too bad i chose a frame count of 17 for the shallow water, that's kinda hard to divide evenly :p 20170828 11:00:15< zookeeper> ah, but i could just double it... 20170828 11:00:53< wesnoth-discord-> I think it would be okay as an option, but not as default. I prefer to keep full fidelity on sufficiently powerful PCs. 20170828 11:07:33< zookeeper> wouldn't make much sense as an option. "maybe increase performance of water animations slightly, probably without any perceivable visual impact" 20170828 11:08:40< wesnoth-discord-> But another question is what's even the point of rendering 60 frames per second or whatever if the frames are just identical... 20170828 11:12:19< zookeeper> anyway, i suppose it would make sense to put in my semi-syncing feature and have someone who has water performance problems test to see if it alone helps 20170828 11:12:36< zookeeper> it's really simple and easy to take out if it turns out undesirable 20170828 11:20:34< zookeeper> ...plus, as said, it has legitimate uses if one wants to make an animation seem a bit more organic by making it be _almost_ in sync 20170828 11:27:56-!- prophile [~alynn@oftn/oswg-member/prophile] has joined #wesnoth 20170828 12:01:18-!- Vorpal [~Vorpal@c83-249-126-249.bredband.comhem.se] has joined #wesnoth 20170828 12:01:18-!- Vorpal [~Vorpal@c83-249-126-249.bredband.comhem.se] has quit [Changing host] 20170828 12:01:18-!- Vorpal [~Vorpal@unaffiliated/vorpal] has joined #wesnoth 20170828 12:56:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170828 12:56:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth 20170828 13:27:22-!- Kranix [~magnus@xd520f683.cust.hiper.dk] has joined #wesnoth 20170828 13:36:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170828 13:36:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth 20170828 14:03:04< wesnoth-discord-> oh did animated water make it ingame? 20170828 14:04:10< wesnoth-discord-> I don't get what you're asking. Even Wesnoth 1.12 has animated water. 20170828 14:06:02< wesnoth-discord-> >_> right, of course it does 20170828 14:06:06< wesnoth-discord-> nevermind 20170828 14:09:05< zookeeper> i thought we've had animated water longer, but apparently it was added as recently as 2010 20170828 14:09:51< wesnoth-discord-> I was just thinking of these crazy ideas for directional water, I guess 20170828 14:11:13< wesnoth-discord-> What about adding water physics 20170828 14:11:33< wesnoth-discord-> In WML, right? 20170828 14:11:39< wesnoth-discord-> 😄 20170828 14:12:45< wesnoth-discord-> So that units move around the map like in those fluid simulations! 20170828 14:17:57-!- Kwandulin [~Kwandulin@p200300E453CC3B7E5D7615C11F82772C.dip0.t-ipconnect.de] has joined #wesnoth 20170828 15:02:02-!- gvghjlkc [~fhasdg@adsl-37.37.6.3.tellas.gr] has joined #wesnoth 20170828 15:02:08-!- gvghjlkc [~fhasdg@adsl-37.37.6.3.tellas.gr] has left #wesnoth [] 20170828 15:36:21-!- Bonobo [~Bonobo@203.220.138.162] has quit [Ping timeout: 240 seconds] 20170828 15:36:41-!- Smedles [~quassel@CPE-58-160-75-119.ssqn1.lon.bigpond.net.au] has quit [Ping timeout: 240 seconds] 20170828 17:18:50-!- Haudegen [~quassel@178.115.237.87] has quit [Remote host closed the connection] 20170828 17:36:13-!- Kwandulin [~Kwandulin@p200300E453CC3B7E5D7615C11F82772C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20170828 18:08:59-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity] 20170828 18:26:35-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 240 seconds] 20170828 18:28:51-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth 20170828 18:53:57-!- prophile [~alynn@oftn/oswg-member/prophile] has quit [Quit: The Game] 20170828 19:21:36-!- cyphase [~cyphase@unaffiliated/cyphase] has joined #wesnoth 20170828 19:31:43-!- Kranix [~magnus@xd520f683.cust.hiper.dk] has quit [Read error: No route to host] 20170828 19:32:36-!- Kranix [~magnus@xd520f683.cust.hiper.dk] has joined #wesnoth 20170828 19:34:37-!- Kranix [~magnus@xd520f683.cust.hiper.dk] has quit [Remote host closed the connection] 20170828 19:37:28-!- Kranix [~magnus@xd520f683.cust.hiper.dk] has joined #wesnoth 20170828 20:29:31< janebot> wesnoth: A Message from Far Away: New Subreddit for Strategy RPGs! (by /u/Dellesaen) https://redd.it/6wm5t2 20170828 20:44:29-!- deathisundead [~quassel@unaffiliated/the-unforgiven/x-8713611] has quit [Remote host closed the connection] 20170828 20:51:44-!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 240 seconds] 20170828 21:20:57-!- Kranix [~magnus@xd520f683.cust.hiper.dk] has quit [Quit: Konversation terminated!] 20170828 21:35:39-!- cyphase [~cyphase@unaffiliated/cyphase] has joined #wesnoth 20170828 22:26:51-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170828 22:26:58-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth 20170828 22:30:10-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds] 20170828 23:07:50-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth 20170828 23:49:16-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth --- Log closed Tue Aug 29 00:00:31 2017