cmatrix icon indicating copy to clipboard operation
cmatrix copied to clipboard

Feature request: (1) Variable individual stream speed (2) Stream over writing

Open TinCanTech opened this issue 5 years ago • 4 comments

These are features of the original Matrix feed:

  1. Variable individual stream speed On an 80x24 terminal there are 40 streams which all scroll at the same speed. Make the speeds vary.

  2. Stream over writing On an 80x24 terminal there are 40 streams, by increasing this to say 60 streams, the extra 20 can over write the existing streams.

Combining these two features, the slower streams would then be over written by the faster streams and the slower streams could be deleted once the head of the slower stream is over written.

My 'C' skills are not good enough to do this for you but I am happy to help test.

Also, thank you for writing this great little homage to The Matrix :-)

TinCanTech avatar Nov 18 '19 16:11 TinCanTech

  1. Variable individual stream speed On an 80x24 terminal there are 40 streams which all scroll at the same speed. Make the speeds vary.

Isn't that what the -a option ("asynchronous scroll") already provides?

2. Stream over writing On an 80x24 terminal there are 40 streams, by increasing this to say 60 streams, the extra 20 can over write the existing streams.

I thought this may actually occur with the -a option, but when I tried to observe that, I couldn't observe it happening. Maybe the column is already erased some rows below (before) the apparent bright "head" of a stream? Or is stream speed limited by the free space in front of its head?

das-g avatar Apr 27 '20 00:04 das-g

  1. Variable individual stream speed On an 80x24 terminal there are 40 streams which all scroll at the same speed. Make the speeds vary.

Isn't that what the -a option ("asynchronous scroll") already provides?

Indeed, you are correct. Thanks!

  1. Stream over writing On an 80x24 terminal there are 40 streams, by increasing this to say 60 streams, the extra 20 can over write the existing streams.

I thought this may actually occur with the -a option, but when I tried to observe that, I couldn't observe it happening. Maybe the column is already erased some rows below (before) the apparent bright "head" of a stream? Or is stream speed limited by the free space in front of its head?

It looks to me like (even with -a) each stream has a fixed speed and even though there may be multiple heads per stream, each head in one stream are all set to the same speed. Thanks for taking a look :smiley:

TinCanTech avatar Apr 27 '20 11:04 TinCanTech

I guess, it is possible that too much randomness would start to look messy. I wish I could experiment but alas my C foo is not strong enough.

TinCanTech avatar Apr 27 '20 11:04 TinCanTech

With the current implementation, there will never be more than one stream per column, and thus a stream will never outrace another stream in the same column. I'll be adding this feature in a patch soon, as a part of a major re-write of the existing codebase.

space-pagan avatar Dec 09 '20 17:12 space-pagan