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

[namida]

This is a suggestion that has come up in the past, and I'd like to look at making it happen.

In order to make this happen without compromising visuals on existing levels (and of the water objects in general), a new feature is needed where the default size of a resizable object*, can be different from the size of the PNG file with its graphic. This feature is already implemented for V12.11.

* and it goes without saying that this feature has been extended to resizable terrain too, even though it's less important there

[Dullstar]

I'm sure most people already know this, but NL already allows vertically resizable water objects - L2 classic has one. However, the default styles, along with most of the L2 styles, do not have them. For the L2 styles, the water.nxmo from L2 classic can be used as a base for the vertical resizing - just make sure to either A) copy the relevant section from L2 classic's water.nxmo, leaving the rest intact or B) change the horizontal size to match the actual size of the water object. Either approach should work; L2 egypt, for example, uses 48x16 water, but it's representable as a resizable 16x16 water object with no graphical losses, so since L2 classic was created long after horizontal resizing was introduced, I didn't duplicate the graphic 3x in the horizontal direction, since I assumed people would just horizontally resize it to whatever they needed. Since I'm not responsible for the other L2 conversions, though, I can't be sure why they were done the way they were; I think they predated resizable water objects though, so I'm guessing that has something to do with it.

[WillLem]

NL already allows vertically resizable water objects - L2 classic has one

Confirmed. Add the following lines to any water.nxmo file:

RESIZE_VERTICAL (directly underneath the line "RESIZE_HORIZONTAL")

NINE_SLICE_TOP N (directly underneath the line "$PRIMARY ANIMATION")

To find "N", have a look at the water graphic itself, and identify a horizontal line somewhere in the middle that always has solid pixels below it in every frame. Then, count how many vertical pixels there are from that line to the top.

For example:



The green line always has solid pixels below it in every frame, whereas above the line is sometimes empty due to the movement of the water in the animation.

There are 8 pixels above this line, noted by the pink dots.

So, for this graphic, the 9-slice line would read NINE_SLICE_TOP 8

Hope this helps

[namida]

Yes, but then the animation ends up a bit awkward. I'd like to do them so that the animation remains nice too, and that requires adding extra size (or revising the graphic altogether). As mentioned - V12.11 will have a feature that allows this without breaking existing levels.

To be clear, it's perfectly fine to make resizable water objects in custom styles already. This is purely about making the Orig / Ohno ones resizable while still looking nice.

[WillLem]

I know what you mean - you end up with two lines of "underwater bubbles" in the above example that I posted, which does look a bit daft.

[namida]

@WillLem - reckon you could have a go at making modified versions of the default water objects, that *can* nicely resize vertically?

It is perfectly fine if the frame count and/or height differ from the standard ones (though keep in mind this is "modify to allow vertical resize", not "remaster them") - I've got features in the pipeline that will avoid issues arising from the latter; while the former would never have caused issues in the first place.

[WillLem]

@WillLem - reckon you could have a go at making modified versions of the default water objects, that *can* nicely resize vertically?

Sure, I can have a look at that. I'm not 100% sure how it would work from a technical POV, i.e. which part of the graphic needs to be modified, so I might need help to do just the first one so I know what we're aiming for, and then I can do the rest on my own.

I probably wouldn't want to change too much about them either, it's important that they remain fully recognisable as the default objects.

[namida]

Sure, I can have a look at that. I'm not 100% sure how it would work from a technical POV, i.e. which part of the graphic needs to be modified, so I might need help to do just the first one so I know what we're aiming for, and then I can do the rest on my own.

How I'd personally envision it - though if you have another idea, sure, let's see it - is that you'd keep the existing graphic exactly as-is, and just add more on to the bottom so that it can be resized vertically while the rising bubble animations still look nice. Snow might need a bit fancier than that, to keep the sediment at the bottom (thankfully we have nine-slicing).

I realise that by default, this addition of size will break existing levels - V12.11 will be introducing a feature to avoid that breakage, so as long as people don't start using these in real-world levels until 12.11, it won't be a problem.

[WillLem]

I've attached an initial version of the pillar water, since that's the easiest to do; I've literally just added 4px of blue at the bottom of each frame. Let me know if this works and I'll do the same for the others.

Snow might need a bit fancier than that, to keep the sediment at the bottom (thankfully we have nine-slicing)

I anticipate that bubble will be the most difficult to get right, since it's a completely random jumble of circles and colours. I'll do my best with it, though!

I realise that by default, this addition of size will break existing levels - V12.11 will be introducing a feature to avoid that breakage, so as long as people don't start using these in real-world levels until 12.11, it won't be a problem.

How will this be fixed, out of interest?

[Dullstar]

On this topic, does anyone want to make the rest of L2 waters resizable, or should I go ahead and do it myself? I don't have a problem doing it, but I don't know who's responsible for maintaining them (depending on the implementation of the 12.11 feature to allow introducing this without breaking existing levels, I might fix the animations, too, as I recently noticed the animations don't tile accurately in NL the way they do in L2 since L2 offsets the frames a bit to create a wave effect.

