Splat rulers (feature wish)

[Forestidia86]

This came up already in this thread/post but what I sorely miss is something like a splat ruler/something to determine splat height.
The levels have by default different sizes and that makes it hard for me to assess what is safe to do concerning fall height. The assessment concerning that determines what I try or if I can get to a particular idea. There was even an instance where I used a real life ruler to get an idea what I can do.

So if at any time new features are added again I would make this feature wish.

[Simon]

Yep, this is still important. Will remember to focus on splat ruler once Lix development resumes!

As a fallback: The survivable height is 126, slightly less than two large 64-pixel-high blocks.

-- Simon

[Ramon]

IIRC, there was a "splat height" tile in one of the debug graphics tilesets that one could use. Has it since been removed?

EDIT: Located in lix\images\guideline\maxfall.png (or maxfall D.png)

[Forestidia86]

IIRC, there was a "splat height" tile in one of the debug graphics tilesets that one could use. Has it since been removed?

EDIT: Located in lix\images\guideline\maxfall.png (or maxfall D.png)

You would have to open the level in the editor to use it I guess. So for creating levels that would be the way to go but for playing the levels it's more of an emergency solution then (and at the the moment I'm more interested in playing).
But nevertheless thank you very much for the information.

[Ramon]

Oh, sorry, I totally didn't grasp it was for actually playing levels, not designing levels. That's another case altogether and such a feature will definitely prove useful.

[Simon]

See attachment: Windows build with splat ruler. The splat ruler snaps automatically to floors and ledges near the mouse cursor. Does this ruler get the job done, or is it confusing?

The splat ruler is always visible, that's probably too intrusive? But the only alternative is button/hotkey bloat. Ideally, I'd like good nonintrusive overlays dependent on the mouse cursor.

Non-Windows users could find branch splatruler in the unstable github repository, ask me in IRC if you want to build test versions yourself.

-- Simon

[Forestidia86]

First of all thanks very much for providing it that fast.

The splat ruler is always visible, that's probably too intrusive? But the only alternative is button/hotkey bloat. Ideally, I'd like good nonintrusive overlays dependent on the mouse cursor.

I had a short glance at it and I would say unfortunately yes. I think I personally could get used to it but it messes with the aesthetics of the level generally. I personally think that activating it by hotkey would be a better option there.
I noticed that it goes not only downwards but upwards as well. That was a bit confusing at the beginning though it makes much sense to me now. 

[Simon]

Thanks for the feedback! Yeah, unless we find a really smart idea, the blatant colorful bars are too distracting. I'd like to sleep over this design problem for a couple nights. I haven't merged the feature into 0.9.3 yet, it'll probably make it into the next release.

-- Simon

[Forestidia86]

I've used the splat rulers at times for a while and they have proven very useful for me.
I still think they should be toggleable:
I've only used the version in levels where it seemed important to know splat height since having them always on seemed a bit distracting/confusing but it was always manageable.

[Simon]

Yep, I haven't come up with anything better than an extra button. I'll make the splat ruler toggleable. The splat ruler must be well-visible to be useful, and snap to any kind of land on the map. This requirement clashes with an unobstrusive splat ruler.

I'd like to merge this functionality with the exit-revealing button in multiplayer, and ideally display gadget trigger areas. Distinguish-steel-from-terrain would be nice too, but that looks harder to implement.

-- Simon

[namida]

Re: Distinguish steel from terrain, if all else fails, could you not just generate a new bitmap on-the-spot based on testing each pixel for (non-solid, solid, steel)? Or if this causes too much of a performance hit, a possible alternative is to generate this map at the start of the level, then update it any time a destructive / constructive skill is used just as is done for the visual map?

(Of course, I don't know Lix's internal workings in regard to testing terrain solidity / steelness. This was a viable approach for NeoLemmix. If looking at NeoLemmix's source code here, you'll want to look at the LemRenderHelpers.pas file primarily, in particular TRenderBitmaps.CombineTo and TRenderBitmaps.DrawClearPhysicsTerrain.)

[Forestidia86]

Only one thing I noticed when playing one of Rubix' levels:
If the background has a similiar color to the ruler, the ruler is only barely visible on that side.
But it is still visible due to having different shades. So it's maybe no problem at all.
I've attached a picture to demonstrate. (It's the upper one in this case.)
For me it's still fine since I can still see the ruler, just showing it for general assessment.

[Simon]

I'll special-case the upper bar and paint it black instead of blue when the background's blue component is too light.

This light-blue background appears in several maps by Rubix. No other bright colors appear commonly. I don't like such special cases without a general rule, but it's fine this time. The ruler is new anyway and needs feedback from others after the next release.

Re namida's ideas: The problem is performance. Pixel-wise VRAM operations are either slow or complicated. Tracking extra copies of the land multiplies the VRAM of the internal savestates by 2. We had already people crashing with out-of-VRAM, factor 2 would be too much. Of course this dovetails into the naivety of the savestating algorithm, which, if improved, could open namida's strategy to track the extra land in each savestate.

-- Simon

[Forestidia86]

Just to show another, critical perspective on/problems with the splat height ruler:

From IchoTolot's recording of the multiplayer session:

https://www.youtube.com/watch?v=1h0JQRX4KT8&t=2501 (starts roughly about 41:41)

(As I indicated I personally get along with it well but that doesn't seem to apply to others, which is important as well or even more important. It works relative to the cursor position (snaps to terrain relative to it) though it really can jump around and be precise if edges are close to each other and you have to learn to understand it.)

Edit: Just for clarification:
I said originally only "It works relative to the cursor position" but meant of course that it snaps to terrain (floor, ledges and the like) relative/close to the cursor position.
So the point is actually that the ruler is not on the position of the cursor but on the position of terrain relative/close to it. (The position where the ruler is on is indicated by the green bar in the release. It goes upwards (blue bar) as well as downwards (red bar). (The bars can get covered by terrain and therefore be not visible.)) This kind of working is what makes the ruler as powerful as confusing at first.

[namida]

I'll special-case the upper bar and paint it black instead of blue when the background's blue component is too light.

This light-blue background appears in several maps by Rubix. No other bright colors appear commonly. I don't like such special cases without a general rule, but it's fine this time. The ruler is new anyway and needs feedback from others after the next release.

Re namida's ideas: The problem is performance. Pixel-wise VRAM operations are either slow or complicated. Tracking extra copies of the land multiplies the VRAM of the internal savestates by 2. We had already people crashing with out-of-VRAM, factor 2 would be too much. Of course this dovetails into the naivety of the savestating algorithm, which, if improved, could open namida's strategy to track the extra land in each savestate.

-- Simon

Hm, yes. NeoLemmix handles all graphics operations in CPU / regular RAM, so wouldn't be as affected by such.
However, then this raises the next question - how does Lix test such pixels during regular gameplay? Does it simply accept the slow VRAM access? If so, might it be better to generate a regular RAM physics map and use that for physics in general, and use VRAM solely for the actual graphical map?
For that matter, in general, how is a steel pixel distinguished from a non-steel pixel, physics-wise?