Back to Home / #openttd / 2011 / 11 / Prev Day | Next Day
#openttd IRC Logs for 2011-11-24

---Logopened Thu Nov 24 00:00:25 2011
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:22-!-Adambean [] has quit [Quit: Gone fishing]
01:33-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
01:45-!-Celestar [] has joined #openttd
01:59-!-Snail_ [] has quit [Quit: Snail_]
02:05-!-Celestar [] has quit [Ping timeout: 480 seconds]
02:14-!-supermop_ [] has quit [Quit: supermop_]
02:25-!-Celestar [] has joined #openttd
02:25-!-Cybertinus [] has joined #openttd
02:37-!-Celestar [] has quit [Ping timeout: 480 seconds]
02:38-!-sla_ro|master [~slaco@] has joined #openttd
03:01-!-DayDreamer [] has joined #openttd
03:06-!-Zuu [] has joined #openttd
03:10<Xaroth>hrnf, tt-forums down
03:19-!-Neon [] has joined #openttd
03:24-!-Celestar [~dax@] has joined #openttd
03:29<Xaroth>lo dih
03:29<dihedral>hello Xaroth
03:30<dihedral>Interesting commits going on lately
03:31<dihedral>TrueBrain, nice to see your activity again ;-)
03:31<dihedral>good old times
03:31-!-MNIM [~mBuntu@] has joined #openttd
03:40-!-Zuu [] has quit [Ping timeout: 480 seconds]
03:42-!-MNIM [~mBuntu@] has quit [Ping timeout: 480 seconds]
03:51-!-MNIM [] has joined #openttd
03:58<@peter1138>i reckon we could get EZ by this evening :D
04:04-!-Arie- [] has joined #openttd
04:18-!-collinp [] has quit [Quit: This computer has gone to sleep.]
04:30-!-Celestar_ [~dax@] has joined #openttd
04:32-!-Celestar [~dax@] has quit [Ping timeout: 480 seconds]
04:38<@peter1138>hmm, quiet this morning
04:41-!-sla_ro|vista [~slaco@] has joined #openttd
04:42-!-tokai|mdlx [] has joined #openttd
04:43-!-hanf [] has joined #openttd
04:44-!-MNIM [] has quit [Remote host closed the connection]
04:45<TomyLobo>towns have goals?
04:45<TomyLobo>what does that mean?
04:46-!-sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
04:46-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
04:48-!-tokai [] has quit [Read error: Operation timed out]
04:56<@peter1138>TomyLobo, in arctic/tropic you may or may not have to send food to them for them to grow
05:08<TomyLobo>oh, that
05:08-!-collinp [] has joined #openttd
05:09-!-collinp [] has quit []
05:11-!-pjpe [] has quit [Quit: ajax IRC Client]
05:15-!-Brianetta [] has joined #openttd
05:37-!-hanf [] has quit [Read error: Connection reset by peer]
05:47-!-andythenorth [] has joined #openttd
05:57-!-sla_ro|vista [~slaco@] has quit []
06:24-!-DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]]
06:26-!-Celestar_ is now known as Celestar
06:27<Eddi|zuHause>where's orudge when the forum is down all day?
06:27<andythenorth>busy working on it, and not hanging out here? :P
06:27*andythenorth hopes
06:31<@orudge>hence the message on the forums
06:31<@orudge>in theory, they should be up within half an hour
06:31<@orudge>possibly sooner
06:31<Eddi|zuHause>the only message i get is a 404
06:31<@orudge>go to then
06:31<@orudge>I didn't bother setting up the message for any request
06:31<@orudge>because of, well, effort
06:31<@orudge>I suppose I could set it as the 404 page though
06:33<Eddi|zuHause>i think i got a 503 or something earlier this morning
06:34<@orudge>that was before I put the message up
06:34<Eddi|zuHause>i wasn't paying too much attention... because it was early morning...
06:45<@orudge>Forums should be back up
06:46<@peter1138>cool, should be lots of posts to read ;)
06:49*andythenorth has been missing out on lots of discussion :(
07:03-!-welshdragon [] has joined #openttd
07:08<Celestar>what's this with people sending about endless mail chains ffs
07:09<Sacro>peter1138 likes endless male chains
07:10<Rubidium>Celestar: then you haven't trained those who email you well enough
07:18<andythenorth>threaded view, delete
07:18<andythenorth>problem solved
07:20<CIA-6>OpenTTD: peter1138 * r23314 /trunk/src/ (8 files in 4 dirs): -Add: Add settings to restrict viewport zoom levels.
07:24<Celestar>andythenorth: the problem is that it comes as ONE mail.
07:24<Celestar>andythenorth: subject: RE: RE: Re: RE: Aw: Re: AW: Re: RE: AW: Re: Re: <actual subject>
07:25<Celestar>and then you dig through the one mail trying to determine wtf they are on about
07:26<CIA-6>OpenTTD: peter1138 * r23315 /trunk/src/ (7 files in 3 dirs): -Codechange: Only encode sprites for zoom levels that will be used.
07:35-!-Progman [] has joined #openttd
07:38<CIA-6>OpenTTD: peter1138 * r23316 /trunk/src/ (29 files in 5 dirs): -Feature: Add ability to zoom in to 2x and 4x level.
07:40<@peter1138>you, er, might wanna increase your spritecache size
07:40<Celestar>are the sprites bigger now? :P
07:40<@peter1138>possibly so
07:42<Celestar>sprite_cache_size is in MB?
07:42<@peter1138>default was 4, not 64
07:43<@peter1138>you can disable the zooming in, in which case it's not needed
07:43<@peter1138>i'll probably stick to 2x max myself
07:44<Rubidium>I think we should increase that default in configs in some way, otherwise it's going to give a lot of "openttd is slow" bug reports with 1.2.0-beta1 and later :(
07:44<Celestar>is OpenGFX getting new graphics?
07:44<@peter1138>Rubidium, yeah
07:48<andythenorth>Celestar: just ignore mails. If it's important, some one phones you...
07:53-!-glx [glx@2a01:e35:2f59:c7c0:3943:8607:c2d9:f6cc] has joined #openttd
07:53-!-mode/#openttd [+v glx] by ChanServ
07:56-!-welshdragon [] has quit [Quit: welshdragon]
08:05-!-Neon [] has joined #openttd
08:12-!-welshdragon [] has joined #openttd
08:19-!-welshdragon [] has quit [Quit: welshdragon]
08:33-!-Kurimus [] has joined #openttd
08:45-!-TomyLobo2 [] has joined #openttd
08:49-!-welshdragon [] has joined #openttd
08:50-!-TomyLobo [] has quit [Ping timeout: 480 seconds]
08:50-!-TomyLobo2 is now known as TomyLobo
09:23-!-TGYoshi [~TGYoshi@] has joined #openttd
09:32-!-welshdragon [] has quit [Quit: welshdragon]
09:42-!-welshdragon [] has joined #openttd
09:43-!-welshdragon [] has quit []
10:00<@planetmaker>Celestar, probably will get additions. But as things are, I'd not assume it'll be quickly
10:01<@planetmaker>thus it's good the upscaling works for my taste quite well :-)
10:01<@planetmaker>But I guess I'll start adding zoomed-in sprites once we can do that
10:07<andythenorth>planetmaker: how does EZ perform on your mac?
10:07*andythenorth has much sadface
10:08<andythenorth>only the intro screen seems to be affected
10:08<andythenorth>with 4x zoom enabled (but not zoomed), there is significant cursor lag on the intro screen
10:08<@planetmaker>andythenorth, change your cfg
10:08<@peter1138>increase sprite cache size
10:08<@planetmaker><planetmaker> sprite_cache_size = 64
10:09<@planetmaker>instead of =4
10:09<@planetmaker>then it performs very well
10:09<andythenorth>interestingly it's fine on a 512x512 map with *no* vehicles
10:09<@peter1138>it would be
10:09<@peter1138>sprites are loaded as needed, so...
10:10<@planetmaker>andythenorth, first quit openttd, then edit the cfg :-)
10:10<andythenorth>yup 64 ftw
10:10<andythenorth>well that's nice
10:10<@peter1138>Celestar, i need paxdest
10:10<@planetmaker>I very much like the 2x zoom, andythenorth :-)
10:10<andythenorth>maybe people will draw the lighting correctly now :D
10:10<@planetmaker>it feels (to me) very natural
10:11<andythenorth>don't look too closely at FIRS sprites though :P
10:12<@peter1138>good job it came after michi_cc's shorter vehicles fix :)
10:12<@planetmaker> <-- not that bad, I'd say
10:12<@planetmaker>And: too late, andythenorth, I did :-P
10:12<@planetmaker>yesterday even ;-)
10:12<V453000>looks superb to me
10:19<@peter1138>all the little people on MB's stations are suddenly big :p
10:24<@planetmaker>I dropped a small hint to grab todays nightly in the German forums... let's see how they'll react :-)
10:24<@planetmaker>You might want to put up a hint here, too - along with the advise to adjust the sprite_cache
10:25<@peter1138>just need to change the setting name
10:25<@peter1138>what to?
10:26<@peter1138>the vehicle windows look tiny now :p
10:27<+michi_cc>peter1138: max_sprite_cache_size (no need to tell anybody we always allocate the max :)
10:28<@peter1138>interesting idea thoug
10:29<@peter1138>if (spritecachefull) resizeit
10:29<@peter1138>would need a lot of pointers updating
10:32<@peter1138>. o O ( YAIM / YACD / YAMA / YANO )
10:33<V453000>YAWTF? :)
10:41-!-Adambean [] has joined #openttd
10:45-!-Celestar [~dax@] has quit [Ping timeout: 480 seconds]
10:52<Eddi|zuHause>Not Another Russian Patchpack?
10:52-!-sla_ro|master [~slaco@] has joined #openttd
10:54<@planetmaker>New Asteroid Ressource Programme
10:57<Eddi|zuHause>if on eath metal ressources are typically found near tectonic fault lines, why would one assume that metals can be found on asteroids? or on mars?
11:02<@planetmaker>I'm not sure that your assumption is correct in the first place. And it might be interesting to note that there are differenciated and undifferenciated asteroids
11:02<CIA-6>OpenTTD: peter1138 * r23317 /trunk/src/table/misc_settings.ini: -Change: Rename sprite_cache_size setting so that the new default is used.
11:03<@planetmaker>in the latter you might have rather pristine abundance of all non-refactory elements. Thus the metal contents is higher than on the average non-magmatic stuff
11:03<@planetmaker>on Earth. And for the differenciated, you might find some which broke up, thus you might find even more or less metal-enriched bodies
11:04<@peter1138>dbg: [sprite] LoadNewGRF: Currently 34999 sprites are loaded
11:04<@peter1138>back in the day
11:07<@planetmaker>that's not so surprising
11:07<@planetmaker>like 6k from the base set already. Always
11:08<@peter1138>use to be 3-4k?
11:08<@planetmaker>hm... or 10k? Not sure currently
11:08<@planetmaker>no, always more
11:08<@planetmaker>it's already >4k in trg1r.grf
11:08<Eddi|zuHause>how much if you load CETS? :)
11:09-!-Elukka [] has joined #openttd
11:09<@peter1138>hm, i misremember :p
11:09<@peter1138>anyway, there was that 16k limit
11:09<@planetmaker>there isn't :-)
11:09<Eddi|zuHause>goes it throw out limitation?
11:09<@planetmaker>anymore. Dunno for how long :-)
11:09<@planetmaker>but longer
11:10<@peter1138>i fixed that with my bare hands
11:10<@peter1138>ooh, new version of CETS :D
11:11<@planetmaker>I hope you didn't dirty your hands too much ;-)
11:11<@peter1138>dbg: [sprite] LoadNewGRF: Currently 60588 sprites are loaded
11:11<@peter1138>planetmaker, it was a huge patch :)
11:11<@peter1138>masses of tables needed reworking
11:12<@peter1138>so yes, 25000+ sprites in cets
11:12<@planetmaker>it was also a huge gain :-)
11:12<@peter1138>and it's not even usable
11:12<@peter1138>oh yes
11:12<@peter1138>well worth it
11:15<@peter1138>CETS is CETSky
11:16-!-rhaeder [] has quit [Ping timeout: 480 seconds]
11:17-!-z-MaTRiX [] has quit [Ping timeout: 480 seconds]
11:19<@peter1138>bit out of place alongside ukrs2 though
11:19<@peter1138>due to 1) awesomely long wagons 2) no running sounds (yet?)
11:40<Pinkbeast>On the other hand UKRS2 really needs _some_ extra set to patch some of the holes
11:41-!-Snail_ [] has joined #openttd
11:45<@peter1138>i don't think CETS is there yet ;)
11:45-!-Zuu [] has joined #openttd
11:59-!-Brianetta [] has quit [Quit: Tschüß]
12:04<@peter1138>i have no CETS wagon for wood :(
12:05<andythenorth>use trucks
12:05<@peter1138>boring :)
12:05<@peter1138>just had a stupid idea for that detailed purchase list sprite
12:05<andythenorth>do tell
12:06<@peter1138>allow the image to be rotated and zoomed
12:06<andythenorth>annoying rotator widget?
12:06<@peter1138>but won't work for those newgrfs that have just a west sprite for the there :S
12:06<@peter1138>except, unlike a flash applet, it won't take a minute to download all the images
12:06<andythenorth>ha, mine are mostly west only :P
12:07-!-welshdragon [] has joined #openttd
12:07<andythenorth>purchase list sometimes misses 'extra information for nerds'
12:07<@peter1138>welshdragon, you have eyesight issues don't you?
12:07<andythenorth>like which newgrf the vehicle is from, loading speed etc
12:09<@peter1138>oh dear, train stuck at 1mph is ... noisy
12:09<@peter1138>maybe i should tone down my freightweight
12:12-!-welshdragon [] has quit [Quit: welshdragon]
12:13-!-Priski [] has joined #openttd
12:15<Zuu>peter1138: Just show west image if the NewGRF doesn't contain rotatable images. I'm sure they will start to provide more images if the feature is added.
12:15-!-TWerkhoven [] has joined #openttd
12:15<CIA-6>OpenTTD: peter1138 * r23318 /trunk/src/texteff.cpp: -Change: Make text effects rise at their previous speed.
12:16<@peter1138>Zuu, the images are there, just... empty :p
12:16<Zuu>Oh, so you need to check if the pixels are transparent upon loading ad set a "empty" flag :-)
12:17<@peter1138>they're not loaded until they're drawn ;)
12:17<Zuu>but after they have been drawn once, aren't they cached then?
12:19<andythenorth>due to the action 2 chain, there's no sane way to predict what sprites a vehicle might show for buy menu
12:19<@peter1138>that too
12:19<andythenorth>for any vehicle, it's deterministic, but there are so many approaches to providing buy menu sprites
12:19<andythenorth>actually, it's not deterministic if I use random bits :P
12:19<andythenorth>which would be madness :P
12:20<@peter1138>anyway, it's not necessary, so there
12:20<andythenorth>would have to be a special flag, but...bigger fish to fry imo
12:20<@peter1138>yeah, like ez sprites
12:20<andythenorth>did I mention any of those?
12:20<TrueBrain>Zuu: FYI, in my latest version I renamed GoalNNN to GSNNN, and renamed 'goal' to 'game' (including directory of scripts). It is not uploaded yet or anything, but it most likely will be in the next version ;)
12:20<@peter1138>you might've done
12:20<andythenorth>you think ez sprites are needed? I like the appearance when zoomed
12:21<andythenorth>it's pretty fly
12:21<@peter1138>andythenorth, i love it
12:21<Zuu>TrueBrain: Thanks for your information.
12:21<Zuu>Sounds like a sensible change
12:22<TrueBrain>the GS part should be a lot easier to type over and over :D
12:22<TrueBrain>exactly :D
12:23<@peter1138>citroen gs?
12:23<Zuu>And it becomes easier to make a lazy AI -> GS conversion :-)
12:23<Zuu>As I assume GS is always uppercase, while Goal was not.
12:24<TrueBrain>another nice new addition, at the start of a new game, you get 250 ticks to do your script thingy. Works really awseom :D
12:24<TrueBrain>it is, yes
12:24<Zuu>For GS or also AIs?
12:24<Zuu>I suppose only GS.
12:24<TrueBrain>GS only, yes
12:24<TrueBrain>AIs have no business in that :)
12:24<+glx><@peter1138> citroen gs? <-- nice car :)
12:25<Zuu>As the other would be unfair against players, although to be really fair, AIs should be then allowed to hit pause and run while paused :-)
12:26<@peter1138>glx :)
12:27<Zuu>One thing with GS being allowed to run while pasued, it breaks my "break on pause" feature in the AI Debug window. :-)
12:27<Zuu>Eh. "break on log"
12:27<Zuu>Where "break" means that it pauses the game.
12:28<Zuu>But that is a secondary thing that could be solved down the road.
12:29<TrueBrain>yup :)
12:30<TrueBrain>and results of running the script for a bit during startup is really epic
12:30<TrueBrain>no longer you have to wait 30 seconds before all towns are marked etc
12:30<Zuu>Is any DoCommand accepted during those 250 ticks? Eg. could you build road, industries etc. ?
12:31<TrueBrain>those who are allowed by the API are, with no restrictions
12:31<TrueBrain>where normally you can only do 1 docommand per tick, you can do many many docommands in those ticks
12:31<Eddi|zuHause><peter1138> i have no CETS wagon for wood :( <-- there should be special wagons for wood
12:31<TrueBrain>it aborts on VM opcodes
12:31<Eddi|zuHause>double-wagons, actually
12:32<Zuu>So by default you have 250 * 10 000 instructions with no limitation that a DoCommand ends the tick?
12:32<TrueBrain>Zuu: but atm it looks like you will get access to all those commands yes
12:32<TrueBrain>so it is good practice to have a sleep() when you are done
12:32<TrueBrain>I now wrote code that inits the map, then it goes in a loop of real timer, waiting for the game to start
12:33<TrueBrain>that is the best way to end your startup cycle
12:33<TrueBrain>I considered adding an event, but polling events takes a lot of opcodes :P
12:33<Zuu>You could possible enforce that by adding a InitDone() function, and "crash" scripts that doesn't use it.
12:33<TrueBrain>I am thinking that the first Sleep() should just suspend it till the next time
12:34<TrueBrain>euh, till the game starts
12:34<TrueBrain>so: (your init code). this.Sleep(<any value>); <it will get here when the game is starting>
12:35<Zuu>It is maybe simplier to use Sleep than a new special InitDone, which will make it easier to learn GS and do it right in the long run.
12:37<TrueBrain>well, the other problem is that you might run out of time and you fail to do the Initdone because of that ;)
12:37<Zuu>But I don't know. Say that you don't know GS and read one GS-script that uses this.Sleep() and another that uses this.WaitForGameStart(), isn't the later more self explationary?
12:37<CIA-6>OpenTTD: peter1138 * r23319 /trunk/src/ (signs.cpp station_cmd.cpp town_cmd.cpp waypoint_cmd.cpp): -Fix (r23316): Offsets of viewport signs were not scaled up.
12:38<Zuu>Oh, yes, punishing GS scripts that don't call it within 250 ticks may be a bit too harsh.
12:39<Eddi|zuHause>what's the problem there? just let it go on tick-by-tick...
12:40<TrueBrain>Eddi|zuHause: that is what he is saying: his idea to abort an GS when it doesn't reach it, is a bit harsh ;)
12:40<TrueBrain>now they just run on, on a much slower speed, but okay
12:40<TrueBrain>Zuu: now thinking about it, I might make the initial part 'infinte' long
12:40<Eddi|zuHause>maybe throw out a debug message?
12:40<TrueBrain>where you have to trigger a Sleep(1) or what-ever function
12:40<TrueBrain>to finish generating the map
12:41<Zuu>Can the user abort map generation?
12:41<TrueBrain>well, there is an Abort button
12:41<Eddi|zuHause>only with threading enabled
12:41<TrueBrain>I am not promising it works on all OSes, but ;)
12:42<Zuu>Though, after 10 000 op codes, isn't the GUI updated?
12:42<TrueBrain>GS that takes very long will be punished by the community I am sure :P
12:42<Zuu>hehe :-)
12:42<TrueBrain>the GUI is updated every tick; not that it really matters :)
12:42<Eddi|zuHause>there is no community feedback on bananas
12:43<Zuu>So there is really no way for a GS to hang OpenTTD on startup. (other than using the same tricks an it could do when running normally)
12:44<TrueBrain>we can build in some extreme failsafe
12:44<TrueBrain>like 1000 ticks or whatever
12:44<Zuu>I don't think that will add anything, if the user can hit Abort if it takes too long.
12:44<TrueBrain>I agree; just not all systems can handle Abort during generation
12:45<TrueBrain>but you can always just kill :D
12:45<Zuu>Other than the fact that OpenTTD can punish the script so that the user don't think OpenTTD is broken :-D
12:45<Zuu>(if OpenTTD abort the script and display a red message if it takes longer than X ticks)
12:46<Eddi|zuHause>as an "outsider", i'd prefer the "run 250 ticks, and then go on tick-by-tick" method
12:46-!-Phoenix_the_II [] has joined #openttd
12:46<TrueBrain>Eddi|zuHause: the problem is that most scripts only need 2 or 3 ticks :)
12:46<TrueBrain>the 250 is completely arbitrair
12:47<TrueBrain>some feedback from the script, with some extreme cut-off would be better
12:47<Eddi|zuHause>TrueBrain: the map runs a few ticks on map generation (to provide snow etc.), could just couple that with the GS ticks
12:47<TrueBrain>the resulst is the same, from a user point of view
12:47<TrueBrain>Eddi|zuHause: where do you think the GS ticks happen?
12:49<TrueBrain>yeah; I like the idea. You hit Sleep, and next time you wake up, you are on a running map
12:49<TrueBrain>no silly idling in loops waiting for that to happen
12:49<TrueBrain>simplification++, clearification++, more users writing scripts :D
12:53-!-Snail_ [] has quit [Quit: Snail_]
12:57<Xaroth>first implementation+++ :P
13:11-!-HerzogDeXtEr [~Flex@] has joined #openttd
13:12-!-Alberth [] has joined #openttd
13:12-!-mode/#openttd [+o Alberth] by ChanServ
13:16-!-hanf [] has joined #openttd
13:20-!-andythenorth [] has quit [Quit: andythenorth]
13:22-!-frosch123 [] has joined #openttd
13:26-!-LordAro [] has joined #openttd
13:26<LordAro>peter1138: i think you just completely ruined the ez patch :)
13:30<TrueBrain>I think he implemented an EZ
13:30<TrueBrain>Zuu: new version is being compiled as wel speak; your script is no longer functional :D
13:30<Zuu>hehe :-)
13:31<LordAro>TrueBrain: quite possibly, haven't yet had the chance to see what's broken (wrt the ez graphics)
13:39-!-Arie- [] has quit [Quit: ajax IRC Client]
13:40-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
13:42<@peter1138>LordAro, quite likely
13:42<@peter1138>no, it's not compatible
13:43-!-mahmoud [] has joined #openttd
13:43<@peter1138>but we all wanted EZ that works everywhere :p
13:44<@peter1138>cept truebrain :)
13:44-!-welshdragon [] has joined #openttd
13:45<welshdragon>peter1138: yes, yes I do
13:45<CIA-6>OpenTTD: translators * r23320 /trunk/src/lang/ (8 files): (log message trimmed)
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: croatian - 7 changes by VoyagerOne
13:45<CIA-6>OpenTTD: dutch - 7 changes by habell
13:45<CIA-6>OpenTTD: english_US - 8 changes by Rubidium
13:45<CIA-6>OpenTTD: french - 15 changes by Snail_, glx
13:45-!-TheMask96 [] has joined #openttd
13:45<CIA-6>OpenTTD: italian - 19 changes by lorenzodv
13:46<LordAro>no problem, its great, just that i now have to work out which parts of the patch were to do with zoom, and which with colour :)
13:46*Zuu wonders what a user would expect to find in a "game" sub directory of the OpenTTD root
13:47<Zuu>first I though it was too broad to contain game scripts, but "game_scripts" would also be a bit comfusing next to "scripts". And after all the game scripts do affect the game, but will just not be the entire game logic.
13:48-!-frosch123 [] has quit [Remote host closed the connection]
13:48<TrueBrain>peter1138: <3 :D
13:55<CIA-6>OpenTTD: peter1138 * r23321 /trunk/src/ (viewport_gui.cpp waypoint_gui.cpp): -Fix (r23316): Extra viewports and waypoint detail opened up at wrong zoom level.
13:56-!-pjpe [] has joined #openttd
13:56-!-pjpe [] has quit []
13:59<@peter1138>LordAro, anything outside of spritecache/spriteloader/blitter stuff is irrelevant
14:04<@peter1138>or should be
14:04-!-HerzogDeXtEr1 [~Flex@] has joined #openttd
14:05<@peter1138>LordAro, some other changes are dubious too, like the transparent changes
14:05*Zuu managed to crash OpenTTD-nogo in the world gen. The crash happened later in the debug build and the stack is not soo usable (it doesn't crash anywhere script-related)
14:05*Zuu tries to take out SuperLib.
14:07<Xaroth>if I run newest binary on my server it crashes after worldgen
14:07<Xaroth>but i didn't have any script loaded, might be due to that
14:08<Xaroth>ah, it does not with a script loaded
14:09<Zuu>it crashes still here without SuperLib. Maybe it doesn't find my script.
14:09-!-JVassie [~James@] has joined #openttd
14:10-!-andythenorth [] has joined #openttd
14:10-!-andythenorth [] has left #openttd []
14:11<Xaroth>you got them in .openttd/game/test/
14:11<Xaroth>cuz thats the only place it looks
14:11-!-HerzogDeXtEr [~Flex@] has quit [Ping timeout: 480 seconds]
14:13-!-TyrHeimdall [] has quit [Remote host closed the connection]
14:14<Zuu>not in the installation directory anymore?
14:14<Xaroth>well the game creates a /game/ folder :P
14:14<Xaroth>so inside there, inside a folder called 'test' .
14:15<Zuu>yep, but I was mostly refering to installation folder vs user folder
14:16<Xaroth>also, the extra zoom levels look weird :/
14:16<Zuu>Things that are under development, I put in a specific installation instead in the global place for all installations. So I was wondering if you really ment that that is not possible for game scripts.
14:16<Xaroth>never bothered to try it
14:16<Xaroth>TrueBrain might know
14:18<TrueBrain>it checks all normal directories
14:18<TrueBrain>so any game dir will do
14:18-!-TWerkhoven [] has quit [Remote host closed the connection]
14:19<TrueBrain>ack on crash when nos cript loaded; fixed locally
14:19<Zuu>It is probably then that my script doesn't compile for some reaoson which is not so easy to figure out at the moment. :-)
14:19<TrueBrain>do you use the binaries, or compile your own?
14:22<Zuu>I've tried both
14:23-!-andythenorth [] has joined #openttd
14:23-!-_tbone3_AMP [~tbone_min@] has joined #openttd
14:24-!-_tbone3_AMP [~tbone_min@] has quit []
14:25<TrueBrain>genworld.cpp, around line 166, put the whole block there around: if (Game::GetInstance() != NULL) {}
14:26<TrueBrain>(so before SetGenerationWorldProgress(GWP_RUNSCRIPT, till the _generating_world = false)
14:26<TrueBrain>that fixes the crash of no script .. shouldn't matter for crashing scripts
14:26<TrueBrain>so that is a bit odd :)
14:26<TrueBrain>I hope you are not doing GetSetings again? :D
14:27<Zuu>I've double checked that
14:27<Zuu>And added it in my translator script to replace all GetSettings with zero :-)
14:28<TrueBrain>else if you can get me a script with as little as possible that filas for you
14:28<Eddi|zuHause>is there a ge-ening as well?
14:29-!-snack2 [] has joined #openttd
14:29<Zuu>No crash anymore. (with your fix above)
14:29*peter1138 zooms on andythenorth's artwork
14:29<@Alberth>hi andy
14:30<Zuu>However, as soon as I clicked on the NoGo tab in the AI Debug window, I hit an assert. :-)
14:30<TrueBrain>yes; then the script never loaded :)
14:30<TrueBrain>make sure it is called TEST :)
14:30<TrueBrain>pushing a new version btw
14:30<TrueBrain>to fix that error
14:30<andythenorth>Alberth: how did groups go the other day? :)
14:31<TrueBrain>and the GUI error ... I should fix that :D But the whole scanning of scripts need work ... meh .. annoying job :P
14:31*Alberth was watching aircraft flying instead
14:33<Zuu>I've now found the error. I hadn't renamed GoalInfo => GameInfo in info.nut.
14:33<Zuu>As for the record, I can run the CF binary without it crashing.
14:34<TrueBrain>good :)
14:34<TrueBrain>and yeah, the conversion is a bit of a bitch ;)
14:34<TrueBrain>it is GSInfo btw :P
14:34<CIA-6>OpenTTD: rubidium * r23322 /trunk/src/lang/french.txt: -Fix: French language used a wrong argument index
14:35<andythenorth>planes should fly like real planes
14:35<andythenorth>using complete stupid routes
14:35<andythenorth>because the world can't agree on how to upgrade control systems
14:35<andythenorth>maybe ottd planes should require players to build navigation beacons every where
14:37-!-Brianetta [] has joined #openttd
14:37<Zuu>Hmm, on 1024*1024 and "high" town amount, my Goal Script uses about 1200 of the 2500 ticks. (for each town, it loops over all towns)
14:37<TrueBrain>huh? I didn't manage to get it passed 1 tick in my script
14:38<TrueBrain>owh, for each town, over all towns
14:38<TrueBrain>so O(n**2)
14:38<TrueBrain>yeah, that will take a while :)
14:38<Zuu>The last I saw before the map gen window was 1250/2500.
14:38<TrueBrain>how 'fast' was it?
14:38<Zuu>Only a few seconds.
14:38<TrueBrain>did it feel okay?
14:38<Zuu>(on a K2600 i7)
14:38<TrueBrain>then it is okay by me tbh, and then it works as intended :D
14:39<TrueBrain>doing Town*Town calculations is a lot :P You might want to refactor?
14:39<TrueBrain>Town! should be possible? :)
14:40-!-pugi [] has joined #openttd
14:40<Zuu>I only do that when it starts up. And in case I will continue with it, I can probably reduce it to only compute half of the town distance matrix as the distances are symetric.
14:40<TrueBrain>in general they are :D
14:42<Zuu>At least when speaking of direct distance.
14:42<Zuu>(or manhattan distance)
14:42-!-TWerkhoven [] has joined #openttd
14:43<Eddi|zuHause>how does calculating distances take so long?
14:44<Eddi|zuHause>i once thought about making a voronoi-partition of the map, but never got around to implementing that
14:44<TrueBrain>walking over, what, 2000 towns?
14:44<TrueBrain>so that is 4M distance calculations
14:44<TrueBrain>that should take a few opcodes ;)
14:44<TrueBrain>10k per tick I believe is granted
14:44<Zuu>It also figures out which are the 5 closest towns within 100 tiles of eacch town.
14:44<TrueBrain>so it should take at least 400 ticks, to start with the calculation alone :)
14:45<Eddi|zuHause>a voronoi-partition would give you all "neighbouring" towns
14:45<Zuu>But since most of it is not DoCommands, it is not that limited if it overruns the 2500 limit.
14:46-!-KritiK [] has joined #openttd
14:47-!-welshdragon [] has quit [Quit: welshdragon]
14:48-!-pugi [] has quit [Ping timeout: 480 seconds]
14:49-!-pugi [] has joined #openttd
14:51-!-andythenorth [] has quit [Read error: Connection reset by peer]
14:51-!-andythenorth [] has joined #openttd
14:52-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
14:52<andythenorth>did I mention how awesome EZ is at 2x?
14:52<Xaroth>did I mention how annoying EZ is if you don't expect it?
14:53<TrueBrain>we need better gfx :P
14:53<TrueBrain>peter1138: when will you implement rotation? :D
14:54<andythenorth>after he's figured out a way to procedurally draw the other side of industries
14:54<andythenorth>based on existing sprites :P
14:54<Xaroth>TrueBrain: didn't he have a patch for that?
14:54*andythenorth is waiting on the spot price economy :P
14:55<andythenorth>spot prices with a GS?
14:55<andythenorth>could be per town, doesn't have to be per tile
14:55<TrueBrain>go for it
14:56<andythenorth>or could be per unit of 16 tiles or so
14:56<andythenorth>it's not that I wouldn't try
14:56<andythenorth>more that I should ship what's started
14:57<andythenorth>there's no point having four crappy newgrfs *and* then starting a GS as well
14:57<andythenorth>I should make the newgrfs less crappy
15:03-!-SammieCat [] has joined #openttd
15:03<SammieCat>Happy US Thanksgiving everyone!
15:06<@Alberth>number of US persons is not so large here, I think :)
15:06<Eddi|zuHause>i'd estimate about 10% of the community
15:07<Eddi|zuHause>which would probably make it the 4th biggest group after germans, english/british and dutch
15:08<SammieCat>what about Japanese?
15:08<Eddi|zuHause>they have a fairly separate community
15:08<SammieCat>I'm just thinking of the big makers of model trains
15:08<Eddi|zuHause>as do the russians
15:08<SammieCat>most of my models are Japanese
15:09<Eddi|zuHause>can't say that about my models :)
15:09<SammieCat>well, I always prefer either KATO models for N or Marklin for HO
15:11-!-DOUK [] has joined #openttd
15:12<SammieCat>I actually came here because I needed to ask a question
15:14<SammieCat>I've been playing a lot of 64x64 games so the industries tend to be just one of each type in a map and oftentimes if I'm not fast enough at providing service to a particular supplier it will drop to what I can only guess is a production of zero where, by all rights, it ought to have been removed from the map. But it isn't removed from the map and it doesn't seem to remove until I add another industry. Even when it increases by 10
15:14<SammieCat>0% it doesn't increase production which I can only figure means they have a production of 0. Is this a bug or is it intended to work this way?
15:16-!-mahmoud [] has quit [Ping timeout: 480 seconds]
15:16<appe>i have noticed the same thing
15:17<Eddi|zuHause>a savegame would be best in that case
15:17<Eddi|zuHause>preferably one short before it lowers production to 0
15:19<@Alberth>SammieCat: non-primary industry does not produce on its own
15:19<SammieCat>I know that ALberth, I should have specified I'm talking about primary industries here
15:20<andythenorth>it's preventing closure of last primary industry
15:20<andythenorth>is my guess
15:20<andythenorth>there is a flag for 'ensure at least one of this type of industry' or such
15:20<SammieCat>Yes, I have to admit to save-scumming a teeny bit. Especially when working with NARS or other GRFs that have very expensive trains. Makes building an infrastructure quickly enough very difficult!
15:20<andythenorth>although it was dubious for a while whether it actually worked
15:20<Eddi|zuHause>may depend on the newgrfs involved and such
15:20<andythenorth>Alberth: didn't you fix that industry feature?
15:21<@Alberth>I fixed that it will build missing industries, I did not touch closure prevention
15:22<andythenorth>industry_cmd.cpp is so squirrely
15:22<SammieCat>maybe a way to deal with this would be to add a check to see if the current production is at 0 and instead of then increasing by a multiple you add one
15:22<Eddi|zuHause>on my small YACD game i had almost no new industries over the course of the game
15:22<andythenorth>so many ifs for different advanced settings P
15:22<SammieCat>that way you don't get a 0*n=0 issue
15:23<Eddi|zuHause>town growth definitely dwarfs industry growth
15:23<Eddi|zuHause>or maybe i'm playing FIRS the wrong way
15:23<SammieCat>either that or add a feature to "buy" a production point for an appropriately large amount of money
15:23<andythenorth>can't we ditch code for town growth, industry growth etc and delegate to scripts?
15:23<@Alberth>SammieCat: another approach could be to close the industry, imho
15:24<@Alberth>andythenorth: you'd need to write a default implementation :)
15:24<SammieCat>Alberth: *nods* that would make sense. I feel that removing the incentive to build fast on 64^2 maps would remove a lot of the fun of those games... It's just important that the game then make another of the industry soon-ish
15:24<Eddi|zuHause>andythenorth: you'd need to include that in any game script, since only one can be active
15:25<andythenorth>I know :(
15:25<andythenorth>and it probably has performance issues
15:25<@Alberth>andythenorth: and if you did, you don't care about what the game does, as your script took over :p
15:25<Eddi|zuHause>instead it should offer triggers that the game script can override
15:25<andythenorth>Alberth: ^ that's my point
15:26<andythenorth>reimplementing vanilla (O)TTD gameplay in a script is probably madness :P
15:26<andythenorth>but if we had lots of time and a high boredom threshold, it would be the logical solution
15:26<SammieCat>must resist Sparta joke...
15:26<Eddi|zuHause>so you'd have a flag "GSTown.automatic_growth" and a function "GSTown.Grow([location])"
15:27<TrueBrain>andythenorth: too much is done by a grf already, some people will complain hard when we move everything to script :P :P
15:27<TrueBrain>Eddi|zuHause: there already is a 'flag' automatic_growth, we call it a setting :D
15:27<TrueBrain>same for Grow (but called ExpandTown) :P
15:27<Eddi|zuHause>TrueBrain: yes, but one that the script should be able to override
15:28<TrueBrain>it can
15:28<andythenorth>TrueBrain: I thought for a while we should abolish industry-specifc code for default industries and move that to a grf :P
15:28<TrueBrain>that I just said :)
15:28*andythenorth -> fish and chips
15:28<TrueBrain>Eddi|zuHause: there are 4 ways to control town growth: set growth-rate, set goals, set goals + growth rate, or do it yourself :)
15:30<SammieCat>andythenorth: being a stupid Yank I always thought fish and chips were like nachos only with fish
15:30<andythenorth>and when I ordered fish and chips in Texas, I was surprised to get fish, cheese and nachos :P
15:31<SammieCat>andythenorth: welcome to the states ;)
15:31-!-andythenorth [] has quit [Quit: andythenorth]
15:32<SammieCat>does town/industry growth really need to be adjusted?
15:32<@Terkhen>good night
15:32<SammieCat>maybe I'm not seeing the whole picture because I only play real tiny maps but it seems that while towns produce more "goods" they also require much, much more of their services
15:33<Eddi|zuHause>SammieCat: i never get to do sensible industry networks, because passengers always congest every line
15:33<Zuu>TrueBrain: Is it intended that signs by the goal script are not showing up in the SignListWindow?
15:33<SammieCat>Eddi|zuHause: I always build two networks, one for freight and one for passengers
15:33<TrueBrain>Zuu: yes
15:34<TrueBrain>they are also transparent
15:34<TrueBrain>and non-editable
15:34<Zuu>I can agree on non-editable, but for debugging it would be useful if they shown up in the sign list.
15:34<TrueBrain>I got annoyed by the many many many many ***CITY*** signs :P
15:34<TrueBrain>problem is that they will be mostly used for non-debugging
15:34<Eddi|zuHause>SammieCat: even then, the passenger lines carry several orders of magnitude more
15:34<Zuu>Perhaps show them in the list if gs_developer_tools is enabled?
15:34<TrueBrain>I can make it into a setting if you really want to
15:35<SammieCat>Eddi|zuHause: maybe a solution would be to increase the value of each passenger from a particular city instead of just producing MORE?!
15:35<Zuu>Actually, I found it useful also as a player to see which towns are claimed by looking in that list.
15:35<Zuu>So, I'm not sure it is really a development-thing.
15:35<Zuu>What the SignList really is missing is a company filter.
15:36<TrueBrain>so far I have mostly seen them being used as something you dont want in the list
15:36<TrueBrain>hehe, yeah, it is
15:36<TrueBrain>we might also just add a method to add signs that are listed in the list, and ones that are not
15:36<TrueBrain>not sure ..
15:36<Zuu>Although it was a bit fixed by my patch that added an option to hide all competitor signs.
15:36<TrueBrain>so it was you who forgot the < and > buttons :P Hihi :D
15:37<TrueBrain>I found that they still walk over all signs, which took me by surprise :D
15:37<Zuu>Oh, I never use those buttons :-)
15:37<TrueBrain>I doubt anyone does :P
15:37<TrueBrain>but they exist :D
15:38<Zuu>And if they are removed, we'll get several hate mails :-p
15:38<TrueBrain>I am used to hatemails ... took months before they stopped coming in regards of CTRL+D
15:39<Eddi|zuHause>i want Ctrl+D back!
15:39<Eddi|zuHause>(that does something completely different now :p)
15:40*SammieCat sends very-much-not-hate mail to the devs for coding her favorite game
15:40<Eddi|zuHause>my cats are fairly indifferent to this game...
15:41<Eddi|zuHause>my CETS however...
15:41<SammieCat>I'm a genetically engineered cyborg cat created by a crazy girlfriend who watches too much anime
15:41<Eddi|zuHause>please keep your fetishes to yourself.
15:42<SammieCat>it wasn't supposed to be a sexual comment, sorry to offend though
15:42<TrueBrain>to offend Eddi|zuHause you need a very large truck, I am afraid
15:42<SammieCat>I don't even want to contemplate what that entails...
15:43<Zuu>TrueBrain: For the two most zoomed out levels, my GoalScript built sign turns black while the two most zoomed in levels have white sign label.
15:44<TrueBrain>huh? It stays fully white here ...
15:44<SammieCat>I hope that truck was made as some kind of joke...
15:44<Zuu>Possible related to fonts?
15:44<Eddi|zuHause>afaik it was a coding mistake
15:45<Zuu>My small_font is a ttf-font while the other two are the fonts provided by OpenGFX.
15:45<TrueBrain>ah, no, turns black here too
15:45<TrueBrain>I Thought it just hided :P
15:45<TrueBrain>ah, I see
15:46-!-andythenorth [] has joined #openttd
15:46<Zuu>Actually it looks like it is the shade that displays, but not the front.
15:46<Zuu>Towns seem to have a black shade one pixel off compared to the white text.
15:47<TrueBrain>tricky to fix, as text tend to blur at those zoom-out
15:47<@Alberth>gui also has that
15:47<TrueBrain>I think I just hide it
15:47<TrueBrain>its unreadable anyway ...
15:49<Zuu>depends on how small your small_font is.
15:49<Zuu>If the small font is large, then it is readable. :-)
15:51<SammieCat>Anyway, I'm going to be late for the feasting so I'll have to go
15:52<SammieCat>I'll come back and hang out soon, though
15:53-!-SammieCat [] has quit [Quit: Leaving]
15:54<TrueBrain>hmmm ... tricky tricky tricky tricky
15:56<TrueBrain>solved it for now; but it is a bit temporary :)
15:56<TrueBrain>tnx for noticing Zuu :)
16:00-!-welshdragon [] has joined #openttd
16:01<__ln__>am i badly mistaken or shouldn't the alphabetical order of {ä,a,b} be (a,ä,b) with de_DE locale?
16:01<Eddi|zuHause>no. for all intents and purposes, 'a' and 'ä' are equal for sorting
16:02<Eddi|zuHause>(so the order is undefined)
16:02<__ln__>mmm ok, though in any case ä < b?
16:04<Eddi|zuHause>if your sort algorithm is "stupid", it'll do a replace s/ä/a/g and sort afterwards
16:04<__ln__>hmmm, now i think i realized what's going wrong... (trying sort on debian command line)
16:05-!-LordAro [] has quit [Quit: ajax IRC Client]
16:05<Rubidium>Eddi|zuHause: those kinds of decisions depend on the language
16:05<Eddi|zuHause>Rubidium: he did specify de_DE
16:06<__ln__>i didn't have any of the de_DE locales generated. duh. and there was no warning about it.
16:07-!-z-MaTRiX [] has joined #openttd
16:08<Rubidium>Eddi|zuHause: then the question is whether you sort for a phonebook or dictionary ;)
16:08<SpComb>collations \o/
16:08<__ln__>(and i never understood why debian insists on generating the locales on end users' systems rather than packaging everything pre-generated)
16:08-!-Kurimus [] has quit []
16:08<Rubidium>German Dictionary: of < öf
16:08<Rubidium>German Telephone: öf < of
16:10-!-JVassie [~James@] has joined #openttd
16:10<Eddi|zuHause>Rubidium: my dictionary doesn't specify that
16:10<Eddi|zuHause>it only specifies ß<ss (in case of otherwise equal words)
16:11<Rubidium> (if you're interested in sorting strings)
16:17-!-Pulec [] has joined #openttd
16:18<Eddi|zuHause>the exact words of my dictionary (Duden, 20. Auflage, ca. 1991): "III. 1. b) Die Anordnung der Stichwörter ist alphabetisch. Die Umlaute ä, ö, ü, äu werden wie die nichtumgelauteten Vokale (Selbstlaute) a, o, u, au behandelt. Die Schreibungen ae,oe,ue (in Namen) werden nach ad usw. eingeordnet. Der Buchstabe ß (vgl. S. 57) wird wie ss eingeordnet. Bei gleichlautenden Wörtern steht das Wort mit ß vor dem mit ss. Beispiele: [...]"
16:20<__ln__>after that the spelling reform took place
16:21<appe>man, i love german
16:21-!-frosch123 [] has joined #openttd
16:26<SpComb>reminds me of timezones
16:26-!-welshdragon [] has quit [Quit: welshdragon]
16:26<SpComb>where due to a design flaw in python's timezone stuff, pytz gives you HMT dates per default for Europe/Helsinki -times
16:27<SpComb>which is some incredibly obsolete timezone
16:29-!-Alberth [] has left #openttd []
16:30<frosch123>so, who is a regular user of the sprite aligner?
16:30<frosch123>andythenorth: ^^ ?
16:30<frosch123>how shall it behave with extra zoom?
16:31<andythenorth>let's see
16:32*SpComb proposes vector graphics
16:33<andythenorth>frosch123: leave it as-is for now
16:33<andythenorth>it's not bad
16:33<andythenorth>give it a few days/weeks/months and see if anyone complains
16:35<Eddi|zuHause>frosch123: allow setting the zoom level manually
16:36<Eddi|zuHause>frosch123: especially if the grf supplies several sprites
16:36-!-welshdragon [] has joined #openttd
16:36<Eddi|zuHause>frosch123: possibly give a hint whether the currently displayed sprite is "original" or "scaled"
16:37<Eddi|zuHause>(if scaled, you likely don't want to change offsets)
16:37<Eddi|zuHause>(maybe disable the changing of offsets in that case)
16:38<frosch123>i guess it should never display a scaled sprite
16:38-!-welshdragon [] has left #openttd []
16:38<frosch123>and only allow to select those which are actually present
16:39<frosch123>maybe we can even catch the zoom level of the sprites being clicked
16:45<__ln__>question #2: why does libc's de_DE locale claim ä>a, not equal?
16:46-!-DOUK [] has quit [Ping timeout: 480 seconds]
16:49<frosch123>as long as it claims ä < b it is fine
16:51-!-perk11 [~perk11@] has joined #openttd
16:57<Eddi|zuHause>frosch123: not according to the rules i quoted above
16:58<Eddi|zuHause>frosch123: if at all, it should be a "secondary" metric. when the "primary" metric results in equal words
16:59<@peter1138>if they were equal it wouldn't be able to sort them
17:00-!-DayDreamer [] has quit [Quit: Leaving.]
17:00<Eddi|zuHause>but take for example: "wurde", "würde", "wurden", "würden". if you define u<ü<v, you will result in "wurde", "wurden", "würde", "würden", which is wrong
17:02<Eddi|zuHause>if you take a primary metric of u=ü<v and a secondary metric of u<ü, you get the correct sorting
17:03-!-TGYoshi [~TGYoshi@] has quit [Quit: Poof]
17:03<Eddi|zuHause>some words will be equal in the primary metric, and each set of equal words will be sorted by the secondary metric
17:05<Eddi|zuHause>if the primary metric is unequal, then the secondary metric is irrelevant
17:07-!-eQualizer [~lauri@] has quit [Read error: Connection reset by peer]
17:07-!-eQualizer [~lauri@] has joined #openttd
17:07<frosch123>i seem to remember some book sorting ä like ae
17:08<frosch123>ad < ä < af
17:08<Eddi|zuHause>now that is seriously weird :p
17:12-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
17:14-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
17:17-!-andythenorth [] has quit [Quit: andythenorth]
17:33-!-snack2 [] has quit []
17:51<Eddi|zuHause>frosch123: how far is your use-other-vehicle's-position-as-anchor-point patch yet? :)
17:51<frosch123>i outsourced writing it to some guy called eddi
17:52<@peter1138>who what where?
17:52<Eddi|zuHause>i wouldn't do that... he's a lazy bastard who couldn't code shit if his life depended on it
17:54<@peter1138>doom 3 was released in 2004? didn't realise it was that long ago
17:57<frosch123>ottd was released in 2004
18:00<@peter1138>also i just downloaded 32bit-gfx-nightly-megapack-2011-06-15.tar
18:00<@peter1138>and modified the png loader to load the z0 sprites
18:00<@peter1138>and boy, does it look ugly :p
18:00<frosch123>could have told you before
18:01<frosch123>does it look better when zooming out?
18:02<frosch123>and at 8x ?
18:02<@peter1138>not much change there
18:03<@peter1138>but then not many sprites are changed
18:05-!-Prof_Frink [] has joined #openttd
18:05<@peter1138>anyway, it's nothing to do with them being higher detail
18:05<@peter1138>just the style is totally different
18:05<frosch123>well, at least i do no longer need a magnifier when reviewing bounding boxes :)
18:07<@peter1138>ahh, loads of stuff isn't changed because... my game is in arctic
18:07<@peter1138>loads of stuff still isn't changed mind you
18:11<@peter1138>hmm, the factory is messed up
18:12<z-MaTRiX>taken a look at the source of openttd
18:13<z-MaTRiX>it still smells like asm in C
18:14<__ln__>no sh**
18:14-!-frosch123 [] has quit [Remote host closed the connection]
18:14-!-Snail_ [] has joined #openttd
18:15<@peter1138>i dunno what version you were looking at...
18:16-!-Cybertinus [] has quit [Remote host closed the connection]
18:17<+michi_cc>z-MaTRiX: Maybe you should look at TTDPatch so you know how asm actually smells like.
18:17<z-MaTRiX>i have no problem with asm, but i thought you like clean looking code
18:18<@Yexo>feel free to suggest improvements instead of making general remarks
18:19<+michi_cc>Or, alternatively take a random commerical code base written by "programmers"...
18:19<z-MaTRiX>no i dont like that idea ;>
18:20<z-MaTRiX>ahah, SDL does not have a very basic text output function yet as default
18:21<z-MaTRiX>i'll spend a few hours making one
18:21<z-MaTRiX>8x5 font needs 5 bytes/character
18:22<z-MaTRiX>it fits in a .h file nicely as dbs
18:22<@Yexo>how is this relevant to OpenTTD again?
18:22<z-MaTRiX>well it uses SDL
18:22<__ln__>OpenTTD mostly doesn't.
18:23<@Yexo>on windows it doesn't use sdl
18:23<@Yexo>on mac osx I think only for sound, not sure there
18:23<z-MaTRiX>ok i see
18:23<@Yexo>and even for linux there are alternatives
18:23<z-MaTRiX>(i only use linux)
18:24<__ln__>Yexo: not even for sound.
18:24-!-Zuu [] has quit [Ping timeout: 480 seconds]
18:26<z-MaTRiX>i see programming is not for everybody
18:28<z-MaTRiX>or programming is for everybody, and writing programs is not
18:30<@peter1138>there's a jack audio driver
18:30<@peter1138>but that was a bit silly really
18:30-!-Pulec [] has quit []
18:31<z-MaTRiX>i'd also change the current architecture of the pc
18:32<z-MaTRiX>like not putting game running procesors in the vga card
18:32<z-MaTRiX>instead add a hypertransport, or cpu integrated parallel processing unit
18:33<z-MaTRiX>that could be used for parallel processing anything, also graphic rendering
18:33<@peter1138>i'm glad you know what you're talking about
18:33<@Yexo>"I see programming is not for everybody" :)
18:34<@planetmaker>Yexo: on OSX nothing of sdl is used
18:34<@planetmaker>it uses coreaudio there
18:35<z-MaTRiX>i'm referring to FPGA-s for example
18:35<z-MaTRiX>they are not only for video processing
18:35<z-MaTRiX>In late 2008, A cluster of 200 PlayStation 3 consoles was used to generate a rogue SSL certificate, effectively cracking its encryption.
18:46<@peter1138>there are no "game running procesors" in any "vga" card
18:48-!-TWerkhoven [] has quit [Quit: Leaving]
18:49<z-MaTRiX>the game actually runs on the video card, it requires the video cards rendering functions for 3D
18:49<z-MaTRiX>(not talking about openttd)
18:49-!-KritiK [] has quit [Quit: Leaving]
18:50<z-MaTRiX>so if the pc would have a powerful parallel processing unit, then all calculations would be done using that, and the fvideo card would only be a fast buffered video output card
18:51<z-MaTRiX>not some closed internal magic blackbox that does whatever
18:52<z-MaTRiX>(especially the nvidia)
18:53<+glx>GPU is the powerful parallel processing unit
18:53<@peter1138>what glx said
18:53<z-MaTRiX>currently- for graphics rendering purpose
18:53<+glx>not only
18:53<+glx>it can do a lot
18:53<+glx>using cuda
18:54<z-MaTRiX>sure i saw them cracking md5 hash with it.
18:54<z-MaTRiX>still not considering that
18:54<Eddi|zuHause>hm... the AI wiki has a dead link: on it links to
18:56<z-MaTRiX>the GPU is a kind of specialized FPGA
18:56<z-MaTRiX>that was designed for graphics processing
18:56<+glx>no it's designed for floating point math
18:56<Eddi|zuHause>maybe you don't really understand what an FPGA is
18:57<z-MaTRiX>maybe, though i have projects with them
18:57<+glx>luckily 3D graphics require a lot of floating point math
18:57-!-MNIM [] has joined #openttd
18:58<z-MaTRiX>btw glx so you happen to know about the working of the glx system on linux?
18:58<+glx>not at all
18:58<+glx>my nick is totally unrelated
19:00<z-MaTRiX>thought you were linux graphics coder
19:01<z-MaTRiX>some dudes got some scrap pplasma tvs that used FPGA-s
19:02<z-MaTRiX>reprogrammed them, and used it for other purposes
19:02<z-MaTRiX>it is a programmable functional logic array.
19:02<z-MaTRiX>you can program it to be a video card
19:02-!-B-17 [] has joined #openttd
19:03<z-MaTRiX>washing machine, or anything.
19:03-!-sla_ro|master [~slaco@] has quit []
19:03*Eddi|zuHause still waits for the day when are you telling us something of value
19:04<z-MaTRiX>Eddi|zuHause<< well you asked if i know what it is
19:05<Eddi|zuHause>but how does "you can program an FPGA to be a graphics card" relate to "a graphics card is a specialized FPGA"?
19:05<z-MaTRiX>i don't see any reason to post random crap on here
19:06<z-MaTRiX>its not an FPGA
19:06<z-MaTRiX>it is a fixed function ic
19:06<__ln__>is this the shortest way to map {<0,0,>0} to {0,1,2}: (s<0)?0:(s>0)?2:1 (we can imagine s is a return value by strcmp, for example)
19:06<z-MaTRiX>that is why its cheaper
19:07<Eddi|zuHause>__ln__: how about "cmp(0,value)+1"?
19:08-!-B-17 [] has quit []
19:08<Eddi|zuHause>__ln__: likely you're asking a way too specialized question, and should look at the more general problem
19:10<z-MaTRiX>cmp value,0;ja above;jb below;mov ax,1;jmp done;above: mov ax,2;jmp done;below:mov ax,0;done:
19:11-!-pjpe [] has joined #openttd
19:11<__ln__>well, actually i'm just thinking about the shortest piece of C code that would give me one of '<','=','>' characters based on the return value of strcmp or strcoll.
19:13<__ln__>this isn't obviously very important.
19:14<z-MaTRiX>wouldn't you want it because you want better performance?
19:15<__ln__>no no, the parameter of optimization is indeed the number of characters in source code this time.
19:15<Eddi|zuHause>__ln__: chr(clamp(value,-1,+1)+ord('='))
19:16<Eddi|zuHause>where in C, chr and ord are NOPs
19:17<__ln__>and clamp is something that would need to be defined separately
19:19<Eddi|zuHause>__ln__: look in src/core/math_func.hpp
19:24<__ln__>z-MaTRiX: cool, that's the winner so far
19:25*Pinkbeast is a Perl programmer and we don't even bother with obfuscated code contests. :-/
19:25<z-MaTRiX>i do it in bash too
19:25<Pinkbeast>It would be like a contest for falling off a log
19:26<Eddi|zuHause>maybe something like s&1-2*s>>31
19:26<Eddi|zuHause>for -1,0,1, assuming s is 32bit
19:27<z-MaTRiX>yeah if its integer
19:27-!-Progman [] has quit [Remote host closed the connection]
19:28<Eddi|zuHause>should check operator precedence first, though
19:28<__ln__>yeah, bit operations would be nice, but as far as i can imagine they need an assumption of the size.
19:30<z-MaTRiX>in asm i'd use rol now
19:30<__ln__>so now i have: printf("%s %c %s\n", argv[1], "<=>"[(s>=0)+(s>0)], argv[2]); which is comfortably short and elegant to add in a thesis, for example
19:30<Eddi|zuHause>oh, i'm stupid.
19:30<Eddi|zuHause>hm... one moment
19:31<Eddi|zuHause>__ln__: i think that is needlessly complicated
19:32-!-DDR [~chatzilla@] has joined #openttd
19:32<Eddi|zuHause>__ln__: as in ascii, <=> are neighbours, so you can just use '='+1 and '='-1
19:33<Eddi|zuHause>or save one character by writing 61 instead of '='
19:34<Eddi|zuHause>yeah, they weren't so bright :p
19:35<Eddi|zuHause>peter1138: but good luck compiling your ascii-encoded c-file on that one :p
19:35<z-MaTRiX>so write char "$3c+(s>=0)+(s>0)"
19:36<z-MaTRiX>sounds c00l
19:37-!-LordAro [] has joined #openttd
19:38<Eddi|zuHause>how about: "61+s&0-(s<0)"?
19:38<Eddi|zuHause>hm, might have some "odd" results
19:38<z-MaTRiX>s&0 = 0
19:38<Eddi|zuHause>that one's wrong
19:40<Eddi|zuHause>need to stay at "61+(s>0)-(s<0)"
19:40<Eddi|zuHause>comparison operators are "bad" because of the needed parentheses
19:41<Eddi|zuHause>__ln__: is that an acceptable solution?
19:42<z-MaTRiX>seems short enough for me
19:42<Eddi|zuHause>"<=>"[(s>=0)+(s>0)] == 19 chars, 61+(s>0)-(s<0) = 14 chars
19:42<__ln__>Eddi|zuHause: sure, it's self-contained and short.
19:43<z-MaTRiX>but nice examples
19:43<Eddi|zuHause>well, it does rely on the assumption of ascii
19:43<z-MaTRiX>that's hardcoding
19:43<z-MaTRiX>otherwise you need to include an ascii table
19:47<z-MaTRiX>i'm willing to include an ascii font set in my SDL.h for basic text output ;/
19:47<z-MaTRiX>i'd prefer the one from my bios
19:49<z-MaTRiX>it'd be cool to detect x86 at program start, and use x86 optimized inline ASM code for outputting text then to graphic sreen
19:49<@peter1138>no it wouldn't
19:49<Eddi|zuHause>that's the compiler's job
19:49<__ln__>agreed, it wouldn't
19:49<z-MaTRiX>why not? bit manipulations in C in a loop?
19:50<z-MaTRiX>for every character
19:50<Eddi|zuHause>that's still the compiler's job
19:51<__ln__>z-MaTRiX: what does "detect x86 at program start" mean actually... your program is compiled for ARM, and then it suddenly detects it's been ran on an x86 (which isn't possible), and utilizes x86-optimized code?
19:51<z-MaTRiX>but its a low level function and could take adventage of optimization
19:51<Eddi|zuHause>then you need to teach the compiler to do these optimisations
19:52<@peter1138>computer graphic subsystems haven't been that low-level for years
19:52<Eddi|zuHause>you would not program a game this way since the mid 90's
19:53<z-MaTRiX>well i was only talking about the outputting of 8x5 pixel fonts
19:53<z-MaTRiX>that only needs 5 bytes / character
19:54<__ln__>and that's the thing that needs optimization the most?
19:54<Eddi|zuHause>"i use a graphical abstraction layer to override the abstraction by directly outputting to video memory"
19:55<Eddi|zuHause>i'm sure you trigger a dozen antipatterns by that :p
19:55<z-MaTRiX>ok the virtual framebuffer may be inefficient too. so?
19:56<z-MaTRiX>i shouldn't optimize anything and just "make it work" ?
19:56<Eddi|zuHause>z-MaTRiX: the order is "make it work" => "profile it" => "optimize the most significant parts"
19:56<z-MaTRiX>it seems to me that bit operations are not the strength of C
19:57<@peter1138>ok, 823 sprites in this "32bit megapack"
19:57<Eddi|zuHause>z-MaTRiX: of course writing C is going to be bad if you're an ASM programmer.
19:57<@peter1138>that seems somewhat of a shortfall
19:58<@peter1138>oops, 768
19:58<z-MaTRiX>Eddi|zuHause<< i can take some compromises
19:58<z-MaTRiX>but i will still optimize my putpixel.
19:58<Eddi|zuHause>z-MaTRiX: likewise your C code will be bad if you're a Haskell programmer
19:59<z-MaTRiX>depends on what you want
19:59<Eddi|zuHause>just from the complete opposite direction
19:59<z-MaTRiX>i've been at both extremes
19:59<__ln__>a compiler can generate different code for different processors even, can you?
20:00<Eddi|zuHause>__ln__: yes. it can even dynamically switch on processor type, if you set it the right way
20:01<__ln__>indeed, i was referring to different code within the same binary
20:01<z-MaTRiX>that'd be interesting :)
20:01<@peter1138>oh. hmm. there are sprites that have 32bpp replacements showing up as 8bpp only :S
20:02<Eddi|zuHause>wrong metadata?
20:02-!-KenjiE20 [] has quit [Remote host closed the connection]
20:03<z-MaTRiX>__ln__<< well it might need recompiling though ;<
20:03<z-MaTRiX>( for an arm )
20:03<@peter1138>,.......,.......if (height > UINT8_MAX || width > UINT16_MAX) {
20:03<@peter1138>ah ha
20:04<z-MaTRiX>it'd be like ifdef x86 ... putpixel_x86 endif ...
20:05<z-MaTRiX>and still be portable
20:05-!-Adambean [] has quit [Quit: Gone fishing]
20:06<__ln__>putpixel_arm could be a bit trickier to do
20:06<Eddi|zuHause>peter1138: that sounds evil
20:06<z-MaTRiX>willing to do that if i'll have an arm :)
20:08<@peter1138>putpixel -> buffer[x+y*pitch] = value
20:08<@peter1138>obviously you keep y*pitch around if you're drawing lots on the same line
20:08<@peter1138>do you think specific assembly will help you with that?
20:09<__ln__>i bet a lot of ARMs don't have any kind of graphics controller, and even within those that do, its specs vary a lot.
20:09<Eddi|zuHause>inline putpixel, and the compiler will likely result in waaaay better assembly that you could ever come up with
20:10<Eddi|zuHause>like some evil MMX or SSE call
20:10<z-MaTRiX>ok guys relax
20:10<@peter1138>__ln__, modern smartphones do, i guess
20:10<Eddi|zuHause>__ln__: but SDL covers all that
20:10<z-MaTRiX>i have not done any benchmark on it
20:11<z-MaTRiX>anyway i did meant DDE2 code for optimizations.
20:11<@peter1138>of course, pixel pushing always comes down to setting a value in a buffer, whether that's video memory or some system memory buffer
20:11<z-MaTRiX>for some things
20:11<__ln__>Eddi|zuHause: but i suppose SDL covers that through some OS abstraction layer, which isn't optimal.
20:11<z-MaTRiX>and it will surely improve matrix transformation speeds.
20:12<Eddi|zuHause>__ln__: yes, we pointed that out already
20:12<@peter1138>bbc micro had a 'fun' memory layout for the screen
20:12<z-MaTRiX>i believe SSE2 code has to be hand written.
20:13<z-MaTRiX>gcc does not optimize for that
20:13<Eddi|zuHause>z-MaTRiX: and is tha belief based on any data?
20:13<z-MaTRiX>it cannot know-all
20:14<Eddi|zuHause>z-MaTRiX: it won't if you put "-m i386"
20:14<z-MaTRiX>Eddi|zuHause<< well, have you used SSE2 before?
20:14<z-MaTRiX>single instruction multiple data
20:15<z-MaTRiX>parallel computing #1
20:15<z-MaTRiX>but still, core functions
20:15<Eddi|zuHause>z-MaTRiX: that's an obvious optimization when you do loop-unfolding
20:15<Eddi|zuHause>why wouldn't GCC do that?
20:16<Eddi|zuHause>and there's other compilers, like icc
20:17<z-MaTRiX>yeah i have seen compilers for $10000+
20:17<z-MaTRiX>doing some insane optimizations
20:18<z-MaTRiX>i'm not argueing with making a monkey drawing
20:18<z-MaTRiX>or painting some art
20:19<z-MaTRiX>it's probably straight-forward
20:25<z-MaTRiX>i found this now
20:26<z-MaTRiX>they say in-theory gcc can optimize using SSE2
20:26<z-MaTRiX>some things
20:36<@peter1138>heh, never noticed that, original trains are drawn 2 pixels too low in the horizontal view
20:36<@peter1138>maybe 1
20:36<@peter1138>oh what have i unleashed? :S
20:37<Eddi|zuHause>yes, that's why practically every set has a depot offset of 2
20:44-!-hanf^ [] has joined #openttd
20:51-!-hanf [] has quit [Ping timeout: 480 seconds]
20:55-!-supermop_ [] has joined #openttd
21:14-!-hanf^ [] has quit [Read error: Connection reset by peer]
21:37-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
21:42-!-glx [glx@2a01:e35:2f59:c7c0:3943:8607:c2d9:f6cc] has quit [Quit: bye]
21:54-!-perk11 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
22:12<z-MaTRiX>[010246] __ln__ is this the shortest way to map {<0,0,>0} to {0,1,2}: (s<0)?0:(s>0)?2:1 (we can imagine s is a return value by strcmp, for example)
22:12<z-MaTRiX>btw it was overcomplicated from the beginning
22:12-!-DDR_ [~chatzilla@] has joined #openttd
22:18<z-MaTRiX>seems to be the most logical approach
22:18-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
22:21<Eddi|zuHause>but the question was not "logical"
22:22-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:22-!-Pixa [~pixa@] has joined #openttd
22:27-!-pjpe [] has quit [Quit: ajax IRC Client]
22:30-!-pjpe [] has joined #openttd
22:32-!-Jerik [] has joined #openttd
22:32<Jerik>Can anyone help me with how to design a good reversal?
22:33<Jerik>As in, say I have a line linking A-B-C-D
22:34<Jerik>How to I get a train to just loop in B and C without travelling all the way around to A and D
22:34<Jerik>This is assuming a two-way line
22:34<Eddi|zuHause>you need to enable the difficulty setting: allow reversing in stations
22:35<Jerik>Yeah, is there a good way without doing that?
22:35<Jerik>So that my stations can all be Roro's
22:36<Eddi|zuHause>never tried that
22:37<Eddi|zuHause>but you'll just need a track that runs around the station, which may be tricky depending on size
22:37<Jerik>I've been trying to put a depot between the lines
22:37<Jerik>And then run tunnels under
22:38<Jerik>But I feel like that just destroys efficiency
22:38<Eddi|zuHause>or you run through the station twice, with "no loading" orders
22:39<Eddi|zuHause>so arrival and departure will be on different platforms
23:10-!-Snail_ [] has quit [Quit: Snail_]
23:24-!-LordPixaII [~pixa@] has joined #openttd
23:24-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:43-!-supermop_ [] has left #openttd []
23:55-!-Jerik [] has quit [Quit: ajax IRC Client]
---Logclosed Fri Nov 25 00:00:27 2011