[namida]

On this topic, does anyone want to make the rest of L2 waters resizable, or should I go ahead and do it myself? I don't have a problem doing it, but I don't know who's responsible for maintaining them (depending on the implementation of the 12.11 feature to allow introducing this without breaking existing levels, I might fix the animations, too, as I recently noticed the animations don't tile accurately in NL the way they do in L2 since L2 offsets the frames a bit to create a wave effect.

IchoTolot is the person to talk to about the L2 styles + L3 biolab (I believe GigaLem is for the other two L3 styles, but I'd have to double-check for sure), but I'd be very surprised if he had any problems with this.

If doing so (WillLem too) - please add the following to the NXMO file. Doesn't matter where, as long as it's in the main section and not a $ANIMATION (or $PRIMARY_ANIMATION) sub-section etc.

Code Select Expand

DEFAULT_WIDTH 64
DEFAULT_HEIGHT 16

(Or, as appropriate. The values that should be specified here are the size of the existing object.)

How will this be fixed, out of interest?

And this is why to add those lines. V12.10 doesn't support them (it will just ignore them - however you can otherwise use 12.10 to test that the animation looks nice, etc, basically using them for new levels will be fine in V12.10, it's only existing levels that will have issues), but in V12.11, this will tell the game what size to make the objects when loading a level that doesn't specifically specify a size. The current behavior (or in the future, the fallback behvaior where these params are not specified) is to use the size of one frame of the object's primary animation graphic.

[WillLem]

I've added the default width & height values to the .nxmo file as specified, as well as vertical resize and nine-slice values.

This looks somewhat better than simply resizing the original version, but there is really no way to get around the "bubbles spontenaeously appearing in the middle of the graphic" thing, even with nine-slicing. However, I'd suggest that it's not really an issue, since that's what currently happens when layering/stacking multiple water objects manually anyway; i.e. the resizable water manifests the exact same result as manual stacking, which may well be perfectly OK, in which case - no problem.

However however, when actually stacking water manually it is possible to flip every other water graphic to avoid the "two distinct lines of bubbles" thing...

I suppose that, if creators prefer, they can still manually stack the water graphic at its default size*. But, those who would prefer the convenience of an automatic resize can do so, albeit with that much less control over the resulting image.

I've attached water.png, .nxmo and a demo level. Let me know your thoughts before I go ahead with the others; they will likely be a fair bit more work than the default one so I'd rather see what everyone thinks first.



*question regarding this: if vertical resize is not applied to a water object in the editor, does it appear as its specified default size in the editor, or the size of 1 frame of the graphic? Either way, I'd suggest that it needs to appear in the editor exactly as it will appear in-game.

[namida]

Here's an attempt at what I'm going for. I didn't quite get it right (except on the furthest-left bubble) but this should give the general idea. Notice how the bubbles essentially repeat and animate nicely (or at least, should do so). The animation might need to be made even taller to get this completely right, not sure?

*question regarding this: if vertical resize is not applied to a water object in the editor, does it appear as its specified default size in the editor, or the size of 1 frame of the graphic? Either way, I'd suggest that it needs to appear in the editor exactly as it will appear in-game.

I'm not sure what you're getting at here? There's no reason why what the editor defaults to, would create an inconsistency in-game, because either way the NXLV file would have the size noted in it. The only time the default size is used (which, if not specified / in V12.10 and earlier, uses the size of the primary anim frame as a fallback) is when loading an existing NXLV that has no specified size, or for the initial size when placing a new object in the editor.

[WillLem]

Here's an attempt at what I'm going for. I didn't quite get it right (except on the furthest-left bubble) but this should give the general idea. Notice how the bubbles essentially repeat and animate nicely (or at least, should do so). The animation might need to be made even taller to get this completely right, not sure?

Ah yes, I see how you've done this. It's essentially matching up the NINE_SLICE_TOP point with the bottom of the frame, so that as the bubble reaches the point at which nine-slicing occurs, it then reappears at the bottom of the next frame. Getting this exactly right for each bubble could be done in a number of different ways, I'll have a play with it and see what I can do.

I'm not sure what you're getting at here?

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)?

[WillLem]

So I've had a look at it and I can see what the issue is; most of the bubbles move up 2px per frame each, but the ones on the far right "jump" up to 3px per frame as they near the top, creating the effect of "increasingly quick movement" that you'd see with real fizzy water. Fixing the animation was as simple as making all bubbles move at 2px per frame, but you do lose some of that effect (see attachment).

The best way to preserve the existing graphics exactly as they are whilst making them pleasingly resizable would be to create an independent animation for the bottom "resizable" part of the graphic, making sure that said animation matches up with what's going on above it, of course. It would simply be an "extension" of the existing graphic, nice-slicing at its base and thus keeping all defaults exactly as they are now.

Again, I'll give this a go with the default water and see if people are happy with the result before proceeding with any of the others.