IRC logs for #openttd on OFTC at 2024-12-06
⏴ go to previous day
01:22:06 *** speeder__ has quit IRC (Ping timeout: 480 seconds)
02:32:41 *** ChanServ sets mode: +v tokai
02:39:33 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
03:00:27 *** speeder__ has joined #openttd
03:17:13 *** Wormnest has quit IRC (Quit: Leaving)
03:19:51 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:55:49 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:57:32 *** D-HUND is now known as debdog
04:46:00 <DorpsGek> - Update: Translations from eints (by translators)
06:59:06 *** speeder__ has quit IRC (Remote host closed the connection)
07:00:19 *** keikoz has quit IRC (Ping timeout: 480 seconds)
09:19:21 <peter1138> Yes, I am definitely losing it. I wanted to say Morning.
09:24:59 <mnhebi> Thats just the middle age dementia setting in.
09:27:11 <andythenorth> what are we doing today?
09:28:54 <peter1138> Breaking everything.
09:30:44 <andythenorth> doing management
09:33:55 <mnhebi> peter1138: oh, are we finally getting freeform tunnels and bridges? :p
09:34:28 <peter1138> I haven't redesigned the map enough for that.
09:36:17 <andythenorth> enuough for flat docks?
09:37:08 <mnhebi> doesn't sound like breaking everything then.
10:06:02 *** kuka_lie has joined #openttd
11:16:39 <xarick> my IncreaseGeneratingWorldProgress counting is a bit off
11:19:39 <xarick> 9 counts, it should be 12 😐
11:38:05 <LordAro> i think there's a typo in that title :p
11:40:09 <peter1138> constructor destructors
11:40:36 <peter1138> Urgh, so much code duplication 😦
11:41:15 <peter1138> Not 100% the same but... nearly.
12:04:00 <peter1138> Always fun when linking code manages to execute.
12:04:33 <peter1138> Hmm, might be a utility being called I guess.
12:11:11 <xarick> once again i fail at boolean logic
12:21:56 <xarick> times got worse because of my failure
12:22:40 <kuka_lie> i am going to run openttd on really slow hardware (windows xp time celerons) what is best way to run it? can i just use tty and use startx /user/bin/openttd to start that program? what disro should i use?
12:25:01 <kuka_lie> i will have like 5 computers and all will be connected to same server for multiplayer
12:30:49 <LordAro> kuka_lie: ottd runs at the speed of the slowest computer
12:32:13 <kuhnovic> And you might want to consider running headless if it's just a server
12:32:27 <xarick> if the server is a fast system, the slow clients might struggle?
12:33:27 <LordAro> xarick: there's a threshold where they just end up getting kicked
12:41:44 <andythenorth> hmm all out of larks
12:41:48 <andythenorth> fishfingers and chips
12:45:23 <kuka_lie> server might be quite fast (1st gen i3)
12:47:17 <kuka_lie> i think i put those computers that way that them has no gui but in .bashrc i put "startx /usr/bin/openttd"
12:47:58 <kuka_lie> i will try first in vm if it works
12:52:02 <kuka_lie> stating it with startx works so i will use it
12:57:09 <LordAro> `openttd -D` will start headless
13:03:07 <kuka_lie> but i dont understand 2.1 "connecting server over the console" what console that means?
13:05:24 <kuka_lie> ok now i understand it thanks
13:54:46 <xarick> time to measure memory usage
13:55:59 <kuka_lie> have like 256 mb of ram
13:57:18 <kuka_lie> i have to check someday how much ram those have. without installing gui it might work with openttd
13:57:27 <xarick> 9107369 * 4 + 1008561 * 4 + 2091171 * (4 + 4) =
13:57:41 <LordAro> kuka_lie: you may assume xarick is doing his own thing
13:58:28 <kuka_lie> openttd is written in c so it should be efficent, right?
13:58:49 <LordAro> there is no correlation between those two things
13:59:04 <xarick> I am making it inefficient
14:00:05 <kuka_lie> if it would be done with javascript it would need supercomputer to run
14:00:31 <LordAro> OTTD can run in the browser just fine
14:00:57 <LordAro> not quite as fast perhaps, but the majority is just fine
14:01:02 <peter1138> kuka_lie: C++, not C.
14:01:16 <kuka_lie> peter1138: almost same thing
14:01:57 <LordAro> just two characters different
14:02:36 <kuka_lie> btw is js just bad at perfomance or have i just used only badly done stuff
14:03:15 <xarick> 57 MB just for setting tropiczones, vs 596 bytes with a single table
14:04:33 <kuka_lie> i used intel core 2 duo and in web browsing and all js pages make cpu go like 100%
14:05:09 <_glx_> modern browser or C2D time browser ?
14:06:42 <xarick> there are no towns at this phase, nor industries, and these 57 MB are temporary, then they poof
14:07:07 <xarick> how much memory would 13k towns and 20k industries take?
14:09:25 <xarick> from 5,1 seconds to 0,4 seconds, so much gains...
14:11:01 <xarick> hmm, i'm gonna try use less memory somehow, still looking at it
14:13:02 <mnhebi> What C++ gains in efficiency it gives away double in sanity :(
14:13:49 *** virtualrandomnumber has joined #openttd
14:14:13 <peter1138> xarick: That is a small fraction of map gen time, it's basically irrelevant.
14:14:19 *** virtualrandomnumber has quit IRC ()
14:15:26 <xarick> well goes from a complete map time gen of 32 seconds to 27 seconds
14:15:47 <_glx_> yeah try generate a huge map with very high number of towns and the worst townname generator 🙂
14:19:39 <kuka_lie> i always use funny english town names
14:21:12 <xarick> hmm one way would be iterating the whole map looking for desert tiles, it would save... 9107369 * 4 memory
14:22:19 <peter1138> By "one way" do you mean "the current way"?
14:22:45 <xarick> current way is very brute force
14:23:18 <xarick> current way: for every tile in the map, look at 149 nearby tiles to decide if we make it a desert
14:24:58 <xarick> and the next tile will look at 149 tiles, most of them overlapping
14:24:59 <peter1138> If the algorithm was smart it would be able to take the previous result into account.
14:25:30 <peter1138> And only check the tiles that the new tiles that are covered.
14:26:56 <peter1138> You'd need to store the state of each those 149 tiles to be able to ignore the tiles that are no longer covered.
14:34:20 <xarick> i'm looking at phase 1 again
14:35:49 <xarick> i could maybe "assume" desert density to be 3 in that phase
14:36:51 <xarick> then phase 2, which eats desert away could perhaps look for an adjacent desert tile when placing normal tiles and assume desert density to 1
14:38:21 <xarick> should eliminate the need of desert_tiles vector
14:38:32 <xarick> which is 9 million tiles
14:40:29 <xarick> or it could be done in phase 3, which works with normal_tiles
14:40:54 <xarick> any adjacent tile which is desert gets its density 1
14:41:03 <andythenorth> did I used to make grfs? 😛
14:53:51 <LordAro> i feel like someone would've noticed
15:06:21 <xarick> mark tile dirty by tile is not cheap 😦
15:09:15 <peter1138> FIRS knows about that.
15:09:52 <mnhebi> andythenorth: what, need a statue 3d printed so you'll remember? :)
15:10:18 <andythenorth> I fell in some kind of grf hole 😛
15:10:43 <mnhebi> still waiting for someone to make a ship grf with triremes and stuff.
15:11:03 <mnhebi> start in 0 AD with your company xD
15:23:53 <FLHerne> kuka_lie: you can play OpenTTD version 1.2 on a 166MHz processor with 64MB of RAM
15:23:59 <FLHerne> I know because I did for a while :p
15:52:56 <xarick> why is MarkTileDirtyByTile slow :(?
15:53:07 <LordAro> because it does things
15:56:40 <xarick> mark whole screen dirty might be cheaper
15:57:47 <xarick> if I don't mark tiles dirty 😦
15:59:36 <xarick> 6,264629 s, new record low time for debug build
15:59:49 <xarick> but that's without dirtying tiles 😦
16:01:50 <kuhnovic> Elapsed time is irrelevant
16:04:36 <xarick> 18,828627 s when using dirtying tiles
16:05:24 <xarick> lemme experiment whole screen dirty
16:09:56 <xarick> whole screen dirty between progress updates it is then
16:17:13 <xarick> oh, I removed 4 steps, need to re-add them somewhere
16:21:59 *** squirejames has joined #openttd
16:21:59 <squirejames> peter1138: Chris Meier's CivliOTTD
16:22:30 <squirejames> (Sid Sawyer's OpenTransportisation)
17:22:33 <xarick> let me count memory usage
17:28:37 <xarick> hmm where can I extract more performance now?
17:45:46 <xarick> hmmm how do I decipher this?
18:04:09 <xarick> can't think of more ways to optimize this
18:04:35 <xarick> well, there's the deque/pop option still
18:27:40 *** Flygon has quit IRC (Read error: Connection reset by peer)
18:42:31 <peter1138> Crap, now Someone™ needs to fiddle with grfcodec and NML 😉
18:51:12 <xarick> deque/pop is slower 😦 only advantage is clearing memory as it goes
18:52:08 <xarick> is there a pop for vectors?
18:54:26 <xarick> hmm from the back, might give it a try
18:55:08 <peter1138> Hmm, some left over reinterprets.
18:59:34 <andythenorth> lol all the phones here just Amber Alerted
19:10:04 <andythenorth> I should add nml constants files to grfs instead?
19:31:09 <peter1138> Funky instructions...
19:40:58 <soylent_cow[m]> ^^^^^^ i have this town, it like got everything, but it's stuck at about 15,000 forever now, how come it's not expanding? it just wobbles around that pop value for many realtime days. is this something having to do with road layout?
20:03:51 <xarick> vector pop back is the fastest, but also has the most differences 😦
20:05:43 <peter1138> Do you ... understand want a 'pop' means here?
20:07:25 <xarick> ```while (!rainforest_queue.empty()) {
20:07:25 <xarick> const auto [rainforest_tile, tile] = rainforest_queue.back();
20:07:25 <xarick> rainforest_queue.pop_back();```
20:23:03 *** gelignite has joined #openttd
20:26:30 *** wallabra has joined #openttd
20:35:55 <xarick> in some edges, the normal tiles buffer is almost non-existant
20:36:10 <xarick> vector pop back is bad confirmed
20:38:29 <xarick> i could attempt to add the tiles in reverse
20:42:25 *** kuka_lie has quit IRC (Quit: i go to watch movie)
20:48:52 <peter1138> Yeah, river and industry generation dwarfs desert/tropical zones.
21:08:30 <xarick> I have another alternative up my sleeve
21:09:04 <xarick> but it involves keeping the table
21:09:31 <xarick> (or replacing with the circle algorithm if removing it is the goal)
21:29:41 <xarick> seems worth the sacrifice
21:31:50 <xarick> that slim line of tiles around desert_tropic_line really shaved a ton of time
21:32:16 <xarick> the circle method was taking 80 seconds in debug previously and 3,8s in release
21:55:37 <Rubidium> no, it's rather time for breakfast ;)
22:05:30 <xarick> I introduced now the circle:)
22:05:47 <xarick> replaces usage of DistanceSquare/DistanceMax
22:06:04 <xarick> ah, let me update the times
22:16:01 <xarick> I think I'm done with it
22:16:46 <xarick> or maybe tomorrow I'll set it to ready, i might come up with some new ideas over sleep
22:33:53 <xarick> there's little of locosage in it now, but it served as inspiration anyway. His magic was on the pair of tileindexes and the walking neighbours
22:47:04 <xarick> what kind of int's do i use there?
22:50:28 <xarick> static const auto circle_offset_of_radius = [](int16_t r, int32_t r2) {
23:15:53 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:29:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:55:38 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:59:40 <peter1138> [1] = 0x004c0024003b004a ""
23:59:46 <peter1138> This pointer is sus.
continue to next day ⏵
