animation for standard terrain tiles

[Yankes]

First impression is good, its hard to say exactly because you move camera to much around, but overall it seem it will not require random offset.
Where I could get working version of this?

[ivandogovich]

https://www.youtube.com/watch?v=DgBrmUp3k9Y&feature=youtu.be

That looks pretty good.  It doesn't look really synched at all.

[bladum]

actually this is simple random offset. I used LightBlock MCD data to determine if tile is using this feature or not ;-) now you can kill me he

[bladum]

regardless of does it work nice or not we need GFX person to actually nice update the sprites.

@robin ?

[volutar]

So it's not synched. And thus looking rather good.
But using actual value "light block" is really bad idea.
We (developers) will not support this ever.
And it's obvious 2 frames is not enough.

[bladum]

@volutar

Actually there is no way to add new flag to MCD file to be backwards compatible and "block light" is never used anyway. If this is going to be used in TFTD then of course it cannot be used for this feature. But block light was never used in vanilla neither. So there is no point not to use it for something else, unless you plan to use it. I can find a way to calculate it somehow on the fly without need to use "block light flag" (if not door, if not special tile etc) but it could be not error proof this way.

Btw how you calculated that 2 frames are not enough ? On which objective measures you make it "obvious" ? I am very curious. 

[volutar]

@volutar

Actually there is no way to add new flag to MCD file to be backwards compatible and "block light" is never used anyway.

Wrong. Wrong.
byte38 will work nicely. It's not used and not even referenced. While BlockLight is referenced and _almost_ used in vanilla and was used in the oxc (Daiky has made a version using it, and code is still there, and it might be used later).
You can make your own version with blocklight used for that, but it will never be merged into master. While byte38 could.

Blocklight is actually filled with different values, and in order not to screw any vanilla animation you'll have to change every animated MCD to make them rendered synched (by default). Which is, well, quite off.

Btw how you calculated that 2 frames are not enough ? On which objective measures you make it "obvious" ? I am very curious.

Because any animation consisting of 2 frames is just perceived as SWITCH, while 3 framed animation can be rendered seamlessly.

[bladum]

1) ok i see now, byte38 is ok but cannot be accessed via MCD editor. Do you plan to update it in the future to support all bytes in MCD ?

2) that is a good point ! is it better to have 4 frames as it can be better put into 8 frames instead of 3 ? (3 + 3 + 2 ?)

PS: i am only interested in master compatibility

[volutar]

1. It already supports. You should just edit MCDEdit.txt
add in the list:

Code: [Select]

mcd 38 byte Stat_Phase | If 0 - animation starting phase is random, otherwise - static (started from 0).This field according ufopaedia is filled with 3. always. I don't know why.
2. 4 is better, but 3 could be enough in some cases.
You can ask Robin, I bet he knows about optimal minimum better.

[bladum]

thanks, now you are talking hope warboy will accept the pull

[volutar]

Actually it's better to use "1" as "random" since "3" is default vanilla value used for byte38, but any custom MCDs might have 0 (for example made with my mcdedit, or any other editor). So 0 and 3 are "default", and "1" will work as "random" just fine. 3 or 4 frames of animated wheat, and trees, and picture will look much more dynamic.

[bladum]

Work is done. No changes to standard tiles that use animation like doors or power sources. Will pull request. Bit 38 is used with 0,1 and 3 values.

Still need someone to improve tiles like grass / wheat / trees etc...

btw: i think we could use special feature in MCD Editor that would work like this. This could be used for this feature even without graphic skills.

1) select pixels with specific colors
2) click new button "randomize"
3) each pixel has light color randomly choose with 30% -1 to lightness, 30% +1 to lightness and 40% no change to lightness.

This would allow to create noisy textures from large flat areas of the same color. What do you think ?

[volutar]

MCDEdit requests are in another place I think. But I could answer here.
This "add random noise" is a quite common thing for graphics editors. But it starting whole new editor section: Filters. Need to collect all really __useful__ filters, used by pixel artists, before starting that.

But.

Considering the topic, this "random noise" is not something that could work for wind or anything else. It really won't make sprites look any good. Pixel artists need to control each pixel value, without any "randomness". If you want to me to add this to MCDEditor, just make quick ugly "animation", I won't connive at this. Sorry, MCDEdit is not for "quick requests". If you want to make every tile noised - you can make "flat" animation, export these expanded sheets as pngs, edit them in any editor with this "noise", and import.

[jackstraw2323]

Just from an art direction point of view, there's probably a limit to how many tiles should be animated at one time. I.E. if every tile seen is animated it might look like too much visual noise, but something like 50%-25% of tiles would probably be a comfortable range. I do think seeing a whole field of wheat animate would be a really nice touch. I'm just starting to get into mcd and maps so I may contribute a few tiles once I understand what's required.

[volutar]

Just from an art direction point of view, there's probably a limit to how many tiles should be animated at one time. I.E. if every tile seen is animated it might look like too much visual noise, but something like 50%-25% of tiles would probably be a comfortable range.

When screen is filled with smoke it really looks bad. And that kind of thing doesn't really look good as LP or any recorded video. I would say that 1/3 of a visible battlescape is a pretty comfort value.