IRC logs for #openttd on OFTC at 2012-06-22
⏴ go to previous day
01:15:09 *** Mazur is now known as Guest771
01:15:22 *** Guest771 is now known as Mazur
01:40:43 *** kkimlabs has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
06:05:33 *** LordPixaII has joined #openttd
06:19:33 *** kkimlabs has joined #openttd
06:32:11 *** LordPixaII has joined #openttd
06:34:23 *** telanus has joined #openttd
06:36:25 *** KingPixaIII has joined #openttd
06:37:02 *** sla_ro|master has joined #openttd
06:44:14 *** LordPixaII has joined #openttd
07:16:08 *** TGYoshi has joined #openttd
08:14:53 *** Devroush has joined #openttd
10:13:02 *** drac_boy has joined #openttd
10:25:58 *** Biolunar has joined #openttd
10:29:08 *** Zeknurn has joined #openttd
12:28:13 *** Prof_Frink has joined #openttd
12:57:13 *** Prof_Frink has joined #openttd
13:08:03 *** Rhamphoryncus has joined #openttd
13:11:39 *** tokai|noir has joined #openttd
13:11:39 *** ChanServ sets mode: +v tokai|noir
13:43:16 *** sla_ro|master has joined #openttd
13:43:41 *** Belugas has joined #openttd
13:43:41 *** ChanServ sets mode: +o Belugas
13:44:25 *** TWerkhoven[l] has joined #openttd
14:24:51 *** HerzogDeXtEr1 has joined #openttd
14:57:00 *** kais58_ has joined #openttd
15:06:48 *** telanus has joined #openttd
15:09:56 *** Progman has joined #openttd
15:10:17 *** FLHerne has joined #openttd
15:41:25 *** kais58_ has joined #openttd
16:06:48 *** kais58_ has joined #openttd
16:14:38 *** mikegrb has joined #openttd
16:21:53 *** frosch123 has joined #openttd
16:22:49 *** kais58_ has joined #openttd
16:28:48 *** Zeknurn has joined #openttd
16:37:18 *** valhallasw has joined #openttd
16:41:10 *** kais58_ has joined #openttd
16:52:08 *** Stimrol has joined #openttd
16:55:47 *** kais58_ has joined #openttd
17:01:45 *** valhalla1w has joined #openttd
17:01:55 *** glx is now known as Guest845
17:07:50 *** telanus1 has joined #openttd
17:23:58 *** Alberth has joined #openttd
17:23:58 *** ChanServ sets mode: +o Alberth
17:28:40 *** kais58_ has joined #openttd
17:30:56 *** telanus1 is now known as telanus
17:32:38 *** Prof_Frink has joined #openttd
17:39:08 <Rubidium> Wolf01: darn it... it's afternoon!
17:39:28 <Rubidium> more than leet o'clock as well
17:39:30 <Wolf01> isn't it saturday morning?
17:40:40 <telanus> it's almost 20:00 here
17:41:16 <Wolf01> good, so I have more time to spend, this time I set wrong (on the right way) the time machine controls
17:41:36 *** kais58_ has joined #openttd
17:55:03 *** kkimlabs has joined #openttd
17:55:20 *** kais58_ has joined #openttd
18:11:06 *** kais58_ has joined #openttd
18:17:55 *** valhallasw has joined #openttd
18:22:29 *** Rubidium_ has joined #openttd
18:25:51 *** kais58_ has joined #openttd
18:28:54 *** Rubidium_ has left #openttd
18:34:18 *** Dr_Tan is now known as Nat_aS
18:42:38 *** kais58_ has joined #openttd
19:00:32 *** kais58_ has joined #openttd
19:15:19 *** kais58_ has joined #openttd
19:21:03 *** mahmoud has joined #openttd
19:22:04 * Belugas wonders if interbase/firebird can do binary operations natively...
19:22:58 <Alberth> kais58 can you please fix your connection?
19:23:34 <Alberth> it's not firefox, is it? :)
19:23:43 <Belugas> or we'll fix it for you >:)
19:25:47 <Alberth> Belugas: perhaps you can try computing 1+1 on it :)
19:26:15 <Alberth> unless you have other binary operations in mind than I have :p
19:26:31 <Belugas> will work for sure... problem : see if bit x is raised on column y
19:26:43 <Belugas> guess i have no choice but do some UDF functions
19:27:21 * Alberth ponders about the magic div/mod formula
19:31:04 *** kais58_ has joined #openttd
19:32:13 <Alberth> (N div (2**y)) mod 2 != 0
19:33:36 <planetmaker> what's magic about that?
19:33:53 <planetmaker> oh, and good evening :-)
19:34:04 <Alberth> I had to think about it for 1 minute?
19:34:13 <Alberth> evenink planetmaker :)
19:34:27 <Alberth> so used to having & and << around :)
19:34:53 <planetmaker> :) And div certainly does not mean the (vector operator) divergence :-P
19:35:35 <Alberth> given that I didn't even know it existed, I doubt it :)
19:36:27 <Alberth> but if it helps in doing bit arithmetic, fine by me :)
19:36:41 <planetmaker> the divergence of a vector field gives you the amount of sinks or sources :-)
19:37:29 <Alberth> oh, is it a bit fast if we apply it to a cargo stream?
19:39:22 <planetmaker> :-) Probably the divergence of an openttd cargo map is positive. More primaries than secondaries and tertiaries ;-) Fast... depends :-P
19:39:36 <Belugas> div and mod and note recognized by the sql server, bt i expecpted that
19:40:13 <Alberth> assuming it has the usual C / semantics :)
19:41:11 *** TheMask96 has joined #openttd
19:41:38 *** mahmoud has joined #openttd
19:50:54 *** kais58_ has joined #openttd
19:53:05 *** kais58_ is now known as kais58r
19:53:12 *** kais58r is now known as kais58
19:56:36 <Alberth> @ban add kais58 100000
20:00:45 *** Alberth sets mode: +b *!*@cpc2-cwma8-2-0-cust293.7-3.cable.virginmedia.com
20:03:20 *** kkimlabs has joined #openttd
21:04:03 <Eddi|zuHause> so i guess tomorrow the headlines will be "greece drops out of euro" :p
21:21:37 *** Chris_Booth has joined #openttd
21:34:39 *** Chris_Booth is now known as Guest878
21:34:44 *** Chris_Booth has joined #openttd
21:40:33 <Chris_Booth> not sure since my openttd account is broken
21:40:51 <Chris_Booth> ask someone who has admin rights or who had voice
21:41:12 <Chris_Booth> the is @/+ or gray/green
21:41:57 <planetmaker> 'player ressources' you mean?
21:42:20 <Chris_Booth> planetmaker: can you delete or reset my account chris_booth?
21:45:59 <planetmaker> maybe I can do that... but... what is a "broken account"?
21:47:43 <GT> PM: yes, see the main page test page
21:48:14 <Chris_Booth> but will not let me use the wiki :S
21:48:39 <Chris_Booth> unless I am wrong and I need a wiki account aswell pm
21:49:54 <GT> I'm removing all links to tar files from innocent newbie info pages. I see an increasing amount of questions that tars don't work for 1.2, which is obviously correct, but reference to tars is now only needed for grf-devs that want to convert to newgrf.
21:51:14 <planetmaker> Chris_Booth: there's only one accout, which works the same on wiki, bugs, bananas, translators, etc
21:51:17 <glx> Chris_Booth: old unmerged account ?
21:51:20 <GT> @PM, thanks, I knew we could cooperate some way or another.
21:52:00 <planetmaker> GT I didn't (yet) check the test page... is there other uncommitted stuff?
21:53:49 <glx> Chris_Booth: hmm maybe wiki login filters too much (wiki does weird things with special chars)
21:53:53 *** kkimlabs_ has joined #openttd
21:53:55 <planetmaker> if it's an old, un-merged account, I'm not sure I can help it...
21:55:54 <planetmaker> I probably just kill my browser by requesting a list of all users registered with openttd...
21:56:53 <planetmaker> "the script doesn't answer or takes too long to answer. Do you want to abort?" :-P
21:57:48 <Chris_Booth> hhhm might just make a new account then
21:58:03 <Chris_Booth> was my old bugs.openttd.org account
21:58:19 <Chris_Booth> not got a clue how to merge and can't be bothered to look
21:58:46 <Chris_Booth> if you want to kill it you can
21:58:56 <Chris_Booth> or you will have a dead account
22:01:31 <planetmaker> I'm not sure I dare do that. It will need Truebrain too look at the account of chris_booth and see why it only works for bugs but not wiki
22:02:56 <planetmaker> is your hotmail address still valid, Chris?
22:03:23 <Chris_Booth> yes chris underscore peter underscore booth at hotmail dot co dot uk
22:03:59 <planetmaker> just asking so that TB could notify you, if / when he looks at it
22:05:09 <Chris_Booth> ah cool just typing it that way to people can't C&P it
22:06:21 <TrueBrain> planetmaker: he can login to www but not to wiki?
22:06:33 <planetmaker> to bugs but not wiki.
22:06:35 <TrueBrain> then there is no merging issue; most likely mediawiki just wants a ' ' (\s, space) for the _
22:06:46 <TrueBrain> I tried to tell it not to, but it is stubborn
22:06:57 <planetmaker> and... he just left...
22:07:17 <TrueBrain> internally mediawiki makes every space a _
22:07:22 <TrueBrain> so I guess the reverse holds too
22:07:35 <TrueBrain> my best guess ... if someone can login to any other of the 3 services, he merged his account
22:07:38 <planetmaker> likely assumption, yes
22:17:43 <GT> @PM, what's your opinion about my publishing of Ben Robbins landscape sprites on http://dev.openttdcoop.org/projects/32bpp/files? I did that to have some 32bpp graphics in newgrf format again so 1.2 users can have some 32bpp graphics again, and get the community active. You and I got into a discussion about jagged edges on ground sprites, but in the end we just succeeded in stalling everything. I think that we first need to have critical mass of newgrf
22:19:02 <GT> I'm not the most patient person in the world, and just wanted to enforce some action in 32bpp again.
22:19:57 <GT> I mean, 4 months have past, and Joe Average still can not have a decent amount of 32bpp graphics in 1.2
22:20:21 *** Arendtsen has joined #openttd
22:27:19 <planetmaker> I've not seen any new arguments or someone looking at solutions wrt border cases. Nor did I have time myself to create such test cases or examples. Thus I can't add anything new to it
22:32:10 <planetmaker> And I personally do not want to rush it without having made a sound decision without looking at the different options we have at the cases we should consider as setting bad first examples causes way too many headaches in the future
22:32:26 <planetmaker> newgrf specs are a good (or rather terrible) example there.
22:33:08 <planetmaker> despite that, GT, I think that Ben's tiles use the wrong sun direction
22:33:59 <GT> Yeah, I remember that discussion too.
22:34:46 <planetmaker> which is no issue, if they exist as templates to be rendered with a proper light template
22:34:58 <planetmaker> s/templates/blender files/
22:34:58 <GT> Original graphics are ambiguous
22:35:42 <frosch123> hmm, is the 2 ton forklift from heqs or from ogfx+rv?
22:36:05 <GT> For a good 32bpp base set, agreement on sun direction is important.
22:36:44 <GT> And I absolutely agree that for some vehicles, the SE side is much too dark.
22:38:33 <planetmaker> GT: do not worry about re-rendering. I'm convinced that every model needs re-rendering before it is proper. Whatever light is used
22:38:52 <planetmaker> as they surely do not use a common light setup
22:39:38 <planetmaker> Thus using the pre-dominant and usually accepted 4:30 ... 5 pm sun high in the sky position would suit it well...
22:41:43 <GT> Well, the predominant and usually accepted part may not be true in the 32bpp world, where the template-f is usually used.
22:42:06 <GT> Which does not use that setup
22:44:06 <planetmaker> GT: there's no 32bpp set except ogfx-trains. And tbh, I still have the feeling that its light setup is too much Easterly and too little Southerly wrt shadows
22:45:12 <planetmaker> i.e. I still have the impression that it uses exactly Eastern sun, despite that Xotic tells me that the sun is not at 3 pm.
22:45:27 <planetmaker> (why is the sun at 3pm in the East :-O ?)
22:47:56 <GT> So accepting the 4:30 ... 5 pm position would render a lot of currently availably graphics useless. And several artists creating the currently available graphs have gone inactive. So I understand your question, but it would set back the available graphics even further. Which would not be a problem if we had lots of artists active, but that is not the case. But you are right that agreement on the template/setup is important. So let's provide clarity for
22:49:10 <planetmaker> GT: "render a lot of currently availably graphics useless" and "I'm convinced that every model needs re-rendering before it is proper. Whatever light is used". Yes. But it's "just" a matter of rendering
22:49:31 <planetmaker> I provide free CPU for those who want. Xotic wrote all the scripts to make sprites from that
22:49:48 <planetmaker> so it's not lost work. Unless it's already lost due to missing models
22:50:00 <planetmaker> which is then no loss really
22:50:16 <planetmaker> well. it is. But one which happened way before OpenTTD 1.2.0
22:51:17 <planetmaker> GT: The DevZone has 2 cpu cores which can be used for rendering 24/7 in principle. Xotic makes use of them a lot currently, but there's space for more
22:52:11 <GT> True, but not all models are available in all formats. E.g Ben uses a 3Dmax, which is a non-free program I don't have. And he is not very active lately, and his renders are heavily post-processed. So re-render is not obvious.
22:54:22 <GT> But maybe the best way would be to just let go of everything that was available in tars, set very clear graphics standard for ogfx / nwgrf, and only accept high quality graphics. The tars were a nice prototype, but now we start the real work.
22:54:26 <Alberth> such a shame, people wasting their time on old and useless graphics
22:54:26 <planetmaker> GT: if you want to release those sprites as is as newgrf: it's a free world and I can't stop you and won't try
22:55:09 <planetmaker> and I do agree, they *are* nice ones.
22:55:19 <planetmaker> But with the mentioned light issues.
22:56:27 <planetmaker> Alberth: *might* be true. ogfx-trains imho has complete 32bpp as xotic made it basically from scratch. completely.
22:57:30 <planetmaker> but it does require a dedicated modeller / artist. And he also programmes it himself mostly
22:57:48 <planetmaker> thus it requires a very high degree of dedication. And knowledge of all the tools
22:58:43 <planetmaker> thus he knows and uses blender, ssh, hg, bash, python, nml, make, gcc
22:58:52 <planetmaker> few artists do :-)
22:59:02 <Alberth> but at the same time, imho that's the only way forward
22:59:30 <Alberth> you need to get sources which are free of license issues and easily re-generatble
23:00:05 <Alberth> however you see everybody messing around with the old graphics instead :(
23:00:29 <Alberth> (as I predicted would happen)
23:00:29 <planetmaker> GT: one issue we have e.g. with ogfx-trains is also the 8bpp sprites. Especially of the newly generated stuff.
23:00:51 <planetmaker> But there we most likely will just use the 8bpp version as script-generated from those renders then
23:01:11 <planetmaker> Alberth: I think that will change when we get ogfx-trains release-ready
23:01:23 <planetmaker> it's all crisp-new :-)
23:01:36 <planetmaker> all zoom levels in 32bpp
23:01:57 <Alberth> I hope so, but I'll have to see it happen first, I am afraid
23:02:55 *** George is now known as Guest895
23:02:56 <planetmaker> we now have 32bpp NewGRFs for 2.5 months. Creating graphics is time consuming. Judge it my April next year :-)
23:05:30 <GT> @Alberth: "such a shame, people wasting their time on old and useless graphics". I'm sorry you made that remark. People have spent a lot of time on creating them, and were not involved in making them useless. In fact, they were not even involved in the process, but put into a 'fait accomplit' when michi made his commit. Don't blame that on the ones that have no power in the process
23:06:43 <Alberth> I was refering to the people currently trying to use the graphics, instead of accepting it is not going to work
23:06:53 <Alberth> I was not refering to the creators
23:07:10 <GT> Sorry, misunderstood you in that case.
23:07:49 <GT> And indeed, I think all the guys using the Rubi script are wasting the time.
23:11:08 <Alberth> the bad thing about it is that it sends out mixed messages, imho
23:12:46 <GT> What would be your preferred way of moving forward. I have the feeling that several people, not excluding myself want 32bpp to be successful, but that miscommunication and unclear guidelines block progress
23:13:43 <planetmaker> GT: from my POV the best way is to take the lessons learnt, take some, single models, but forget about all sprites.
23:14:21 <Alberth> in particular stop making them available to the public
23:14:31 <planetmaker> And then create the sprites from models for all ogfx+ NewGRFs (existing + yet to be created like tracks, bridges, stations, aircraft and ships)
23:14:51 <planetmaker> and to make those NewGRFs in their own right
23:15:09 <Alberth> make clear rules on new models that can be accepted (if it does not exist already)
23:15:56 <Alberth> I am not sure whether the edge problem can be post-poned, by optionally re-rendering if the wrong decision is made now
23:16:01 <frosch123> oh, it's turing day
23:16:07 <planetmaker> GT: I actually do think that I should start putting the trains as 32bpp into OpenGFX itself. They're quite finished already
23:16:31 <Alberth> if so, just pick one way, and move forward
23:16:39 <planetmaker> Alberth: I don't think it should be postponed - even if it can. I think it rather cannot
23:16:58 <Alberth> planetmaker: ok, so what do we do?
23:17:31 <planetmaker> edge / test cases there are: building covering whole tile next to plain ground tile (like large depots). The building must not be overwritten by the ground tile.
23:18:09 <planetmaker> - bridge ramp on both slope and flat terrain must connect to road w/o glitch. Same with track pieces connecting
23:18:26 <Alberth> so some testing needs to be done?
23:19:22 <Alberth> GT: the whole point is imho that it should be cheap to create sprites, that makes these sprite issues much less of a problem
23:19:25 <planetmaker> - flat terrain on foundations. The foundations probably should not be as jagged as a simple pixel-scaling for 2x and 4x results in
23:19:49 <frosch123> Alberth: basically it needs a decision what looks worse :) glitches when combining extra-zoom with normal zoom sprites (e.g. from existing newgrfs), or weird tileborders forever :p
23:20:25 <GT> Imo the most important first thing is to set the lighting standard. The ground tile edges discussion is important too, but affects only the ground tiles. The lighting includes every sprite, including trains and other vehicles.
23:20:32 <planetmaker> frosch123: and a clear definition of what the tile border is in the first case
23:20:45 <frosch123> though the weird tileborders are actually only noticeable when using the biggest zoom level, at which actually a lot of stuff looks weird, e.g. vehicle movement
23:21:05 <planetmaker> GT: "only" means about 50% of the base set
23:22:01 <planetmaker> as train, road, water, fields, industries, houses, bridges, stations, objects all have tiles :-)
23:22:39 <Alberth> so some testcases are needed I think to be able to judge it both ways (which should be easy if sprite generation is cheap enough)
23:23:21 <GT> True. In my opinion combining existing newgrfs with extra zooms will never look good, so weird edges in that case are acceptable. But having all ground sprites, when not combining with old newgrf look weird is just silly.
23:23:44 <Alberth> In the long run, we are going to be more happy with straight borders, perhaps
23:23:46 <GT> The true is about the 50 %
23:24:11 *** mahmoud has joined #openttd
23:24:44 <planetmaker> so we need a way to make that as glitch-free as possible
23:25:06 <frosch123> which means testing different overlapping strategies :)
23:25:08 <GT> rendering is also more difficult, as renderers would use a straight edge, and making them jagged would require postprocessing using some mask
23:25:25 <Alberth> GT: so perhaps examples of jagged borders with only new tiles too?
23:25:46 <frosch123> GT: rendered groundtiles will always need postprocessing
23:26:09 <frosch123> no rendered will be able to make the proper shape itself, esp. when antialiasing is involved
23:26:22 <frosch123> so, it always needs cutting out from a bigger sprite
23:26:38 <GT> You cannot AA groundtiles, they overlap, at least on 2 edges
23:26:50 <frosch123> (which would also solve continuation issues with "high grass")
23:26:52 <planetmaker> every render probably needs some post-processing...
23:27:32 <planetmaker> cutting out from something bigger might actually be a good idea for ground
23:27:36 <GT> High grass is another discussion, I agree that overlapping should not extend the jaggedness of borders
23:27:55 <planetmaker> so then it would need masks for ground tiles (whatever exact shape) - but does it hurt to have such masks?
23:28:04 <GT> But Blender can render perfectly within a certain border
23:28:30 <planetmaker> GT: I was told that the result is bad, if you render sprite size. It's better to down-scale in the post-processing
23:28:35 <Alberth> then the mask simply does nothing
23:29:33 <planetmaker> I can only try to tell what xotic tries to teach me. But he showed me the difference and it does look considerably better to render bigger and post-process with scaling to sprite sizes
23:30:14 <GT> Yes, but even when you do postprocessing, the result looks bad, e.g when combining a grass till with a pavement tile. It tried, and just does not look good.
23:31:37 <GT> he'll read tomorrow and be pleased about our kindness
23:32:53 <Alberth> I never read back #openttd after log in, I trust you guys behave while I am not here :p
23:33:14 <planetmaker> :-D It's nice to see people still have illusions and dreams ;-)
23:33:47 <Alberth> GT: so the best way to make a ground tile seems to be another issue that needs examples and discussion
23:35:07 <planetmaker> without wanting to end the discussion (it's been good), I'd like to put it off to another day. I got to get up in 6 hours...
23:35:29 <planetmaker> so a good night from here, too :-)
23:35:37 <Alberth> good night planetmaker
23:35:54 <GT> Night (fast enough now). We´ll be in touch and thanks for the fruitful discussion, I enjoyed.
23:35:55 <Alberth> and from me too, good night
23:36:22 <planetmaker> yep, sleep well, you two
23:36:28 <Alberth> pm never leaves, so you never know whether he reads it or not :)
23:36:42 <planetmaker> :-D Not before Sunday evening
23:36:57 <Alberth> have a nice weekend then
23:37:20 <GT> He does not have illusions, so Im sure he'll read back
continue to next day ⏵