[SUG][STYLES] Allow vertical resize of default water objects

[WillLem]

Right then... this sorts it out so that the top part of the animation is exactly as-is in the default, and the bubbles below (in the "resizable" section) animate such that they constantly rise until they "meet" the corresponding bubble in the original graphic.

The only caveat is that the resizable section has to be 16px tall in order to correspond exactly with the original graphic, i.e no bubbles "disappearing" on any frames. Any other height will result in an inconsistent animation, either in terms of 'presence of bubbles' or speed.

Note that, for demonstration purposes, I have recoloured the resizable part a darker shade of blue to illustrate exactly what's going on. This will of course be corrected in the final version of the graphic.

Let me know your thoughts, everyone. I won't proceed any further until I've had some feedback.

EDIT: forgot to change the trigger height this has now been done, please download the resizable water demo from here.

[namida]

So, for a graphic which is 20px tall (per frame), but has DEFAULT_HEIGHT_16 specified in the .nxmo, I understand that this will cause the graphic to appear 16px tall in-game (in order to preserve water objects in existing levels), but - will it appear as 20px tall or 16px tall in the editor (i.e. specifically at the point when drawn)?

You're overestimating how much the DEFAULT_HEIGHT parameter does.

It does exactly two things, and nothing more (and similar for DEFAULT_WIDTH):
1. When loading a level file that contains (for example) default:water, but does not specify a height for it, DEFAULT_HEIGHT is used for the height. (If DEFAULT_HEIGHT is set to whatever the old size was - in this case 16 - this will mean levels do not break - because they expect the water to be 16 tall, and it is.) This applies to both the game and editor.
2. When placing a new copy of the object in the editor, it will initially be DEFAULT_HEIGHT pixels tall, again, 16px in this case. Same size it always has been upon initial placement.

There's no reason why the same object, with the same width / height (whether it is manually applied, or just the default), would look different in the game vs in the editor, beyond the normal game / editor differences (eg. editor doesn't support alpha blending). In particular, they are not going to draw it at a different height. Once the object is placed, and its size is loaded (using the default, or the frame size, as fallbacks), the DEFAULT_HEIGHT parameter no longer does anything, and the renderer never knows it exists nor what its value is.

I should note to anyone reading this - if you're getting confused by DEFAULT_WIDTH and DEFAULT_HEIGHT, but don't actually need to be using it (and aren't simply curious about how it works), the answer is pretty much "don't worry about it". You can continue doing what you've always done, and there's not much reason to use them on new objects, they're more a backwards-compatibility thing if you have to change the base size of an existing resizable object.



Regarding the graphics - sounds good based on your explanation, will actually take a look later.

[WillLem]

You're overestimating how much the DEFAULT_HEIGHT parameter does.
---
There's no reason why the same object, with the same width / height... would look different in the game vs in the editor

Actually, I think I'm underestimating it's capabilities. I was checking to make sure that it does specify height for both in-game levels and editor. Your answer has clarified that it does.

The reason I thought it might not is because the graphic itself is 20px tall. So, the DEFAULT_HEIGHT text is needed to override that and tell the editor (and the player) to display the graphic at 16px.

Simple case of misunderstanding each other's questions and responses there I think. No worries, all is understood now. Thanks for the explanation

[WillLem]

Forgot to change the trigger height

This has been done now; consider this a fully operational demo

N.B. again, I'll correct the water colour once everyone's happy with what's going on in the graphic - the darker shade is to make this more clear for demo purposes.

[namida]

Perfect!

[WillLem]

Brillsies!

Since the above demo meets with namida's approval, I'll continue with the others in similar fashion.

Please do comment if you have any ideas or anything to say about it either way, though. Feedback is very welcome, since these are the default water objects that we'll all be using.

[Dullstar]

I haven't checked to see if yours meets this criteria, but I would prefer if the water objects look the same as they do currently at the default size.

If this is the case (your posts lead me to believe this is the case?), then it should be good.

[WillLem]

I haven't checked to see if yours meets this criteria, but I would prefer if the water objects look the same as they do currently at the default size.

That's the plan; so far all of them are identical to the originals at default size (including Snow and Fire, each of which makes use of nine-slicing at both the top and bottom edges to preserve the sediment/flames part of the graphic at the base).

The only one that currently* looks slightly different is the ohno_rock "tentacle" water - I tried a number of things to make this work as a resizable graphic, but they all looked fairly crap tbh. So, I added some murky-looking "swamp water" to the base of the animation, the top of which can be seen at the very bottom of the default-sized graphic.

*N.B. This is purely for demo purposes - if people don't like this idea, then I'd suggest keeping this one as horizontal resize only.

EDIT: Another idea could be to separate out the "swamp water" and simply have it as a new water graphic.

See attached zip folder of all of the resizable water graphics, plus a demo level so you can view them all at the same time

Comments welcome; I'm fairly happy with these, but I am of course prepared to make tweaks based on feedback.



Some comments regarding the creation process:

This is by far the most challenging graphical project I've embarked on for NeoLemmix so far; I'll likely make a tutorial video at some point to show how it's done, particularly when the original graphic features a both a "top" and a "base".

The most difficult of these was the Snow water, which has an icy top and a sediment base ejecting little chunks of ice which float up through the water. There were so many of these, and getting the animation correct for all of them was very time consuming. That and the logistics of getting the nine-slicing just right made this one the biggest challenge; very satisfying to get it finished though.

Fire and Rock presented the most creative challenges, since neither looks particularly good when simply repeating the original graphic (also, Fire - like Snow - has a base of flames spitting out hot bubbles into the lava). I'm fairly happy with the solutions to these; Rock now has a "swamp water" base as its resizable section, and Fire employs an effect similar to the one used in the Crystal water graphic to simulate lava bubbles continually expanding and popping throughout its resizable section (this is not visible at default size).

The easiest, by far (and the one I did last due to alphabetical order) was the Marble "pea soup"; only 3 bubbles to animate!

[namida]

Yep, these all seem great to me!