IRC logs for #openttd.dev on OFTC at 2013-05-07
⏴ go to previous day
06:49:54 *** Zuu has joined #openttd.dev
10:08:30 *** Ristovski has joined #openttd.dev
10:41:41 *** frosch123 has joined #openttd.dev
10:41:41 *** ChanServ sets mode: +v frosch123
10:49:55 <frosch123> planetmaker: for ottd you could make the spritenumber of the first coast sprite avaialble via actiond
10:50:00 <frosch123> similiar to the 2cc remaps
10:50:14 <frosch123> (will only work in ottd though, not possible for ttdp, if you care :p )
10:56:12 <planetmaker> frosch123, but how does that work with base sets? They have the sprites in the base grf and 10 in the extra grf?
10:56:30 <frosch123> you are underestimating the magic that ottd does :p
10:56:56 <planetmaker> frosch123, can we make that approach you pasted more generic? So that it takes a parameter
10:57:02 <frosch123> for ottd the shores and foundations are always in the same spot (though they are moved when you add new gui sprites)=
10:57:03 <planetmaker> which indicates the action5 set
10:57:10 <planetmaker> or which allows adding further?
10:57:21 <frosch123> it does not make a lot of sense for other action5 sets
10:57:33 <frosch123> i just took those which make sense, and would rather hide others
10:57:46 <frosch123> planetmaker: so we can never change tram sprites again?
10:57:52 <frosch123> good luck with road types :p
10:57:56 <planetmaker> yes, no need to expose all. But so that we don't add a separate var for each?
10:58:04 <frosch123> i already wonder about exposing the foundatin graphhics
10:58:36 <frosch123> if we would include slope information in tile layouts, ottd could draw the proper foundations itself
10:58:55 <frosch123> planetmaker: we already have a var for 2cc, and i don't see we would get mroe
10:59:10 <frosch123> and there is currently no method for a parameterised action d variable
10:59:41 <planetmaker> well, yes. The terrain sprites are needed as reference often
10:59:50 <planetmaker> so that's most important
11:00:02 <planetmaker> foundations... dunno... I really haven#t thought about them
11:01:22 <frosch123> foundations are quite complicated to use for newgrf
11:01:30 <frosch123> because the Z position varies in layouts
11:01:48 <frosch123> so, maybe we should skip them, and only expose the shore base then? :)
11:02:20 <frosch123> i don't see anyone using the foundations sprites, except in a fixed slope configuration
11:02:27 <frosch123> but well, maybe that is reason enough
11:03:25 <planetmaker> well, One might want to use them in terraced multi-tile house or industry :-)
11:03:58 <frosch123> well, using the default foundations might be better than drawing custom ones :p
11:04:20 <planetmaker> default foundations or default foundation sprites? :-)
11:06:12 <planetmaker> interesting... I don't recall reading the wiki page you linked :-)
11:06:39 <planetmaker> I might have, but probably forgot :-)
11:07:47 <planetmaker> And if we use separate variables like you suggest, we can of course always add foundations sprite offset later in another var
11:08:13 <planetmaker> having the shore sprite offset for now would suffice for me. And likely to the guy in that thread, too
11:09:31 <frosch123> well, in other cases we added the magic to the tile layout drawing
11:09:53 <frosch123> i.e. if you use the plain water tile in a sprite layout, ottd will add canal/river borders to it
11:10:07 <frosch123> we just never had a good idea how to do that with shores
11:10:29 <frosch123> esp. because the shore detection is so complicated, when the shore is inside the industry .p
11:11:38 <planetmaker> you mean... if I take an industry. How do I make it a water tile?
11:11:45 <planetmaker> or you mean to leave a gap in the layout?
11:11:57 <frosch123> no, a industry you build on water
11:12:17 <planetmaker> yeah. but they have no river banks?
11:12:25 <frosch123> the newgrf draws the plain water sprite
11:12:35 <frosch123> ottd catches that case and turns it into drawing the river or canal water
11:12:37 <planetmaker> that's a plain flat terrain tile
11:12:39 <frosch123> instead of the sea water
11:12:42 <frosch123> including the borders
11:13:08 <planetmaker> sorry... I miss something. How does an industry draw a plain water tile?
11:13:22 <planetmaker> I can reference the sprite just fine. but that doesn#t make it water
11:13:27 <frosch123> it just puts the default ttd sprite number in the ground sprite
11:13:46 <planetmaker> but... no borders are drawn then?
11:14:01 <frosch123> ottd catches that case and does something different
11:14:33 <planetmaker> uh... then ogfx-landscape wind mills on water should have river / canal borders
11:14:42 <frosch123> see IndustryDrawTileLayout
11:14:45 <planetmaker> or is an additional requirement that there's no child sprite or building?
11:14:56 <frosch123> it must be the first ground sprite
11:15:00 <frosch123> not some additional ground sprite
11:16:08 <planetmaker> uh... that's weired magic in that place
11:16:16 <planetmaker> and tbh I've never seen it kick in
11:16:27 <frosch123> it works for default industries
11:16:30 <frosch123> at least it used to work :p
11:17:18 <planetmaker> ah... so I'll only see a difference, if is a river or canal water tile
11:17:25 <planetmaker> as sea tiles have no border. hm...
11:17:45 <planetmaker> I guess I never saw that case. Need to check
11:18:14 <planetmaker> But why do we do so only for flat tiles?
11:18:18 <planetmaker> why not for sloped?
11:18:25 <frosch123> tell me how to do it for slopes :p
11:18:40 <frosch123> what is coast, what is land?
11:18:54 <frosch123> you do not know what the industry does on the inside
11:19:08 <frosch123> you would have to check whether a neighboured tile would draw a water ground or somiething like that
11:19:29 <frosch123> or you could require the industry to draw the default coast graphics
11:19:35 <frosch123> which you could replace with other ones
11:19:44 <frosch123> but then there are no sprites for the diagonal coasts
11:21:09 <planetmaker> well :-) I generally believe that the best approach to all this would be: always draw the ground as if nothing was on it. Then draw anything on top which the industry / object / house / whatever wants to draw on top
11:21:20 <planetmaker> it then can draw water where there's land or vice versa
11:24:35 <planetmaker> hm... can industries set the water class of a tile? I think not
11:29:19 <frosch123> no, it's whatever it was before
11:29:37 <frosch123> though autoslope might completely break it :p
11:30:01 <frosch123> so, when the industry is removed, it checks whether the waterclass is still possible on the slope/height :p
11:30:41 <planetmaker> But generally wouldn't it make sense to draw the world without any objects / houses / industries /... and then those on top?
11:30:53 <planetmaker> It avoids the need for lookup (though they still could)?
11:31:07 <frosch123> well, yeah, it would also fix snow and desert density :p
11:31:30 <frosch123> but i guess we would need to mess around with the map array for that
11:31:42 <frosch123> and separate the surface stuff from the rest
11:31:45 <planetmaker> snow can be externalized. I think it should
11:32:07 <frosch123> what do you mean with 'externalized' ?
11:32:09 <planetmaker> then we only need two zones or three: desert, grass, rainforest
11:32:14 <planetmaker> by snowline height
11:32:39 <frosch123> i did that once, but never made it work properly :p
11:32:57 <planetmaker> sm4tz or m1chi did so, too, afair
11:33:32 <frosch123> i only did the snow line height thingie
11:33:46 <planetmaker> yes, that's what I mean they did, too :-)
11:33:59 <planetmaker> but... my memory is not know for accurate remembrance ;-)
11:35:54 <planetmaker> how many bits do we need for landscape description? 8 for height, 2 or 3 for terrain type. 2 or 3 for water class
11:40:34 <planetmaker> 2 water type bits.
11:40:59 <planetmaker> 2 bits tropcial zone
11:41:06 <planetmaker> thus 4 bits for tile description
11:41:16 <planetmaker> density is in some. but in principle can be derived
11:41:49 <planetmaker> both for snow and desert transition. bare ground density is only needed for normal ground tiles, no others
11:45:05 <frosch123> i think that's about what i thought in 2008 or 2009 when i first had the idea to expose shores/foundations via action d :p
11:47:17 <planetmaker> so... should we make a new attempt at changing it? :-)
11:49:43 <frosch123> well, it's certainly better than people hardcoding sprite numbers
11:49:52 <frosch123> and then complaining that it breaks when we add a gui sprite :p
11:50:04 <planetmaker> yes. And it indeed solves an issue which I tried to programme around in NewGRFs for some time
11:50:55 <frosch123> so, add them anyway? :p
11:52:08 <planetmaker> them? We'd be well off with just the shore base sprite.
11:52:16 <planetmaker> Or did I miss that we have any alternative?
11:52:34 <planetmaker> it would not be a loss even when the ground issue is totally reworked to be always drawn
11:53:26 <planetmaker> I took from the discussion that foundation offset needs maybe another thought, so I'd not add that for now
11:54:36 <frosch123> i think foundations hurt even less
11:55:18 <planetmaker> but shore base doesn't hurt either? Or how can it hurt?
12:07:09 <planetmaker> If you don't want to go for it I'll think about your paste tonight, I guess :D
12:48:30 <frosch123> planetmaker: i assign the nml task to you :p
15:13:36 *** Zuu has joined #openttd.dev
17:38:12 *** Alberth has joined #openttd.dev
17:38:12 *** ChanServ sets mode: +v Alberth
19:12:34 *** Supercheese has joined #openttd.dev
20:21:10 *** Zuu has joined #openttd.dev
21:11:17 *** Alberth has left #openttd.dev
continue to next day ⏵