Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
AAFB
#11
This is so good, I wanted to learn ASCII graphics.
Now I've got a cool library to read.
Reply
#12
Quote:It does not render to the console / terminal. There are other of libraries that do that. However, they are limited to a reduced set of ASCII characters. AAFB uses all 256 ASCII characters.
must tell some people like this:

"screen 0" is not the same as "terminal" which is "cmd.exe" on windows.  or konsole or gnome/mate/xfce terminal or xterm or "urxvt" ... argh!  or the like program rarely opened on macos.  "screen 0" in qb64/phoenix is like a "mainwin."  what used to be a mandatory screen only so you could use input and print.  if not then deal with the mess of "gui programming" in freebasic or other basic language product.

another good one!  well done.
Reply
#13
My only hesitation to using this in all my apps is high CPU output. Since I almost never do graphics, I really don't know what is the norm to expect, but I can tell folks, straight up, that the CPU goes way up with even minor graphics, like buttons or effects for buttons when using hardware acceleration. If that is less true for this graphics interface that would be wonderful.

I remember the old days when we had to protect monitors by invoking home-made screen savers. Now with graphics available in screen 0 causing more extensive CPU usage, maybe a similar situation should be coded when a program, that stays on all day, is idle.

Pete
Reply
#14
(02-04-2025, 10:44 PM)Pete Wrote: My only hesitation to using this in all my apps is high CPU output. Since I almost never do graphics, I really don't know what is the norm to expect, but I can tell folks, straight up, that the CPU goes way up with even minor graphics, like buttons or effects for buttons when using hardware acceleration. If that is less true for this graphics interface that would be wonderful.

I remember the old days when we had to protect monitors by invoking home-made screen savers. Now with graphics available in screen 0 causing more extensive CPU usage, maybe a similar situation should be coded when a program, that stays on all day, is idle.

Pete
You're right graphics can definitely drive up CPU usage, especially with hardware acceleration. For apps that are idle for long periods, it's a good idea to implement something like a screen saver or a low power mode to prevent unnecessary CPU strain. Modern graphics interfaces, like those in UI frameworks, can be more efficient, but still, if you're not using graphics much, you can keep things light and save resources. It's all about finding that balance
Reply




Users browsing this thread: 2 Guest(s)