IRC logs for #openttd on OFTC at 2012-03-27
⏴ go to previous day
00:07:35 *** theholyduck has joined #openttd
01:57:56 *** HerzogDeXtEr1 has joined #openttd
02:37:09 *** Rhamphoryncus has joined #openttd
04:38:11 *** FreeArtMan has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
05:14:38 *** andythenorth has joined #openttd
06:45:16 *** LordPixaII has joined #openttd
06:47:26 *** TWerkhoven[l] has joined #openttd
07:03:51 *** andythenorth has joined #openttd
07:08:51 *** Twofish has joined #openttd
07:11:55 *** andythenorth has joined #openttd
07:16:24 *** andythenorth has left #openttd
07:18:50 *** sla_ro|master has joined #openttd
08:02:38 *** devilsadvocate has quit IRC
08:04:13 *** Eddi|zuHause has joined #openttd
08:04:13 *** Rhamphoryncus has joined #openttd
08:04:13 *** kaenkky_ has joined #openttd
08:04:13 *** telanus1 has joined #openttd
08:04:13 *** tokai|noir has joined #openttd
08:04:13 *** FlyingFoX has joined #openttd
08:04:13 *** devilsadvocate has joined #openttd
08:04:13 *** mikegrb has joined #openttd
08:04:13 *** resistance.oftc.net sets mode: +v tokai|noir
08:06:32 *** tparker has joined #openttd
08:06:32 *** Born_Acorn has joined #openttd
08:06:32 *** charm.oftc.net sets mode: +ov orudge orudge
10:23:02 *** wouterh has joined #openttd
10:40:19 *** wouterh is now known as Achilleshiel
10:46:20 *** TWerkhoven[l] has joined #openttd
10:53:37 *** Markavian has joined #openttd
10:55:26 *** Devroush has joined #openttd
11:05:02 *** oskari89 has joined #openttd
11:13:55 <Rhamphoryncus> Gee, I just rebuilt my airport, now the plane that was about to arrive is just going in tight circles.. err... :P
11:14:36 <MNIM> yeah, those aircrafts pull turns that not even a fighter would be able to do :P
11:16:37 <peter1138> if it hasn't crashed already :p
11:18:02 <Pikka> I don't know why making planes hit the statemachine prettily is considered a hurdle for newairports... they certainly don't hit the current statemachines prettily
11:18:14 *** roboboy has joined #openttd
11:21:23 <Rhamphoryncus> The airport was a drop, joined with some other stations at a factory. Emphasis on "was"
11:22:00 <Rhamphoryncus> By the 3rd attempt I got it right
11:33:45 *** roboboy has joined #openttd
11:36:09 *** TGYoshi has joined #openttd
11:41:59 *** Markavian` has joined #openttd
11:48:29 *** sla_ro|master has joined #openttd
12:13:37 *** Devroush has joined #openttd
12:14:15 <CQ> is there a way I can get openttd to automatically grab graphics and sound on startup? I get the message Error: Failed to find a graphics set. Please acquire a graphics set for OpenTTD. See section 4.1 of readme.txt.
12:14:47 <CQ> If I grab the mercurial files, I guess I need to build the data first before putting it in .openttd/* ?
12:15:35 <Pinkbeast> What is the difficulty with the instructions in section 4.1 of the readme?
12:34:33 <Eddi|zuHause> maybe we should encode them in numbers instead
12:34:44 <Eddi|zuHause> numbers are easier, because they are fewer
12:37:20 <__ln__> yeah, only from zero to infinity
12:38:26 <Eddi|zuHause> sorry. i meant digits :)
13:24:21 *** goodger has joined #openttd
13:47:55 <CQ> wouldn't it make sense to name the road vehivles after what they can transport, i.e. Livestock11 and Coal14 etc.?
13:52:25 <planetmaker> CQ: wouldn't that be dead boring?
13:53:16 <planetmaker> CQ: and... new versions of openttd DO grab all files upon startup, if not found (at least on windows and linux)
13:55:59 <planetmaker> but generally, CQ, especially if you have several installs, do put your base sets and newgrf files in the user's global openttd data dir (not relative to the binary)
13:57:10 <Belugas> CQ: I think it would make sens for you, but it might very well be against other players schemes
13:57:28 <Belugas> bottom line: adapt, don't impose ;)
13:58:45 <peter1138> i don't name my vehicles
14:04:52 <Pikka> next 1.2 RC due soon? :)
14:06:07 <Eddi|zuHause> i don't think we ever had a 4th RC
14:06:37 <Pikka> just as long as "my" bugfixes get backported :)
14:07:16 <Eddi|zuHause> but with the amount of prospected bugfixes, a last-minute RC might be useful
14:07:22 <Eddi|zuHause> like 3 days before release
14:07:34 <planetmaker> what would be the use therein, Eddi|zuHause?
14:07:45 <planetmaker> it would not get any test, thus a pointless RC
14:07:52 *** Firartix has joined #openttd
14:07:54 <Pikka> it would get 3 days of test
14:08:07 <Pikka> better than a poke in the eye with a damp marshmallow
14:08:10 <Eddi|zuHause> planetmaker: ideally, there should be no changes between an RC and a release
14:08:29 <planetmaker> Yes, of course there shouldn't
14:08:47 <planetmaker> but ideally there should be *some* significant testing between RC and release
14:09:25 <Eddi|zuHause> that's why i said 3 days
14:10:22 <Eddi|zuHause> planetmaker: the main idea is to test things that may get broken by the backports themselves
14:17:28 *** HerzogDeXtEr has joined #openttd
14:20:04 <Belugas> i see that peter1138 has the same game style as mine ;)
14:20:40 <Eddi|zuHause> you actually play the game? :p
14:21:10 <peter1138> loads of changes without RC, no thanks
14:21:14 <peter1138> i know, it's more work...
14:21:55 <oskari89> So, is that sand tile within TTD-Win palette?
14:22:47 <Belugas> Eddi|zuHause, yeah, i kinda get back on it, on my way home :)
14:25:32 <Eddi|zuHause> oskari89: generally, making a small test grf (with either grfcodec or nml) will tell you whether it's the right palette
14:25:45 <Eddi|zuHause> oskari89: also, you might consider switching to DOS palette
14:26:32 <planetmaker> yeah. No point using the windoze palette for new newgrfs.
14:28:08 <planetmaker> and grfcodec or nml will naturally complain, if a graphics file has the wrong palette
14:29:37 <planetmaker> oskari89: why do you draw there X times the equipment cabin instead of composing that as tile layout in the game (and drawing each ground tile only once and each view of the cabin only once and gaining the chance to easily use other ground tiles, too)
14:30:08 <planetmaker> the cabin could be a micron-sized building on top of a ground tile
14:30:41 <planetmaker> same actually with all the houses and whatever
14:30:51 <planetmaker> less work. easier extended to other ground tiles
14:38:50 <oskari89> Planetmaker: I don't know about tile layouts :P
14:38:54 *** DonKarnage_ has joined #openttd
14:39:07 <oskari89> That's why i did paste all those..
14:39:25 <planetmaker> oskari89: did you write a station newgrf so far? (I thought so)
14:39:55 <oskari89> I wait for a coder to do his job, which i have already..
14:39:58 <planetmaker> otherwise I really would like to suggest to post the (ground) tiles separately and the single elements on it as seaprate sprites
14:40:10 <DonKarnage_> Is there anything that can control how much each industries produces?
14:40:11 <planetmaker> then the coder can arrange them on the tiles
14:40:35 <planetmaker> ok, sorry, I thought we were in the process of writing it already, oskari89
14:41:13 <oskari89> Base tiles are there, just need to do little changes, such as that sand....
14:41:46 <planetmaker> one can compose the stuff on a tile as ground tile (+ child sprites within its bounding box) + building sprite (+ child sprites within its bounding box)
14:42:05 <planetmaker> thus much less drawing is actually needed
14:42:25 <planetmaker> you only need to draw the building (w/o ground) from all views. You don't need to add ground there
14:42:55 <planetmaker> you might want to create an additional sprite which shows the buildings footprint in black (for the transparent mode)
14:43:17 <oskari89> Thanks for the info.
14:47:34 <planetmaker> note that the dirt tracks are drawn on top of the default ground tile
14:47:44 <planetmaker> which the newgrf does not supply itself :-)
14:48:14 <planetmaker> thus it's base set ground + dirt tracks + one of the buildings shown there
14:48:40 *** Keyboard_Warrior has joined #openttd
14:49:44 <planetmaker> thus you might want to consider also drawing snow versions of your buildings. Or maybe just a separate sprite which adds snow on top :-)
14:49:53 <planetmaker> might be more interesting actually
14:50:11 <planetmaker> as it allows easier adjustment of house sprites w/o need to touch the snow house in the same way
14:56:21 <planetmaker> oskari89: I wonder whether some of that stuff could become part of the CHIPS station set
14:56:41 <planetmaker> (need to ask andy / yexo about CHIPS)
15:08:57 <oskari89> Well, what part of those?
15:11:35 <planetmaker> well, that's what would need discussion I guess. It's andy's baby.
15:14:01 *** tokai|mdlx has joined #openttd
15:17:13 <oskari89> Planetmaker: But no need to replace already done stuff with overlaying those sprites.. ?
15:23:24 *** tokai|noir has joined #openttd
15:23:24 *** ChanServ sets mode: +v tokai|noir
15:45:26 <Eddi|zuHause> how do you make tracks from ice?
15:47:06 *** holyduck has joined #openttd
15:54:30 *** Keyboard_Warrior has quit IRC
16:00:26 *** Progman has joined #openttd
16:02:40 <planetmaker> oskari89: well. Needed certainly not
16:03:16 <planetmaker> maybe it's easier to code, though
16:03:23 <planetmaker> depends a bit on approach
16:05:40 <CQ> how do you remove a signal?
16:06:14 <Eddi|zuHause> (or the bulldozer button)
16:07:38 <CQ> well, that worked, now how do I remove a train wreck ? ;)
16:08:14 <Eddi|zuHause> load your previous savegame, which you certainly did right before messing with signals on a live junction :p
16:08:34 <Eddi|zuHause> otherwise, wait like one month
16:08:36 <CQ> lol as I was experimenting no big loss ;)
16:09:06 <oskari89> Hmm, there's town cars...
16:09:15 <oskari89> But why there's no sports cars? :D
16:09:36 <Eddi|zuHause> anyone know bash-fu? need a function that reads the output of a command and say whether it is "true" or "false"
16:11:42 *** Markavian has joined #openttd
16:13:16 *** valhallasw has joined #openttd
16:14:03 <Eddi|zuHause> hm... that seemed to work...
16:17:02 <oskari89> Mazda RX7 and Nissan Skyline R32 would be nice in that set.. :)
16:24:27 *** Markavian` has joined #openttd
16:34:01 *** Markavian has joined #openttd
16:34:56 <oskari89> In fact, online OpenTTD streetracing/roadracing mod would be amusing.
16:36:09 <Nat_aS> is there a way to get towns to generate civilian cars?
16:36:22 <Nat_aS> to cause traffic jams and provide eye candy?
16:37:04 <oskari89> There is a AI for that, and grf.. :P
16:38:02 <Nat_aS> could it be tied into town growth?
16:38:29 <Nat_aS> like if you send lots of goods it goes up, but if you provide transportation it goes down?
16:39:10 <Eddi|zuHause> sounds good. go ahead :)
16:39:43 <oskari89> If someone writes a patch for it.. :P
16:42:04 *** andythenorth has joined #openttd
16:45:02 *** frosch123 has joined #openttd
16:45:16 *** Markavian` has joined #openttd
16:46:33 *** HerzogDeXtEr has joined #openttd
16:49:05 *** andythenorth has joined #openttd
16:50:05 *** Doorslammer has joined #openttd
16:51:53 *** Markavian has joined #openttd
17:02:01 *** Markavian` has joined #openttd
17:05:10 *** andythenorth has joined #openttd
17:05:15 <Eddi|zuHause> oskari89: it should be already possible, if you convert the AI into a GameScript
17:15:04 <andythenorth> 'make choo choo'
17:15:22 <andythenorth> "new in 1.2.0: the toddler interface"
17:28:57 <V453000> oh, I dont have such train in NUTS yet
17:45:43 <CIA-1> OpenTTD: translators * r24076 /trunk/src/lang/ (6 files): (log message trimmed)
17:45:43 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:45:43 <CIA-1> OpenTTD: french - 4 changes by OliTTD
17:45:43 <CIA-1> OpenTTD: italian - 1 changes by lorenzodv
17:45:43 <CIA-1> OpenTTD: latvian - 1 changes by Parastais
17:45:44 <CIA-1> OpenTTD: lithuanian - 2 changes by Stabilitronas
17:45:44 <CIA-1> OpenTTD: luxembourgish - 8 changes by Phreeze
18:01:52 *** mahmoud has joined #openttd
18:08:49 *** Alberth has joined #openttd
18:08:49 *** ChanServ sets mode: +o Alberth
18:09:04 *** FLHerne has joined #openttd
18:10:30 *** Markavian has joined #openttd
18:21:35 *** TheMask96 has joined #openttd
18:26:43 <Nat_aS> 8 way rotations scare me
18:28:09 <Nat_aS> the train sprites that can be rotated in 12 directions scare me because I can't imagine spriting up all those angles, and I'm afraid it will encourage people to trace 3dcg models
18:28:19 <Nat_aS> and next thing we know, we are Simutrans/Locomotion
18:28:26 <Nat_aS> and all the charming pixel art is lost.
18:32:52 *** andythenorth has joined #openttd
18:35:51 *** Markavian` has joined #openttd
18:37:34 <V453000> Nat_aS: I have pretty much exactly the same opinion :)
18:38:05 <Nat_aS> the problem with incresing technical graphics, is you have to increse artist skill along with it
18:38:10 <Nat_aS> or the result will be ugly
18:38:23 <Nat_aS> i'm not one of those guys who hates 3d games
18:38:31 <Nat_aS> but I don't like it when they overlap
18:40:11 <V453000> well, I myself do not intend to switch to 32bpp/extra zoom/24rotations. Colours simply because I like drawing in the limited palette for pixel art, zoom simply because I consider that pointless and the main focus still has to be the normal zoom, and rotations simply because that would taky waaaay too much more effort than it does now
18:41:00 <V453000> but on the other hand I can imagine that combining all of those three with 3dcg modelling could look great
18:41:20 <andythenorth> V453000: your stuff will be increasingly left behind
18:41:38 <andythenorth> we're now in a simutrans world of multiple non-compatible paks
18:41:54 <andythenorth> whereas previously all grfs were in principle, compatible
18:42:01 <andythenorth> now there will be competing standards
18:43:10 <V453000> I will stay with the old standards however
18:44:01 <Nat_aS> soon we will be simutrans
18:44:16 <Nat_aS> PACK 128! ugly traced 3dcgi all day every day
18:44:36 <Nat_aS> the higher resolution you get though, the more glaring inconsistencies in scale become tohugh.
18:44:41 *** Chris_Booth has joined #openttd
18:48:33 <Nat_aS> really, I want to see a train game where tracks take up quarter tiles.
18:48:47 <Nat_aS> or rather houses and roads are twice as wide as tracks.
18:49:43 <Nat_aS> the scale problem comes from the fact that everything is 1 square wide.
18:49:52 <Nat_aS> a house, a road, a train track
18:50:12 <frosch123> multi tile stuff is a lot more complicated
18:50:20 <Pinkbeast> Surely a more glaringly unavoidable scale problem is length rather than width?
18:51:07 <Nat_aS> well in this case, train cars would be more than 1 tile long
18:51:22 <Nat_aS> trains and there tracks are long and thin, houses and roads are wider.
18:51:53 *** Chris_Booth is now known as Guest7943
18:52:00 *** Chris_Booth has joined #openttd
18:52:24 <V453000> lol, I cant say I ever cared about scales, lengths or whatever
18:53:22 <Pinkbeast> That doesn't matter. A car can be 2 tiles or 1 or 1/2, but: "player can pan across the map sensibly", "trains have visible length on the map rather than being points", "short hops on the map are not absurdly close to train-length"... pick two.
18:57:58 <Nat_aS> increse distances as well then!
18:58:42 <Pinkbeast> Now the map is unfeasibly huge; you picked numbers 2 and 3.
18:59:17 <Nat_aS> most maps are unfeasibly huge in OTTD already :V
18:59:28 <Nat_aS> what they really need to do is add move upwards zoom levels
18:59:32 <Nat_aS> so you can actualy see the map
18:59:54 <Nat_aS> probably also make things more visible without having to consult the minmap
19:00:07 <Nat_aS> like when you zoom all the way out, you start to see an overlay
19:00:14 <Nat_aS> like supreme commander.
19:00:18 <Pinkbeast> That's "trains appear as points", if the map is really vast and you have to zoom right out to use it
19:00:42 <Nat_aS> they would not appear as points on regular zoom
19:00:47 <Nat_aS> just when you zoom all the way out
19:01:03 <Nat_aS> and I was thinking more of factories and towns appear as points
19:01:10 <Nat_aS> and trains are invisible at high zoom levels
19:01:15 <Pinkbeast> OK, so you're letting the player choose whether the game fails #1 or #2. You still can't have all 3.
19:01:18 <Nat_aS> so the game does not slow down
19:01:32 <Nat_aS> you don't need all three at once though.
19:01:39 <CQ> how do you make cities grow faster? people transport, and give them goods, or is more needed?
19:01:55 <Pinkbeast> Errr yes, since I'm saying you can't have all three at once, I presumably know that
19:02:06 <Nat_aS> then they need water as well
19:02:20 <Nat_aS> they need food, goods, and most importantly pasingers and mail
19:02:27 <Nat_aS> water if they are in a desert.
19:02:47 <Nat_aS> i don't think goods and food are nessary, but they help
19:03:07 <Nat_aS> unless it's the desert, then water and food are nessary
19:03:15 <Nat_aS> i'm not sure about alpine
19:10:33 <oskari89> Is OpenTTD going to have 24 rotations?
19:12:49 <oskari89> Ok, what about tracks?
19:12:49 <Nat_aS> keep in mind that 24 is just 12 twice
19:12:59 <Nat_aS> no, tracks are still 8 ways
19:13:15 <Nat_aS> but this allows trains to turn corners more gracefully.
19:13:19 * andythenorth will draw buildings instead
19:13:23 <andythenorth> with 1 rotation :P
19:13:34 <Nat_aS> i want to see sprites for going up and down hills without looking silly.
19:14:09 <oskari89> Corners are a pain, i would like to see curves instead :P
19:14:22 <frosch123> andythenorth: draw windmills with infinite rotation
19:15:18 <andythenorth> which type of infinity?
19:15:45 <andythenorth> for some definitions 0 is infinite
19:16:16 <Alberth> oh, happy to not use some definitions then :)
19:16:42 <andythenorth> 0 is for example, infinitely small
19:17:04 <Nat_aS> yes but zero rotations is no sprite at all
19:17:07 <andythenorth> it is, for some definitions of 'measurement', unmeasurably small
19:17:19 <Nat_aS> and no -1 is a whole 1 away from 0
19:17:47 <Nat_aS> and because of the nature of numbers, it's an infinite distance from zero.
19:18:02 <andythenorth> on a cartesian plane, 0 is an infinitely small distance from origin
19:18:20 <Nat_aS> and 1 is an infinite distance from zero.
19:18:50 <andythenorth> only if you're applying zeno's paradox
19:19:05 * andythenorth ponders doing work instead
19:19:42 <Alberth> that's inifinitely more productive, probably
19:38:17 <Rhamphoryncus> Huh, never seen a ship randomly get lost before
19:38:48 <Alberth> there's a first for everything :p
19:39:00 <Nat_aS> that happlens like all the time
19:39:10 <Nat_aS> do you not play on maps with complex coastlines?
19:41:13 <andythenorth> it's easy to trap a ship behind a peninsula
19:46:28 <Rhamphoryncus> oskari89: I've been looking at real curves. I'd have to drug the devs to have any chance of acceptance though ;)
19:50:41 *** Chris_Booth has joined #openttd
19:54:07 <Alberth> we should code them while drugged? Not sure you'd like the result :D
19:55:59 <Nat_aS> I think I remember a probably autocratically story of Email being invented while high.
20:08:47 *** Prof_Frink has joined #openttd
20:25:19 <Rhamphoryncus> Alberth: naw, I'm gonna code it, it's just committing that needs to happen while high :)
20:31:05 <Terkhen> cout << "Real curve" << endl; // You did not need to drug me.
20:40:20 <Sidar> Hey guys, doing a school assignment on Design patterns. I picked OpenTTD as my source of code. I've found 6 patterns so far. I assumed a Flyweight pattern would also be there for visuals. Could someone help me understand how the visuals are rendered?
20:41:52 <Alberth> from the map, and newgrfs
20:42:33 <__ln__> have you identified any anti-design patterns?
20:42:48 <Sidar> No need for anti-design patterns so I didnt look for it xD
20:43:10 <Alberth> I am not sure we need patterns either :)
20:43:47 <Sidar> Alberth: I looked at viewport.cpp but can't figure out how images are managed. I assume every object that needs to be drawn takes graphical data from one source?
20:45:09 <Alberth> map has several types of tiles, each tile has its own set of bits to decide what to draw
20:45:31 <Alberth> objects have xy hash I think, never looked at it in detail
20:46:15 <Sidar> Yes but how are these images managed? I assume you don't literaly create a new instance of an image for every object. You simply draw it at a certain position right?
20:46:33 <Alberth> then the sprites are looked up in the newgrf through the sprite cache, where in general you draw a number of sprites as defined in the newgrf
20:46:34 <Sidar> I was hoping to find a flyweight pattern somewhere, but I really can't.
20:47:33 <Alberth> newgrf is quite literally everything you see
20:47:34 *** kaenkky has joined #openttd
20:47:52 <Sidar> In which virtual map does it reside?
20:48:37 <andythenorth> adobe flash might use flyweight pattern for instances of movieclips
20:49:28 <Sidar> I know of several flyweight implementations. But for some reason OpenTTD overwhelms me
20:49:50 <Sidar> I figured most games use it anyways. Saves tons of memory
20:49:59 <Alberth> it's written before OO was invented :)
20:50:37 <__ln__> Alberth: design patterns exist regardless of OO.
20:50:57 <Alberth> I guess you could see newgrf sprite references as flyweight stuff
20:51:00 <Sidar> that is true, and there are actually some visible patterns.
20:51:20 <Alberth> __ln__: that does not make them needed
20:51:35 <Sidar> Alberth: im looking at it right now...my C++ skillss....argh
20:52:11 <__ln__> Alberth: design patterns exist even if they were not conciously used by the developer.
20:52:27 <Alberth> Sidar: code is pretty dense and complicated, not sure how that is with other games
20:52:35 <Sidar> I wasn't trying to provoke a discussion guys =) sorry for that
20:52:57 <Alberth> __ln__: I am not arguing existence, I was arguing need for them :)
20:53:10 <Alberth> Sidar: no worries, it's on-topic here :)
20:55:26 <Sidar> So when an object is about to draw it calls a newgrf object?
20:56:55 <Alberth> don't know how that works in detail, but the newgrf spec has all sorts of complicated ways to state what sprites to actually draw, so that has to be done somewhere
20:57:43 <Sidar> Well do you know where the images/sprites are cached?
20:57:52 <Sidar> perhaps that will help me by far
20:58:30 <Alberth> In spritecache.cpp ?? :)
20:59:51 <Sidar> Ok so the spritecache holds the actual sprite
21:00:15 <Sidar> while the newgrf sorts out the drawing state
21:02:07 <frosch123> for every tile there are 9 bytes in the map array
21:02:36 <frosch123> one of them identifies the type of a tile which then identifies a set of function (like. virtual functions of a tile object) to do the stuff
21:02:43 <frosch123> one of them is for drawing the tile
21:03:12 <frosch123> it is up to the "tile class" to interpret/use the 9 bytes in the map as it fits
21:03:57 <frosch123> for drawing every tile just dumps the sprites into some container, which is then sorted for drawing order (we have no z buffer, but sprite sorting) and then drawn
21:05:35 <Sidar> Thanks for the help, however I need to know how these sprites are loaded and cached so that they can be reused without making a new instance for every object.
21:06:19 <Sidar> I have to create an uml diagram from it
21:06:46 <Sidar> ( if im being a pain just say so xD )
21:06:50 <frosch123> they are put into some lru cache (is that it's name?)
21:07:07 <frosch123> there is a fixed size of sprite memory (the spritecache) and sprites are loaded from disk into it
21:07:29 <frosch123> if it is full, the entry which was not used for the longest time is removed
21:19:40 <Sidar> Gah. Can't see how this works. =[
21:20:02 <michi_cc> Sidar: You won't find an OO object for the sprite stuff anywhere, but most visible entities store a SpriteID somehow (either indirectly in the map array or directly in the object, e.g. vehicles). The SpriteID is a reference into the sprite cache which stores the pixels to draw.
21:21:03 <Sidar> and then passed into the blitter to draw?
21:21:59 <michi_cc> With a bit of a stretch you could say most of the map uses a flyweight design pattern. A station tile for example contains a reference to a StationSpec, which contains data common to all station tiles of the same kind.
21:22:30 <Sidar> Thanks. Ill ook into these files
21:23:26 <michi_cc> Drawing is: collect visible entities, put corresponding sprites into a list, sort list by drawing order, send to blitter.
21:24:46 <Alberth> ViewportDoDraw() looks like a main routine (lots of collecting, and at the end sorting & drawing)
21:38:48 *** andythenorth has left #openttd
22:14:19 <Sidar> Sorry for bothering you guys with this. But, I know there is a SpriteID, but what class gets the actual pixel data?
22:16:25 <Sidar> nvm, im just going to fake this uml XD
22:21:07 <Eddi|zuHause> the pixel data is in the sprite cache
22:22:30 <Sidar> Doesnt it just load the complete spritesheet/TextureAtlas?
22:22:52 <Sidar> or is it seperated into seperate sprites on load time?
22:27:44 <planetmaker> each sprite is separate with its ID. But all are loaded upon load time, if the cache is big enough
22:31:38 <Eddi|zuHause> i don't actually know the code, but i presume that upon game start, only the positions of the sprites are loaded. the actual pixel data is only loaded on the first draw (and then cached for future redraws)
22:32:26 <Eddi|zuHause> "position" means "which file and at what offset"
22:33:15 <Eddi|zuHause> which btw brings me back to an old suggestion: in the sprite-aligner, it should show the grf-local sprite id
22:35:27 <Sidar> Is there by any chance somewhere a State-Pattern implemented? Or something close to that?
22:37:31 <Eddi|zuHause> probably you should refer to the canonical documentation for that kind of question
22:39:06 <__ln__> or the United States constitution
22:52:53 <michi_cc> Sidar: If you want a class, then probably no. But the cursor action handling is doing it, just without classes (start at SetObjectToPlace in viewport.cpp).
23:00:28 <Eddi|zuHause> Sidar: due to the nature of OpenTTD as a reverse-engineered asm-to-c project, some of this stuff may be so old it doesn't fit into classes or patterns very well
23:01:10 <Sidar> Picked the wrong project then didnt I XD
23:09:32 <michi_cc> Most of the design pattern crowd seems to forget that there's more than just object oriented programming, and obviously OOP is always the best thing in the world (Java, I'm looking at you :)
23:11:38 <Eddi|zuHause> historically "design patterns" are not "how to do it" templates, but "how did people actually do this" surveys
23:12:09 <Eddi|zuHause> no theoretical computer scientist ever bothered with "design patterns"
23:12:46 <Sidar> It's just a school assignment, dont point at me.
23:13:34 <Sidar> Eddi|zuHause: a bold statement dont you think? I mean they are applied in tons of applications.
23:14:01 <Eddi|zuHause> Sidar: but applications are not written by theorists either
23:14:37 <Sidar> However lots of theorists actually do bother with design patterns. I mean how else are they thought up to begin with.
23:15:36 <Eddi|zuHause> Sidar: that's what i am telling you. design patterns were thought up by practicians, and later formalized when it worked.
23:15:42 <Sidar> Design patterns are just abstract ideas, not actual implementations
23:16:14 <Eddi|zuHause> the pattern wasn't there first
23:16:40 <Sidar> That doesn't mean a thing. Thats like saying the factory wasn't there first, so we should still do things by hand.
23:17:02 <Eddi|zuHause> where do you think i said that?
23:17:05 <Sidar> I mean design patterns are there to help with a problem. Its not there to be fancy
23:17:26 <Eddi|zuHause> besides, 90% of the "patterns" are "glue" that try to bring two existing implementations together
23:17:28 <Sidar> Well you say the pattern wasn't there first. What else are you implying?
23:17:37 <__ln__> no, design patterns are there to describe how smart people have solved some particular types of problems.
23:18:24 <Eddi|zuHause> that also means, you don't need 90% of the "patterns" when you design an application properly
23:21:15 <Sidar> "need" is ambiguous. And "properly" as well. But I digress. Enough programming for todat
23:23:19 <__ln__> using 90% of the design patterns in one application doesn't make it good.
23:23:38 <Sidar> Doesnt make sense either =P
23:35:55 <Rhamphoryncus> I'm with Eddi. Techniques -> patterns of code -> design patterns. It's not the other way around
23:36:04 <Rhamphoryncus> And techniques are very fluid
23:37:51 <Rhamphoryncus> Is a linked list a design pattern? It's just a linked list implementation
23:38:16 <Rhamphoryncus> "pattern" is merely a buzzword. A fad.
continue to next day ⏵
