QB64 Phoenix Edition 3.4.1 Released

[mnrvovrfc]

When I think back to tape-loading days, when just loading the programme to be used could take up to 10 minutes, I realize how far we've (you've) come.

Someone who might know something about 8-track tapes! Those looked cool but took too long before the "click" and then waiting another several seconds before the music came out again LOL.

Also having to use "SKIPF" on the Color Computer 2, that neither saved nor loaded... what an useless statement! How about the number of I/O errors I suffered trying to load a program from cassette? If a program could be gotten in five minutes or less it was great, except such a program was a few lines long. I used a word processor that could save data files to cassette but it did "too many" yelps for my taste. It was easy however to recover some data if not all of it.

There was more. A "POKE" was given away for Color Computer 3 that made things run about twice as fast. However if the programmer forgot to "disable" that trick then saved a 1000-line program to cassette, then well... that's why the floppy drive was introduced for that computer.

[DSMan195276]

https://qb64phoenix.com/forum/showthread...63#pid9163

I should have a decent amount of freetime next week, I'll try to take a look at fixing #234.

[mnrvovrfc]

https://www.khronos.org/opengl/wiki/Prog...Resolution

[Coolman]

@mnrvovrfc. it's a software problem. the operating system has nothing to do with it. giving up windows for linux was the best decision i ever made. no more crashes, no blue screens, everything works fine. i've installed kde neon on many computers. even on a pentium4 with only 4gb of memory and a mechanical hard drive, the system is still usable. that said linux is not used like windows. after installation, it must be configured to manage memory, disk cache and other options efficiently, this is done by modifying some files in the system. do not install the proprietary drivers for the graphics card as they cause many instability problems. opensource drivers are sufficient even for 3d.

the latency problem I found is probably due to the detection. for example, I use kdialog often in scripts and it doesn't take about a second to run, example for kde, type in command line :

kdialog --getopenfilename ~

it's practically instantaneous.

@SMcNeill. if it's a problem with freeglut, just report it to the developers. i had a small problem with kde during an update years ago. i informed the developers and it was fixed in one day. that's the strength of opensource...

@DSMan195276. thank you for your efforts and your expertise...

[DSMan195276]

the latency problem I found is probably due to the detection. for example, I use kdialog often in scripts and it doesn't take about a second to run, example for kde, type in command line :

kdialog --getopenfilename ~

Yeah I was wondering if that might be the cause for what you're seeing, but the detection should only happen once and then it caches the result.

[mnrvovrfc]

the latency problem I found is probably due to the detection. for example, I use kdialog often in scripts and it doesn't take about a second to run, example for kde, type in command line :

kdialog --getopenfilename ~

it's practically instantaneous.

Again you're demonstrating you know about only one D.E. and know about it well, much better than everybody else in this forum. This is something that will not work on any Linux installation that has nothing from KDE. Maybe it would work in XFCE with KDE stuff installed... but why do I want a "fat" open file dialog that looks like Dolphin away from Plasma? :O

Nobody likes being stuck adjusting system settings regularly only to make it run faster. One that is knowledgeable, a Linux expert could get away with it regularly. But that's like 1% of the population of users of personal computers. Somebody else with deep knowledge of Macintosh or Windows could be the same way. But with Linux is harder because there are different mixes of the same thing.

You didn't answer my question about logging in, because that might take much longer than one second. It cannot bother me, because I choose to put a few installed distros onto pluggable USB disks to check them out. I cannot "virtual box." I don't like live distros and even less now with persistence after checking out AV Linux and its leaving such a bad impression. In addition I tried "Liveslak DAW" and it was a mother to have to copy it to another USB drive only to be able to get persistence... but that must have been a limitation of Ventoy.

On at least one external USB disk I could start up faster than I could with the built-in HDD of my laptop. But that still takes some time, at least 30 seconds from turning on computer to being able to use the desktop. That's what I meant in my previous post.

Maybe on QB64(PE) earlier than v3.4 you could change the "libqb.cpp" to use "kdialog" instead of "xmessage", to fake the call to "MessageBox" function that was originally meant for Windows API. It's not as hard as it looks; I adjusted it previously so it used "zenity".

The fix has to be as universal as possible on Linux, it cannot depend on anything KDE, GNOME, XFCE etc. installed. Because the QB64PE developers decided to bypass "freeglut" on Windows to get the desktop width and height, I think an attempt should be made on Linux to check if X11 is in place, and then at least call "xrandr" command-line program or some other scheme. It might not solve the race condition that Steve described. Also the problem would remain, having to wait for "SCREEN _NEWIMAGE()" with much larger dimensions than old VGA.

[Coolman]

the latency problem I found is probably due to the detection. for example, I use kdialog often in scripts and it doesn't take about a second to run, example for kde, type in command line :

kdialog --getopenfilename ~

Yeah I was wondering if that might be the cause for what you're seeing, but the detection should only happen once and then it caches the result.

indeed. the second time, it's better. i looked at the source code a bit:

for graphic mode:
windows_wchar windows applescript kdialog zenity zenity3 matedialog
shellementary qarma yad python2-tkinter python3-tkinter python-dbus
perl-dbus gxmessage gmessage xmessage xdialog gdialog
for console mode:
dialog whiptail basicinput no_solution

it's a lot. no wonder it's slow at first.

[mnrvovrfc]

for graphic mode:
  windows_wchar windows applescript kdialog zenity zenity3 matedialog
  shellementary qarma yad python2-tkinter python3-tkinter python-dbus
  perl-dbus gxmessage gmessage xmessage xdialog gdialog
for console mode:
  dialog whiptail basicinput no_solution

Wow! No wonder cross-platform programming could be a headache. Of course proprietary stuff would say a lot about it.

[gaslouk]

Congratulations, very good job. We are also looking forward to multilingual support. So far English and Spanish are supported, we will gladly accept Greek as well. Good luck in your work.

[mnrvovrfc]

One hurdle will have to be overcome: Unicode. The "standard" characters produced by a QB64 program doesn't have enough Greek symbols, only those considered good enough for mathematics. Otherwise have to make do with letters that look enough alike such as "H" and "n" for Greek "eta" but might not be acceptable. Irritatingly, "sigma" seems to be the only one having both its states although not the "s-like" one usually used at the words ending in "os".

I don't know if one of you who is Greek would like reading his/her native language in symbols like this. This goes for Russian and other languages having other writing systems. Otherwise, it would have to be solved with something stronger than the somewhat broken "_MAPUNICODE" implementation.

If only the QB64 IDE and compiler messages are desired in a language other than English, then it might require something like the "gettext" library with "PO" file support. I don't know much about that, I'm only speaking out of looking at some "MIME" type files having short messages written out in different languages. Note that the BASIC keywords and built-in function names would always have to be in English -- this comes from the inventors of the programming language.