Back to Home / #openttd / 2015 / 02 / Prev Day | Next Day
#openttd IRC Logs for 2015-02-08

---Logopened Sun Feb 08 00:00:03 2015
00:07-!-guru3-vp1 [~guru3-vps@] has joined #openttd
00:12-!-guru3-vps [~guru3-vps@] has quit [Ping timeout: 480 seconds]
00:37-!-Flygon_ [] has joined #openttd
00:43-!-Flygon [] has quit [Ping timeout: 480 seconds]
00:56-!-Eddi|zuHause [] has quit []
00:56-!-Eddi|zuHause [] has joined #openttd
00:57-!-luaduck is now known as luaduck_zzz
01:23-!-Extrems1 [] has quit [Read error: Connection reset by peer]
01:25-!-Extrems [] has joined #openttd
01:45-!-DanMacK [] has quit [Quit: Page closed]
01:46-!-shirish [~quassel@] has joined #openttd
01:47-!-tokai|noir [] has joined #openttd
01:47-!-mode/#openttd [+v tokai|noir] by ChanServ
01:52-!-tokai|mdlx [] has quit [Ping timeout: 480 seconds]
02:37-!-jogi [] has joined #openttd
02:56-!-Progman [] has joined #openttd
03:13-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
03:14-!-mode/#openttd [+o Alberth] by ChanServ
03:15-!-smoke_fumus [~smoke_fum@] has joined #openttd
03:38-!-DDR [] has quit [Read error: Connection reset by peer]
03:49-!-sla_ro|master [slamaster@] has joined #openttd
03:49-!-Wolf01 [] has joined #openttd
03:49<Wolf01>hi hi
04:02-!-Pensacola [] has joined #openttd
04:03-!-andythenorth [] has joined #openttd
04:10-!-Suicyder [~Suicyder@] has joined #openttd
04:18<V453000>wtf izup andythesouth
04:19-!-Principal8 [] has joined #openttd
04:20<Principal8>is it possible to set up openttd in "sandbox mode"?
04:20<Principal8>with infinite funds
04:20<Principal8>or everything is free
04:21<Principal8>ok, thanks
04:21-!-Principal8 [] has left #openttd []
04:21<V453000>South Antarctican Replacement Snow?
04:21<andythenorth>caballo de hiero
04:22<andythenorth>many years ago I tried to persuade pikka to make SARS after NARS
04:25<V453000>-> pineapplez :P
04:30*andythenorth considers a QLDR roster
04:31-!-Yotson [~Yotson@2001:980:6ac8:1:353b:9d32:e247:5068] has joined #openttd
04:35<@peter1138>Quite long, didn't read?
04:36<andythenorth>one engine
04:36<andythenorth>one wagon
04:36*andythenorth biab
04:36-!-andythenorth [] has quit [Quit: andythenorth]
04:38-!-jjavaholic [] has quit [Remote host closed the connection]
04:46-!-andythenorth [] has joined #openttd
04:50*andythenorth wonders if there’s a way to have hg track file name changes
04:51<@Alberth>hg mv old new afaik
04:51<andythenorth>yeah that’s what I want to avoid
04:51<andythenorth>probably I should get a UI client
04:51<@Alberth>oh, the magic git "lets guess what the user did" is better? :)
04:51<andythenorth>lower friction
04:52<Eddi|zuHause>afair, "hg addremove" tries to record things as move when the files are identical
04:53<Eddi|zuHause>alternatively, you can override "mv" with a macro that checks for hg, and uses "hg mv" instead
04:54<@Alberth>but you have to type a command to move a file anyway, so hg mv is as good as mv
04:54<andythenorth>I tend to use my file browser
04:54<andythenorth>or in my editor
04:54<andythenorth>addremove looks like the closest I’m going to get
04:55<andythenorth>or I give in and install a hg UI client :(
04:55<@Alberth>if there is one that does what you want :)
04:56<andythenorth>there will be some for “OS X users who are terrified of the terminal"
04:56<andythenorth>and they’ll hide everything away, and do magic, and it will be impossible to understood what it’s doing
04:59-!-oskari89 [] has joined #openttd
04:59<@Alberth>as long as it doesn't fail, it's ok :)
05:01<andythenorth>maybe I just need to learn mv better
05:02<andythenorth>typing the path twice is a bore
05:02<Eddi|zuHause>you can drag and drop the file from the browser
05:02<andythenorth>or copy-paste
05:03<Eddi|zuHause>also, /oath/to/{file1,file2}
05:03<andythenorth>that’s what I need I think
05:07<@Alberth>cd path/to ; hg mv file1 file2
05:13-!-Quatroking [] has joined #openttd
05:32-!-jogi [] has left #openttd []
05:32-!-jogi [] has joined #openttd
05:32<jogi>Hello all
05:33<jogi>Just a quick question:
05:34<jogi>I just started making edits to the openttd source
05:35<__ln__>you are brave
05:35<jogi>When I have written a patch from the todo list from the wiki and submitted it to flyspray, is there anything else I should do?
05:35<jogi>Well, thanks
05:36<jogi>ok great
05:36<Eddi|zuHause>"don't call us, we call you."
05:36<__ln__>1. wait, 2. wait more, 3. wait a few more months, 4. remind the developers about it, 5. wait more, 6. get kicked from the channel, 7. wait, 8. patch applied.
05:37<@Alberth>you wrote ?
05:37-!-chillcore [~chillcore@] has joined #openttd
05:37<chillcore>hello all ;)
05:38<jogi>__ln__: Are you speaking from experience? ;-)
05:38<jogi>hi chillcore
05:39<@Alberth>hi hi chillcore
05:39<chillcore>hello alberth
05:39<jogi>thank you alberth for your your comment
05:39<@Alberth>jogi: the question is how to change it. One solution is to move the checks + warnings to the order gui. That would definitely work
05:40<@Alberth>I can imagine there are ways to give your feedback of the command to a specific player only, but I don't know exactly if that's possible, and how
05:41<jogi>I thought about doing it in the CheckOrders(), function, but that gets called every day for each vehicle, so I feared making edits there because of performance
05:41<@Alberth>you don't want a warning every day either :)
05:42*chillcore pokes frosch to commit FS#6156 fixes if he finds a few moments
05:42<@Alberth>especially if you share a wrong order with 50 vehicles :)
05:42<@Alberth>little early for frosch :)
05:43<__ln__>jogi: yes i am
05:43<@Alberth>adding it to the gui is conceptually nicer too, you check and warn before applying the change, instead of afterwards
05:43<chillcore>Alberth: np ... I am reluctantly going to look at compiling a windoze binary for v
05:44<Eddi|zuHause>i've had patches sit there quietly for a year. and then they got commited. and then the bugs were found. :p
05:44<chillcore>might take a bit or maybe I will just have to connect my xp machine for a bit ... which is a terrible idea seeing as it runs now
05:45<@Alberth>catch it quickly before it leaves the room :)
05:45<Pikka>andythenorth: been writing AI today.Who knows, I might do some newgrf work some time soon at this rate. :)
05:46<jogi>Alberth: If I think about it, maybe I should only take the check for servicing into that function, because the settings can change without making a change to the order
05:47<jogi>for the rest, I will take a look into the order gui.
05:47<jogi>Maybe useless conditions could be marked in red or something like this
05:48<@Alberth>good idea
05:48-!-itsatacoshop247__ [] has quit [Ping timeout: 480 seconds]
05:48<@Alberth>currently "Invalid order" is in red, if a vehicle wants to visit a non-existing station
05:49<chillcore>Alberth: is there somewhere in the code a functional slider I can lurk code of off?
05:49<@Alberth>only sliders we have are the scrollbars, afaik
05:49<chillcore>music volume perhaps ?
05:49<@Alberth>:O good point
05:50<chillcore>I don't know how it functions yet ... could be just checking the point being clicked though ...
05:50<@Alberth>it was some make-believe indeed, iirc
05:50<@Alberth>but if it works..... :)
05:51<chillcore>I'll have a looksie. just found a few more snippets in my code that are in the wrong patch still too
05:52<@Alberth>scrollbars have page magic, you may want just a single point in a range instead of an interval
05:54<chillcore>an actual slider would be cool though ... not sure though if the slider itself should contain the value in it. or if the values should be visible outside of it (on a button as is now)
05:54<chillcore>Also had a quick look at your doings ... seems a bit complicated with all that magic gathereing of guis in one
05:54<chillcore>that is what makes worldgen so compliated IMHO
05:55<@Alberth>yeah, I was thinking how to untangle that mess iirc
05:55<@Alberth>a class for each page or so
05:55<chillcore>huhu seems like the esiest way ... now there is the gui for new game and the one for scenario editor just describes the differences between them?
05:56<chillcore>just a hint ignore scenario editor untill you understand new game
05:56<chillcore>makes it a whole lot easier
05:56<@Alberth>no worries, I was not going to mess in the scenario world soon :)
05:56<Eddi|zuHause>i think new game and scenario editor warrant much different gui setups
05:56<chillcore>I agree eddi
05:57<Eddi|zuHause>PS: what i always missed in scenario editor was to run the individual map generation steps individually
05:57<@Alberth>the entire scenarios are kind of dead until we fix the file format :(
05:58<Eddi|zuHause>like generate hills, generate towns, generate industries, ...
05:58<chillcore>there should be 4 guis ... new game, scenario and then for both ... original and 'whatsitcalled' again terraingenerotor
05:58<chillcore>try my patch eddi?
05:58<Eddi|zuHause>probably not.
05:58<chillcore>terrain is a seperate step ... but if you have still eg. rivers enabled it takes a bit
05:59<chillcore>not showing them all at once though ... ;)
05:59<Eddi|zuHause>generate rivers should also be one of those individual steps
05:59<chillcore>but did not get that far yet
06:00<chillcore>for now smootness is functional as seperate process
06:00<@Alberth>I wonder why you want that in the SE, it sounds like manual "new game"
06:00<Eddi|zuHause>Alberth: you can make adjustments inbetween
06:00<chillcore>once that is done properly I can move the rest too
06:00<Eddi|zuHause>Alberth: or save, try with some settings, see it not working well, reload.
06:00<@Alberth>yeah, undo last generation would be spiffy
06:01<chillcore>albert new game is just play ... scenario is tweak like crazy (or skip steps you never change anyways)
06:01<@Alberth>sure, but "tweak like crazy" sort of makes "generate some random setup" sort of useless
06:01<chillcore>yes and no ...
06:02<Eddi|zuHause>Alberth: one of the problems is that in scenario editor you cannot actually reproduce the later stages of a "new game"
06:02<chillcore>perhaps yo want rondom terrai but manual placements of indstries and stuffs
06:02<@Alberth>ie you may have to fix practically all generated things afterwards
06:02<chillcore>how so?
06:02<Eddi|zuHause>Alberth: like, if you placed manual towns, you cannot run "random industries" [with the appropriate density options], only this not-very-well controlled "create many industries"
06:03<Eddi|zuHause>or... trees
06:03<@Alberth>say you generate towns, but you don't like the positions, so you have to 'move' the towns afterwards
06:03<chillcore>with my patch: you tweak terrain like crazy untill happy, then the next step you generate the rest, and yes terrain gets re-generated in the process but result remains
06:03<@Alberth>Eddi|zuHause: true, you need more fine-grained control on the generation process
06:03<Eddi|zuHause>Alberth: but all that is for the player to decide. the scenario editor should support that with options
06:04<chillcore>I see ... generating towns during setup of terrain makes no sense really ... untill you are happy with terrain everything gets destroyed anyways
06:04<Eddi|zuHause>Alberth: and the options should not only consist of "create random set without parameters to tweak, or place everything individually"
06:04<@Alberth>Eddi|zuHause: no argument from me :)
06:05<@Alberth>I fully agree :)
06:05<chillcore>^^^ in scneario editor that is
06:05<chillcore>CTRL new game is everything random ... not planning to change that in any way
06:05<jogi>Thank you for your time, I'm off to lunch
06:05<@Alberth>bye jogi
06:06-!-jogi [] has quit [Quit: jogi]
06:06<@Alberth>in newgame, you still have options, and that's good
06:06<chillcore>however ... I do plan to add a button to generate random settings ...
06:06<chillcore>true and you should have
06:06<@Alberth>the main problem in worldgen is weird order of steps
06:07<Eddi|zuHause>things like town name set should be in world generation settings
06:07<@Alberth>and long turn-around time to generate a nice looking map
06:08<chillcore>should it Eddi? that is changing newgrf settings ingame practically and opens the can of worms again
06:08<@Alberth>newgrf settings should be in the steps too, imho
06:09<@Alberth>ie before you generate towns/industries/etc :)
06:09<chillcore>ok ... then I will have to use a lot of _game_mode magics
06:09<chillcore>that or scenario editor should be loosened up
06:10<chillcore>hmm ... something to ponder about
06:10<chillcore>I know Rubi does not like that much
06:10<chillcore>I had some of that magic in tgp.cpp
06:10<chillcore>he removed it all
06:10<chillcore>^^^ MHL patch
06:11<Eddi|zuHause>well, a new scenario editor could be designed towards the new scenario [heightmap] format
06:11<@Alberth>calculation code should not be mixed with control flow code if possible
06:11<chillcore>huhu ...
06:12<Eddi|zuHause>chillcore: i don't see any harm in changing the town name generator when to towns exist.
06:12<chillcore>there is plety of room for improvments: alberth
06:12<@Alberth>problem is that it's a newgrf Eddi|zuHause, so you can have all the side effects of newgrf changes
06:13<chillcore>Eddi: and what do you when you have industries named after them alreaydy?
06:13<@Alberth>can't have industries without town :p
06:13<Eddi|zuHause>chillcore: cannot have industries without town
06:13<chillcore>or when you edit an existing savegame?
06:13<Eddi|zuHause>then changing town name is forbidden
06:13<chillcore>how does the game know that this is not a new scenario you are creating?
06:13<@Alberth>chillcore: that's what the new format fixes
06:14<Eddi|zuHause>Alberth: adding a town name newgrf and selecting the town name generator are two different steps
06:14<@Alberth>fair enough
06:14-!-peter1138 [] has quit [Ping timeout: 480 seconds]
06:15<chillcore>hmm ... lots of things happening ... you could be right eddi not going to argue untill I see things happening ;)
06:15<@Alberth>chillcore: the new scenario file format basically specifies how to generate a scenario from scratch, instead of saving it as a save game
06:15<Eddi|zuHause>also, town name newgrfs should work separate from all other newgrfs
06:15<@Alberth>so you don't edit a save game, you edit the generation specification
06:15<chillcore>ah like that
06:16<Eddi|zuHause>with the new format you might lose some precision, like which house goes where exactly
06:17<@Alberth>it's more detailed specification, which is left out for now, but not impossible to add again
06:17<@Alberth>and there are cases where people want that
06:17<@Alberth>in particular, you may want to use some external script to generate such things instead of placing each house in the editor
06:18<chillcore>yes ... scripts too ...
06:19<Eddi|zuHause>well, "script" in this context would be a gimp-fu or something
06:20<Eddi|zuHause>but we're digressing, i think :)
06:20<@Alberth>we are? it's still all OpenTTD :p
06:20<andythenorth>huh, I turn away for 5 minutes, and people are talking about stuff :o
06:21<@Alberth>no vehicle groups yet :p
06:21<chillcore>hehe ye it is kinda three topics in one eddi
06:21<Eddi|zuHause>andythenorth: weirdm we've beent talking for like 20 minutes
06:21<chillcore>gotta love spaghettios
06:23<chillcore>but in all fairness the code has come a long way during the last couple of years
06:23<chillcore>lees spaghetti ... still too much magic nrs though ... getting there
06:24<chillcore>I'll have a quick look at that music volume slider code ... brb
06:26<chillcore> int x = pt.x - this->GetWidget<NWidgetBase>(widget)->pos_x;
06:26<chillcore>poitnreference indeed
06:27-!-zeknurn [] has quit [Remote host closed the connection]
06:27-!-zeknurn [] has joined #openttd
06:27<chillcore>would introducing a real slider be hard much?
06:28<@Alberth>it's like a horizontal scrollbar mostly, without the page magic
06:29<chillcore>why did I not think of that hehe.
06:29<@Alberth>just a class with some widget functions, and a drawing routine
06:29<@Alberth>maybe you wanted vertical sliders :p
06:30<@Alberth>shouldn't be very complicated
06:30<chillcore>Hmm that would make for an intersting gui
06:30<@Alberth>callback to the window with the new value may be tricky
06:30<chillcore>labels vertically too for saving screen estate
06:31<@Alberth>people turning their monitor to read the labels :p
06:31<@Alberth>width is much less of a problem than height at current screens
06:31<chillcore>true that
06:32<chillcore>remind me of this game I played ... "liquidsketch"
06:32<chillcore>I believe it was by Purno's brother ... pretty sweet anyways... turn ipad and water flows
06:33<chillcore>except here we make trains glide down rails
06:33<@Alberth>wow :)
06:33<Eddi|zuHause>my grandmother had a pen with the wuppertal schwebebahn that slided when you tilted the pen
06:34<chillcore>hehe I had the same but with superman in it
06:34<Eddi|zuHause>and that was even before wuppertal was in the world that you could reach :p
06:34<chillcore>anyhoo now we disgress :P
06:35<chillcore>maybe I will tackle them sliders later when a true live preview is available?
06:36<chillcore>which is not something I would now how to start with at this point in time ... welp
06:36<Eddi|zuHause>i think peter's true colour company colour patch had horizontal sliders for the rgb values
06:36<Eddi|zuHause>not sure if you mean that
06:37<chillcore>got a link to that Eddi? <- I collect links at the moment.
06:37<chillcore>yes pretty much that
06:39<Eddi|zuHause>probably around here:
06:39<chillcore>thank you eddi
06:41<chillcore>before I forget ... Andy: about a gui for hg ... I did not know I had one (workbench) installed by default untill I entered "thg" in terminal ;)
06:41<chillcore>^^^ linux
06:42<andythenorth>k ta
07:00-!-[1]Suicyder [~Suicyder@] has joined #openttd
07:04<chillcore>Just thinking out loud and totally unrelated. Would it be a good idea to skip savegameversions 200 to 250? there is a bunch of patches out there (including some of mine) that have their values set to 200 to avoid having to adjust it while bumping ... so there will be a ton of savegames out there that will suddenly become valid.
07:06-!-Suicyder [~Suicyder@] has quit [Ping timeout: 480 seconds]
07:06-!-[1]Suicyder is now known as Suicyder
07:06<chillcore>in a few 'time units' we will have to go from byte to uint anyways
07:11-!-Pikka [] has quit [Quit: Leaving]
07:15-!-frosch123 [] has joined #openttd
07:15<Eddi|zuHause>chillcore: savegame version is not the only thing that makes a game "valid"
07:16<chillcore>true but OpenTTD does not know that untill it crashes?
07:17<chillcore>might just refuse to load ... never really tested
07:17<Eddi|zuHause>the most common thing of changing settings will lead to "invalid chunk" errors
07:17<Eddi|zuHause>it won't crash
07:18-!-supermop [] has quit [Ping timeout: 480 seconds]
07:18<chillcore>hmm ok ... I guess untill FS gets swamped with bugreports the subject is moot
07:28-!-Progman [] has quit [Remote host closed the connection]
07:34*chillcore will be back laters ... switching to windoze HDD, setting up environment to produce test binaries ... needs feedback on usability badly in order to proceed.
07:34-!-chillcore [~chillcore@] has quit [Quit: Ex-Chat]
07:43-!-gelignite [] has joined #openttd
08:23-!-Pereba [~UserNick@] has joined #openttd
08:38-!-shirish [] has quit [Remote host closed the connection]
08:53-!-chillcore [~chillcore@] has joined #openttd
08:55<chillcore>V453000: I am sorry but I will not be compiling a binarie for windoze. my brain advises against it. I duno what happened to sourceforge the last couple of years but the place is riddled with crapware
08:56<chillcore>read: way too many buttons that make you download stuffs without knowin what you get. aka. click link think it is the download button and got something else
08:56<chillcore>not that I have any of that stuffs downloaded as I moused over and looked ata the links
08:56<andythenorth>it scamware mostly, no?
08:56<chillcore>yeah make pc faster kinda shit
08:57<chillcore>amongst others
08:57<andythenorth>“Why so slow is Mac?"
08:57<andythenorth>“Special software to remove viruses and malware"
08:57<andythenorth>yeah, right
08:57<andythenorth>idiots gonna id
08:57<chillcore>also the compiling page on wiki is i a pretty bad shape
08:59<chillcore>mentions zlib 1.2.7 at top but is dead link then lower (in instructions) it gives the instructions for 1.2.8 ...
08:59<chillcore>I needed to do some digging in a completely other sectio to get it
08:59<chillcore>^^^ on sourceforge that is
09:00<@Alberth>compiling is a dying art
09:00<chillcore>sorry v ... maybe I could go the openttdcoop way but I feel it is a bit too soon
09:00<chillcore>yeah long live linux
09:01<@Alberth>ask for a build at the forum?
09:01<chillcore>I did alberth ... seems like everyone is busy doing other stuffs
09:02<chillcore>that or I buried the request to deep in my post
09:06<chillcore>hope you understand, I would apreciate someone messing about very much though for the defaults ... so it double stings a bit
09:09<chillcore>the compiling page I mentioned being out of shape is the mingw/msys one
09:09<V453000>I got enough of my things to do :P no worries
09:09<V453000>want to get done some RAWR bridges this week
09:12<chillcore>maybe it is time to provide our own deps in a sane way? it'sall GPL v2 after all?
09:12<chillcore>for windoze that is
09:13-!-roidal [] has joined #openttd
09:13<@Alberth>you only need deps for development, for building a release, you have to build everything anyway
09:14<@Alberth>unless you have other ideas about 'deps' than source file dependencies
09:14<roidal>Alberth: are you one of the openttd-dev's?
09:14<chillcore>for windoze that is meant ... my prob right now is that I do not trust what I downloaded just now
09:14<chillcore>*I meant
09:14<@Alberth>roidal: yeah, I do commit stuff every now and then
09:15<roidal>so, you know this stuff very well?! :D
09:15<chillcore>that last (of mine) sentence no sense make
09:16<@Alberth>roidal: not likely :p
09:16<roidal>iam still wondering about town-growth
09:16<@Alberth>for some reason "have commit rights" seems to imply "knows everything" :)
09:16<chillcore>that is what I meant alberth them source zips may or may not have surprises... etc
09:17<chillcore>^^^ better
09:17<roidal>Alberth: wouldn't say "knows everything" but "knows much more than me"
09:17<@Alberth>about town growth? I doubt that :)
09:17<@Alberth>it's not a topic I am interested in :)
09:18<@Alberth>players are often much more knowledgeable in such details
09:19<roidal>iam generally interested in gamce mechanics
09:19<@Alberth>but in general, the Game Mechanics wiki page explains how it works at code level
09:19<@Alberth>and then there is the actual source code itself as final and definitive source of knowledge :)
09:20<@Alberth>(some every revision X :p )
09:20<@Alberth>but sure, ask away, maybe someone in the channel knows the answer
09:20-!-Suicyder [~Suicyder@] has quit [Quit: HydraIRC -> <- The alternative IRC client]
09:21<roidal>yes, was reading the wiki, and it writes about "stations within town influence",
09:22<roidal>now i try to figure out how far town influence goes
09:22<@Alberth>right :)
09:23<roidal>is it written in C oder C++
09:23<chillcore>good question ... need digging in the source for that I am afraid
09:23<chillcore>both roidal but movement is towards c++ completely
09:24<roidal>don't like C++ :D
09:24<chillcore>also since c is valid c++ ... it is c++ ;)
09:26<@Alberth>random guess is, the station tile with the label is the location of the station. If that tile has an authority (query the tile with the "?" button), the station is part of town influence
09:26<@Alberth>but again, this is a random guess
09:27<@Alberth>/me fails to see the fascination with town growth in a tycoon game
09:29<@Alberth>it's not anywhere near modern c++ such as c++11
09:29<chillcore>it just gives an extra goal alberth ... make town grow by transporting stuffs to it
09:29<+michi_cc>chillcore: What's wrong with the we provide? Except for the special case of cross-compiling to windows, using MSVC is mostly a lot easier.
09:29<chillcore>I see town as industry made of houses?
09:30<chillcore>ooh did not think of that one ... thanks michi_cc
09:30<roidal>Alberth: its only because iam wondering that i have a city with no growth even if i deliver goods
09:30<@Alberth>true, that's how Busy Bee uses towns, but those town goal scripts concentrate on towns only, I think
09:30<roidal>and the game mechanics wiki says that in this case there should be growth :)
09:31<efess>roidal - I think you need to move passengers to stimulate growth
09:31<roidal>chillcore | it just gives an extra goal alberth ... make town grow by transporting stuffs to it <- and thats another point
09:31<roidal>like to choose cities and make them very big :D
09:32<chillcore>I do prefer just the terminal and modyfying files manually. Also the exe is not produced in bin? so extra steps are needed to provide binaries opening door to mistakes. michi_cc
09:32<@Alberth> <-- first answer by pikkabird may be a cause perhaps, but you'll have to check the source if the claim is true
09:32<chillcore>last time I used it anyays
09:32<roidal>efess: i have another city only delivering goods, but this one is
09:34<@Alberth>if it is true, I can even see that it should be considered to be a bug
09:34<@Alberth>although it's also 'realistic' :p
09:35<@Rubidium>Alberth: then we should really start using mercurial because then everyone knows everything and we don't need to answer such questions anymore ;)
09:35<@Alberth>just stop advertising svn as the master repository :)
09:36<chillcore>roidal there is more then just delivering goods that influences towns growth or not grow
09:36<chillcore>or shrinkage for that matter
09:36<chillcore>fraquency of vehicles visiting stations is one of them
09:37<chillcore>road works too
09:37<chillcore>etc etc etc
09:37<@Alberth>good point, growth does some random walk, which may fail
09:38<@Alberth>playing sub-tropical roidal? then you need to work for getting growth :)
09:40<roidal>and luky for me the game shows the town-groth-rate in the city-overview window
09:41<roidal>and i see in cities where the station is very near to the center that the growth-rate increase very short after unloading some cargo
09:42<roidal>and at one city, where there was too less place for the station beside the center, there i deliver cargo without affecting the growth-rate, even if the station is still within the influence area
09:43-!-peter1138 [] has joined #openttd
09:43-!-mode/#openttd [+o peter1138] by ChanServ
09:46<roidal>but i see you guys are bored from my questions :D
09:47<chillcore>UpdateTownRadius() in town_cmd.cpp
09:47<roidal>oh, cool, thanks!
09:47<chillcore>not at all roidal see I consider myself to kow a bit due to making my patchpack
09:47<chillcore>still had to search and that may not be the only function
09:48<chillcore>lol ... it is old ... r22555
09:48<chillcore>try grasping vanilla first maybe?
09:48<roidal>but, know i was able to build a station a little bit more near of the center
09:48<Eddi|zuHause>that sounds like a chill's patchpack revision
09:48<roidal>and now it affects the growth :)
09:48<chillcore>indeedeleedom eddi
09:48<Eddi|zuHause>not sure if you've heard of that one :p
09:49<chillcore>it's a first ...
09:49<chillcore>cool though have a revision dedicated to me ...
09:49<chillcore>and not so much cause I got stuck there ... which may be for the better in the long run :P
09:50<chillcore>it was fun while it lasted but toomuch bandage in the end
09:50<chillcore>*duct tape
09:51<Eddi|zuHause>you could just make a new one :p
09:51<chillcore>I could ... but I figured it benefits openttd moe me doing single patches
09:51<chillcore>also peeps stopped trying single pacthes and I was holding peeps back from making their own
09:52<chillcore>which is sad in itself
09:52<chillcore>maybe I will someday ...
09:52<chillcore>tbh it was more work then a normal day job ... my choice offcourse
09:52-!-quorzom [] has joined #openttd
09:56<chillcore>I even dreamt code at some point ... waking up and thinking I need to write this down so I remember this tomorrow
09:56<@Alberth>and you learned a lot :)
09:56<Eddi|zuHause> <-- i'm assuming there's some pronunciation thing going on here?
09:56<chillcore>I can not describe how much Alberth
09:56<chillcore>thanks again to all of you ;)
09:56<@Alberth>and I do write things down in the middle of the night, to prevent it from circling in my head for hours :)
10:01<roidal>is there a key for disabling/enabling visibilities of trees?
10:01<roidal>which one? :P
10:01<chillcore>xtrl-X and then select trees? could be wrong
10:02<Eddi|zuHause>'X' as well
10:02<chillcore>"could be wrong" <- that is the reason peeps do not reply sometimes when they do not know for sure often
10:03<roidal>x change all types
10:03<roidal>there must be a dedicated for trees only
10:03<chillcore>then open the menu and select trees only
10:03<Eddi|zuHause>with ctrl+x you can decide which of the entries should be chanced with 'x'
10:03<chillcore>x will toggle afterwards
10:03<Eddi|zuHause>ctrl+click the buttons to lock them
10:04<chillcore>also tooltips ...
10:05<Eddi|zuHause>also, you can probably assign hotkeys to the button in the transparency gui via hotkeys.cfg
10:05<Eddi|zuHause>possibly even a global hotkey
10:09-!-Pulec [] has quit [Remote host closed the connection]
10:09-!-Myhorta [] has joined #openttd
10:19<chillcore>hmm Drury is such a strange guy sometimes ... I have no clue how to continue the discussion no more (randomness thread)
10:20-!-liq3 [] has quit []
10:33-!-luaduck_zzz [] has quit [Ping timeout: 480 seconds]
10:33-!-luaduck_zzz [] has joined #openttd
10:33-!-luaduck_zzz is now known as luaduck
10:56-!-Progman [] has joined #openttd
11:09<andythenorth>is the game skippy under linux?
11:09*andythenorth considers switching
11:09<andythenorth>‘stutter’ would be more accurate than ‘skip'
11:09<andythenorth>principally when opening windows, trying to provide orders, drag vehicles in groups etc
11:10<andythenorth>2x GUI zoom
11:17<chillcore>it does not for me ... then again it has been a while I loaded any significantly sized savegame.
11:17<chillcore>maybe unrelated ... some games run better when the CPU is set to slow mode instead of dynamic speeds in bios.
11:18<andythenorth>this savegame is tiny
11:18<chillcore>hmm ...
11:18<chillcore>OSX much?
11:18<chillcore>just guessing
11:18<chillcore>try linux on USB first?
11:19<chillcore>will load slower and such but performance should remain while not doing disk operations
11:19<chillcore>disk being USB here
11:20<andythenorth>it’s annoyingly hard to recreate
11:20<chillcore>while doing that best is to remove your HDD to prevent misshaps
11:21<chillcore>if you cold pinpoint it to some guis and not all?
11:21<chillcore>got many background apps?
11:23<chillcore>no OSX expert by any means but I increased speed on iOS by jailbreaking and deleting stuffs
11:25<chillcore>Also by trying on USB I mean not a live version but really installing ;)
11:25<Eddi|zuHause>andythenorth: so have you tried profiling and waiting for it to happen?
11:26<andythenorth>no, how?
11:26<andythenorth>profiling knowledge = none
11:27<Eddi|zuHause>make a build with symbols (debug level 1 or so), and run "make run_prof" (or run-prof, i never remember)
11:27<andythenorth>run-prof seems to do something
11:27<andythenorth>run_prof complains about lack of .o file
11:28<Eddi|zuHause>then let the program run for however long you deem appropriate. and when you exit, it shows you a list of functions, sorted by how much time was spent in each
11:28<andythenorth>k, looks like I need to increase debug level
11:28<andythenorth>on exit, nothing shown
11:28<Eddi|zuHause>it may be stored in a file
11:31<Eddi|zuHause>was configure ever refitted with a "no strip" option?
11:33<chillcore>yes ... I remember using no strip on occasions to get a nice huge debug buid, 37MB or something
11:34<Eddi|zuHause>the build should otherwise behave exactly like a release build
11:34<Eddi|zuHause>no magic flipping of buttons and stuff
11:35<chillcore>look at me all being expert-like :P
11:35<chillcore>emphasis on like
11:36<chillcore>as usual shoot when I put foot in mouth
11:36<Eddi|zuHause>"expert" is a label used by news broadcasters to equip people with credibility
11:37<chillcore>so true ... and sad at the same time
11:37<Eddi|zuHause>some random journalist will become "terror expert"
11:38<chillcore>from zero to here in less then 10 mins ... use wikipedia and take for truth :P
11:39<chillcore>there is also tic() and toc() still?
11:40<Eddi|zuHause>chillcore: yes, but that assumes some guesswork as to where the slowdown will be happening in the first place
11:40<chillcore>not sure if that is any good in andy's case were faster
11:49<chillcore>hmm someone can explain me why we need to restrict max mapheight to some value in the worldgen gui? kinda does not make sense as the heights are already restricted based on mapsize and terrain type in tgp.cpp while generating maps.
11:49<chillcore>is it really that bad to let peeps raise untill 255 is reached?
11:49<Eddi|zuHause>people might want to have lower limits?
11:49<frosch123>there is tons of stuff that depends on max height level
11:49<@Alberth>people may want to have a flat-ish map at 4096x4096
11:50<Eddi|zuHause>also, snowline is relative to that value
11:50<frosch123>like desert, rainforest, industry placement, ...
11:50<chillcore>I sees.
11:51-!-HerzogDeXtEr [] has joined #openttd
11:51<chillcore>it seems a bit confusing that is all
11:51-!-andythenorth [] has left #openttd []
11:57-!-HerzogDeXtEr1 [] has quit [Ping timeout: 480 seconds]
12:34-!-andythenorth [] has joined #openttd
12:45<@DorpsGek>Commit by translators :: r27139 trunk/src/lang/korean.txt (2015-02-08 17:45:49 UTC)
12:45<@DorpsGek>-Update from WebTranslator v3.0:
12:45<@DorpsGek>korean - 12 changes by Gimel3830
13:02-!-zeknurn [] has quit [Ping timeout: 480 seconds]
13:06<chillcore>hmm ... warning about destruction of current scenario when proceeding ... mention it in tooltip before clicking or red popup after clicking the button?
13:07<chillcore>^^^ opening tgen gui from terraform gui
13:07-!-shirish [~quassel@] has joined #openttd
13:09<chillcore>option three not allow that and remove that button, which may lead to some frustration about clickfest if tgen is closed by accident
13:11<@Alberth>tgen doesn't belong in terraform, I think
13:14<chillcore>hmm I meant land generation sorry. that little gui where "create new scenario is" and "delete landscape and companies"
13:15<chillcore>anyhoo I agree that terraforming and opening tgen should not be in the same gui
13:15<chillcore>maybe that gui needs some splitting too? trunk
13:16<@Alberth>I don't know that gui, I would have to look it up
13:16<chillcore>removing tgen button ...
13:16<@Alberth>but likely, yeah, people tend to just add random stuff to random existing infra structure:)
13:17<chillcore>creating new guis is hard ... not really but 'grrr' sometimes ;)
13:17<chillcore>hat off to all you gui gurus out there ;)
13:18<@Alberth>assuming you add it in some "world destroy" window, I don't think it needs a warning
13:18<@Alberth>really, what is so hard?
13:18<chillcore>collecting all the needed chunks
13:19<@Alberth>ah yeah, a bit of shopping in the other windows :)
13:19<chillcore>but as I progress slowly it is managable ... would be different if I had to come up with a gui in one go
13:20<chillcore>also behavior ... keeping in mind that other guis might have to be updated etc
13:20<@Alberth>I start on paper first, to get some design, usually
13:20<chillcore>ususally yes hehe ... I have stuffs in my head and keep chunks of code that need to be adjusted in a file
13:21<chillcore>now I need to find the code that draws text white on currently active preset
13:21<chillcore>background is auto black but text is not white ...
13:22<chillcore>^^^ that kind of grrr
13:22<chillcore>I love it though cause O am about to learn something new :P
13:22<chillcore>s O/I
13:24<chillcore>Also it is easy to get distracted ... I am tempted to split that land generation gui in trunk first ...
13:25<chillcore>which would mean creating another gui ... think I am going to wait a bit with that hehe
13:29-!-zeknurn [] has joined #openttd
13:29<chillcore>hmm I have a better idea ... instead of button that opens tgen gui just change create new scenario button to behave as if comming from main menu ... that way the behavior remains consistent too
13:32<@Alberth>in the language file STR_FOO :{WHITE}some text
13:33<chillcore>hmm for dropdowns? I never noticed to having two strings for the same option
13:33-!-Pereba_ [~UserNick@] has joined #openttd
13:34<chillcore>checking lang files.
13:37<@Alberth>oh, hmm, don't know
13:37<@Alberth>you may be able to add colours to the dropdown generation call?
13:39-!-Pereba__ [~UserNick@] has joined #openttd
13:41-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
13:41-!-Pereba__ is now known as Pereba
13:41-!-Pensacola [] has quit [Remote host closed the connection]
13:41<chillcore>I do not see how it is handled at first sight ... I looked for terrain type "very flat" there is only one string of that in lang
13:41<chillcore>but it has no colour designation so that may be the error I made
13:41<chillcore>testing, thx alberth
13:45-!-Pereba_ [~UserNick@] has quit [Ping timeout: 480 seconds]
13:45<@Alberth>not hard-coding a colour helps if you want it to change :)
13:48*andythenorth wonders how python will handle evolução
13:48<andythenorth>as a module name :P
13:48<andythenorth>not happily
13:50<@Alberth>interesting :)
13:50<@Alberth>I guess it needs an encoding to find the filename?
13:51<andythenorth>even using it as a string is failing
13:52<andythenorth>thought that would work with u’evolução’
13:52<andythenorth>except not with magic quotes :P
13:52<andythenorth>stupid irc client
13:52*chillcore makes a little woohoohoo dance
13:52<@Alberth>of course not, u' means unicode, ie no encoding at all
13:53*andythenorth always has a sad day with unicode
13:54<@Alberth>the mistake that everybody makes is to think 'unicode' is an encoding
13:54<andythenorth>do I need to encode it and set utf-8?
13:54*andythenorth is pure guessing
13:54<chillcore>hehe the highs and lows all in one place. next victory is for you andy ;)
13:54*chillcore give andy hug
13:54<@Alberth>unicode text is a sequence of code points
13:55<@Alberth>where a code point is a number, as defined in the unicode standard
13:55<@Alberth>ie from 0 to 2**24 or so
13:55<@Alberth>obviously, you cannot send that on a wire or store on a disk
13:56<@Alberth>that's where encodings come in
13:56<@Alberth>there are a lot of encodings, where utf-8 is a common one in the wesrern world
13:57<andythenorth>so I can’t just do this?
13:57<andythenorth> title = u'Evolução [Diesel]'.encode('utf-8'),
13:57<andythenorth>I know I can’t, because it doesn’t work :P
13:57<@Alberth>basically, it takes a code point, and converts it to a sequence of bytes
13:57<@Alberth>what does it say?
13:59<@Alberth>windows code pages are a different form of encoding, for example
13:59-!-Kurimus [] has quit [Ping timeout: 480 seconds]
14:00<@Alberth>decoding is the reverse process, it takes encoded bytes, and converts back to code points. In general you need to know the encoding to do that
14:00<@Alberth>that's it :)
14:01-!-Pereba_ [~UserNick@] has joined #openttd
14:03<andythenorth>SyntaxError: Non-ASCII character '\xcc' in file /Users/andy/Documents/OTTD_graphics/Iron_Horse/iron-horse/src/vehicles/ on line 6, but no encoding declared; see for details
14:03<andythenorth>file is encoded utf-8, and the line is what I pasted above
14:04-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
14:04-!-Pereba_ is now known as Pereba
14:05<@Alberth>Add line # coding=utf-8 at the top
14:05<@Alberth># -*- coding: utf-8 -*- <-- or that one, if you like -*- thingies
14:05<@Alberth>1st or 2nd line
14:06<@Alberth>the problem is that your source file is not unicode, its encoded as utf-8, but python doesn't know that, and cannot decode without you telling that
14:07<@Alberth>it assumes ascii as encoding, and then breaks on a non-ascii character at line 6
14:08<andythenorth>that makes sense
14:08<andythenorth>never dealt with unicode in the src before
14:08<andythenorth>usually just input from web forms or lang files
14:08<@Alberth>you never have string literals in your source?
14:09<@Alberth>ie templates?
14:09<@Alberth>all files have an encoding, or you cannot store them :)
14:12<andythenorth>the only non-ASCII strings come in via i18n
14:16<@Alberth>ascii is a very safe encoding to use :)
14:17<andythenorth>ok, now I just need to call decode everywhere in my code :P
14:17<andythenorth>I guess it’s worth it, I need to learn how unicode handling works properly
14:17<@Alberth>python3 is much more strict in unicode handling
14:18<andythenorth>this set will probably end up in python 3
14:18<@Alberth>it's the main reason why I picked python3 for eints
14:21<andythenorth>ok that works
14:21<andythenorth>I’m a bit uncomfortable that I’ve solved the remaining failures with vehicle.title.decode(‘utf-8’)
14:22<andythenorth>seems like there might be a better way than decoding every time I want to ‘print' the string
14:22<@Alberth>normally, you decode to unicode as soon as you get the string, and encode back when printing
14:22<@Alberth>and all manipulation is done in unicode
14:23<andythenorth>decoding in the template seems non-future proof for cases that aren’t utf-8
14:23<andythenorth>but I don’t know if that’s a valid concern
14:23<@Alberth>eg utf-8 encoded text has a different number of bytes for different code points
14:23<@Alberth>so string manipulations are a pain
14:24<andythenorth>so this is bad? Because I decode, then manipulate?
14:26<@Alberth>it's correct in the sense that you decode and then perform string manipulations on it
14:26<@Alberth>but the output is unicode now
14:27<@Alberth>and you have to take care not to mix encoded with non-encoded strings
14:27<@Alberth>you can do that unpunished with ascii text, but it breaks badly with non-ascii
14:28<andythenorth>so L6, should I call u’’ or just ‘’
14:28<@Alberth>by decidong all as soon as possible, you eliminate that source of errors
14:28<andythenorth>oh this irc client is stupid, it even smart-quotes ‘ when put in via the special-characters palette
14:29<@Alberth>don't know what python does when adding u'x' + 'y'
14:29<Eddi|zuHause>i don't have a lot of experience with python3, but i solved most of my troubles by using u'' everywhere
14:29<Eddi|zuHause>and opening files in utf-8 mode
14:30<andythenorth>I got a bit angry last year when I found someone had added u’’ to all of our dict keys
14:30<@Alberth>python3 is really much better for unicode, as it prevents accidents
14:31<@Alberth>and you don't need to type u'' everywhere :)
14:31<@Alberth>python3 open('file', 'rw', encoding='utf-8')
14:31<andythenorth>dict keys that are private internally to the app seemed an overly-literal interpretation of “this app uses i18n everywhere"
14:32*andythenorth grumbles
14:32<andythenorth>also Iron Horse should be converted to python 3 :P
14:32<@Alberth>it does make life easier if you use the same kind of text everywhere
14:32<Eddi|zuHause>you stumble over encoding troubles much easier if you speak a non-english language :p
14:33<@Alberth>nederlands helpt niet echt hoor (dutch doesn't really help )
14:33*andythenorth lives in ignorant arrogance
14:33<andythenorth>being as ASCII is all stacked in my favour
14:36<andythenorth>this Iron Horse partial compile is astoundingly useful
14:36<andythenorth>I can a new vehicle and see it in game in ~5s
14:36<andythenorth>add +
14:37<@Alberth>I bet that excludes drawing the pixels :)
14:37<chillcore>Hmm Alberth is geen duitser? Geen idee waarom ik dat dacht ... :P
14:38<@Alberth>me neither :p
14:39<chillcore>for the english ... I thought Alberth was german.
14:39<andythenorth>Alberth: the pixels arrive from Dan :)
14:39<andythenorth>my favourite way
14:39<andythenorth>Alberth is very not German :)
14:39<@Alberth>in batch, nicely organized in rows
14:39<@Alberth>very useful :)
14:42-!-roidal [] has quit [Quit: WeeChat 1.0.1]
14:43<andythenorth>rosters bother me
14:43<andythenorth>it would be nice to have a better way of turning them on or off
14:47<andythenorth>Eddi|zuHause: thanks, hg addremove is 100% better
14:47<andythenorth>100% is a stupid measurement, but eh
14:49<Eddi|zuHause>chillcore: i always used to think Alberth was english, because of the "th"
14:53-!-Celestar1 [] has joined #openttd
14:54-!-glx [] has joined #openttd
14:54-!-mode/#openttd [+v glx] by ChanServ
14:55<chillcore>eddi: I thought so for the same reason I guess ... dutch Alberts usually do not have the h
14:58<chillcore>nether do belgian alberts <- just to be safe hehe
14:58-!-Celestar [] has quit [Ping timeout: 480 seconds]
14:59<andythenorth>neither do English Alberts
14:59<@Alberth>maybe it's not part of my first name :p
15:00<chillcore>btw andy you had thg by default? just curious
15:02<andythenorth>might be in ports somewhere
15:02<andythenorth>addremove solves my problem
15:02<chillcore>ok then I know not to suggest it to other OSX users in the future
15:02<andythenorth>hg will guess at filename changes using that command, similar to git
15:03<andythenorth>according to [Lego fan] forums, Lego is dying
15:03<@Alberth>thg is pretty useful to suggest, I use it for browsing and searching a lot
15:03<andythenorth>everything is dying
15:03<chillcore>*me has no chillcore in his first name neither :P
15:03<chillcore>*me* fail
15:04<@Alberth>usually you type /me
15:04<chillcore>ye ... hahah
15:05<chillcore>you should see my typing after playing minecraft ... the amount of leading 't's are rediculous for the first hour
15:18<chillcore>GenenerateLandscapeWindowMode() ... the extra 'en' shoud be fixed in trunk yes? so I better leave that untouched?
15:19<chillcore>^^^ saw that one in your patch Alberth ... I have missed that one for years
15:20<@Alberth>it's in trunk?
15:20<chillcore>yes ;)
15:20<chillcore>line 300-ish ingenworld gui
15:21<@Alberth>feel free to make a patch
15:22<chillcore>will do
15:23<chillcore>need to take my mind of this for a bit anyways before going crazy :P
15:23<chillcore>^^^ wanting to do too much at once
15:25<@Alberth>decide on an order to change things :)
15:26<chillcore>I did ... thing is deciding what should be one patch and what should be multiple sometimes moving code to a different one
15:26<chillcore>I'll get there ;)
15:29<@Alberth>ha, yes, I have that too
15:31<chillcore>for that svn is better ... one blob
15:33<chillcore>another something ... I have compiler warnings in three files due to old compiler ... so i did not report them. should I wait until linux mint fixes that or should that be fixed in trunk too?
15:33<chillcore>as far as my pc is concerned it thinks it is up to date ...
15:34<chillcore>thinking of switching to pure debian sometime soon-ish
15:43<chillcore>patch done it is just 6 lines but did make clean to be sure ... where do I put it? PM, forum, flyspray?
15:43<@Alberth>no idea about warnings, if they are legit, they should be fixed, else the compiler is broken :p
15:43<@Alberth> paste will do :)
15:44<chillcore>ok. warnings go like this:
15:44<chillcore>[SRC] Compiling crashlog.cpp
15:44<chillcore>In file included from /home/chillcore/chiottd/clean_openttd_hg/src/crashlog.cpp:193:0:
15:44<chillcore>/usr/include/libpng12/png.h:2659:31: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
15:44<chillcore> fprintf(PNG_DEBUG_FILE,"%s"m PNG_STRING_NEWLINE,(num_tabs==1 ? "\t" : \
15:44<chillcore> ^
15:44<chillcore>/usr/include/libpng12/png.h:2667:31: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
15:44<chillcore> fprintf(PNG_DEBUG_FILE,"%s"m PNG_STRING_NEWLINE,(num_tabs==1 ? "\t" : \
15:44<chillcore> ^
15:44<chillcore>/usr/include/libpng12/png.h:2675:31: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
15:45<chillcore> fprintf(PNG_DEBUG_FILE,"%s"m PNG_STRING_NEWLINE,(num_tabs==1 ? "\t" : \
15:45<@Alberth>yeah, paste works better
15:45<chillcore>sorry spam
15:45<@Alberth>oh, I have seen this before
15:45<@Alberth>it throws stuff about /usr/include/libpng12/png.h ie libpng source code, not openttd
15:46<chillcore>yes you said compiler warning and you told him to fix it locally? which results in modified anarie and no MP
15:46<chillcore>compiler error*
15:47<chillcore>or someone did somewhere ...
15:47<@Alberth>the above are just warning
15:47<@Alberth>and it's in 3rd party source code, nothing we check or can do anything about
15:47<chillcore>yes but If I add spaces to a normal checkout then it becomes modified ... is what I meant
15:47<chillcore>ok no touchy touchy then
15:48<@Alberth>no, because we don't check png.h
15:48<+glx>it's on your system not in ottd source
15:48<@Alberth>it's not in the openttd source tree that you checked out
15:50<@Alberth>we link against libpng for screenshots. For that we need to include the png.h header file, but we blindly assume it's correct whatever you do with it.
15:50<@Alberth>your package manager may not like modified files though
15:51<@Alberth>if you want to report it anywhere, you should do that at the libpng guys, but no doubt they already know
15:52<@Alberth>you can add the spaces to the file if you like
15:52<@Alberth>or you can just ignore the warnings
15:53<chillcore>welp ... access to this resource denied ... no pasting unless I unlock browser ...
15:54<chillcore>I could paste it here :P
15:54<chillcore>I won't no worries
15:57-!-HerzogDeXtEr1 [] has joined #openttd
16:00-!-shadowalker [] has quit [Quit: WeeChat 1.0.1]
16:01<chillcore>needed to allow cookies alberth
16:02-!-gelignite [] has quit [Quit:]
16:03-!-sla_ro|master [slamaster@] has quit []
16:03-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
16:04<chillcore>offcouse I made a misstake in commit message ... miises "Window"
16:05<@DorpsGek>Commit by alberth :: r27140 trunk/src/genworld_gui.cpp (2015-02-08 21:05:48 UTC)
16:05<@DorpsGek>-Codechange: Fix typo in GenenerateLandscapeWindowMode (chillcore)
16:06<@Alberth>one step done :p
16:06<chillcore>that was fast ... thx
16:07<@Alberth>either you do them sneakily with other changes, or you just throw them in
16:07<@Alberth>no point in collecting them first or so :)
16:08<chillcore>there is more where that came from :P
16:08<chillcore>little things ...
16:09<@Alberth>there is an pretty much infinite supply of them :)
16:09<Wolf01>one more video and then I'll go to sleep
16:09<@Alberth>enjoy Wolf01
16:09<chillcore>1 more ... hehe ... have you seen sixty symbols yet? :P
16:10<Wolf01>not yet
16:11<chillcore>hehe you may want to wait or you'll not sleep and ten you'll have to kill me three times
16:17-!-supermop [] has joined #openttd
16:24-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
16:25-!-Yotson [~Yotson@2001:980:6ac8:1:353b:9d32:e247:5068] has quit [Quit: .]
16:28-!-shadowalker [] has joined #openttd
16:28-!-Kurimus [] has joined #openttd
16:31<chillcore>^^^ some more coding style in genworld_gui.cpp Alberth ;)
16:31-!-Supercheese [] has joined #openttd
16:31<chillcore>all dots except two slight ajdustments in comments
16:39-!-Flygon [] has joined #openttd
16:45-!-Flygon_ [] has quit [Ping timeout: 480 seconds]
16:57-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:58<Wolf01>ooook, I really think that I watched more than one video...
16:59<Eddi|zuHause>that's what usually happens :p
16:59<Wolf01>so.. good night, before I'll watch ten more :P
16:59-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
16:59-!-shirish [] has quit [Remote host closed the connection]
17:06-!-HerzogDeXtEr1 [] has quit [Quit: Leaving.]
17:06-!-andythenorth [] has left #openttd []
17:07-!-DDR [] has joined #openttd
17:20-!-itsatacoshop247__ [] has joined #openttd
17:23-!-supermop [] has quit [Ping timeout: 480 seconds]
17:27-!-oskari89 [] has quit []
17:34<chillcore>goodnight all
17:34-!-chillcore [~chillcore@] has quit [Quit: Ex-Chat]
17:41-!-supermop [] has joined #openttd
17:57-!-DanMacK [] has joined #openttd
17:58-!-Quatroking [] has quit [Read error: Connection reset by peer]
18:19-!-DanMacK [] has quit [Quit: Page closed]
18:24-!-Myhorta [] has quit [Read error: Connection reset by peer]
18:43-!-Diablo-D3 [] has joined #openttd
18:43<Diablo-D3>hey alll
18:44<Diablo-D3>Does anyone know when the bug with mouse not being locked in a fullscreen window is going to be fixed?
18:44<Diablo-D3>its making it unusable on multiple desktop setups on windows
18:47<@planetmaker>is there such bug?
18:47<@planetmaker>did you report it?
18:47-!-Progman [] has quit [Remote host closed the connection]
18:49<@planetmaker>so what's the link to the bug report?
18:49<Diablo-D3>I didnt report it
18:49<Diablo-D3>but I think it is reported
18:49<Diablo-D3>its a single missing line
18:50<@planetmaker>so it has been reported and a patch suggested in our bug tracker?
18:50<@planetmaker>if not: probably indefinitely
18:51<@planetmaker>for simple grounds of "do not know about" --> "do nothing about". I don't use windows, thus couldn't test it
18:51<@planetmaker>but others who do and read issue tracker might, and will, if it's reported and a patch suggested
18:54<Diablo-D3>planetmaker: just add SDL_WM_GrabInput(SDL_GRAB_ON);
18:55<Diablo-D3>its a common mistake that a lot of devs forget
18:55<@planetmaker>Diablo-D3, don't tell me now. Please file a bug report. It's 1am Sunday night and I don't have windows
18:55-!-smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 4.2.0 Equilibrium]
18:58<Diablo-D3>planetmaker: openttd DOES use sdl on windows, right?
18:58<Diablo-D3>planetmaker: dont worry, you're in with a lot of games that never get this right
18:58<Diablo-D3>half the games in my steam library do not work properly on windows.
18:58<@planetmaker>it uses GDI
18:59<@planetmaker>GDI on windoze, SDL on *nix, cocoa on OSX
18:59<@planetmaker>at least by default
19:01<Diablo-D3>normally I would ask why, but Im not going to
19:01<@planetmaker>simple: better performance
19:02<Diablo-D3>depends how you define better
19:03<Diablo-D3>modern hardware cannot optimize draw calls that way anymore
19:06<Diablo-D3>its faster to paint the entire frame every frame
19:06<Diablo-D3>than just do updates
19:15<Flygon>Modern hardware needs HScroll function
19:15<Flygon>Hallucination effect in RO broken due to modern hardware lacking HScroll equivilant
19:15<Flygon>And having to do it in software D:
19:16<Flygon>IS it really so hard to retain the ability to offset a scanline by x amount of pixels as a herediary function?
19:16<Diablo-D3>Flygon: well, modern hardware isnt meant to be used for direct framebuffer manipulation
19:16<Diablo-D3>either do it all in software, or use hardware accelerated methods via d3d or ogl
19:16<Flygon>Why not do the effect post-framebuffer then?
19:17<Diablo-D3>because post-framebuffer is the monitor.
19:17<Flygon>Delay or introduce early the amount of pixels by how much the HScroll effect says, add black border for... seriously?
19:17<Flygon>It's just a literal framebuffer > video port > monitor thing?
19:17<Diablo-D3>yup, thats how hardware still works
19:17<Flygon>Zero additional steps apart from making...
19:17<Flygon>The world I lived in hasn't existed for 15 years
19:17<Diablo-D3>framebuffers for a window may be secondary framebuffers
19:18<Diablo-D3>but it depends entirely on the OS and the driver
19:18<Flygon>x3 Sorry for sounding like a fool
19:18<Flygon>Just... long story short
19:18<Flygon>Too used to working with older hardware
19:18<Diablo-D3>yeah, basically, radeon 5xxx and up and geforce 8xxx and up are modern hardware
19:18<Flygon>And noted that certain older games ran horridly on modern hardware due to using hardware effects tricks that don't work anymore
19:18<Diablo-D3>and trying to do openttd's rendering pipeline on them doesnt work
19:19<Flygon>Due to the fact that they clearly use functions that would've been great in the 90s, but now require (incredibly slow) software rendering
19:19<Diablo-D3>worst case, it will flush a shadow framebuffer to the screen on every blit
19:19<Flygon>eg. making the screen all wavey by offsetting individual scanlines by x amount
19:19<Diablo-D3>Flygon: no
19:19<Diablo-D3>you can still do that in hardware
19:19<Flygon>You can?
19:19<Diablo-D3>write a pixel shader for it.
19:19<Diablo-D3>thats what you got in exchange
19:19<Flygon>Was that possible in 1999?
19:19<Diablo-D3>_specific_ methods are gone
19:19<Diablo-D3>but its all generic hardware now
19:20<Flygon>=/ I still feel that it shouldn't be so slow for a game written in 1999-2001 to execute an effect on a 2015 PC that it could on a 1999 PC
19:20<Diablo-D3>ANYTHING you did in the old days can be done now
19:20<Diablo-D3>Flygon: its because they're all badly software emulated effects
19:20<Flygon>It CAN be done now. But the software has to be rewritten for it.
19:20<Diablo-D3>you can _correctly_ software emulate them
19:21<Diablo-D3>the thing is, those old effects? were a dumb thing to do
19:21<Diablo-D3>they abused the hardware to do it
19:21<Diablo-D3>you CAN do it now, in hardware, just by rendering to a texture, uploading the texture, and then using a shader on it.
19:21<Flygon>It seemed like a good idea at the time :P
19:21<Flygon>Again, I'm probably seeing this from a weird perspective
19:21<Flygon>My friends and I tend to work on Mega Drive related stuff
19:22<Diablo-D3>yeah, see
19:22<Diablo-D3>consoles are different
19:22<Diablo-D3>you were MEANT to abuse the hardware
19:22<Flygon>Which had all sorts of neat hardware functions related to the background
19:22<Flygon>HScroll related ones being... well, bread and butter
19:22<Diablo-D3>because you knew exactly what the chip was, and all genesises were the same hardware
19:22<Diablo-D3>but PCs are different
19:22<Diablo-D3>always at least 3 different manufs doing hardware differently
19:22<Flygon>Hence my confusion it could break so absurdly on a modern PC, despite older ones accepting it and rendering it 30fps+ no problem
19:22<Diablo-D3>for every part in the PC
19:22<Flygon>Because it's just such a damn simple effect
19:23<Diablo-D3>Flygon: because, like I said, the hardware no longer works that way
19:23<Diablo-D3>and no one cares to fix it
19:23<Flygon>I know
19:23<Diablo-D3>older games literally should be handled in virtual hardware
19:23<Flygon>Part of the bafflement is, of course
19:23<Diablo-D3>and done entirely in software
19:23<Diablo-D3>and then the screen completely blitted every frame
19:23<Flygon>Is that emulating the effect in an emulator for older hardware is trivial
19:23<Diablo-D3>its 100% trivial
19:23<Diablo-D3>look at dos box
19:23<Flygon>But an application actually written for PC completely borks out
19:23<Diablo-D3>it emulates every trick VGA can do
19:24<Diablo-D3>even some of the most screwed up games run fine in dosbox
19:24<Flygon>Yeah, I'm quite a fan of DOSBox myself
19:24<Diablo-D3>the thing is
19:24<Diablo-D3>newer hardware, newer drivers, newer OSen
19:24<Flygon>...that reminds me, I should probably see how well YouTube handles 72fps
19:24<Diablo-D3>just dont give a fuck about backwards compat
19:24-!-Pikka [] has joined #openttd
19:25<Diablo-D3>the only way to get old code running on new hardware is to port it like it was an entirely new platform... because it IS an entirely new platform
19:25<Flygon>The sad thing is, the first time I really saw modern hardware was cutting some features I'dve considered quit trivial... was actually a Mega Drive emulator for the DS
19:25<Diablo-D3>well thats the thing Flygon
19:25<Diablo-D3>ANY trick
19:25<Diablo-D3>can be done on modern hardware
19:25<Diablo-D3>you just need to do it the way the modern hardware requires you to
19:26<Diablo-D3>either do it entirely in software, or do it in a pixel shader
19:26<Flygon>Long story short: Emulator basically did hardware emulation of the sprites and backgrounds. A fair few games used vertical column scrolling effects for... well, effects. But that wasn't actually possible on the DS... and probably not possible on the GBA either, because, the DS's 2D hardware is basically the GBA's up to 11. @_@
19:26<Diablo-D3>Flygon: the thing is, GPUs are now entirely software driven
19:27<Diablo-D3>theres virtually no fixed function left
19:27<Diablo-D3>and thats just the way it is
19:27<Flygon>iirc, when the guy got hired by Sega to code the emulator specifically for some sort of Sonic collection for the DS/DSi, he managed to fix that issue due to affecting S3K heavily.
19:27<Diablo-D3>to get maximum performance out of the hardware, thats what they had to do
19:27<Flygon>Hmm =/
19:27<Flygon>I understand why things've changed
19:27<Flygon>But... well, it bugs me
19:27<Diablo-D3>so yes, every little thing you used to do? could be emulated by the driver perfectly
19:27<Diablo-D3>it just doesnt.
19:27<Diablo-D3>because no one cares.
19:27<Diablo-D3>and if openttd wants 100% performance (since we're in #openttd and all)
19:28<Diablo-D3>it needs to seriously rewrite the rendering pipeline
19:28<Diablo-D3>there should be pretty much two things done every frane
19:29<Diablo-D3>blit surface used for sw rendering to screen, flip screen.
19:29<Flygon>O_o I never noticed OTTD's rendering was slow
19:29<Diablo-D3>its not
19:29<Diablo-D3>but people like planetmaker think it is
19:29<Flygon>I always just assumed it was due to me building a cocktillion amount of ships and using a CPU heavy pathfinder
19:29<Diablo-D3>so they keep trying to optimize in ways that dont make sense
19:29<Diablo-D3>Flygon: the thing is, even if it WAS slow, the entire thing could be written as an opengl bilboarding renderer
19:30<Flygon>Oh, man. When I first spoke to a guy about modern video rendering on PC's... the concept of billboards confused me
19:30<Flygon>Then I realized they make a fair bit of sense
19:30<Diablo-D3>bilboards in 2D space are sprites.
19:30<Diablo-D3>opengl nor d3d is a 3D api... its just an api that allows 3D.
19:31<Flygon>The real stupid thing is... is that I know a fair few Mega Drive games have managed to reimplement billboard-equivilants using hardware rendering because hurting brains is half the job :B
19:31<raincomplex>if anything, convert to sdl2
19:31<Diablo-D3>raincomplex: sdl2 doesnt magically do things.
19:32<raincomplex>what do you mean
19:32<Flygon>Such brainhurting things include the Road Rash series implementing scalable sprites as part of the background layer and making them work by abusing the hell out of h-int and v-int effects...
19:32<Diablo-D3>Flygon: oh christ that
19:32<Diablo-D3>yeah thats ugly as hell
19:32<Flygon>Yeah, but it worked :D
19:32<Flygon>I do kinda wonder why they didn't just make prescaled sprites
19:33<Flygon>It can'tve taken up THAT much VRAM...
19:33<Flygon>Then again, you also have buildings and the environment to render...
19:34<Flygon>The fact they managed to get over 15-20fps (assuming NTSC console, PAL rendered faster) most of the time is a bloody miracle
19:34<Diablo-D3>vram really isnt a concept anymore
19:34<Flygon>Given the entire game was basically softrendered
19:34<Diablo-D3>I cant imagine how much trouble they had on genesis and snes
19:34-!-itsatacoshop247_ [] has joined #openttd
19:34<Flygon>THe SNES was even more of a headache
19:35<Flygon>Transfer times to the video chip (and the SPC/soundchip too, incidentally) were painfully slow
19:35<raincomplex>what are you talking about vram isn't a concept
19:35<Flygon>Made porting things over from the Mega Drive a huge pain in the ass, apperantly
19:35<Diablo-D3>raincomplex: anymore. on modern hardware. as in, PCs.
19:36<raincomplex>games are constantly pushing the vram limits
19:36<Diablo-D3>raincomplex: textures are cached in memory
19:36<Diablo-D3>the actual texture pool can be far larger than the vram on the card
19:36<raincomplex>yeah but you need to push them through to the card if they fall out, which is way slower
19:36<Flygon>(though, games that made clones of Road Rash's engine such as Outlander had a far higher framerate. So Road Rash's quite lackluster frameright might be partially down to EA Games being... well, EA Games)
19:36-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:2096:d0be:8715:f653] has joined #openttd
19:37<Diablo-D3>raincomplex: a pci-e 3.0 x16 slot is 128gbit/sec
19:37<+glx>but sprite drawing and scrolling usually was done by hardware, not software
19:38<raincomplex>which at 60 fps can only handle 266mb/sec
19:38<raincomplex>i'm sorry, 266mb/frame
19:38<Diablo-D3>raincomplex: the r9 290x's memory bandwidth is 320.
19:39<Flygon>glx: Yeah. But you can't really scale sprites without prerendering the scaled sprites. If you lack enough VRAM, easier off just making sprites part of the background and abusing the hell out of the vint/hint functions
19:39<Flygon>Not that Road Rash was completely devoid of sprites
19:39<+glx>neogeo had this function in hardware ;)
19:39<Diablo-D3>neogeo was magic
19:39<Flygon>Just that anything that had to scale had to be done in software
19:40<Diablo-D3>the only game where 256MB roms were normal
19:40<Diablo-D3>er only platform
19:40<Flygon>I forgot, was Neo Geo scaling just one direction?
19:40<Flygon>Or both directions?
19:40<Flygon>Diablo: You forgot the 3/DS
19:40<Diablo-D3>Flygon: doesnt matter
19:40<Flygon>(as in, could you only zoom out, or zoom in from 100% too?)
19:40<+glx>from big to small IIRC
19:40<Flygon>I'm not as savvy on the Neo GEo
19:41<Flygon>Ah, right
19:41<Diablo-D3>faster bilinear is done in two stages
19:41<Diablo-D3>shrink/enlarge one way, shrink/enlarge the other way
19:41<Flygon>So if you wanted to have an object scale up on the Neo Geo, you had to first make it the maximum size then scale down?
19:41<Flygon>One thing I love about the Neo Geo btw
19:41<+glx>yes but the result was impressive :)
19:42<Flygon>Is that the VRAM (may's well be VROM) is accessed entirely from the cartridge
19:42-!-itsatacoshop247__ [] has quit [Ping timeout: 480 seconds]
19:42<Flygon>(also something I like about the NES/Famicom btw, that function being available)
19:42<+glx>neogeo is based from an arcade board
19:42<Flygon>No more loading sprites into the VRAM, just eat it up from the ROM quick as hell :D
19:43<+glx>NES had 2 roms on cartridge, program and sprites
19:44<Flygon>Couldn't it be just one unified ROM, as well as being seperate?
19:44<supermop>who wants to code a quick and dirty set of a few trams
19:44-!-itsatacoshop247_ [] has quit [Ping timeout: 480 seconds]
19:44<Flygon>And couldn't the NES/Famicom have RAM on the cart be directly read and written to by the PPU?
19:44<Pikka>pick me, pick me
19:45<Eddi|zuHause><Diablo-D3> Flygon: the thing is, even if it WAS slow, the entire thing could be written as an opengl bilboarding renderer <-- so where is your patch, and your profiling results that show it's at least not-slower than what there is currently?
19:45<+glx>probably not as the hardware managed the sprites
19:45<supermop>ill have some standardized (but no guarantee of good) renders in less than an hour
19:45<Diablo-D3>Eddi|zuHause: I said WAS slow
19:45<Diablo-D3>Eddi|zuHause: openttd doesnnt do enough rendering to be slow enough on modern hardware
19:45<Flygon>glx: Hmm... alright
19:46<Diablo-D3>Eddi|zuHause: so even if it IS using the slow path, its not slow enough
19:46<Flygon>Sorry, the NES/Famicom isn't my forete
19:46<Diablo-D3>Eddi|zuHause: it'd have to do millions of sprites to be an issue
19:46<Flygon>Kinda started from the Mega Drive and worked from there
19:46<supermop>images can be later subbed for renders of Melb trams, or generic , but are just silly/novelty for now
19:46<Eddi|zuHause>Diablo-D3: doesn't mean it couldn't be faster. but a lot of people just talk rubbish
19:46<+glx>I'm not a specialist either :)
19:46<Eddi|zuHause>Diablo-D3: just zoom out, you have plenty of sprites :p
19:46<Diablo-D3>Eddi|zuHause: the correct fix would be to do purely software rendering, and do two calls per frame, blit surface, and flip
19:47<Flygon>Either way... I do wish more of the consoles supported directly rendering the sprites from the ROM
19:47<Flygon>The Mega Drive could've used it. The SNES practically NEEDED it.
19:47<Eddi|zuHause>Diablo-D3: that's basically what it already does
19:47<Diablo-D3>Eddi|zuHause: but last time I suggested that, I got banned from here
19:47<Diablo-D3>Eddi|zuHause: so w/e
19:47<Eddi|zuHause>Diablo-D3: don't do suggestions. do patches.
19:47<Flygon>I cannot emphasise enough how crippling the SNES's slow transfer times from ROM to RAM is
19:48<Diablo-D3>Eddi|zuHause: last time I was interested in doing a patch, I was banned the previous time before that
19:48<+glx>but SNES had mode 7 and it was nice to see on screen :)
19:48<Diablo-D3>Eddi|zuHause: so screw it, Im not coding for openttd
19:48<Diablo-D3>even if the fix is trivial
19:48<Flygon>Almost all devs being forced to use the standard SPC sound driver was also stupid
19:48<Eddi|zuHause>Diablo-D3: then why bother us?
19:48<Flygon>It made streaming audio from the ROM utterly impossible
19:48<Diablo-D3>Eddi|zuHause: I want the mouse locking issue fixed
19:49<Diablo-D3>Eddi|zuHause: currently openttd is unusable on windows on multiple monitors because it doesnt lock the cursor
19:49<Eddi|zuHause>and you were told how to go about doing that
19:49<Flygon>It's an incredibly stupid situation when the Mega Drive has an easier time streaming multi-channel PCM audio from the ROM, than the SNES
19:49<Diablo-D3>Eddi|zuHause: yes, file a bug ticket that will never be fixed
19:49<Flygon>Desite how utterly crippled the DAC is on the SMD
19:49<Diablo-D3>Eddi|zuHause: Ive already accepted the fact it wont be fixed, so Im now looking for a program that fixes it in broken games
19:49<Eddi|zuHause>well, certainly ranting about unrelated stuff in the middle of the night will fix it.
19:50<Diablo-D3>its 8pm.
19:50<+glx>using a dedicated CPU helped for that I think
19:50<Diablo-D3>it is hardly the middle of the night.
19:50<Diablo-D3>Flygon: to be fair, the SPC _is_ its own DSP
19:50<Diablo-D3>Flygon: and someone even wrote a sid emulator for the spc.
19:50<Eddi|zuHause>it's 2am
19:50<Eddi|zuHause>doesn't get much more middle-of-night.
19:50<Diablo-D3>Eddi|zuHause: the only time zone I recognize is the one Im in.
19:50<Flygon>Diablo: Modern hardware isn't forced to use standard SPC driver anymore :)
19:50<Flygon>Modern SPC drivers are quite incredble, given what they have to deal with
19:50<Eddi|zuHause>good luck finding a developer in that timezone.
19:51<Flygon>Basically... the situation in the 90s was
19:51<Diablo-D3>Eddi|zuHause: great news! Im a developer!
19:51<Eddi|zuHause>no, you're not.
19:51<+glx>I guess on MD you can do whatever you want with the z80
19:51<Flygon>The Mega Drive was allowed to stream audio into a buffer then play it, software mixing if you had a reeaaallly good sound driver guy
19:51<Eddi|zuHause>you just said you won't code in openttd.
19:51<Flygon>But Nintendo's default SPC driver only let sound play on the SPC after everything was written and set in stone...
19:52<Eddi|zuHause>that's kind of a prerequesite of being a developer
19:52<Diablo-D3>Eddi|zuHause: no, I wont submit patches because Ive gotten banned for discussing me patching behavior in the past
19:52<Flygon>So it wasn't like you could set up the audio buffer arragement the Mega Drive had
19:52<Diablo-D3>Flygon: theres a difference
19:52<Flygon>This utterly cripped the SPC's ability to use RAM efficiently
19:52<Diablo-D3>Flygon: the SPC700 had its own ram and was its own mixer
19:52<Flygon>And buggered games that relied on streaming audio to save audio RAM
19:52<+glx>it was possible to use custom SPC driver I think
19:52<Diablo-D3>Flygon: and nothing stopped you from swapping out samples during program execution
19:52<+glx>but noone really wanted to write its own
19:53<Flygon>glx: Last I heard, Nintendo never allowed it except for several Japanese devs
19:53<Eddi|zuHause>Diablo-D3: for the record, i totally understand why that happened.
19:53<Diablo-D3>Flygon: zombies ate my neighbors was rather masterful on how it manipulated the spc700
19:53<Flygon>Diablo: Technically there was nothing wrong with doing that with the default SPC driver. It's a shame the transfer times with said driver was inredibly slow.
19:53<Diablo-D3>its not that it was slow in as much as the timing was very controlled
19:53<Flygon>I know a few Japanese games were allowed custom drivers with much faster sample transfers, however
19:53<Diablo-D3>you had a very small window in which to transfer data
19:53<Flygon>As well as a few other features
19:54<Diablo-D3>also whats with nintendo and crippling hardware
19:54<Diablo-D3>n64 had that whole sgi firmware issue
19:54<Flygon>I just put it down to the Japanese being Japanese
19:54<Diablo-D3>nintendo refused to pay for the good firmware because it'd increase the cost of the n64 a tiny smidgen
19:54<Diablo-D3>thus causing the n64 to be a pile of shit
19:54<Flygon>The Mega Drive did also has some asinine software control practices btw
19:55<Flygon>And some utterly incredibly stupid hardware design decisions
19:55<Diablo-D3>and the only games that fixed it were rouge squadron and that episode 1 popdracing game
19:55<Flygon>Such as somehow forgetting to connect an interrupt line from the Z80 to the YM2612's DAC
19:55<Diablo-D3>Flygon: wat.
19:55<Flygon>Which makes multichannel PCM a huuuuuuuuuuuuuge pain in the ass
19:55<Flygon>I'm serious
19:55<Diablo-D3>in during gams using pcm for drums.
19:55<+glx>oups :)
19:55<supermop>ok make it 2 hours, i have to get lunch
19:56<supermop>should i pm these renders or what?
19:56<Diablo-D3>Eddi|zuHause: I dunno man, I was willing to look into how to make openttd maps have more height
19:56<Flygon>It would've been like
19:56<Flygon>A 50c fix per Mega Drive in the initial production runs
19:56<Diablo-D3>Eddi|zuHause: but no one was interested in it because "it'd break existing shit"
19:56<Flygon>Just add a wire from the Z80 to the YM, and it's fixed
19:56<Diablo-D3>Eddi|zuHause: and I got banned for it
19:56<Diablo-D3>so fuck that
19:56<Flygon>And ensure all future production runs are fixed
19:56<Flygon>But nope. Sega borked the Mega Drive permanantly D:
19:57<Flygon> We could've had 8 channel .mod players for the Mega Drive if we had that interrupt line D:
19:57<Diablo-D3>Flygon: sega was just fucking retarded a lot of places
19:57<Diablo-D3>like, segacd? srsly? 32x? srsly?
19:57<Flygon>The Sega CD, in my opinion
19:57<Flygon>Was actually pretty good
19:57<Diablo-D3>and then decided, hey, lets plug the segacd into the 32x
19:57<Diablo-D3>and upgrade it a little bit
19:57<Flygon>The 32x has no excuse though
19:57<Diablo-D3>BOOM saturn
19:58<Diablo-D3>they didnt pull their heads out of their ass until the dreamcast
19:58<Flygon>The Saturn's not really anything like the Mega Drive
19:58<Diablo-D3>and by then it was too late
19:58<Diablo-D3>Flygon: no, the saturn is a LOT like the 32x
19:58<Flygon>It's their first mainline console not at all derived from the SG-1000
19:58<Flygon>The Saturn and 32x share having two SH-2's
19:58<Flygon>But the 32x worked entirely in softrendering
19:58<Flygon>The Saturn did hardware quad rendering
19:59<Diablo-D3>32x and saturn are dual sh2s, the saturn dragged in a minature version of the sega 3D arcade game thing's gpu
19:59<Flygon>The Saturn didn't have an entire Mega Drive in the background to help assist it, the 32x did
19:59<+glx>6-button controller reading is silly ;)
19:59<Diablo-D3>absolutely nothing in the saturn was new
19:59<Flygon>(if it's 2D on the 32x, it's probably rendered by the Mega Drive)
19:59<+glx>yeah let's play with the control line
19:59<Diablo-D3>Flygon: no 32x game used the genesis hardware, even though it could
19:59<Diablo-D3>except chaotix
19:59<Flygon>Plenty of 32x games used the Mega Drive hardware
19:59<Diablo-D3>not from what I heard
19:59<Flygon>It saved time rendering into the buffer
19:59<Flygon>Tempo, Pitfall...
20:00<Diablo-D3>there were 32x games other than chaotix?
20:00<Flygon>There's a few more examples too, but those two come to mind as abusing the hell out of the Mega Drive hardware
20:00<Pikka>supermop, where are these trams then?
20:00<Flygon>The 32x did have a good idea in mind... in theory
20:00<Flygon>You COULD be developing a Mega Drive game
20:00<Flygon>Then convert it to use the 32x hardware
20:00<Flygon>In reality, that was incredibly difficult to do
20:01<Flygon>But there is already PoC's made by the hacking community. eg. Sonic 1 for 32x
20:01<Diablo-D3>Flygon: well
20:01<Diablo-D3>no one even used 32x or saturn correctly
20:01<Diablo-D3>because they were both dual sh2s
20:01<Diablo-D3>and not in the nice and friendly SMP way
20:02<Eddi|zuHause><Diablo-D3> Eddi|zuHause: and I got banned for it <-- ok, i let you your belief that that's what actually happened.
20:03<Diablo-D3>Eddi|zuHause: patch was half done, I nuked it afterwards
20:03<Diablo-D3>so, your loss.
20:03<Flygon>Diablo: I'd still say the 32x was more painful to work with
20:03<Flygon>Want to make a Sega CD 32x application?
20:03<Diablo-D3>Flygon: no such thing.
20:03<Flygon>Have fun working with 5 CPUs and 3 CPU archiatectures at once :D
20:03<Diablo-D3>Flygon: a 32x segacd game is called a saturn game.
20:03<Flygon>No, it was called a 32xCD game
20:03<Flygon>And they actually exist
20:04<Flygon>I'm serious
20:04<Flygon>They were all FMV games tho
20:04<Diablo-D3>name one commercially sold title in the US that did that
20:04<Flygon>They basicaly streamed from the CD, and used the 32x to decode the video then render to framebuffer
20:05<Flygon>To copypasta
20:05<Flygon>Corpse Killer
20:05<Flygon>Night Trap
20:05<Flygon>Slam City with Scottie Pippen
20:05<Flygon>Surgical Strike (Brazil only)
20:05<Flygon>Supreme Warrior
20:06<supermop>Pikka: being rendered in flamingo on my computer right now?
20:06<Flygon>But... yeah
20:06<Flygon>The Sega CD was far more elevant
20:06<supermop>they are not trams per se
20:06<Flygon>It had it's own framebuffer that could transfer tiles to the Mega Drive's VDP
20:06<Flygon>But far more usefully
20:07<supermop>i wanted to make some blocks with the dimensions of the various parts of melbourne trams as place holders
20:07<Flygon>Calculate stuff to, essentially, give the Mega Drive far more efficient use of it's hint/vint functions
20:07<Flygon>Mode 7 on the Mega Drive is trivial and all...
20:07<Flygon> just need good enough use of CPU power :D
20:07<supermop>but then last night i was thinking, may as well make the blocks a little interesting
20:08<supermop>so they are... things
20:08<Pikka>"things". fair enough :)
20:09<supermop>should the background of a 32bpp sprite me clear or solid color?
20:09<Pikka>alpha masked
20:11<Eddi|zuHause><Diablo-D3> Eddi|zuHause: patch was half done, I nuked it afterwards <-- so how do you explain this line then? [Mittwoch, 16. Juli 2014] [21:57:53] <Diablo-D3> frosch123: well, I refuse to do c++
20:12<Diablo-D3>[08:05:08] <Flygon> To copypasta
20:12<Diablo-D3>Flygon: I suspect none of those were licensed titles.
20:12<Flygon>They were all licensed
20:13-!-liq3 [] has joined #openttd
20:13<Diablo-D3>Slam City is a basketball game, rendered entirely with full motion video. The player has to gain enough "respect" to play against Scottie Pippen. It was a very large game, distributed over four separate discs.
20:14<Flygon>90s video codecs were extremely inefficient
20:14<Flygon>And Sega pressed 500mbyte Sega CD discs for some reason
20:14<Flygon>Despite the console having reliably read 750mb ones no problem
20:14<Flygon>Though, 700 is the highest anyone can get anymore
20:15<Flygon>So, yeah
20:15<Flygon>The game was 2 gigabytes of cinepak :U
20:15<Diablo-D3>and then we have 99 minute CDs
20:15<Diablo-D3>or 870mb
20:15<Diablo-D3>which nothing supports sanely
20:15<Flygon>Nothing? As in
20:15<Flygon>Refuses to read?
20:15<Flygon>Dreamcast might read it :B
20:16<Diablo-D3>its really spotty
20:17<Diablo-D3>and some of the most randomest shit will play them
20:17<Diablo-D3>like really old CD players will because they dont know any better
20:17<Flygon>Probably works in the Sega CD then
20:17<Flygon>The thing just reads whatever it's given
20:17-!-Biolunar [] has joined #openttd
20:17<Flygon>Unfortunately, since it reads whatever it's given
20:17<Flygon>It's error correcting isn't fantasy
20:17<Flygon>1x CD ROM drive =/
20:17<Diablo-D3>lol error correcting on a cd
20:18<Flygon>This means you can't stream Redbook and Data at same tie
20:18<Flygon>isn't fantastic*
20:18<Flygon>same time*
20:18<Flygon>Ehh, streaming the audio isn't really necessary on the Sega CD anyway
20:19<Flygon>I mean, you got the YM2612, the PSG, and the Sega CD's bloody Ricoh chip
20:19<Diablo-D3>yeah but it was free
20:19<Flygon>You basically have the early 90s most powerful sound hardware right there
20:19<Flygon>I'd argue the Sega CD's even better at handling sound than the Saturn if used right
20:21<supermop>i wonder if its worth my time to render a glowing vacuum tube
20:21<Flygon>A SCD track taking full advantage of the hardware of both consoles will be really difficult to replicate on the Saturn (chances are, the FM won't sound right, and to make FM channels on the Saturn, you need to sacrafice PCM channels... 4 op FM means 4 PCM channels used. There's only 32 channels)
20:22<Flygon>But the Sega CD won't be able to handle a track taking full advantage of the Saturn at all
20:26<supermop>should i bother setting up lighting yet?
20:28*Flygon goes for a walk. Good luck supermop. :3
20:31<Pikka>it's worth the time if you want to do it...
20:36<supermop>ok most of the rigging done, going to head to footscray for lunch
20:36<supermop>will pm renders when i get home
21:37-!-quorzom [] has quit [Read error: Connection reset by peer]
21:51-!-gnu_jj [] has joined #openttd
21:51-!-itsatacoshop247 [~itsatacos@2601:9:1180:237:2096:d0be:8715:f653] has quit [Ping timeout: 480 seconds]
22:03-!-Biolunar_ [] has joined #openttd
22:06-!-Pereba [~UserNick@] has quit [Quit: AdiIRC - if you don't try it, you can't tell me it sucks. (]
22:10-!-Biolunar [] has quit [Ping timeout: 480 seconds]
22:16-!-itsatacoshop247 [] has joined #openttd
22:48-!-glx [] has quit [Quit: Bye]
22:58<supermop>banh mi was good as always
23:00<supermop>how many px wide is a tile at 4x? 128?
23:01<Pikka>256, or thereabouts
---Logclosed Mon Feb 09 00:00:05 2015