I ported the classic ASCII Donut to Fortran

Announcements
1

Link to the GitHub repo : ASCII-Donut-Fortran

donut

Suggestions and improvements highly welcome :slight_smile:

14 Likes
2

That looks very nice - and the code is concise. I do have a number of remarks about it, but I will first take a closer look :slight_smile:

3 Likes
3

On a first look, it seems that your ANSI escape sequences lack the escape character (27):

write(*,"(A)",advance="no")"[2J"
! […]
write(*,"(A)",advance="no")"[d"

Probably better to set the character explicitly:

write (*, '(a1, "[2J")', advance='no') char(27)
! […]
write (*, '(a1, "[d")', advance='no') char(27)
2 Likes
4

I directly used the escape character directly to avoid a function call in the loops. The escape character looks like a square or like this image

Another option is defining a variable and using that.

Please take a look at the latest commit.

Implemented like this.

CHARACTER::ESC=achar(27)
! […]
write(*,"(A)",advance="no")ESC//"[2J"
1 Like
5

Just a little color

Ansi colors 31 and 32

colors_donut2

4 Likes
6

Good idea, Even I thought of color.

But using just two colors will make it lose the luminance detail because the “fill” from different characters become not very apparent. At least for me, I see less luminance detail in the two colored version (I partially close my eye to make each character blurry and blend in).

To preserve or even enhance the luminance detail, we could use a gradient from color A to color B, and these characters for every gradient resulting both a single color and the “fill” giving the luminance detail. Implementation seems pretty straight forward too since in line 41, 8 is multiplied to distribute luminance values from 1st character to 12th character. If we have N resolution, then we can distribute that accordingly and get essentially what constitutes as “HDR”

That being said, a bit off-topic, but I have implemented some more features in this python version (which I modified)

Features include, auto resize on terminal resize/font size change, show “FPS”, Auto adjust speed so that scale doesn’t change the animation speed etc. Trying first on python version as a proof of concept would be nice idea.

3 Likes
7

@ShrirajHegde welcome to the forum!

Nice example. I have one suggestion: rename the repository from ASCII-Donut-FORTRAN to ASCII-Donut-Fortran. :slight_smile:

5 Likes
8

The animation above also appears on the readme.md, and its source is a file gif\scale-1.gif . How is such a file created from a program that writes text to the screen?

2 Likes
9

It’s just OBS screen-record of the terminal and then extract frames with FFmpeg, Then I used https://gif.ski/ to convert those frames to a good quality GIF without artifacts.

GitHub should support using silent MP4s as GIFs like other platforms. GIF is too inferior for 2021.

3 Likes
10

I think GitHub supports videos.

11

I had named it ASCII-Donut-Fortran itself, but for some reason https://languagetool.org/ insisted it should be ASCII-Donut-FORTRAN

1 Like
12

I think https://languagetool.org/ needs to improve…

2 Likes
13

Can you confirm or any reference/example? I have tried placing MP4 and MKV but no luck.

14

Thanks for the suggestion, Repository renamed.

1 Like
15

I tested uploading mp4 into a github comment and it shows. I can’t remember which comment I did it in now.

1 Like
16

Nice, if they could play silent MP4s as GIFs (autoplay and loop support) it would be great. But this is better than nothing.

No other major platforms use GIFs, they just loop MP4s, Sometimes MP4s even with audio but muted.

17

Welcome @ShrirajHegde and thanks for sharing it. I just posted it on our Twitter:

4 Likes
18

Thanks a lot ! I saw it !

19

Just a few remarks on the style. Of course in a program like this the understanding of the code is secondary, but in general, just my opinion:

  • Do not use variable names like i and j for REAL variables. People are used to using these as index variables, so automatically assume they are integers. LIkewise, the other way around for names like x and y
  • Make clear that a literal value is a REAL value: instead of 4, use 4.0 (or 4.)
  • CHARACTER :: ATABLE*12 - make that CHARACTER(LEN=12) :: ATABLE
  • A variable name like “o” can easily be mistaken for 0 (not in the font used by Github, but in many others). Similarly, “l”

But, like I said, that holds in general. In a compact program like this, the result counts :slight_smile:

4 Likes
20

I personally usually prefer integers if it is an integer assigned to a real.

I agree with all your other points.

2 Likes