Back to Home / #openttd / 2017 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2017-08-27

---Logopened Sun Aug 27 00:00:30 2017
00:48-!-Cubey [] has quit [Ping timeout: 480 seconds]
01:02-!-Alberth [] has joined #openttd
01:02-!-mode/#openttd [+o Alberth] by ChanServ
01:02-!-Alberth is "purple" on @#openttd
02:09-!-chomwitt [~chomwitt@2a02:587:dc0e:9300:1c4b:488:f428:7368] has quit [Ping timeout: 480 seconds]
02:35-!-adf88 [] has joined #openttd
02:35-!-adf88 is "adf88" on #openttd
02:39-!-KouDy_ [] has quit [Ping timeout: 480 seconds]
03:20-!-blocage [] has joined #openttd
03:20-!-blocage is "Benoit Gschwind" on #openttd #gcc
03:41-!-KouDy [] has joined #openttd
03:41-!-KouDy is "KouDy" on #openttd
04:16-!-Progman [] has joined #openttd
04:16-!-Progman is "Peter Henschel" on #openttdcoop #openttd
04:37-!-HerzogDeXtEr [] has joined #openttd
04:37-!-HerzogDeXtEr is "purple" on #openttd
04:51-!-Wolf01 [] has joined #openttd
04:51-!-Wolf01 is "Wolf01" on #openttd
04:55<blocage>hello, there is plan to switch from vehicle based GUI to track/order list based GUI ?
04:57<blocage>It would be nice to setup order list independently from vehicle, then assign vehicle on them
04:58<LordAro>blocage: you might be interested in
04:59<LordAro>but i can't see such a pivotal change to the UI happening at all
05:00<blocage>LordAro, I know how to share orders, but the GUI is quite dificult to handle
05:01<blocage>LordAro, mm ok
05:01<LordAro>it is a good idea though, i think, i just can't see it getting done any time soon
05:02<blocage>ok, so no plan for this :)
05:10-!-Stimrol [] has joined #openttd
05:10-!-Stimrol is "Stimrol" on #openttd
05:19<@Alberth>lots of plans exist, realizations of plans is the problem, as it takes time
05:19<@Alberth>your best chance of getting it in is to make it yourself
05:20<blocage>Alberth, ^^ at less I don't start a work that is already started :)
05:21<@Alberth>oh, don't worry about that
05:21<@Alberth>plans always look similar, but there are enough details to decide to make your solution unique
05:22<@Alberth>and those details decide how good the solution is
05:23<blocage>but I think it's better to join an effort that is already started than starting a new one from scratch
05:23<@Alberth>ie we have around a handful of day-length patches, and none are the same
05:23<@Alberth>if you can find yourself in the approach that the developers took, sure
05:24<@Alberth>but these things are not just "plan -> just start typing code -> done"
05:24<@Alberth>even if you know how to code"
05:24<@Alberth>the first arrow hides a shitload of thinking and deciding
05:25<blocage>first I think there some sub-task to do, for exemple: visual feedback for order list
05:25<@Alberth>what does that mean?
05:25<@Alberth>"visual feedback", that is
05:26<blocage>i.e. showing on map the path of a vehicle, where he should drop it's content, where he gather goods
05:26<blocage>and so on
05:27<blocage>so you select a vehicle, show-order-list-on-map
05:27<@Alberth>alright, "path" is simple if you draw straight lines
05:27<blocage>and see this think on map
05:27<blocage>this is a first subtask
05:27<@Alberth>if you mean real actual path, that's complicated, as you need to understand how the tracks/roads/bouys go
05:28<blocage>that can be splitted into other sub-task, like: path of plane vs path of train vs path of other vehicle
05:28<@Alberth>you can decompose everything several times, usually :)
05:28<@Alberth>but sure, have a go at it.
05:29<blocage>that waht I call plan that can be share amoung developpers
05:29<@Alberth>how many devs are you?
05:29<blocage>I'm the one :D
05:30<@Alberth>hmm, sharing might not work very good then :)
05:30<blocage>but having a task list may provide idea to other devs
05:31<blocage>but anyway I will look what I can do, maybe I will have the time, maybe not :)
05:31<@Alberth>it never hurts to decompose and make a list
05:31<@Alberth>you can post at the forum
05:31<@Alberth>but in general, people are happy to comment and suggest, but not in helping out
05:32<blocage>I will do so if I reach something that look viable, and that I can support
05:32<@Alberth>but who knows, you may be lucky
05:32<@Alberth>ok, have fun!
05:33<blocage>As everyone my time is not extensible, even after Einstein work :D
05:33-!-Hiddenfunstuff [] has joined #openttd
05:33-!-Hiddenfunstuff is "Geth" on #openttd #/r/openttd #openttdcoop
05:39-!-Celestar [] has joined #openttd
05:39-!-Celestar is "purple" on #openttd
05:45-!-Celestar1 [] has quit [Ping timeout: 480 seconds]
06:03<Wolf01>Alberth: is there some way to set the size of a nwid_vertical to like 30% of the window width?
06:04<Wolf01>I'm trying with spacers with fill, but every container fills a different space based on the content
06:09<@Alberth>non-leaf widgets get their size from their childs
06:09<@Alberth>so you have to compute a good size of the childs (leafs)
06:10<Wolf01>That could be difficult
06:10<@Alberth>or write a custom widget that handles such control (if there is room to do so, I guess)
06:10<@Alberth>widgets generally don't know window size
06:10<@Alberth>just their own size and position in the window
06:11<@Alberth>town window is probably the most hacky case for such a feature :p
06:12<@Alberth>it has 2 widgets under each other that resize iirc, but the window can't quite handle that
06:13<@Alberth>it got done by some custom code in the window
06:13<@Alberth>map window has some special code for the list at the bottom
06:14<@Alberth>but it's a complicated problem, if you have stuff that can move around to fill available space, as you can then exchange width for height and vice versa
06:14<Wolf01>If I want to set a fixed width instead?
06:15<@Alberth>if you have a good upper limit that would work
06:15<@Alberth>if you don't know, a common trick is to just pick something and enlarge when it doesn't fit
06:16<@Alberth>lots of windows do that
06:16<@Alberth>eg station picker and vehicle gui
06:16<@Alberth>variable text in it, so sometimes it resizes to fit
06:16<@Alberth>so that's definitely an option as well
06:17<Wolf01>I just want to align the buttons at the same distance between different sections, buttons now gets larger because labels have different text width in different sections
06:18<Wolf01>I'm fine with labels to change size accordingly to text, but buttons should always stay the same size
06:18<@Alberth>just compute the size of all buttons, and return the max for all
06:20<Wolf01>Which is what NC_EQUALSIZE already does
06:22-!-Wormnest [] has joined #openttd
06:22-!-Wormnest is "Wormnest" on #openttd
06:22<@Alberth>that's inside a single container, isn't it?
06:22<@Alberth>if you can put all buttons in one container, that will work
06:23<@Alberth>but "different sections" suggests you cannot, to me
06:24<@Alberth>oh, vehicle order buttons do this kind of stuff, but it's a complicated gui
06:25<@Alberth>with all the different rows that change between vehicle types
06:25<@Alberth>no idea how it works there
06:25<@Alberth>main menu also does it, but that might be a bad example
06:28-!-_3298 [] has joined #openttd
06:28-!-_3298 is "realname" on #openttd
06:33<Wolf01>Is possible to show the boxmodel of widgets?
06:34<adf88>Wolf01: you can always override UpdateWidgetSize to workaround problems
06:35<adf88>in your case, this would be the solution:
06:35<adf88>1. iterate all possible button texts and compute maximum
06:36<adf88>2. use the computed value as the size for all buttons (in UpdateWidgetSize)
06:36<@Alberth>unless someone added it, there is no grid-widget
06:36<@Alberth>you can port it from freerct :p
06:36<@Alberth>it's not simple copy/paste though
06:37<@Alberth>or if that's not what you mean with "boxmodel", what is the latter?
06:37<_dp_>iirc openttd does some grid-like things by putting vertical lists in horizontal
06:38<@Alberth>or the other way around, but yes
06:38<@Alberth>one of the omissions we found too late :)
06:38<_dp_>Alberth, usually keeping width is more problematic
06:38<Wolf01> <-boxmodel
06:39<@Alberth>fixed in freerct, where I discarded horizontal and vertical containers instead, as they both fit in a grid container
06:39<adf88>The model is a bit different
06:40<adf88>but it's something like that
06:40<adf88>we have paddings, no margins etc.
06:40<Wolf01>I just want to see the widget bounding box
06:40<@Alberth>we have margins but no border I think
06:40<adf88>you just wanted a WYSIWYG designer?
06:41<Wolf01>I'm making that in javascript
06:41<adf88>none exists
06:41<Wolf01>But in OTTD I would like to see which widget is too large and makes all the others resize
06:42<adf88>hint: sometimes i'm just using differently coloured backgrouds for debug purposes
06:43<LordAro>Alberth: thought about changing OTTD to do it the FRCT way? it always did seem simpler
06:43<Wolf01>adf88: a bit difficult when the widget doesn't get a colour and you need to add panels everywhere
06:44<@Alberth>LordAro: I haven't
06:44<@Alberth>freerct is version 2, which is usually simpler relative to its predecessor :)
06:47<@Alberth>I used to have a patch for dumping widget positions, resize settings, and sizes in an indented tree, but can't find it
06:48-!-Defaultti [] has quit [Ping timeout: 480 seconds]
06:51-!-Defaultti is "Defaultti" on #debian
06:51-!-Defaultti [] has joined #openttd
06:52<adf88>Wolf01: yes, spaces don't get coloured (naturally!)
06:52<adf88>if you colour widgets differently, the spaces will be visible too
06:52<Wolf01>Ok, found it, it was a vertical spacer which fucked up with the width
06:55<Wolf01>Doesn't a NWID_SPACER stack vertically with NWID_HORIZONTAL? Like an hamburger
06:56<Wolf01>So I have to find another way
06:56<adf88>no, if I understand correctly :p
06:56<adf88>what did you mean exactly?
06:57<Wolf01>NWID_VERTICAL {
06:57<Wolf01> NWID_HORIZONTAL {}
06:57<Wolf01> NWID_SPACER
06:57<Wolf01> NWID_HORIZONTAL {}
07:00<adf88>the spacer should be just between horizontal containers
07:00<adf88>not sure what you are asking for
07:01<adf88>height of the spacer should give a distance between horizontal containers
07:01<@Alberth>remove the space widget, and use a pip of (0, N, 0) on the vertical container
07:01<adf88>width of the spacer should give some minimal size to the vertical container
07:01<@Alberth>pretty sure it works that way adf88 :)
07:03<adf88>SetPIP/SetMinimalSize would work too, yes
07:04<@Alberth>trick that might work is to replace the space widget by a NWidgetBackground widget of some colour
07:04<@Alberth>BG color, that is
07:04<@Alberth>that allows you to see its space
07:05<LordAro>would be nice to have a better way of specifying the windows, the current way isn't all that user friendly
07:07<@Alberth>lol, you improve python code on suggestions by pylint, and your grade decreases :p
07:11<@Alberth>making the windows more consistent in style and colour would be nice too
07:13<Wolf01> <Alberth> remove the space widget, and use a pip of (0, N, 0) on the vertical container <- yes, that was an example, I have many horizontal containers and need the space only between 2 of them, with PIP I need to wrap the other ones into another vertical container
07:13-!-FLHerne [] has joined #openttd
07:13-!-FLHerne is "Francis Herne" on #openttd
07:13<Wolf01>The spacer already had a setminimalsize of 0, 6
07:18<adf88>Yes, PIP is for all "internal" paddings between contained widgets
07:18<adf88>if you want a spece just in a single place, use a spacer just like you did
07:18<Wolf01>The spacer was put on the side of the horizontal container
07:19<Wolf01>Even if inside a vertical container
07:19<adf88>on a side?
07:19<adf88>PIP is for "pre" "in" "post"
07:20<Wolf01>I know
07:20<Wolf01>Don't change the subject every 2 lines please
07:20<adf88>I'm not
07:21<adf88>i'm trying to say that you should use "pre" or "post" for a side space
07:21<adf88>you don't have to put a spacer on a side
07:21<Wolf01>I'm not putting the spacer on the side
07:21<adf88>OK then
07:23<Wolf01> <- second image
07:23<@Alberth>looks nice, no idea what to notice in that picture though
07:24<@Alberth>oh, bottom text line explains
07:24<@Alberth>some code please?
07:25<@Alberth>clearly it's not under a row :p
07:26<Wolf01>I put the code in the comments of the images
07:26<Wolf01>Pseudocode at lease
07:27-!-frosch123 [] has joined #openttd
07:27-!-frosch123 is "frosch" on #openttdcoop.devzone #openttd
07:28<adf88>sorry but it's too cryptic too me
07:29<Wolf01>Does it break the format?
07:31<Wolf01>Sorry, I left a rogue PIP in the bottom one
07:32-!-gelignite [] has joined #openttd
07:32-!-gelignite is "gelignite" on #openttd #openttdcoop.devzone
07:34<Wolf01> <- this is the actual code (with wrong behaviour)
07:35<Wolf01>Uncomment PIP on line 3 and the vertical container at L:36-62, remove the spacer at L:34 and it works, but I didn't want to use the PIP to do that (maybe I'm wrong)
07:40<adf88>the spacer on line 34
07:40<adf88>why do you need this?
07:40<adf88>it seems problematic
07:41<adf88>not his one
07:41<Wolf01>Yes it is, it's to separate the edge buttons
07:41<adf88>not this one
07:41<adf88>moment please, decrypting ;P
07:43<adf88>you need this vertical container
07:43<adf88>uncomment it
07:44<Wolf01>Same result, weird space at the right
07:44<Wolf01>Which goes away if you remove the spacer
07:44<adf88>SetFill(1, 0) ?
07:45<Wolf01>Nope, same result
07:46<adf88>you should take care what's inside your vertical container
07:46<Wolf01>Oh, if you put setfill for the spacer it works
07:47<Wolf01>NWidget(NWID_SPACER), SetMinimalSize(0, 6), SetFill(1,0), <- but it looks weird
07:48<Wolf01>I expected it to have the same width of the containers, not bigger
07:48<Wolf01>Maybe smaller, but not bigger
07:48<@DorpsGek>Commit by frosch :: r27900 /trunk/src (widget_type.h window.cpp) (2017-08-27 13:48:38 +0200 )
07:48<@DorpsGek>-Change [FS#6568]: Remove the gap between windows when positioning them after opening.
07:48<@DorpsGek>-Fix: Make automatic window-positioning RTL-aware.
07:48<@DorpsGek>-Fix: Automatic window-positioning now uses GUI-scale/style dependent sizes/distances instead of fixed pixel values.
07:48-!-_3298 [] has quit [Ping timeout: 480 seconds]
07:49<Wolf01>I think it's because the spacer doesn't get the PIP 10,0,10 of the parent container, so it's initialized with the size of the parent container
07:49<Wolf01>Alberth: could you confirm this? It's too much chinese to me
07:54<@Alberth>line 3 isn't doing anything, as it has only 1 column
07:56<@Alberth>that would then also hold for line 2
07:56<@Alberth>(bot for 1 row)
07:57<@Alberth>hmm, horizontal container has pip (10, 0, 10), so it handles spaceing at left and right thus
07:57<Wolf01>I could move PIP to the parent yes, all the panels have the same PIP
07:57<Wolf01>But I need to keep at least one container for every tab
07:57<Wolf01>Even if it does nothing
07:58<Wolf01>I could use WWT_PANEL, so tabs could have different colour
07:59<@Alberth>what bothers me is the vertical fill in the first column but not in the second, but that's not the problem, right?
07:59<Wolf01>No, that doesn't seem to be the problem
08:00<Wolf01>I copied it right away from the original code
08:00-!-_3298 [] has joined #openttd
08:00-!-_3298 is "realname" on #openttd
08:02<@Alberth>tbh I don't understand what the problem is, currently
08:02<Wolf01>The spacer creates a weird space on the right even when stacked vertically
08:03<Wolf01>It seem too large
08:03<Wolf01>SetFill(1,0) fixed it
08:03<Wolf01>But why is too large?
08:07<@Alberth>what happens if you replace line 34 by NWidget(WWT_PANEL, COULOR_RED), SetMinimalSize(0, 6), EndContainer(),
08:07<@Alberth>ie replace it by a widget with colour
08:08<@Alberth>all widgets have a default fill and resize, so if you don't specify one, you get the default
08:08<Wolf01>It works fine
08:08<@Alberth>but I don't see how it makes things move, unless you set sizes of the other widgets in some way
08:09<@Alberth>I'd expect SetFill(0, 0) tbh, ie no initial resizing at all
08:09<@Alberth>hmm, no, that would prevent other widgets from filling too
08:15<Wolf01>I noticed NWID_SPACER has implicit equalsize
08:15<@Alberth>everything has
08:16<@Alberth>if you give more room than required, the remaining space gets distributed between the widgets that can fill
08:19-!-efess [] has quit [Ping timeout: 480 seconds]
08:25<@Alberth>although, it's not equal size, as the initial size is not taken into account
08:25-!-blocage [] has quit [Ping timeout: 480 seconds]
08:26-!-blocage [] has joined #openttd
08:26-!-blocage is "Benoit Gschwind" on #gcc #openttd
08:28<Wolf01>What I can't understand is that in the first tab the spacer works fine
08:31<Wolf01> here is the patch if you want to try it
08:53<@Alberth>what is exactly broken, there is no empty space at the right of "advanced"
08:53-!-blocage [] has quit [Ping timeout: 480 seconds]
08:54<Wolf01>What do you mean?
08:59<@Alberth>windows look fine to me
08:59<Wolf01>Yes, there's the SetFill
08:59<Wolf01>Remove that and see
09:00<@Alberth>line number please?
09:00<@Alberth>thank you
09:01<Wolf01>L:267 sorry
09:01<Wolf01>L:207 is the working one (without setfill)
09:14<@DorpsGek>Commit by frosch :: r27901 trunk/src/window.cpp (2017-08-27 15:14:37 +0200 )
09:14<@DorpsGek>-Codechange: GetWindowZPriority only needs a WindowClass; this way it can also be used for WindowDesc before a Window instance is created. (3298)
09:15<_3298>... does that mean you intend to commit something that actually makes use of that?
09:16<frosch123>no idea
09:16<frosch123>still figureing out what it actually does
09:17<_3298>the main point is to place windows in less-than-optimal places if there is no optimal place
09:18<_3298>the best way to do that (imo) is a scoring system
09:19*_dp_ sometimes wish openttd will just place less windows
09:19<frosch123>yes, but the current "put child window on top of parent" is very different to the proposed "put child window next to parent"
09:19<@Alberth>as you can see, the two light green areas from the top got distributed to the bottom
09:20<@Alberth>it's a few pixels off, but I eye-balled it, you need to get the numbers or work pixel-precise in the image editor
09:20<_3298>that's actually something that comes later down the line, i just make use of the scoring system to declare positions next to the parent "optimal"
09:20<Wolf01>Alberth: so what causes this?
09:20<@Alberth>what happens is that the default of spacer widget is not to fill, so if you leave it out, the right column cannot stretch to fill the space
09:20<frosch123>_3298: you mean it's possible to split the patch and postpone the design decision onto a smaller patch?
09:21<_3298>of course
09:21<@Alberth>so there is room around the widgets, and that gets evenly spread to other widgets in the row
09:22<@Alberth>or failing that, it might become lost space
09:22<@Alberth>filling and resizing works only if ALL widgets can do it
09:23<@Alberth>at least perpendicular to the direction of the container
09:23<@Alberth>in the direction of the container, you need only 1 widget
09:25<Wolf01>Is it possible for one like me to notice this behaviour and fix the UI structure without knowing the internals?
09:32<@Alberth>there is no written record about default fill and resize afaik, but you can simply always specify them
09:33<@Alberth>Without knowledge of fill and resize, don't think you get far. However, I don't see that as "internal"
09:33<@Alberth>it's the core mechanism how the window is setup and resizes
09:34<Wolf01>So the only alternatives are 1) try and fail; 2) post the code here and get it fixed by someone which knows exactly how it works
09:35<frosch123>it works the same in other gui frameworks
09:35<@Alberth>I don't see how you would not need to worry about it under varying lengths of texts in the buttons and possibly varying size of the window by user-resize
09:36<@Alberth>just changing language already changes layout
09:38<Wolf01>Ok, but taking it as a basic structure, ignoring all the possible resizing etc, do you think I should know how to fix a space which pops out from nowhere?
09:40<@Alberth>have you read widget.cpp lines 690 to 712?
09:40<@Alberth>it's described how fill and resize works
09:42<@Alberth>generated docs are nicer, as there are links to definitions
09:42<@Alberth>widget_type.h explains about the parts array line 808 and further
09:46<@Alberth>note that you can never ignore filling
09:47<@Alberth>but yeah, it's a non-trivial system that shows unexpected behavior to new users
09:47<@Alberth>just like about every sub-system that does internal computations
09:48<@Alberth>like fios and fileio :p
09:48<frosch123>i had an easier time understanding the gui :p
09:48<Wolf01>The problem is: I set [label][fill][button][fill] and I get [label] void space [button][fill][fill], there is something I can't understand
09:49<@Alberth>labels and buttons fill too
09:49<@Alberth>unless you explicitly disable it, afaik
09:49<@Alberth>frosch123: keep it :)
09:50<@Alberth>makes life simpler :)
09:50<Wolf01>Ok, but if I mess up the UI, I would like to know why I messed it up, without any reference, boundingbox, different colours etc I can only read the whole code and learn exactly how it works
09:51<Wolf01>For example, replacing the NWID_SPACER with WWT_PANEL, the panel worked fine, right size etc, why the spacer didn't?
09:51<Wolf01>Also, why the spacer worked fine in L:207 but not in L:267?
09:52<Wolf01>I missed a SetFill in some other widget? Ok, which one?
09:52<@Alberth>maybe there is less space in line 207
09:52<@Alberth>ie it could be the tab that decides the window space
09:53<@Alberth>I can see the problem, but no idea how to fix
09:54<@Alberth>I had a patch that dumped the widget tree settings to stdout, which worked, but it was a mess to figure out
09:54<@Alberth>ie you had to study all the numbers
09:54<@Alberth>and it still assumed you understood how the filling and resize mechanisms work
09:55<@Alberth>since it's a dump after all computations are done
09:55<@Alberth>likely it's simpler to print the contents of the few widgets you are interested in, when you have a problem
09:55<frosch123>maybe there could be a compile time switch to add a panel around every container
09:56<frosch123>and then those panels get color by tree-depth or something
09:56<@Alberth>edges are on top of each other
09:56<Wolf01>That could be a nice thing to have
09:57<@Alberth>unless you add 2 everywhere
09:57<Wolf01>I'm fine with that, you can even explode the UI to show it better
09:58<@Alberth>in that case, depth isn't even needed, as edges are strictly nested inside each other than
09:59<Wolf01>If only...
09:59<@Alberth>not sure if it would help in this case
09:59<_dp_>does _tick_counter overflow?
10:00<@Alberth>sure, just add OpenGL to OpenTTD, please :)
10:01<@Alberth>_dp_: date.cpp line 30: uint16 _tick_counter;  ///< Ever incrementing (and sometimes wrapping) tick counter for setting off various events
10:02<_dp_>Alberth, oh, right, I somehow missed () part ^^
10:02<@Alberth>if you look at usage, you'll see everything does & or %
10:03<_dp_>anyway, it's a bit of a bug that it does
10:03<frosch123>what else should it do?
10:03<_dp_>coz, for example it mean towns grow ad slightly different speeds
10:03<Wolf01>I started to write down a tool to preview a UI, it would be cool to be able to load the base widget list and show that, I know that resize and other changes happen when window is instanced, but it could help at least to set the initial structure with PIP, padding and see how to arrange elements
10:05<@Alberth>parsing a window parts array isn't that complicated, I think
10:05<Wolf01>The complicate part is making it show the right way
10:05<@Alberth>or dump the tree after openttd constructed it
10:05<@Alberth>in some easy to load format
10:06<@Alberth>eg json or yaml
10:06<_dp_>towns with index % 74 < 46 grow 0.1% faster if I done the math right
10:06<Wolf01>It would be cool to use the tool to generate some basic code to copy/paste and complete
10:07<@Alberth>just the parts array?
10:07<@Alberth>specify a tree in some format
10:07<Wolf01>Already with fill, pip, colour etc
10:07<frosch123>that sounds like you would end up re-impleneting the whole fill stuff
10:08<@Alberth>I would see it as a high-level description of the tree, which you can "compile" to the array format
10:09<Wolf01>Yes frosch123, I think that is the only option to learn how things work, just looking at other UIs to copy parts doesn't seem to effective
10:09<Wolf01>*to be
10:09<frosch123>Alberth: sound like it would only work for entire new windows
10:10<frosch123>it's even more harder to reimport an existing window
10:11<@Alberth>the tree is constructed, if you could get a copy before any calculation is done, you could get all data too, I think
10:11<_dp_>replacing if(_current_tick % smth) with if(_current_tick == _next_smth_tick) { _next_smth_tick += smth } can fix uneven calls
10:11<_dp_>also is likely faster
10:13<@Alberth>oh, % might not trigger, ok, that's tru
10:14<@Alberth>Wolf01: The question is whether having the tree structure would be actually useful
10:14<@Alberth>ie it's a tree with a zillion numbers
10:15<frosch123>adf88: change it to uint32 to reduce the effect by factor 64k?
10:15<frosch123>_dp_: ^^ not adf
10:15<frosch123>underscores are hard
10:16<_dp_>frosch123, yeah, but imo adding _next is better
10:16<@Alberth>but it breaks having a single counter
10:17<_dp_>I'm also thinking of it in context of town growth, and it has grow_counter already which can be replaced by next thingie
10:17<Wolf01>Alberth: I don't want to change the structure, I just need to show it in a format I can read, and since I'm used with xml, xaml, html, I just want a tool for fast UI prototyping
10:19<Wolf01>I think I could make the same without tree structure even in html+js
10:19<_dp_>only problem I see with _next is that it'll break if tick is skipped for whatever reason, but that shouldn't happen anyway
10:19-!-sim-al2 [] has quit [Ping timeout: 480 seconds]
10:24<_dp_>only towns and stations seem to be affected by % problem, all other stuff works in powers of 2
10:25<@Alberth>NWID_MATRIX does exist, no idea what it does :)
10:25<Wolf01>The depot windos
10:26<@Alberth>:O of course
10:39<@planetmaker>@op adf88
10:39<@DorpsGek>planetmaker: I don't recognize you.
10:39<@planetmaker>ah yes
10:40<@planetmaker>@op adf88
10:40-!-mode/#openttd [+o adf88] by DorpsGek
10:41<@adf88>i'm here
10:42<@adf88>ssh account works flwlessly
10:42<@Alberth>congrats !
10:43<_dp_>hmm, is it ok to drop support for town growth speeds that are slower than 1 house in 1000 days?
10:43<@planetmaker>wonderful :)
10:43<_dp_>like I can change to bigger type but who the heck needs those anyway?
10:43<@planetmaker>not sure whether I can really change adf88's permissions with dorpsgek
10:44<frosch123>_dp_: which towns does that affect?
10:44<frosch123>iirc there is some special code to make small desert towns grow to ensure that they accept food at some point
10:45<_dp_>frosch123, nah, it has nothing to do with it
10:45<_dp_>frosch123, it's not even possible to achieve such slow speeds without GS
10:46<_dp_>well, mb 0 houses town without stations will grow at about that speed but not any reasonable one
10:49-!-blocage [] has joined #openttd
10:49-!-blocage is "Benoit Gschwind" on #openttd #gcc
10:49<_dp_>lol, town with 1 station grows slower than town with 0
10:50<_dp_>wonder if that's intended or just typo xD
10:54<@Alberth>quick&dirty patch
10:54<_3298>frosch123, i've split the window placement patch for FS#5451 into two parts; are those more understandable or should i split the first part further?
10:55<Wolf01>Alberth: nice
10:55<@Alberth>until you find a 0 or 1 in a sea of numbers :p
10:55<@Alberth>*look for
10:56<@Alberth>which is why I am not sure this actually helps
10:57<Wolf01>WWT_PANEL(fill=(1, 0), resize=(0, 0), smallest=(304, 4), current=(304, 4), pos=(10, 144)) <- did you put the panel instead of the spacer?
10:57<@Alberth>oh, could be an experiment
10:57<_dp_>frosch123, ok, just checked, slowest growth speed without GS is about 1house/200 days, so base game won't be affected in any way
10:57<@Alberth>yes, just a test
10:59<Wolf01>Mmmh, I could edit that to dump html
10:59<Wolf01>Could it dump strings or other stuff?
10:59<@Alberth>any format, basically :p
11:00<Wolf01>For example the label text?
11:00<Wolf01>Or you just have the uint32?
11:00<@Alberth>sure, it's dumped while running, so everything is there
11:00<@Alberth>no it's all there, or you cannot compute widget size
11:00<_dp_>damn, TOWN_GROW_RATE_CUSTOM takes one bit so it'll be 1 house / 500 days at slowest
11:00<@Alberth>but it needs code to convert number to text, of course
11:01<_dp_>still twice slower than anything achievable without GS
11:01<@Alberth>likely fake painting the widget
11:01<@Alberth>might be less than trivial
11:01<@Alberth>setting dparam etc
11:02<@Alberth>_dp_: can't make it stop growing?
11:02<Wolf01>I'll try to look why it changes between the 2 versions of the spacer
11:03<_dp_>Alberth, there is special flag to stop growing
11:03<@Alberth>so just stop it temporarily in GS? :)
11:03<Wolf01>I was about to ask "were it dups the stuff?" then I noticed the wall-o-text
11:03<_dp_>Alberth, sure, that's what GS should be doing
11:03<@planetmaker>well, seems I don't have dorpsgek admin power
11:04-!-blocage [] has quit [Ping timeout: 480 seconds]
11:04<@Alberth>dorpsgek is a bit picky :)
11:04<@Alberth>doesn't always obey the regular authorities :)
11:05<_dp_>Alberth, that's why I think it's fine to drop compatibility there
11:06<@Alberth>tbh I don't know if it's worth the trouble, 1/250 days, is pretty much once a year
11:07<@Alberth>at that rate you get nowhere in a competition
11:07<TrueBrain>Alberth: who did give you commit permission? (Sorry, reading old thread)
11:08<_dp_>Alberth, what's worth? I want to allow faster speeds but instead of switching to uint32 I think of dropping slower ones
11:08<Wolf01>WTF, they removed the diff tool from NP++?
11:08<@Alberth>TrueBrain: there is small yet distinct difference between real authorities and regular authorities :p
11:09<TrueBrain>I am afraid they overlapped in this case :P
11:09<@Alberth>RB asked me
11:09<TrueBrain>(sorry, you made me giggle hard, with your: somebody stupid enough :D)
11:10<_dp_>Alberth, so it's basically slow speeds vs 2 extra bytes per town and some more code
11:10<@Alberth>TrueBrain true reason was that he was fed up adding my patches :p
11:10<TrueBrain>as how things go :)
11:11<TrueBrain>also holds for regular work ... if you ask the same people to do your stuff over and over, sooner or later they just give you access :D
11:11<frosch123>you can also forward questions to them
11:12<frosch123>"no time, just ask that other guy", i always wonder whether that chains
11:12<TrueBrain>at my work, that chains pretty quickly :D
11:13<TrueBrain>"ask that guy" - "he told me to ask you"
11:13<frosch123>does it go in circles?
11:13<TrueBrain>its always the hope they ask me first
11:13<Wolf01>HA! Alberth:
11:14-!-blocage [] has joined #openttd
11:14-!-blocage is "Benoit Gschwind" on #gcc #openttd
11:14<TrueBrain>Wolf01: wtf is wrong with you? THAT NESTING! :P
11:15<Wolf01>It's a dump
11:15<@Alberth>Wolf01: so the text-widget grew, now what?
11:15<TrueBrain>please keep those in toilets
11:15<@Alberth>ie it doesn't point to the cause
11:15<Wolf01>The spacer enabled the fill on NWID_HORIZONTAL and NWID_VERTICAL
11:16-!-Flygon [] has quit [Read error: Connection reset by peer]
11:16<TrueBrain>omg, even Darkvater replied on the forums? I totally forgot about how (SORRY!) .. blast from the past, damn
11:16<@Alberth>I am surprised you get only one line change then
11:16<frosch123>TrueBrain: at work we have a legacy/deprecated configuration file format named "dump" :p
11:17<TrueBrain>that is why I always clal my configuration files .data
11:17<TrueBrain>just so I know it will piss off the next person
11:17-!-jinks [~jinks@] has quit [Quit: ZNC -]
11:18<Wolf01>Alberth: By default they don't fill horizontally, so I should put SetFill(1,1) on the containers and not the spacer
11:19<@Alberth>Wolf01: oh sorry, that white line is the cursor, all yellow is change
11:19<@Alberth>except containers derive from child widgets, so no
11:20<@Alberth>ie containers have no size of themselves, it's all from their childs
11:20-!-jinks [~jinks@] has joined #openttd
11:20-!-jinks is "Got ZNC?" on #openttd #awesome
11:20<@Alberth>the panel is a bit in-between, so it can have size
11:20<Wolf01>Like in html, empty div is invisible
11:22<@Alberth>what you see is the spacer setting made resize consistent in its container, so it gets propagated upwards
11:23<Wolf01>Ok, it's right
11:23<Wolf01>The problem is not shown there, widgets are just smaller in the right
11:24<Wolf01>The only difference is the fill enabled on the spacer
11:26<@Alberth>yep, while the dump has all the numbers, it's still not quite trivial to found the problem
11:26<@Alberth> <bleh/>
11:27<TrueBrain>ugh, I am always reminded why I nowedays dislike IRC when I try to do things for OpenTTD :P (sorry :D Last project standing for me ... :D)
11:28<TrueBrain-Bot>which reminded me I had a discord bridge 😄
11:28<TrueBrain-Bot>one which does smilleeeyyyssssssss
11:28<LordAro>oh dear
11:29<TrueBrain-Bot>well, you know how much I love my smilies 😃
11:29<@Alberth>like :bleh: ?
11:29<TrueBrain-Bot>yup! Pretty and all 😃
11:29<TrueBrain-Bot>I love how my IRC client doesn't understand UTF8 😛
11:29<@Alberth>mine does :)
11:29<LordAro>sounds like you need a better client
11:29<Wolf01>Mine too
11:29<Wolf01>Or just change font
11:30<TrueBrain-Bot>I don't need a better client; you guys need to stop living in 1990 😛 😛
11:31<LordAro>you disappoint me, TrueBrain
11:31<TrueBrain-Bot>as I should!
11:31<LordAro>fair point
11:31<TrueBrain-Bot>happy we could keep this brief 😃
11:31<Wolf01>mIRC is old but still works, I don't miss smileys and images, ok, maybe images yes
11:32<Wolf01>For smileys there's always (extended)ascii art
11:32<Wolf01>ᕕ( ᐛ )ᕗ
11:33<TrueBrain-Bot>mIRC .. lol ..
11:33<LordAro>(╯°□°)╯︵ Ɩ0ɟloM
11:33<TrueBrain-Bot>sorry, my grandpa called, he said he wants mIRC back
11:34<@planetmaker>honestly... I'm not sure I find other chat options really nicer than IRC
11:34<@planetmaker>they don't really work better
11:34<TrueBrain-Bot>no, you just need to get used to them 😃
11:34<Wolf01>Also I have many (one) friend on irc
11:34<TrueBrain-Bot>but having multiple devices working in sync ... its so lovely ...
11:35<@planetmaker>yeah... but change for the sake of it?
11:35<TrueBrain-Bot>not having to be online 24/7 for your client to track everything ....
11:35<TrueBrain-Bot>change is good!
11:35<@planetmaker>I don't ... that's a bouncer for
11:35<TrueBrain-Bot>and clients rarely understand bouncers
11:35<Wolf01>When discord will support whatsapp and telegram too I could try it
11:35<TrueBrain-Bot>so you see the timestamp of your connect 😛
11:35<@planetmaker>I do
11:36<TrueBrain-Bot>but, this always reminds me of XKCD: .. I think it is true ..
11:36<@planetmaker>for the love and hate, there's so many chat options. And every and anyone wants and likes another. But neither talks nicely to a 2nd one
11:36<@planetmaker>such a pain
11:36<LordAro>irssi 4 lyfe
11:36<TrueBrain-Bot>hence my IRC <-> Discord bridge 😄
11:36<TrueBrain-Bot>fuck you oldies 😛 (but I do love you guys)
11:37<@planetmaker>tehehe :)
11:37<@planetmaker>sure that's true
11:37<LordAro>how much does matrix do these days?
11:38<@Alberth>online 24/7 is grossly over-estimated :p
11:39<TrueBrain-Bot>sorry, I couldn't hear youover this IRC wire
11:39<TrueBrain-Bot>*trolls happily*
11:39<LordAro> is more relevant
11:39<TrueBrain-Bot>why more? why being so insulting? omg! Learn manners! 😄
11:39<LordAro>which doesn't even have discord on it
11:39<LordAro>^ discord user right there
11:39<Alkel_U3>I tried the weechat-matrix plugin but in this particular case it's pretty difficult to get encryption. Other than that I think Matrix has what it takes to eventually replace IRC
11:40<TrueBrain-Bot>I am pretty sure I am bored ... so I will annoy you guys a bit more 😃
11:40<Alkel_U3>well, not counting resistance to change :P
11:40<LordAro>yeah, i think matrix has potential
11:40<LordAro>but it's not ready yet
11:40<TrueBrain-Bot>"eventually replace IRC" .. THERE IS NO REPLACING IRC! 😦
11:40<@planetmaker>oh, so true @ LordAro :)
11:41<@planetmaker>maybe I should give pidgin a try
11:41<LordAro>frosch123: didn't you say you had issues connecting to the compile farm? while TrueBrain's here and all, might be worth looking into...
11:41<frosch123>oh, those were fixed
11:41<TrueBrain-Bot>he bugged me already 😛
11:42<TrueBrain-Bot>and I tried to finish my OSX cross-compiler in Docker
11:42<TrueBrain-Bot>only to find out it still doesn't work 😦
11:42<@planetmaker>or again doesn't. It's not like OSX is a fixed target ;)
11:42<TrueBrain-Bot>it tried to compile a system library against OpenTTD .. which for some reason was not compatible ... (a x86_64-linux library against 10.8 OSX :P)
11:42<frosch123>LordAro: my plan is to make tb publish what is done and what needs doing, and then you to finish it :)
11:43<TrueBrain-Bot>owh, is he the victim? Gooooddddd 😛
11:43<TrueBrain-Bot>planetmaker: which is a good point .. do we support OSX?
11:43<frosch123>TrueBrain-Bot: he explored external compile services and setup like 5 targets
11:43<TrueBrain-Bot>10.3.9 - 10.5
11:44<frosch123>TrueBrain-Bot: it works for those who compile themself
11:44<TrueBrain-Bot>yeah .. cross-compiling is really tricky
11:44<TrueBrain-Bot>even more with 10.12
11:44<frosch123>people who use the binaries report crashes regulary, which may be related or may not
11:44<LordAro>and apparently i got rid of the actual circleci stuff, let me readd
11:44<TrueBrain-Bot>ah, CI stuff
11:44<TrueBrain-Bot>that is good
11:45<TrueBrain-Bot>I have most stuff for releases (except OSX) ready
11:45<TrueBrain-Bot>wait, I was trying to order food
11:46<frosch123>get your priorities right :)
11:46<TrueBrain-Bot>I am! Which makes me more hungry ..
11:47<@Alberth>order more ?
11:47<TrueBrain-Bot>it is the time it takes
11:47<TrueBrain-Bot>which is the issue
11:48<frosch123>Alberth: interesting singularity, whenever half of the order time passed, order agani
11:48<TrueBrain-Bot>and take-out is by 15 minutes, so because I missed 17:45, I can now only pick itup at 18:15, instead of 18:00
11:48<@Alberth>oh dear
11:49<LordAro> there we go
11:50<TrueBrain-Bot> and there I go
11:50<TrueBrain-Bot>it doesnt fully work yet, because we copy our debian files outside the source directory .. and than you have permissions to fix in docker
11:50<TrueBrain-Bot>which is annoying
11:51<@Alberth>frosch123: now if delivery time also halves each time...
11:51<TrueBrain-Bot>and OSX fails to do compile-rt on 10.8, but 10.6 build-ish .. only the endianness is wrong
11:51<@Alberth>not sure you want to be around when you hit 0 :)
11:51<TrueBrain-Bot>frosch123: that is all I have for now; if we have working Docker-files, I can fix up the CF easily
11:52<TrueBrain-Bot>(but moving to git (or even github) might not be the worst idea either :D)
11:53<frosch123>well, we can only run so many payed services
11:53<LordAro>< Alberth> grumbly noises
11:53<frosch123>the admin effort is likely exponential
11:54<TrueBrain-Bot>owh, and btw, we really need someone who redoes both our website and BaNaNaS
11:54<TrueBrain-Bot>it is getting really old ... 😄
11:54<frosch123>so, a single server is easier to purchase every year, than 2 different compile farms (circleci does not do windows) and a main server
11:54<frosch123>yeah, the bananas thing is a mistery to me
11:54<TrueBrain-Bot>ah, yes; we got a bit hijacked into two conversations
11:55<TrueBrain-Bot>we can run the CF ourself just fine
11:55<TrueBrain-Bot>it is more the subversion which is annoying 😄
11:55<frosch123>there should be so many web-cruds, why does noone volunteer?
11:55*LordAro tentatively raises his hand
11:55<TrueBrain-Bot>a docker-based CF is piss-easy to maintain, so 😃
11:55<LordAro>TrueBrain-Bot: yeah, but cross compiling is so ew
11:55<frosch123>TrueBrain-Bot: we kind of do not need subversion anymore
11:55<TrueBrain-Bot>go git, go git
11:56<TrueBrain-Bot>LordAro: Windows also supports docker 😃
11:56<frosch123>the old argument "linear version number" is kind of deprecated, noone uses that anyway
11:56<LordAro>semver for releases still holds strong, however
11:56<TrueBrain-Bot>host code at github, easy PR and all that easy shit
11:56<TrueBrain-Bot>or ... we can install gitlab/github enterprise/bitbucket server
11:56<TrueBrain-Bot>which .. kinda works too I guess 😛
11:56<LordAro>gitlab does come with its own CI stuff
11:57<frosch123>i would go for host less ourself :)
11:57<TrueBrain-Bot>and bug tracker, and ...
11:57<LordAro>and i know i guy who works there
11:57<TrueBrain-Bot>frosch123: that is wha tI am aiming for yes 😄
11:57<LordAro>a guy*
11:57<TrueBrain-Bot>I know a girl who worked there! HIGH FIVE!
11:57<TrueBrain-Bot>gitlab is nice, but I wonder if they support squasing by now ....
11:57<TrueBrain-Bot>sometimes it are those silly things ...
11:58<LordAro>tbf, github only got it a year or so ago
11:58<TrueBrain-Bot>I know 😦
11:58<TrueBrain-Bot>BitBucket Server still doesnt' have it
11:58<TrueBrain-Bot>well, -ish
11:58<TrueBrain-Bot>it is such a wonderful feature ...
11:58<TrueBrain-Bot>but in BitBucket Server you cannot change how the commit message looks
11:58<TrueBrain-Bot>which is stupid
11:58<TrueBrain-Bot>gitlab has stupid stuff too
11:59<TrueBrain-Bot>GitHub Enterprise is hilarious .. comes as an Appliance ... you need VMWare ...
11:59<TrueBrain-Bot>I laughed my ass off, twice
11:59<TrueBrain-Bot>let me find that vendor-lock switch
11:59<TrueBrain-Bot>owh, there it is
12:00<@planetmaker>TrueBrain, dunno whether we support it. I don't really have any working Mac hardware anymore
12:00<TrueBrain-Bot>honestly, things like GitHub (or BitBucket for all I care) makes things easier .. you no longer need FS etc .. all in one place
12:00<TrueBrain-Bot>lovely client-applications
12:00<LordAro> ¯\_(ツ)_/¯
12:01<TrueBrain-Bot>yes, lets put OpenTTD in a CD
12:01<TrueBrain-Bot>you auto-deploy a new version to all systems
12:01<TrueBrain-Bot>which have OpenTTD installed 😄
12:01<TrueBrain-Bot>but we can indeed run GitLab ourself (I refuse to run GitHub Enterprise, sorry)
12:02<TrueBrain-Bot>still better than having a FS which is disconnected from the source tbh 😃
12:02<TrueBrain-Bot>integration is POWERFULLLLLL 😄
12:02<LordAro>^ amen to that
12:02<TrueBrain-Bot>just my 2 cents .. 😄
12:02<TrueBrain-Bot>time to get my fooddddd
12:02<TrueBrain-Bot>I have annoyed you guys enough 😛
12:03<LordAro>i'm not entirely convinced you're not hammered
12:03<LordAro>but o/
12:03<TrueBrain-Bot>owh, PS: frosch123: another approach is going for AWS etc .. 😄
12:03<TrueBrain-Bot>there is your proof LordAro 😄
12:04<frosch123>meh, i am too nooby to get jokes in that area :/
12:05<LordAro>i'm not sure OTTD has enough money for AWS
12:05<TrueBrain-Bot>Who said I was joking?
12:05<TrueBrain-Bot>Most likely cheaper tbh
12:05-!-planetmaker [] has left #openttd []
12:05<TrueBrain-Bot>I can do that math ...
12:06<LordAro>really? i have to admit i've never looked into it significantly myself
12:06<LordAro>i've always got the impression it was expensive though
12:07<@DorpsGek>Commit by adf88 :: r27902 trunk/config.lib (2017-08-27 18:07:24 +0200 )
12:07<@DorpsGek>-Feature [FS#6614]: Preserve PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR environment variables in config.cache file (just like other variabes CFLAGS, LDFLAGS etc.) so they can be resused when OpenTTD re-configures itself
12:07<LordAro>grats on the promotion, adf88
12:08<frosch123>LordAro: see, you have the chance to become cf admin :)
12:08-!-planetmaker [] has joined #openttd
12:08-!-mode/#openttd [+o planetmaker] by ChanServ
12:08-!-planetmaker is "Ingo von Borstel" on @#openttd
12:08<frosch123>so many career paths without payment
12:08-!-planetmaker [] has left #openttd []
12:09<TrueBrain-Bot>Plenty of those :D
12:09<TrueBrain-Bot>Gratz adf88
12:09<TrueBrain-Bot>And only expensive is the CF
12:11<TrueBrain-Bot>Still would need a new website and BaNaNaS :D
12:11<LordAro>what's particularly wrong with the website & BaNaNaS?
12:11<TrueBrain-Bot>Django 1.2 .. nuff said
12:12<TrueBrain-Bot>Python 2.5 ...
12:12-!-planetmaker [] has joined #openttd
12:12-!-mode/#openttd [+o planetmaker] by ChanServ
12:12-!-planetmaker is "Ingo von Borstel" on @#openttd #openttdcoop.devzone
12:12<frosch123>LordAro: users cannot rename stuff, lots of other missing features
12:12<TrueBrain-Bot>Site from 2009 ...
12:12<milek7>what's wrong with site from 2009?
12:12<TrueBrain-Bot>The design still stands, funny enough
12:13<frosch123>@calc 365*2*10*2*0.005
12:13<@DorpsGek>frosch123: 73
12:14<TrueBrain-Bot>I did rebuild it in Angular2 .. but we have users without Javascript :D
12:14<frosch123>aws compile farm would cost us 70$/year
12:14<frosch123>that's way cheaper than the other offers
12:14<frosch123>but i think they do not compile for windows either
12:14<TrueBrain-Bot>Sounds about right
12:14<milek7>appveyor is free
12:15<LordAro>yeah, need to investigate appveyor
12:15<frosch123>otoh, we already have a server :p
12:18<TrueBrain-Bot>let me rephrase than: if we can switch to git, other possibilities besides FlySpray open up 😄
12:19-!-mescalito [] has joined #openttd
12:19-!-mescalito is "realname" on #openttdcoop #openttd
12:20<@planetmaker>can't say that I'd find that terrific... but it might actually be of advantage
12:20<LordAro>ultimately it's obviously up to you guys with the little '@' next to your names, but i think it'd be a good thing overall
12:20<LordAro>github does even have a svn bridge :p
12:20<TrueBrain-Bot>he is an hg fan 😛
12:20<TrueBrain-Bot>those still exist 😄
12:20<@planetmaker>it would mostly require some thoughts on how to handle the versioning scheme of OpenTTD
12:21<@planetmaker>yes, they do ;)
12:21<frosch123>all of the reasonable patchpacks use git
12:21<@Alberth>switch to random 40 digit hex numbers
12:21<LordAro>i see no reason why stable version needs to change at all
12:21<LordAro>nightly might be a bit trickier, but datestamp is feasible
12:21<frosch123>so, git/github are obvious options
12:21<frosch123>it's just a lot of migration work, that would break everything for a while :p
12:21<@Alberth>pretty close to the only options
12:22<LordAro>anything else can use the 10(?) digit hex value that they do already
12:22<TrueBrain-Bot>migration? 😄
12:22<@planetmaker>stable versions don't need much change. But the nightly builds etc need a continuous numbering
12:22<TrueBrain-Bot>we already support git and hg
12:22<@Alberth>LordAro: 7 iirc :)
12:22<frosch123>planetmaker: not really
12:22<@planetmaker>and for NewGRF versions for NewGRFs to decide where they run on
12:22<TrueBrain-Bot>we only need to do something like: 7.0-123
12:22<TrueBrain-Bot>where 123 is the amount of commits since 7.0 😄
12:22<frosch123>noone uses that, we can just drop the linear version
12:22<@planetmaker>LordAro: *that* doesn't work even for NewGRFs
12:22<LordAro>gonna be a lot larger than the current ~27000
12:22<frosch123>stable version is enough
12:22<LordAro>why not?
12:23<@planetmaker>is there something like stable-commits-since-last-stable?
12:23<@planetmaker>or so for the 73rd commit based on 1.7.3
12:23<TrueBrain-Bot>litterly what I just said 😛
12:24<@planetmaker>but... it might be ambiduous when there's two branches... but name them differently. dev and stable or so
12:24<LordAro>i mean, since 1.7.3 doesn't make much sense because of branch
12:24<LordAro>but 1.7.0 could work
12:24<LordAro>but... why?
12:24<frosch123>TrueBrain-Bot: with migration i mean stuff like compilefarm, eints, hg/git bridges, ...
12:24<TrueBrain-Bot>you dont branch like that
12:24<TrueBrain-Bot>you branch 1.7, not 1.7.3
12:24<TrueBrain-Bot>you tag 1.7.3
12:24<TrueBrain-Bot>so you get 1.7.3-131
12:24<@planetmaker>yes, of course
12:24<TrueBrain-Bot>which goes fine with multiple branches
12:24<@planetmaker>but the current trunk won't be 1.7.3-131, but... what would it be?
12:25<TrueBrain-Bot>just not multiple repos 😄
12:25<LordAro>oh, i see
12:25<frosch123>planetmaker: trunk is 1.8
12:25<LordAro>so trunk would be 1.8.0-foobar
12:25<frosch123>that's already the case today
12:25<TrueBrain-Bot>trunk is 1.8-dev-123 or so 😛
12:25<@planetmaker>but not yet tagged
12:25<frosch123>but already in
12:25<@planetmaker>yeah... probably like TB says
12:25<frosch123>and the number would not start at branching of 1.7, but at r0
12:25<TrueBrain-Bot>CF already supports git
12:25<TrueBrain-Bot>we compile from GitHub
12:26<frosch123>we do? :o
12:26<TrueBrain-Bot>hg bridge ... maybe time to say: sorry, not sorry
12:26<TrueBrain-Bot>eints .. no clue 😄
12:26<frosch123>eints does support git iirc
12:26<LordAro>well hg-git is a thing
12:26<TrueBrain-Bot>frosch123: some patchpacks compile from github
12:26<TrueBrain-Bot>not trunk 😃
12:26<@planetmaker>hg-git works mostly
12:27<@planetmaker>eints... we shall see. But likely no deal breaker
12:27<frosch123>eints runs with git projects on devzone
12:28<TrueBrain-Bot>I hear nobody complaining, so .. we can draw up a small plan?
12:28<TrueBrain-Bot>we just need to figure out what to use to host git
12:28<TrueBrain-Bot>(github, gitlab, BitBucket, BitBucket Server, ..)
12:28<TrueBrain-Bot>direct hosted ... *facepalm*
12:29<frosch123>we are already on github and all patches are there
12:29<LordAro>i would personally suggest gitlab over github
12:29<TrueBrain-Bot>gitlab allows eaiser CI
12:29<LordAro>purely for the builtin CI
12:29<frosch123>though i guess in the end it does not matter
12:29<TrueBrain-Bot>but github is more mainstream
12:29<@Alberth>planetmaker: I tried that with github, it technically works, but don't try to do thing the hg way too much, in my experience
12:29<TrueBrain-Bot>so there is a balance
12:29<frosch123>would we use the webinterface to commit stuff, or still push to, which then syncs?
12:30<milek7>github cannot be self-hosted
12:30<TrueBrain-Bot>frosch123: I prefer the first, not the latter
12:30<frosch123>in the latter case it does not matter whether github/lab, we can just sync both
12:30<TrueBrain-Bot>milek7: GitHub Enterprise is not on the table; I am not vendor-locking to VMWare 😛
12:30<TrueBrain-Bot>I prefer to use PRs and accept patches like that
12:30<TrueBrain-Bot>instead of pushes by "those who have the keys"
12:30<LordAro>gitlab does have the ability to sync from an external source
12:31<TrueBrain-Bot>(in other words, no raw access to the underlaying git repos directly)
12:31<LordAro> oh hey
12:31<milek7>gitlab problem is that its interface feels wrong
12:31<TrueBrain-Bot>it only feels wrong because you are used to github 😄
12:32<TrueBrain-Bot>takes a bit of time to get used to
12:32<@Alberth>TB gitlab/hub has the concept of protected branch, which solves that
12:32<TrueBrain-Bot>same for BitBucket Server I noticed 😛
12:32<TrueBrain-Bot>Alberth: exactly
12:32<milek7>it looks like somebody designed it for phones, and than used that on desktop browsers
12:32<@Alberth>and I am +1 to that policy :)
12:32<LordAro> hmm
12:32<TrueBrain-Bot>frosch123 asked if we sync to github after a push to local git .. tha tI rather don't 😃
12:32<TrueBrain-Bot>from experience, the software to use is rather up-to-taste .. they all have issues and benefits
12:32<@Alberth>milek7: it's github, but nobody is really designing a CSS for it
12:33<TrueBrain-Bot>but wanting to switch to a frontend before git, is the main switch 😃
12:35<TrueBrain-Bot>for me, gitlab vs github is more about: who is going to maintain what? 😃
12:35<TrueBrain-Bot>but I am lazy 😄
12:36<@Alberth>first 3 or so pages you can safely skip :)
12:36<TrueBrain-Bot>for no reason what-so-ever we are at step 3 😛
12:37<TrueBrain-Bot>4 even 😄
12:37<TrueBrain-Bot>just github things I made all those commits .. it keeps giving people who follow me notificatiosn I pushed those commits 😄
12:37<TrueBrain-Bot>which makes me giggle every single time 😃
12:39<LordAro>so, the next step is to decide between,, or gitlab self hosted
12:39<@planetmaker>Alberth: yes... you cannot work too much with what makes hg actually nice. I know :(
12:39<LordAro>(or bitbucket, i guess)
12:39<TrueBrain-Bot>LordAro: first choice is: git, yes/no. Than: frontend before git yes/no. Only than you can talk about what software 😃
12:39<TrueBrain-Bot>the software is a minor detail
12:40<TrueBrain-Bot>frontend allows more restrictions, easier configuration, PR tracking, comment tracking, etc
12:41<LordAro>there's no reason to switch to git without having the frontend in place, otherwise there's just no point
12:41<@planetmaker>kallithea :)
12:42<TrueBrain-Bot>I agree LordAro. But consensus is important 😃
12:42<@planetmaker>or rhodecode... they changed their policy again to be (a)gpl. Not sure I can trust that, though
12:42<LordAro>kallithea looks a bit dead, in terms of releases
12:42<@planetmaker>but tbh... having pull requests working is a big bonus. But that's likely supported by everything
12:43<TrueBrain-Bot>PRs are so cool 😄
12:43<TrueBrain-Bot>no more .patch files in a bug-tracker (?!?!?!?! :D)
12:43<LordAro>what about .diff files?
12:43<@planetmaker>oh, I think one should still accept those
12:43<@planetmaker>however... no need for those
12:44<TrueBrain-Bot>nobody should accept those 😛 Make a PR or go away 😛
12:44<TrueBrain-Bot>giving feedback on a static file is so 1990 😄
12:45<@planetmaker>giving feedback on a dynamic file is not exactly something which works. Having the possibility to comment on the code on a per-line basis would be a big pro
12:45<LordAro>i'd say that there would be the occasional person who would be opposed to git(hub/lab/w/e), but if the issues is also hosted on this frontend...
12:45<@planetmaker>be that the diff or the code itself... in the latter case it needs proper highlighting of what changed
12:46<TrueBrain-Bot>so yeah ... BitBucket vs BitBucker Server vs Gitlab vs GtHub 😄
12:46<TrueBrain-Bot>Python went to GitHub .. just saying
12:47-!-FLHerne [] has quit [Ping timeout: 480 seconds]
12:47<_dp_>is there anything that didn't go to github?
12:48<_dp_>figured :p
12:48<_dp_>anything else?
12:48<TrueBrain-Bot>BitBucket has more than a few
12:48<LordAro>planetmaker: have you seen github code reviews lately? they're getting rather good, and can cope with the file changing underneath it
12:49<TrueBrain-Bot>I think going GitHub with the CF self-hosted is the easiest/most-robust way to go
12:50<_3298><_dp_> is there anything that didn't go to github? <- freedroidrpg seems to be on gitlab
12:50<LordAro> openage have one of the best github integration setups i've seen
12:50<LordAro>and they manage to get people to rebase their PRs too :)
12:50<TrueBrain-Bot>there is a button for that 😛
12:50<_dp_>_3298, never heard of that one :p
12:51<LordAro>TrueBrain-Bot: yeah, but history is sometimes better than just squashing everything down
12:51<TrueBrain-Bot>I know 😃
12:51<TrueBrain-Bot>most of my projects work with forced fast-forward no-commit merges (read: REBASE)
12:51<_3298>i found that game one day browsing my distro's games, doesn't look very active
12:51<LordAro>they're also slightly insane, given they're designing their own data description language and have built their own CI server
12:52<TrueBrain-Bot>we would NEVER do that
12:52<TrueBrain-Bot>*looks at NewGRF*
12:52<TrueBrain-Bot>*looks at CF*
12:52<TrueBrain-Bot>*goes sit in a corner*
12:52<TrueBrain-Bot>Compile Farm
12:53<TrueBrain-Bot>OpentTD is fully self-hosted
12:53<TrueBrain-Bot>back in those days, you only had SourceForge
12:53<TrueBrain-Bot>and ugh ..........
12:53<@planetmaker>LordAro: not so much... I still like self-hosted repo really
12:54<LordAro>i get it, there's definitely a lot of appeal to self-hosting
12:54<@planetmaker>however, I'm not to complain if for simplicity's and less work's sake GitHub hosting is chosen...
12:54<TrueBrain-Bot>what do you like about it? (more than just liking it, ofc)
12:54<TrueBrain-Bot>(serious question btw; not trying to be funny etc)
12:54<TrueBrain-Bot>(very bad I have to add that to my question :D)
12:55-!-Alberth [] has quit [Ping timeout: 480 seconds]
12:55<LordAro>being in full control of it is my main one. there are certain aspects that github still hide away from you
12:55<TrueBrain-Bot>why is it important to be in full control?
12:55<TrueBrain-Bot>what is the gain?
12:55<LordAro>(although now that you can rebase and suchlike, most of thsoe aspects have gone away)
12:55<@planetmaker>it's in our hands, we don't need to rely on 3rd-party. No vendor-lock-in. The source is our most precious asset. That's the project
12:56<TrueBrain-Bot>I understand; just do realise we currently are vendor-locked, in terms of: all bug-tickets are in FS
12:56<@planetmaker>Yes, the whole repo is everywhere, whoever has a clone.
12:56<LordAro>but ultimately, if github were to suddenly disappear from the internet, we'd have a backup somewhere
12:56<TrueBrain-Bot>but if you only look at code, you are right 😃
12:56<LordAro>currently there's only a couple svn repos
12:56<TrueBrain-Bot>LordAro: currently we backup our source over 3 continents .. we will keep doing that 😃
12:57<@planetmaker>TrueBrain yes... the bug tracker is the dark duck in our barn... kinda
12:57<@planetmaker>we did loos Alberth :(
12:57<TrueBrain-Bot>owh no, go get him back! QUICK!
12:57<milek7>when it breaks during update you can just spend few hours fixing it, instead of waiting and complianing it is broken :p
12:57<TrueBrain-Bot>LordAro: OpenTTD once lost its source ... never again 😃
12:57<TrueBrain-Bot>not on my watch, at least 😛
12:58<TrueBrain-Bot>"just spend few hours" .. if you can fix it .. and if you have the expertise .. 😉
12:58<TrueBrain-Bot>fixing broken VCSes is hoping you know what the fuck you are doing 😄
12:58<@planetmaker>and the time, really
12:58<@planetmaker>it's not like anyone is paid to do that... thus work work might interfere
12:58<_dp_>Am I the only one who feels that openttd has much greater chance of dying than github or anything of that caliber?
12:59<TrueBrain-Bot>but we also had incidents like: our server was down .. took 24h+ to get it back online (someone pushed the power-off button in the DC)
12:59<TrueBrain-Bot>_dp_: OpenTTD is alive longer than GitHub ..
12:59<@planetmaker>_dp_: sure, gibhub has a big audience. But that's not the reason to have our *primary* repo there, is it?
13:00<TrueBrain-Bot>I think the main thing is, what-ever we pick, that we have to migrate our bugs (or don't, ofc)
13:00<TrueBrain-Bot>so we want to minimize the chance of that being done again 😃
13:00<LordAro>we wouldn't move to github/lab purely for git, we'd move for their frontends and whatever integrations that they bring
13:00<TrueBrain-Bot>and bug tracker! 😛
13:00<@planetmaker>(19:00:29) LordAro: we wouldn't move to github/lab purely for git, we'd move for their frontends and whatever integrations that they bring
13:00<@planetmaker>^^^ very much so
13:00<LordAro>TrueBrain-Bot: good thing andy's cut the number of open bugs in half them :)
13:00<TrueBrain-Bot>just one place to do it all 😛
13:01-!-Cubey [] has joined #openttd
13:01-!-Cubey is "Jaybar" on #openttd
13:01<TrueBrain-Bot>also easier for others to work on the project etc
13:01<TrueBrain-Bot>left or right, the thing we can already do, is test our software with git
13:02<TrueBrain-Bot>for example,we can switch the nightly to GitHub .. not that we have to use GitHub, but because git is already on there
13:02<TrueBrain-Bot>(or our internal git, from which GitHub is pushed)
13:02<TrueBrain-Bot>same for eints, etc
13:02<TrueBrain-Bot>(just the read part)
13:02<TrueBrain-Bot>that allows us to figure out shit like versions etc
13:03<TrueBrain-Bot>and given I am moving houses, I won't have time for that the next 2 weeks from my side .. which gives you guys plenty of time to think this over a few times 😄
13:03-!-Alberth [] has joined #openttd
13:03-!-mode/#openttd [+o Alberth] by ChanServ
13:03-!-Alberth is "purple" on @#openttd
13:03<TrueBrain-Bot>ALBERTH IS BACK! 😄
13:03<@planetmaker>welcome back, Alberth :)
13:04<@Alberth>somewhat flakey connection
13:05<@planetmaker>I somewhat feared you found the git topic annoying :D
13:05<@Alberth>nah, I use git daily, pretty much
13:05<@planetmaker>oh, ok
13:05<@planetmaker>so much changed :P
13:06<frosch123>planetmaker: according to google trends hg was most popular in 2011, which is also when ottd development was most popular
13:06<@Alberth>well, not sure it's a very sane tool, but it works
13:06<frosch123>so it really was just us :p
13:07<milek7>btw. what vcs use for 10gib of assets? git?
13:07<@Alberth>I still use patch queues in openttd though
13:07<TrueBrain-Bot>file storage
13:07<TrueBrain-Bot>assets should never hit any VCS
13:07<TrueBrain-Bot>they are .. assets 😃
13:07<milek7>uh, but assets also have history :P
13:07<LordAro> became a thing recently
13:07<LordAro>no idea how well it works
13:08<TrueBrain-Bot>assets have history .. in a relational database 😛
13:08<TrueBrain-Bot>ffs 😄
13:08<TrueBrain-Bot>you don't diff assets
13:09<@Alberth>you just store the new version next to the old one, each time
13:09<@Alberth>disks are around 1TB minimum size nowadays
13:11<_dp_>Alberth, there is never enough disk space :p
13:11<milek7>but why store old assets in the same tree?
13:11<milek7>and how to pack assets for users to download then
13:12<TrueBrain-Bot>look in the BaNaNaS source code! 😄
13:15<@Alberth>just send the users a hard disk
13:15<milek7>(i'm asking because in obscure train simulator we migrated assets from svn to git, but git method of packing everything into monolithic 10gib archive for download seems to be causing problems for people with poor connections)
13:16<TrueBrain-Bot>git, like SVN, should only be used for source code tbh .. anything binary you should prefer to keep outside a VCS; you have bette rsystems for that
13:17<TrueBrain-Bot>this is mainly because VCSes are really good in diffing, and you rarely want to diff binaries (in a visual way)
13:17<TrueBrain-Bot>that said, there are solutions .. never played with those 😃
13:17<TrueBrain-Bot>BaNaNaS stores things based on an unique number and hash
13:17<LordAro>milek7: shallow clones are a thing
13:17<LordAro>and svn can cope better with binary files than git because it's a checkout, rather than a clone
13:18<LordAro>but yeah, ideally you don't put binaries in VCS
13:18<TrueBrain-Bot>I know companies where you need 4 (!) hours of 1 gbit/s to do a single SVN checkout 😄
13:18<TrueBrain-Bot>I laughed my ass off 😄
13:18<LordAro>that's... no
13:18<LordAro>just don't do that
13:18<TrueBrain-Bot>^^ 😄
13:18<@Alberth>git-lfs is one solution, but there are others too, never needed any of those however
13:18<LordAro>that's what you need a shared filesystem for
13:20<Wolf01> cool
13:20<milek7>so throw it into server with ftp, and optionally preserve history with lvm snapshots? :p
13:20<TrueBrain-Bot>ftp? What is that?
13:22<@Alberth>milek7: do a search, "git large binary files" or so, and it will give you ways to go about this problem
13:22<Wolf01> what the fuck?
13:23<@Alberth>TB pre-90s I think, can't be relevant with discord
13:23<LordAro>ew, ftp
13:23<@Alberth>when security was a non-issue :p
13:24<TrueBrain-Bot>its like casettes 😄
13:24<@Alberth>hmm, have used those too, at a 2400 baud :p
13:24<@Alberth>or was it 1200?, don't remember
13:27<frosch123>Wolf01: what? i expected lego
13:27<Wolf01>Eh, I like trains too ;)
13:34*_dp_ needs a new keyboard
13:34<_dp_>smashing old one no longer fixes it :(
13:34<TrueBrain-Bot>and smashing the current?
13:36<_dp_>currently using laptop one and I'm afraid to break something else if I smash it :p
13:36<TrueBrain-Bot>I just find it weird that you smash something old in hope to fix something current, and claim that you need something new because of that
13:36<TrueBrain-Bot>your logic is simply flawed 😛
13:37<_dp_>if anything is flawed it's my english :p
13:40<Wolf01>I should change back to white background, inverted colours smiles are terrible
13:41<frosch123>can you ready them anyway?
13:41<Wolf01>Aaaaaargh my eyes hurt... back to night mode
13:41<frosch123>i always failed to distingush emoji past :) and :(
13:43-!-blocage [] has quit [Quit: Leaving]
13:44-!-blocage [] has joined #openttd
13:44-!-blocage is "Benoit Gschwind" on #openttd #gcc
13:50<frosch123>though i like the vomit-modifier
13:58<@adf88>what's the default target CPU arch in VS?
13:58<@adf88>in OpenTTD project files
14:08-!-FLHerne [] has joined #openttd
14:08-!-FLHerne is "Francis Herne" on #openttd
14:14<V453000>sup huminz
14:32<Wolf01>adf88 win32
14:36<blocage>how does sprite_id map to file ?
14:36<frosch123>check the sprite aligner window?
14:36<frosch123>it does display the source file
14:37<frosch123>anyway, it will be something in spritecache.cpp
14:39<blocage>mm, let see
14:39-!-idl0r [] has joined #openttd
14:39-!-idl0r is "Christian Ruppert" on #openttd
14:40<idl0r>hey, how's the progress of those 32bpp graphics nowaydays? is there anything finished/usable yet?
14:42<frosch123>thats subjective
14:42<frosch123>but there is zbase baseset, yeti industry set, and various landscape sets
14:42<frosch123>also pineapple trains
14:43<FLHerne>And those really neat Chinese sets
14:43<frosch123>i guess just go to content download and filter for 32bpp
14:43<frosch123>i would expect everyone to use that tag
14:43<Wolf01>And download 8GB
14:44<FLHerne>idl0r: is pretty much up to date afaik
14:44-!-glx [] has joined #openttd
14:44-!-mode/#openttd [+v glx] by ChanServ
14:44-!-glx is "Loïc GUILLOUX" on +#openttd
14:48<idl0r>hm, are zbase and abase dead?
14:49<@planetmaker>they could definitely use someone taking care of. At least zBase. I can't speak for aBase
14:50<LordAro>i'd imagine zeph is contactable if you need it
14:50<@planetmaker>probably. However zBase repo has basically everything you need to continue. And Zeph has also some nice blog postings about how he does things
14:51<_dp_>jeez, why the heck is grow_counter exported to newgrfs?
14:52<frosch123>remove it :)
14:52<frosch123>many of the 80+x things are just there for completeness
14:52<_dp_>gladly xD
14:52<frosch123>also, i wonder how much performance we can gain for newgrf when providing better va2 operators
14:53<frosch123>taking a regular firs game: the operators used most by far are "min", "xor" and "cmp"
14:53<frosch123>which i believe nml generates for ? :
14:53<frosch123>like, who would use "xor" other than a compiler :p
14:55<V453000>BRIX ain't even mentioned on the 32bpp page :( can't say the v 0.0.1 is worth much though :) however some people actually do use it as static
14:55<@planetmaker> <-- there we go
14:56<@planetmaker>V453000: add it :)
14:56<V453000>yeah, 135 hours is insanely fast
14:56<V453000>yeah eventually ;P
14:57<_dp_>frosch123, I use xor sometimes :p (or != if there is no xor)
15:01<frosch123> <- that's where all the CMP, MIN and XOR come from
15:03<idl0r>thx guys, zbase looks pretty much decent
15:04<_3298>there are quite some people who call it ugly
15:05<@Alberth>looks like a lookup in an array?
15:17<_dp_>hm, looks like next_counter thingie wasn't a great idea after all since it can't preserve progress when town isn't growing
15:19<_dp_>does anyone know if -- is slower than % ?
15:22<@Alberth>for powers of 2, % becomes &
15:23<@Alberth>in general, division is way more expensive
15:23<_dp_>Alberth, it's 74 not power of 2
15:24<_dp_>Alberth, but -- is a write while % is only read
15:25<@Alberth>not that good in speeds at that level
15:26<@Alberth>but in both cases you need it in L1 cache, so the cache wait time is equal
15:26<@Alberth>writing out is likely done without cpu intervention
15:29<_dp_>Alberth, yeah, looks like it doesn't matter much to modern processors
15:31<_dp_>they don't even seem to care for anything but cache and vectorization xD
15:32<frosch123>they used to care about conditional if
15:33<_dp_>fonsinchen, because it's vectorization :p
15:34<_dp_>frosch123, *
15:37<frosch123>haha, i just applied a manual optimisation which i thought would double speed, but it halfed it :p
15:38<milek7>speed of what?
15:38<milek7>newgrf code execution really takes measurable time?
15:39<frosch123>i replaced (a <= b) && (b <= c) with (b - a <= c - a)
15:39<frosch123>which is our fancy macro to do range checks
15:40<_dp_>pff, that doesn't even look as optimization :p
15:40<frosch123>anyway, my measuring is probably imprecise as well
15:40<frosch123>the test case is too flaky
15:40<frosch123>milek7: yes
15:41<frosch123>newgrf vehicles are somewhat expensive
15:41<_dp_>frosch123, does it even work the same? b - a <= c - a is pretty much b <= c
15:41<frosch123>and ecs industry animations can completely kill it, but i put a huge warning into the specs so that ecs is the only set which uses that part now
15:42<frosch123>_dp_: everything must be unsigned
15:42<frosch123>if b < a, then b-a is bigger than c-a
15:43<_dp_>frosch123, what if c < a as well?
15:43<frosch123>then it breaks :p
15:45<frosch123>but since the intention is a range check of "b", "a <= c" is pretty safe
15:45<frosch123>anyway, the -O2 is probably smarter than the old "arithmetic is better than comparision"
15:45<blocage>frosch123, does not look an optimization
15:45<_dp_>frosch123, ah, ok.
15:46<_dp_>frosch123, still kinda shaky with values > max/2
15:46<blocage>a <= b is a - b and sign bit register
15:47<frosch123> <- anyway, that's the standard reference for weird tricks
15:47<frosch123>not sure whether this is listed there though
15:47<_dp_>nice thing about && is that it doesn't always need both operands
15:47<_dp_>though it's probably irrelevant in this case
15:48<milek7>i think compilers are usually better at such micro-optimizations
15:48<blocage>frosch123, I think you should double chack, because tricky unoptimal code, just just worth
15:48<blocage>worst *
15:49<frosch123>well, anyway. i did a statistical analysis about the composition of va2 chains. and it did not give a hint for useful tree optimisations
15:49<blocage>and I fairly sure compiler are quite smart about boolean expresion
15:51<frosch123>hmm, otoh, those weird CMP+XOR make up 20%
15:51<frosch123>probably should look into the source grf where those comparisions really originate from
15:52<_dp_>there is even instruction for bounds checking
15:53<frosch123>initially i hoped STORE_TMP and LOAD_TMP would show up big time, but they are only 7%
15:54<milek7>(a <= b) && (b <= c) is cmp, ja, xor, cmp, setbe, mov, xor, jne and (b - a <= c - a) is sub, sub, cmp, setbe, mov, xor, jne
15:54<milek7>but i think it is possible to do it without arithmetic and with only one branch
15:55<milek7>maybe we need jit for newgrfs? :D
15:55<@adf88>i think that compilers are smarter
15:55<@adf88>ind can do this without branching
15:55<_dp_>yeah, to replace nml xors with sane operations :p
15:57<@adf88>&& doesn't have to be a jump
15:59-!-sim-al2 [] has joined #openttd
15:59-!-sim-al2 is "sim-al2" on #openttd @#/r/openttd
15:59<@adf88>imagine this pseudo-asm:
15:59<@adf88>1. compute "a <= b" and "b <= c" in paralel
15:59<@adf88>2. AND the results
15:59<_dp_>adf88, why not? I bet it's an if condition so it has to be a jump anyway
16:00<frosch123>hmm, just noticed that i never used x64 assembly
16:01<@adf88>the last thing would be to jump
16:01<frosch123>maybe comparisons are smarter there than in i386
16:01<@adf88>or do something else
16:01<@adf88>based on the result of calcuations
16:01<@adf88>"if" is not always a jump
16:08<blocage>frosch123, objdump -d
16:11<frosch123>i always use gdb for disasembling
16:13<@Alberth>in C++, && in parallel is much less than trivial, due to exceptions
16:14<blocage>frosch123, gdb is also fine :D
16:14<frosch123>oh, also, does anyone have experience with thread_local storage class?
16:15<frosch123>do the compilers use specific offset registers to reference the thread-specific memory
16:15<frosch123>like for position-independent code
16:15*_dp_ only used thread locals in python
16:15<frosch123>or is access to them more expensive?
16:16<blocage>do not know, I never did such micro optimization
16:17<frosch123>ottd has many "static" variables to store temporary values and return values to avoid heap allocations
16:17<frosch123>but they make the code non-reentrant
16:17<frosch123>making the stuff thread_local would be enough
16:17<frosch123>but i have no idea how thread_local compares to heap allocations
16:18<_dp_>can we revert that already?
16:19<frosch123>i think i was against it back then :p
16:19<blocage>frosch123, also micro optimization are often specific to a given arch+CPU generation, the CPU do a lot of optimization himself, can manage instruction out of order, on multiple units and so on
16:21<_dp_>openttd network lobby can as well be in that video imo :p
16:25<@adf88>this whole hardware/software optimizations grown into something big and crazy
16:25<@adf88>paradoxically, RISC processors seems to be a rescue from this situation :)
16:26<frosch123>ok, x64 still uses the same flags register as i386. i do not have to learn anything new :p
16:26<@adf88>we need to throw x86 and other away and start again
16:30<frosch123>the most modern microprocessor i programmed was atmel avr
16:30<frosch123>and they also had flags and similar branch commands
16:30-!-keoz [~keikoz@2a01:e35:2fd5:51e0:1037:e61d:fbf:2ba8] has joined #openttd
16:30-!-keoz is "Grmph" on #debian-fr #kernelnewbies #openttdcoop #openttd
16:34-!-moonythedwarf [] has joined #openttd
16:34-!-moonythedwarf is "realname" on #openttd
16:45-!-Alberth [] has left #openttd []
17:08-!-Stimrol [] has quit [Quit: ZNC -]
17:24-!-Hiddenfunstuff [] has quit [Ping timeout: 480 seconds]
17:30-!-gelignite [] has quit [Quit:]
17:31-!-blocage [] has quit [Quit: Leaving]
17:34<frosch123> <- this explains most about thread_local :)
17:44-!-keoz [~keikoz@2a01:e35:2fd5:51e0:1037:e61d:fbf:2ba8] has quit [Ping timeout: 480 seconds]
18:05-!-mescalito [] has quit [Ping timeout: 480 seconds]
18:07-!-Wolf01 [] has quit [Read error: Connection reset by peer]
18:07-!-Wolf01 [] has joined #openttd
18:07-!-Wolf01 is "Wolf01" on #openttd
18:18-!-Lejving [] has quit [Read error: Connection reset by peer]
18:20-!-Wormnest [] has quit [Quit: Leaving]
18:26-!-adf88 [] has quit [Quit: adf88]
18:27-!-FLHerne [] has quit [Quit: There's a real world out here!]
18:30-!-Lejving [] has joined #openttd
18:30-!-Lejving is "realname" on #openttd #/r/openttd #factoriocoop #openttdcoop #openttdcoop.stable @#openttdcoop.pz #mashinky
18:35-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
18:39-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
18:45-!-Progman [] has quit [Remote host closed the connection]
18:52-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:58-!-_3298 [] has quit [Quit: Leaving]
20:29-!-efess [] has joined #openttd
20:29-!-efess is "afsd" on #openttdcoop #openttd #/r/openttd
21:26-!-ToBeFree [] has joined #openttd
21:26-!-ToBeFree is "Tobias "ToBeFree" Frei" on #https-everywhere @#freiwuppertal #oolite-dev #openttd #tor #debian #linux #oolite #oolite-ger
21:30-!-moonythedwarf [] has quit [Ping timeout: 480 seconds]
21:46-!-ToBeFree [] has quit [Quit: Leaving]
22:29-!-Flygon [] has joined #openttd
22:29-!-Flygon is "Flygon" on #openttd
22:35-!-Jas [] has joined #openttd
22:35-!-Jas is "OFTC WebIRC Client" on #openttd
22:35-!-Jas [] has quit []
22:36-!-Jass [] has joined #openttd
22:36-!-Jass is "OFTC WebIRC Client" on #openttd
22:37-!-glx [] has quit [Quit: Bye]
22:38-!-Jass [] has quit []
23:17-!-Cubey [] has quit [Ping timeout: 480 seconds]
---Logclosed Mon Aug 28 00:00:32 2017