Adjust speed of cursor left/right movement to match wall speed.

[zaphod77]

This ensures that a pattern that's doable at the start of the level is also doable at the end of the level with the same motions.

TODO: adjust the initial speed of the cursor in the opposite directions so it's the same as it was before this commit.

[zaphod77]

okay, i've now finished this. Cursor speed is now fixed, and collision is fixed, because adding that other bit broke it.

When the wall speed goes up because of the multiplier increase, so does the cursor move speed and collision test. This ensures that any pattern doable at the start of a level is guaranteed doable at the end of it.

This closes my issue if implemented, without removing the wallspeed increase mechanic. you still have to react faster, but you will no longer fall short as long as you are in the same position wen the move starts.

[RedTopper]

Hey! This looks pretty good. I'll have to see how it works in the fastest level, my only worry is that you'll increase the cursor rotation speed so high it will be hard to position yourself in the center of each hexagon face, particularly when your framerate is low. I might need to implement a "grace step" where if you are very close to making a wall (less then 1 step away from the edge) it will snap your cursor position to the edge of that wall rather than killing you.

I'm not sure if you are building just for a desktop OS, but I released a build so you can try it out on other devices if you'd like.

[zaphod77]

Right. levels that start faster might have issues. which level is the fastest? i'm assuming it's either level 6 or 7, and i'm not good at level 6.

At fastest, it is 1.308823529411765*the speed in the file. the speed increase seems subtle, and void seesm perfectly playable. broke 60, and that's only two speed bumps left.

There is an issue where the game refuses to do a partial move to approach a wall, and stops if a full step would go inside the wall instead of camping as close as you can get, and that may be made worse at higher speeds, but it hasn't been an issue for me in testing on any level i can play decently.

[RedTopper]

@zaphod77 I made some changes from the feedback. I re-kicked off a build with them. It should be functionally the same as what you had, but you can test it out just to be sure.

I'm still deciding if I like the changes. From what I've noticed, it's a little (but not hugely) jarring to go back to the "slow" speed at the beginning of the level, but it fixes the patterns feeling "tight" as the levels progress.

[RedTopper]

From the review thread:

Also i didn't know that the intended wall speed was 1.0

Yeah, I remember now, sorry, it's been a while since I designed that. Here's why it starts at 0.85:

The wall speed multiplier gets to 1.0 right at PENTAGON, or a little over halfway through the level. I made the assumption that it going up to 1.15 multiplier would still allow for the movements to be possible, so when I designed the difficulty multiplication of the wall speed, I started at 0.85 and went to 1.15, keeping what I knew was "possible" (1.0 speed) right in the middle.

As you found, the way you do one of the movements in the patterns caused it to no longer be possible. I always intended the movement for the "step"/"chevron" pattern to be stepping one side at a time, rather than going backwards, so I never realized the movement would be broken at the 1.15ish wall speed multiplier.

I guess technically if I'm going based on that 1.0 is the "intended" speed to do all patterns, I should really start the cursor at 0.85 multiplier too, but as you found, it feels kinda bad doing that.

[zaphod77]

looks fine.

[zaphod77]

Wall of text about pattern design here. :)

The deal is certain patterns have multiple possible routes, and depending on wall speed, some of them work and some of them not.

For example we have alternating cs. the possible routes are

1. constant rotation same direction.
2. same direction but pause as needed
3. switch directions every hole, pause if needed.

only route 3 works at all speeds.

At slow wall speeds, 2 and 3 work, while one will crash.
if it gets fast enough, one starts, working, then 2 stops working, then 1 stops working, then 3 stops working and the pattern is impossible.

In Super Hexagon, 1 never works, while at 1.0 is super haxagon in hexagonest, 1 always worked.

Therefore, because that never worked in Super Hexagon, i assumed that what i got on level 1 before was the intended starting speed for the patterns.

For chevrons, there are 4 possible routes.

1. tap reverse
2. hold reverse
3. tap forward
4. hold forward

Up to two routes will work at once for a given wall speed. 1 and 4 usually do not work. But this time NO route works at all possible speeds. it's possible for the pattern to be too fast for route 3, or too slow for route 4. if its' too fast for 3, it's too fast for 1 and 2 as well.

Going through stepping chevrons in Super Hexagon in reverse by holding down works, EXCEPT in The Final Hexagon, which has the walls move a little too fast, and forces you to tap and do it the "right" way. This is what annoyed me and made me start on this pull request. This move did work fine before i put in the correction to speed up the start, but as i explained, it opened up a route that didn't work before in the triple C pattern when i tried it.

Learning a route through a pattern that breaks after the color change is not very fun. For the chevrons pattern for that level in particular, i gravitated towards the reverse route because it only has two error points, while the intended route has many more change to screw up. Further, it's okay to overshoot the move at the end.

The previous level's chevron pattern has a double wall (two identical walls with a small space between) at the end, so i always did it the normal way, because reverse risks overshooting into the double wall.

I also didn't even realize the walls actually were accelerating, and thought it was all in my head until i crashed halfway through reverse route at Octagon, which proved it. Open hexagon gets around this by pausing and giving you a message announcing the speedup, which tells you that routes dependent on speed that were working before may fail.

Super Hexagon's philosophy is you develop muscle memory for patterns to deal with the distractions, and thus the walls never accelerate until after you beat the level and last 60 seconds.

[RedTopper]

Yep, I see how that can be annoying.

I'll go ahead and merge this change for now. I'm going to go create some issues over in the Haxa-Editor repository for future improvements with this stuff, because I never really liked the level designs that I came up with any. Many are a patchwork of tests, "close enough" and whatever else (for example Octagon and the final VOID level don't even have many patterns in them at all!)

I'm sure someone else will notice this in an upcoming release and have some complaint that the cursor speed is too fast, but that solution will just have to wait until a future release. I think you've pretty clearly articulated that this is an improvement, and as long as it is, I think it'll be OK.

Thank you for your contribution!

[zaphod77]

to be sure i can now sync my fork, right?

[RedTopper]

Yeah, I think I finished the sweeping changes I wanted to make to the driver infrastructure, so things should be more stable now.

If you're having trouble syncing, that might be because I squash merged, so I messed up the history of master compared to yours, particularly when I added my changes on top of yours. If you create a branch off of master next time, that might make syncing go a bit better.

Should be stable enough to pull in the latest changes though!

[zaphod77]

all i had to do was click discard commits and it's done. just wanted to be sure this didn't affect the master any.