IRC logs for #openttd on OFTC at 2020-07-20
⏴ go to previous day
05:04:31 *** Gustavo6046 has joined #openttd
06:38:00 *** WormnestAndroid has quit IRC
06:39:50 *** WormnestAndroid has joined #openttd
06:39:52 *** WormnestAndroid has quit IRC
06:42:00 *** WormnestAndroid has joined #openttd
06:43:48 *** WormnestAndroid has joined #openttd
08:28:08 <_dp_> I don't even see any attempts on handling that in the code
08:30:50 <LordAro> if it's not been reported, assume it's not known
08:32:46 *** WormnestAndroid has quit IRC
08:32:59 *** WormnestAndroid has joined #openttd
08:37:10 <_dp_> LordAro, I'm not sure there is even any point reporting it, it's quite tricky to handle correctly so if no one though if it when implementing the feature who's going to do that now?
08:37:46 <_dp_> you need to somehow know what objects use what tiles and make a graph of some sort
08:40:45 <_dp_> well, or update 15x15 area on every change...
08:55:12 *** Lejving has joined #openttd
08:58:03 <Eddi|zuHause> _dp_: how would you even detect that the value changed?
08:58:36 <Eddi|zuHause> _dp_: i'd file that under "newgrf bug" not under "code bug"
08:59:04 <Eddi|zuHause> _dp_: the newgrf could use animation state for that
08:59:54 <Eddi|zuHause> changing the animation state would trigger a proper redraw
09:04:58 <_dp_> Eddi|zuHause, well, grf is quite limited so technically there could be some sort of code analysis for it
09:05:31 <Eddi|zuHause> i don't think that's a good route to go
09:05:50 <_dp_> Eddi|zuHause, by "newgrf bug" you mean as a bug of a particular newgrf?
09:06:13 <_dp_> well, I'll be filing it to myself then xD
09:06:27 <Eddi|zuHause> like i said, go via animation state
09:06:33 <_dp_> I think it's a very good route but it's kinda late to go for it
09:07:00 <Eddi|zuHause> i.e. the graphical representation reads the animation state, instead of the nearby_whatever, and the animation callback instead reads nearby_whatever to set the state
09:07:54 <Eddi|zuHause> the graphical representation then changes properly in the tileloop
09:10:31 <_dp_> is animation stuff triggered without full animation checkbox?
09:13:28 <Eddi|zuHause> "full animation" is only palette stuff
09:14:04 <Eddi|zuHause> one of those hysterical misnomers
09:20:30 <_dp_> Eddi|zuHause, but won't using animation mean I'm redrawing every tile each animation frame?
09:21:03 <Eddi|zuHause> you don't have to change state every frame
09:21:25 <Eddi|zuHause> i'm pretty sure it redraws only if the state changes
09:22:15 <Eddi|zuHause> i've never worked with animation state myself
09:22:58 <_dp_> well, I guess I could play around with animation_speed but that still means having a callback every frame
09:24:14 <_dp_> though I guess just a callback isn't that big of an issue
09:24:41 <_dp_> still a lot of stuff to do for something that isn't even animated in a first place :p
09:29:00 <Eddi|zuHause> and the "periodic tile loop" trigger
09:29:55 <Eddi|zuHause> in the "animation triggers" property
09:32:40 <_dp_> yeah, that may also work...
09:33:02 <_dp_> can I have more than 253 frames though?
09:52:38 <Eddi|zuHause> what do you need that many frames for?
09:54:33 <Eddi|zuHause> if you need more than that, you need persistent storage, i guess
09:58:47 *** gelignite has joined #openttd
10:01:11 <_dp_> one tile has 256 states and is combined from 4 sprites
10:02:05 <Eddi|zuHause> i'm not seeing anything in that picture
10:02:39 <Eddi|zuHause> also, don't assume people have read everything written here
10:19:16 <_dp_> yellow stuff is an object with nearby detection
10:20:22 <_dp_> though I kind of screwed up with non-rectangular shapes so no idea how many frames I actually need
10:23:26 <Eddi|zuHause> i guess you should request for GRFv9 to untagle the animation callbacks so you can use the full 8 bits for referencing frames, and have the special start/stop values be outside the 8 bit range
10:24:50 <Eddi|zuHause> dunno if there's enough off-map infrastructure for ebjects to have persistent storage
14:32:49 *** gelignite has joined #openttd
14:50:07 *** WormnestAndroid has quit IRC
14:53:06 *** WormnestAndroid has joined #openttd
14:54:04 *** WormnestAndroid has joined #openttd
15:00:05 *** WormnestAndroid has joined #openttd
15:00:24 <_dp_> I think I'll give up on composing ground from 4 sprites: too fiddly and impractical for graphics.
15:00:43 <_dp_> Also noticed I only have 16 states anyway so 300 sprites isn't an issue
15:06:08 *** snail_UES_ has joined #openttd
16:11:13 *** tokai|noir has joined #openttd
16:11:13 *** ChanServ sets mode: +v tokai|noir
16:54:03 *** Wormnest has joined #openttd
18:43:14 *** frosch123 has joined #openttd
18:53:10 *** Progman has joined #openttd
19:32:10 *** gelignite has joined #openttd
19:34:54 *** HerzogDeXtEr has joined #openttd
20:25:36 *** b_jonas has joined #openttd
continue to next day ⏵
