Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A couple of bug reports #7

Closed
ryanfelder opened this issue May 3, 2014 · 9 comments
Closed

A couple of bug reports #7

ryanfelder opened this issue May 3, 2014 · 9 comments

Comments

@ryanfelder
Copy link

Hey, I just got cool-old-term to build and run on ubuntu 14.04/elementary trusty, and I have noticed a few things that could be done to make it a little better.

  1. any part of a letter that hangs below the bottom of the vertical alignment for the line is cut off. the bottom of y and p for example.

  2. the scanlines do not distort with the 'screen distortion' this causes the scanlines effect to render incorrectly

Both of these issues can be observed in this image, http://i.imgur.com/7HocIor.png

Notice how the bottom of the letter p is missing. Also notice how the scanlines are perfectly straight, even though screen distortion is on, causing the letters to spill over from one set of scanlines to the next, causing information loss and less attractive rendering, like at the end of the word laptop. I believe this could be corrected by simply changing the order of operations, applying the scanline effect before the screen distortion instead of after.

  1. the motion blur seems way too intense, even at 1%. I'd like a little motion blur, but less than 1% presently causes.

And some feature requests...

  1. I personally love using a drop down terminal in fullscreen, like guake. If this terminal could be set up to run persistently and appear full screen at a keypress, it would be my ideal terminal.

  2. I'd like to limit the baud rate of the terminal, so I can see the cursor updating the screen.

  3. I like the noise effect, but I'd like a type of noise that's only seen where the phosphor is actually intentionally being lit, kindof like the speckled interference pattern you see when you look at a laser pointer's dot. So, noise in the bright parts, but not in the dark parts, basically.

Thanks for working on this awesome project, I've been looking for something like this for years!

@Swordfish90
Copy link
Owner

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.

@ryanfelder
Copy link
Author

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

  1. 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.

  1. 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.

  2. 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 <
notifications@github.com> 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
.

@ryanfelder
Copy link
Author

New motion blur looks fantastic

@Swordfish90
Copy link
Owner

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.

@ryanfelder
Copy link
Author

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.

@ryanfelder
Copy link
Author

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.

@Swordfish90
Copy link
Owner

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.

@ryanfelder
Copy link
Author

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.

@Swordfish90
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants