A couple of bug reports about cool-retro-term HOT 9 CLOSED

You are welcome, I'm glad you like it and thank you for your feedback. Let's start commenting the issues you found:

1. You are definitely right, there is a problem with line spacing. At the moment it is set to 2pxs for every font end every size which is simply bad. I'm going to look for a solution in the next few days.
2. This is, as you wrote, related to the order in which effects are applied. In the first versions I did exactly what you suggest but there were problems since scanlines are 1pxs wide, so they can't follow curvature without aliasing. The artifacts generated were really ugly, so I decided for this solution, which even if approximate, looks a lot better.
3. I really love when blur is intense 😄 but I can reduce the minimum coefficient.

Now for features requests:

1. I really don't know if this is even possible in QML, I think that this is unlikely to happen sorry.
2. That is something that I would love but It would need many changes to the underlying konsole. I can look into it but I can't promise anything.
3. I understand what you say, that is a different kind of noise that I will definitely look at.

I will leave this issue open for further suggestions and comment. Thank you again for the feedback.

from cool-retro-term.

Hey Filippo, thanks for the quick and thorough reply! Here's my comments on
your comments :)

1. Awesome, looking forward to seeing that resolved whenever it's
   convenient for you

2. I do see your point, but that kindof leads to a different concern I have
   with the implementation of the scanline effect. I do not think the
   scanlines should always be 1px wide.
   The resolution of display devices are getting higher and higher. 1080 lines
   of horizontal resolution are common, 1440 lines are beginning to become
   common, and 2160 line displays exist in the market for consumers today. In
   comparison, the apple ii, which is one of your options, had a maximum
   horizontal resolution of 192 lines. On a 1920x1080 monitor, I could
   potentially use 4 actual lines of my display for every 1 apple ii scanline,
   which would significantly reduce the artifacts you are referring to.

Your solution works when the fonts are non-scalable, but again, as display
resolution goes up, scalability of the fonts becomes even more important. I
would like to urge you to consider allowing this to at least be a user
selectable option, to apply the scanlines before or after the screen
distortion effect. The scale of the fonts should also hopefully one day be
adjustable, and the number of scanlines per character dependent on the
resolution of the underlying bitmapped font. I'd guess most if not all of
these old school fonts were only 8 pixels tall, so that shouldn't vary much.

Have you looked at all into the opengl shaders that have been developed for
simulating a CRT display for video game emulation? Perhaps there's some
overlap there that could be useful to you...

http://filthypants.blogspot.com/2011/05/more-emulator-pixel-shaders-crt-updated.html

http://emulation-general.wikia.com/wiki/Shaders_and_Filters

3. awesome, thanks, in your own time

Feature requests

1. So I looked up the KDE equivalent of guake, yakuake, and they seem to
   think it's a solvable problem as they are migrating to QML.

http://blogs.kde.org/2014/02/17/yakuake-update-frameworks-5-wayland-more

"General feature plans

Yakuake's theming system has been showing its age for a while, so I'm
looking to implement a replacement for it. The new system will be based on
QML, taking some inspiration from KWin's Aurorae decoration engine."
You've already got most of the functionality I am interested in, being able
to go full screen. I would think the difficult problem to solve beyond that
is two parts, a) monitoring the keyboard for the hotkey even when the app
is not in focus, and b) hiding completely when not in full screen. I
understand if this is not an interesting use case for you and would
completely understand if you don't develop it into your program.

2. Limiting the baud rate of the terminal is something I could potentially
   solve outside of the terminal application, maybe on the command line
   somehow. I wouldn't spend too much time spinning your wheels on it unless
   it really interests you.

3. Cool, thanks

Thank you for the thoughtful reply and for considering my bug reports and
feature suggestions.

On Sun, May 4, 2014 at 6:10 PM, Filippo Scognamiglio <
[email protected]> wrote:

You are welcome, I'm glad you like it and thank you for your feedback.
Let's start commenting the issues you found:

1. You are definitely right, there is a problem with line spacing. At the
   moment it is set to 2pxs for every font end every size which is simply bad.
   I'm going to look for a solution in the next few days.
2. This is, as you wrote, related to the order in which effects are
   applied. In the first versions I did exactly what you suggest but there
   were problems since scanlines are 1pxs wide, so they can't follow curvature
   without aliasing. The artifacts generated were really ugly, so I decided
   for this solution, which even if approximate, looks a lot better.
