Log for on 4th August 2013:
Times are UTC Toggle Colours
01:20:28  *** frosch123 has quit IRC
07:18:41  *** Zuu has joined
07:18:41  *** ChanServ sets mode: +v Zuu
08:10:35  *** Supercheese has quit IRC
08:35:29  <fonsinchen> Is it nasty to hijack the "index" field of pool items in order to implement a single linked list on a pool? see
08:41:19  <fonsinchen> Well, it probably is. I should probably split that in two classes.
08:41:26  <Rubidium> it definitely feels nasty
08:43:07  <Rubidium> and I can quite grasp (quickly) what the heck it's doing
08:44:45  <fonsinchen> I want a single linked list of StationIDs that doesn't allocate any heap if you have only one item
08:45:00  <fonsinchen> And it should have a 16bit "pointer" type
08:45:22  <fonsinchen> So that the thing is 32 bits big and aligns nicely when passed around as value
08:46:06  <Rubidium> but the pool allocates an object for each and every pool element
08:46:23  <fonsinchen> You can put pool items on the stack
08:46:42  <fonsinchen> I have a new idea anyway
08:46:50  <Rubidium> why don't you just use AllocaM?
08:47:00  <fonsinchen> What is that?
08:47:12  <Rubidium> a macro to allocate memory on the stack
08:47:21  <Rubidium> (macro for alloca)
08:47:43  <Rubidium> (behaves just like AllocT, except that it allocates on the stack)
08:47:52  <fonsinchen> Well, if I have multiple items in the list I actually want them to reside on the heap
08:48:10  <fonsinchen> Otherwise I'll be passing around huge arguments on the stack
08:48:42  <Rubidium> can you just pass the pointer to that stack allocated bit? Or does it need to survive longer?
08:48:45  <fonsinchen> The point of it is to properly support conditional orders when predicting next hops
08:49:00  <fonsinchen> A pointer is rather large
08:49:31  <Rubidium> if you allocate an object on the heap you use at least a few size_t worth of memory anyway
08:50:04  <fonsinchen> The heap allocation should only happen if there are conditional orders. Thus it should be rare
08:50:13  <fonsinchen> In comparison to just passing a single value around
08:50:53  <fonsinchen> This is why I'm trying to optimize it for the single value case and why I'm trying to bitstuff it into 32 bits
08:51:48  <fonsinchen> And usually the whole thing will be returned from functions. So allocating on the stack is probably not so clever.
08:54:19  <fonsinchen> Well, I'll just make a base class without pool and another derived class with pool. The latter doesn't have to align and is only used if there are multiple values.
08:56:16  *** Ristovski has joined
09:09:17  *** ntoskrnl has joined
09:13:39  <fonsinchen> Shorter, better and no index hijacking:
09:14:50  <fonsinchen> Oh, one can make it even shorter ...
09:17:48  *** frosch123 has joined
09:17:49  *** ChanServ sets mode: +v frosch123
09:23:28  <fonsinchen> Maybe that wants to be a general "SmallStack"
10:28:06  *** Zuu has quit IRC
11:47:16  <frosch123>
11:47:55  <frosch123> invalidate vehicle sprite and colourmap whenever (un)loading cargo, and also in some corner cases more
11:48:19  <frosch123> generally the invalidation of the colourmap was weird before, since it did not trigger redrawing of the vehicle
12:17:40  <Rubidium> seems to be okay
12:17:49  <Rubidium> can vehicles get their current palette though?
12:18:07  <Rubidium> in e.g. the vehicle's age property?
12:59:28  <frosch123> vehicle age?
12:59:44  <frosch123> nothing depends on the palette
12:59:53  <Rubidium> aging ;)
13:00:01  <frosch123> it's client specific anyway, due to the company colour of opponents setting
13:01:36  <Rubidium> hmm, good point
13:58:21  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25648 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
14:39:41  *** Zuu has joined
14:39:41  *** ChanServ sets mode: +v Zuu
15:12:19  *** LordAro has joined
15:12:19  *** ChanServ sets mode: +v LordAro
17:41:03  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25649 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:20:28  *** Alberth has joined
18:20:28  *** ChanServ sets mode: +v Alberth
19:12:24  *** ntoskrnl has quit IRC
19:20:42  *** Alberth has left
20:30:57  *** frosch123 has quit IRC
20:46:57  *** Supercheese has joined
22:16:32  *** Zuu has quit IRC
23:06:16  *** Ristovski has quit IRC

Powered by YARRSTE version: svn-trunk