IRC logs for #openttd.dev on OFTC at 2013-08-04
⏴ go to previous day
07:22:49 *** Zuu has joined #openttd.dev
08:45:26 <fonsinchen> Well, it probably is. I should probably split that in two classes.
08:45:34 <Rubidium> it definitely feels nasty
08:47:15 <Rubidium> and I can quite grasp (quickly) what the heck it's doing
08:48:52 <fonsinchen> I want a single linked list of StationIDs that doesn't allocate any heap if you have only one item
08:49:07 <fonsinchen> And it should have a 16bit "pointer" type
08:49:30 <fonsinchen> So that the thing is 32 bits big and aligns nicely when passed around as value
08:50:14 <Rubidium> but the pool allocates an object for each and every pool element
08:50:31 <fonsinchen> You can put pool items on the stack
08:50:49 <fonsinchen> I have a new idea anyway
08:50:57 <Rubidium> why don't you just use AllocaM?
08:51:20 <Rubidium> a macro to allocate memory on the stack
08:51:51 <Rubidium> (behaves just like AllocT, except that it allocates on the stack)
08:52:00 <fonsinchen> Well, if I have multiple items in the list I actually want them to reside on the heap
08:52:18 <fonsinchen> Otherwise I'll be passing around huge arguments on the stack
08:52:49 <Rubidium> can you just pass the pointer to that stack allocated bit? Or does it need to survive longer?
08:52:53 <fonsinchen> The point of it is to properly support conditional orders when predicting next hops
08:53:07 <fonsinchen> A pointer is rather large
08:53:39 <Rubidium> if you allocate an object on the heap you use at least a few size_t worth of memory anyway
08:54:11 <fonsinchen> The heap allocation should only happen if there are conditional orders. Thus it should be rare
08:54:21 <fonsinchen> In comparison to just passing a single value around
08:55:01 <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:55:55 <fonsinchen> And usually the whole thing will be returned from functions. So allocating on the stack is probably not so clever.
08:58:26 <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.
09:00:24 *** Ristovski has joined #openttd.dev
09:13:24 *** ntoskrnl has joined #openttd.dev
09:18:57 <fonsinchen> Oh, one can make it even shorter ...
09:21:56 *** frosch123 has joined #openttd.dev
09:21:56 *** ChanServ sets mode: +v frosch123
09:27:36 <fonsinchen> Maybe that wants to be a general "SmallStack"
11:52:02 <frosch123> invalidate vehicle sprite and colourmap whenever (un)loading cargo, and also in some corner cases more
11:52:27 <frosch123> generally the invalidation of the colourmap was weird before, since it did not trigger redrawing of the vehicle
12:21:57 <Rubidium> can vehicles get their current palette though?
12:22:15 <Rubidium> in e.g. the vehicle's age property?
13:03:52 <frosch123> nothing depends on the palette
13:04:09 <frosch123> it's client specific anyway, due to the company colour of opponents setting
14:43:49 *** Zuu has joined #openttd.dev
15:16:27 *** LordAro has joined #openttd.dev
15:16:27 *** ChanServ sets mode: +v LordAro
18:24:36 *** Alberth has joined #openttd.dev
18:24:36 *** ChanServ sets mode: +v Alberth
19:24:50 *** Alberth has left #openttd.dev
20:51:05 *** Supercheese has joined #openttd.dev
continue to next day ⏵