3. I really love when blur is intense [image: 😄] but I can reduce
   the minimum coefficient.

Now for features requests:

1. I really don't know if this is even possible in QML, I think that this
   is unlikely to happen sorry.
2. That is something that I would love but It would need many changes to
   the underlying konsole. I can look into it but I can't promise anything.
3. I understand what you say, that is a different kind of noise that I
   will definitely look at.

I will leave this issue open for further suggestions and comment. Thank
you again for the feedback.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-42150237
.

from cool-retro-term.

New motion blur looks fantastic

from cool-retro-term.

Sorry if I didn't write here in the last weeks but I've been very busy with my thesis. Anyway I found some time to work on the terminal and I just pushed a new version with much better scanlines; now they are properly implemented (they follow the curvature and scale with the font size).
When you have time try it and let me know what you think. Moreover I'd like to know if you still experience the problem with the chopped letters, because I pushed a couple of commits related to the line spacing.

from cool-retro-term.

Hey, hope things are going well with your thesis.

It does appear that the chopped letters issue has been fixed when I tested yesterday.

I am seeing some artifacts with the new scanline system though, where some fonts are possibly not aligned properly to the scanlines, for example, a dash lighting up two scanlines, one brighter than the other, or the horizonal line in a lower case e, also occupying two scanlines.

I'm a little busy for the next couple of days but I'll try to take a closer look this weekend and see if I can provide any more concrete assistance.

from cool-retro-term.

Honestly, if you don't use a font that's supposed to be bit perfect, like the modern default, this is glorious. Scanlines look great.

http://i.imgur.com/8tVYFHj.png

I might be completely satisfied with not using the bitmapped antique typefaces entirely like this.

from cool-retro-term.

Ahahah, the mighty asciiquarium!... I'm glad things are working almost fine.
Anyway the previous solution worked often but as you saw, had problems with some fonts and some scaling levels. In the new version I'm basically enumerating all the possible combination to set the parameters which look best (to my eye) in every condition. It was a boring and tedious afternoon but I think the scanlines are now almost perfect. Let me know.
And of course if you find any configuration (font + scaling) which looks bad, let me know and I'll fix it. Thank you very much for all your testing! I'm glad to have an external opinion.

from cool-retro-term.

When I first compiled and loaded the new version today, in a clean directory, it initially came up with some bizarre artifacts. The glow was misaligned up and to the left a few pixels, the noise elements were the size of entire characters.

http://i.imgur.com/mah3Jwl.png

When I enabled scanlines, the characters were completely unreadable, and appeared as though they were being viewed through a slit. Kind of like the following image, but unfortunately I did not grab a screenshot.

http://spiff.rit.edu/classes/phys312/workshops/w10b/spectra/spec_proper_orientation.gif

After toggling some of the eye-candy settings, though, the program began to behave normally. If I had to guess, I'd say it seems like some values were not pre-initialized immediately after compiling.

I also noticed that if I turn some eye candy elements off, but then load a preset where these elements are on, the element will render, but the settings page shows the effect as disabled.

There's also another settings related issue that I have documented in a screenshot below. If you go from Atari 400-800 to Commodore 64, there's a strange double exposure/alignment issue with the font. If you go to Terminus and then to Commodore 64, the Commodore font renders normally.

Here is an album with some screenshots of alignment issues I am still seeing.

http://imgur.com/a/6CcdJ

Commodore PET, Apple II, Atari 400-800, and Commodore 64 (when you go through Terminus first) look pretty much perfect, although they are a little big for my screen. I think I should be upgrading from this laptop to a larger screen soon.

Finally, I just noticed that the font alignment issue I am seeing on IBM DOS is present at scaling 1, but not at scaling 2. The Atari ST alignment issues seem to be reduced but still present at scaling 2.

Glad you're enjoying the feedback, I'm really enjoying the terminal.

from cool-retro-term.

Most of those issues should be fixed. I'm closing this thread but if some of those issues are still valid please reopen them as new issues dividing them one for each thread. As you might have noticed managing this repository has become much harder so I need strict rules. Thank you very much for all your help here!

from cool-retro-term.