Log for on 15th November 2013:
Times are UTC Toggle Colours
00:11:06  *** frosch123 has quit IRC
00:13:46  *** tycoondemon has quit IRC
00:14:01  *** tycoondemon has joined
00:16:22  *** zydeco has quit IRC
02:24:39  *** LordAro has quit IRC
08:00:39  *** adf88 has joined
08:00:39  *** ChanServ sets mode: +v adf88
08:18:46  *** adf88 has quit IRC
08:21:44  *** adf88 has joined
08:21:44  *** ChanServ sets mode: +v adf88
08:54:53  *** Alberth has joined
08:54:53  *** ChanServ sets mode: +v Alberth
09:03:18  *** LordAro has joined
09:03:18  *** ChanServ sets mode: +v LordAro
09:22:33  *** Supercheese has quit IRC
11:50:56  *** Lord_Aro has joined
11:50:56  *** LordAro has quit IRC
11:51:43  *** Lord_Aro is now known as LordAro
11:52:05  *** ChanServ sets mode: +v LordAro
12:14:30  *** frosch123 has joined
12:14:30  *** ChanServ sets mode: +v frosch123
14:05:24  *** adf88 has quit IRC
15:15:18  *** adf88 has joined
15:15:18  *** ChanServ sets mode: +v adf88
16:23:06  *** adf88 has quit IRC
17:22:06  *** juanjo_ has joined
17:42:41  <frosch123> @voice juanjo_
17:42:41  *** DorpsGek sets mode: +v juanjo_
17:43:04  <frosch123> if you have registered to nickserv, you can bother pm to give you permanent voice
17:48:10  *** peter1138 has joined
17:48:10  *** ChanServ sets mode: +v peter1138
17:48:11  <peter1138> ok
17:49:51  *** adf88 has joined
17:49:51  *** ChanServ sets mode: +v adf88
17:56:20  <juanjo_> Hi! I would like to comment about r25998.
17:57:22  <frosch123> feel free :)
17:58:12  <juanjo_> In the comment added about catchment areas it is stated that they are different due to performance decisions.
17:58:37  <planetmaker> yes, basically
17:59:54  <juanjo_> I tried with the last option: change the search from stations and use the tiles of stations.
18:00:11  <juanjo_> The implementation I did was not the best possible
18:01:34  <juanjo_> But as I cached the catchment area, although the cost of calculating it is quite high, I barely noticed performance problems
18:01:51  <frosch123> how did you cache it?
18:01:56  <frosch123> some set of tiles per station?
18:02:05  <planetmaker> can you prove your 'barely notice' by profiling data?
18:03:18  <juanjo_> I don't know how to profile data. Sorry.
18:03:22  <planetmaker> I actually haven't seen any for any solutions to that issue, even the one disregarded with the reasoning given
18:04:29  <juanjo_> Anyway, as I can't give profiling data, I'll try to explain it another way.
18:05:57  <juanjo_> The cost of calculating a catchment area considering each tile of the station is high, but you only need to calculate that when you load a game or when you add/delete parts of a station
18:07:31  <planetmaker> the area: yes. Acceptance: no
18:07:39  <planetmaker> you need to check that every time
18:08:53  <frosch123> that's what i asked: did you add some list of tiles to stations?
18:09:03  <frosch123> which contains the tiles in the catchment area without duplicated?
18:09:17  <frosch123> did you also do that for industries? (which also have non-rectangular shapes)
18:11:20  <juanjo_> For each station there is a global tile area, which includes all tiles that could fall inside station's catchment.
18:11:54  <juanjo_> Then I also store an array for referencing each tile of the tile area.
18:12:58  <juanjo_> The array is a bit array, each bit representing each one of the tiles, in the same order as TILE_AREA_LOOP.
18:13:26  <juanjo_> Let me put it with an example
18:16:13  <juanjo_> I have a station with two tiles t1=25634, t2=2335346. I build the rectangle containing those two tiles. Then I expand it, with a convenient radius, as some tiles that will be serviced will fall outside the rectangle
18:17:51  <adf88> So it's a bitmap...
18:17:58  <adf88> maybe a sparse tree
18:17:59  <adf88> ?
18:18:09  <juanjo_> Once I have the tile area of all tiles that can fall into station's catchment (let's say it is a 20x30 tilearea), I allocate 20x30 bits...
18:18:11  <frosch123> <- that one?
18:19:58  <juanjo_> No, that's for seeing the catchment area. That comes later. I'm looking for it...
18:21:01  <juanjo_> It's this one and later commits:
18:21:23  <LordAro> needs some coding style stuffs
18:21:36  <frosch123> LordAro: not now
18:21:44  <LordAro> :p
18:21:52  * LordAro blames Alberth
18:22:00  <frosch123> stop the code style trolling
18:22:13  <frosch123> it's the algorithm that matters
18:22:41  <juanjo_> While you complain about coding style and not about the implementation, I'm okay with it :P
18:24:11  <LordAro> :p
18:27:33  <juanjo_> Finally, the algorithm fills in the 20x30 array, so you keep the list of "serviced tiles", used when doing tile area loops
18:28:36  <frosch123> oh, you are using bool*
18:28:45  <frosch123> i guess you can use TileIndex* then as well
18:29:04  <frosch123> do you have an estimate how many memory that needs in a normal game?
18:29:22  <frosch123> hmm, how many stations are there in an average game?
18:29:40  <frosch123> maybe depends whether busstops are used
18:30:12  <juanjo_> What is the maximum distance between two tiles of the same station? 64?
18:30:39  <frosch123> hmm, 1000 busstops with 81 catchment tiles each, would be less than 400k, so i guess no issue at all
18:30:55  <frosch123> yeah, max stations spread is 64
18:31:02  <frosch123> anyway, looks like memory is no concern
18:31:14  <frosch123> so, one could cache the tiles in the catchment area per station and per industry
18:31:31  <frosch123> and even add a switch to use the traditional catchment area for savegame compatibility
18:31:33  <juanjo_> per industry is not needed
18:31:38  <frosch123> btw. i like the oilrig thingie :p
18:31:56  <frosch123> industries also have non-rectangular shapes
18:31:58  <juanjo_> I hate oilrigs
18:32:13  <frosch123> so for industry->station transfer it should also use the new algorithm
18:32:15  <juanjo_> i store just their footprint
18:32:52  <frosch123> luckily houses are only rectangular :p
18:33:09  <juanjo_> Just check which tiles of industry footprint are "serviced" by a station
18:33:51  <frosch123> hmm, we already have a list of stations per industry, right?
18:34:04  <frosch123> or was it the other way around
18:34:39  <juanjo_> I also add that cached list:รง
18:43:51  <juanjo_> About the memory it requires, I'm not an expert to say it is not so much. Biggest station possible requires about 5k bits... There are lots of other issues. I just did the implementation and it worked. I didn't cared to make things more efficient.
18:44:44  <frosch123> mind that boolean is usually 4 bytes, not 1 bit
18:45:01  <Rubidium> isn't there a bitset or so in stl?
18:45:13  <frosch123> yes, std::set<boolean> is specialised
18:45:14  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26004 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:46:57  <juanjo_> I'll look into it and rewrite it. Hope it is not a big deal.
18:48:39  <Rubidium> there's bitset, but that's not really a proper set and has a compile time size. I reckon it's the fastest though
18:49:41  <frosch123> you mean a fixed size bitset for 64x64 + biggest catchment radius?
18:49:59  <frosch123> i guess an ordered set is good enough
18:50:00  <Rubidium> if you want to use bitset, then yet
18:50:15  <frosch123> and actually, since you only want to do inclusion tests fast, and not insert/delete
18:50:21  <frosch123> it could even be an ordered vector
18:50:41  <Rubidium> yup
18:50:42  <frosch123> maybe bitset is vector-ish
18:51:13  <Rubidium> nope, there's a bit_vector/vector<bool>
18:51:34  <Rubidium>
18:51:39  <LordAro> or,
18:51:55  <frosch123> oh, right, std::Vector<bool> was specialised, not std::set<bool> :/
18:52:36  <Rubidium> so vector<bool> would be the 'right' one to use?
18:52:41  <frosch123> i think so
18:53:05  <LordAro> according to documentation
18:54:30  <juanjo_> Well, I have to go. If you find more issues or any other idea, please let me know.
18:54:41  <juanjo_> Bye
18:55:01  *** juanjo_ has quit IRC
19:55:07  *** Alberth has left
20:32:38  *** zydeco has joined
20:37:10  *** Supercheese has joined
21:03:10  <Rubidium> <- I hope that works as a fix for the problem; not that I really found a problem with the current code, but this design might be more resilient
21:06:00  <frosch123> +			mutex->WaitForSignal(); <- + this->
21:12:12  <frosch123> doesn't look wrong
22:22:03  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26005 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
23:21:23  *** frosch123 has quit IRC
23:23:34  *** adf88 has quit IRC

Powered by YARRSTE version: svn-trunk