Swinging ropes in games

[Joefish]

Ah, it's not the point positions. It's the offset from the point immediately above. So you start at the top point, then the next point is +0 horizontally, +6 downwards, and so on through the table until you've plotted enough points.

Then if you start a little bit later in the table, so a little offset sneaks in at the bottom, and that works its way up to the top until the whole chain of points is offset to one side or the other.

And since it's a table, a random bit of wobblyness can be added that appears to ripple up then back down the rope near the end of the swing.

[RMartins]

A reference Lookup table would be the obvious choice, for performance concerns.

[Jonathan]

Egghead Goes to Town used a big table of coordinates for speed, all pre-calculated in Sinclair BASIC. It was quite expensive but seeing as the screens were very efficiently stored I figured it was affordable.

[R-Tape]

Egghead Goes to Town used a big table of coordinates for speed, all pre-calculated in Sinclair BASIC. It was quite expensive but seeing as the screens were very efficiently stored I figured it was affordable.

There's a flaw somewhere though, you've gone against Spectrum best practise by not having a rope with 75% unfair collision.

[Ralf]

Egghead Goes to Town used a big table of coordinates for speed, all pre-calculated in Sinclair BASIC

Wow, calculating data in Spectrum Basic in 2017 is certainly retro

Personally when I needed once some precalculated data for my game, I used Excel. Not very cool, I suppose

By the way, welcome to the forums, Jonathan !