issue with the lines appearing in a instant no matter the speed

[Reaster0]

hey it is me again! this time after compiling succesfully with the help of st3w the program work as intended...but the lines are not drawed one characters at the time, it's just : one line, one line, etc the speed argument won't change anything, well yes actually it change the speed at which the lines pop but not the drawing speed in itself (the fps option also dosen't do anything)

[st3w]

What does your command look like? Can you please attach a screenshot?

It might help me to know:

• which terminal you are using
• the locale you are using
• Values of $TERM and $LANG environment variables (not sure if Mac sets those, but I know Linux does)
• Anything that might be "unusual" about your setup (e.g. trying to run within tmux)

[Reaster0]

thanks for your help! i can do better than that and send a video : https://youtu.be/e2R4rD8iURU i'm using iterm2 $TERM=xterm-256color $LANG=fr_FR.UTF-8 locale=LANG="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_CTYPE="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_ALL=

and no nothing unusual, i don't use tmux, nor any weird overlay or things like that

[st3w]

What in the hell...

Can you please try this?

neo --shadingmode=1

I had some optimizations to avoid drawing characters that shouldn't need to be redrawn. I'm wondering if that's biting me here somehow. --shadingmode=1 effectively disables that optimization. It also intentionally changes the visual appearance.

Edit: Forgot to mention that I find it extra odd that the droplets seem to disappear smoothly but they appear out of nowhere...

[st3w]

Sorry, two more things to try:

1. Can you please send me which version of ncurses you have installed? There are a few ways to find it. I think one of these 3 should list it:

infocmp -V
tic -V
brew list --versions

2. Can you try a different terminal emulator? Some other Mac compatible terminal emulators: GNOME Terminal, XTerm, Terminal, Alacritty, and Kitty.

Edit: I'm expecting the ncurses version to be 6.2 or 6.3 something. If it's 5.X, that's a red flag. I used 6.2.20200212 for implementing/testing.

[Reaster0]

nope shadingmode dosen't change anything and yes i find it very weird too the droplets seems to disappear smoothly i use ncurses 6.3 unfortunately this is not the issue :/ i have used neo on the basic terminal app of macos and no the issue is still here really it's a weird issue because cmatrix or tmatrix dosen't have any issue, (like it's not like in a docker or a ssh session where the drawing is always broken)

[st3w]

I think I finally found the bug!

The code that moves the droplets down the screen is in a class method called Droplet::Advance() in droplet.cpp. This method needs to know how many seconds have elapsed since the droplet last moved:

uint64_t elapsedNs = duration_cast<nanoseconds>(curTime - _lastTime).count();

The bug is that _lastTime can actually be greater than curTime. This causes an underflow, and since elapsedNs is unsigned, it becomes a really big number. _lastTime gets initialized in Droplet::Activate(). However, Droplet::Activate() is called after curTime is set. I confirmed in GDB that elapsedNs gets set to a huge value right after each droplet is spawned.

So if there's a bug, why does @Reaster0 seem to be the only person seeing the issue? I believe it's because on most systems (including mine), this line ends up evaluating to 0:

uint16_t charsAdvanced = static_cast<uint16_t>(round(_charsPerSec * elapsedSec));

I think on @Reaster0's system, charsAdvanced ends up being a really large number. Since elapsedSec is huge, the expression is too big to fit in a uint16_t. In C/C++, it's undefined behavior to cast a float to an integral type that is too small to fit it. My guess is that on macOS Monterey this ends up being 0xFFFF instead of 0 like on most other platforms. I added logic that prevents droplets from moving past where they're supposed to finish. So nothing crashes, but the droplets appear instantly even when their speed is set very low.

I have a simple fix in mind. I'll probably commit it tomorrow.

[st3w]

I checked in the fix at commit bd5491fdfa62258b5e3952619846b4b53eda4f11.

@Reaster0, here is a tarball you can try if you don't want to build from the repo:

neo-0.6_quickfix.tar.gz

[st3w]

@Reaster0, any luck?

[Reaster0]

sorry i was busy i've compiled from the tarball and yess this was the issue, nice work of you! underflow and overflow are always the issue haha