stepmania icon indicating copy to clipboard operation
stepmania copied to clipboard

Regression: Hold tails are visually overlapping Hold heads

Open dinsfire64 opened this issue 4 years ago • 7 comments

So for the longest time I was running 5-1_new beta 2 and just recently updated to the latest branch.

So running off 6a645b4, on certain charts the end of a hold is overlapping the start of another hold.

Comparing to b2 f1ebe8d, you can see the following.

diff

It appears StepMania is drawing the notes in the wrong z axis order for the notes.

Just wanted to write it down in case someone knows the regression to save me the time digging through.

dinsfire64 avatar Nov 20 '20 00:11 dinsfire64

not a bug - this was intentionally changed in revs e96b170 + 567f836 although i can't remember the details. i think older builds (3.9 or so) behave as in current, and the b2 behavior was a pump pro change or something of that nature.

edit: leaving this open to discuss, i'm willing to accept this might be a misbehavior, particularly for holds (i believe it's correct note drawing order as-is, but maybe hold tails should always be on lowest level or something)

shakesoda avatar Nov 20 '20 00:11 shakesoda

OpenITG behaves as such.

Screen Capture_20201119185634

dinsfire64 avatar Nov 20 '20 00:11 dinsfire64

please compare against a 2d noteskin in oitg or a 3d skin in latest (fast note rendering should be enabled to match oitg, if i recall)

shakesoda avatar Nov 20 '20 00:11 shakesoda

Here's how it looks in the current with jousway's USWCel3DSM5 and fast note rendering on.

Attached is also the stepchart (sans ogg).

Screen Capture_StepMania 5 1_20201119190659

Also I couldn't find the issue/PR for the original issue that caused the z drawing order to be reversed. Can you link me?

Stars Above.zip

dinsfire64 avatar Nov 20 '20 01:11 dinsfire64

I think the report was on IRC at the time unfortunately - thanks for testing this though, I think you're right that this is bad behavior with the tails. The intention is that further in the future notes are always behind current/past ones, but that's a bad policy here, so I've tagged it as a misfeature, I won't be able to get around to this immediately but locally reverting those two revisions shouldn't have any sprawling consequences.

shakesoda avatar Nov 20 '20 01:11 shakesoda

Got'cha yeah because it's not a terribly big issue in the scheme of things (there are not that many stepchart makers writing these kind of charts anymore). When I first came across it I shrugged and moved on.

But someone else brought it to my attention so I thought I'd at least do my duty and document it.

Let me know how else I can lend a hand.

<3

dinsfire64 avatar Nov 20 '20 01:11 dinsfire64

I was curious how notes should be rendered so I did some digging. Turns out DDR and ITG do different things:

For DDR, earlier notes should render on top of later notes (shown below): image

For some reason, there's an exception for the up arrow, where earlier ones render below later ones: image On reverse, this exception becomes the down arrow image

Notes are always rendered on top of hold tails (regardless if it's the up arrow or not): image

For ITG, it seems that earlier notes are rendered below later notes in general except in the case of a tap note overlapping with a hold head, where the tap note will be rendered on top of the hold head.

image

teejusb avatar Aug 24 '21 20:08 teejusb