QB64 Phoenix Edition - BASIC programming language

For discussions about programming and projects not necessarily associated with Porteus.
gnintilgyes
Black ninja
Black ninja
Posts: 73
Joined: 14 Sep 2022, 17:52
Distribution: Debian

QB64 Phoenix Edition - BASIC programming language

Post#1 by gnintilgyes » 15 Sep 2022, 23:25

QB64 Phoenix Edition is a front end to "g++" which allows writing code that is nearly 100% compatible with M$ QuickBASIC v4.5 (interpreter and compiler) and with QBasic (interpreter). The language was extended to support loading images and music, for Internet functionality and for safe memory management. The system comes with an IDE which is similar to that of QuickBASIC. It has a help system discussing the keywords, data types and a few other things about the programming language. It does active syntax checking, and could be configured for appearance and debugging. The editor is slow and a bit tedious to use, however. Instead you could compose your programs with your favorite source code editor.

Very important! Almost forgot to say this: on Porteus the "05-devel.xzm" module is required activated.

Note there are multiple flavors of QB64 around but the Phoenix Edition is the one being actively developed at this time. Recently QB64PE regained the ability to load and play back ancient tracker modules such as MOD and IT; for a long time MP3, OGG (OGG Vorbis) and WAV were supported. At this time the team is working on MIDI file support which includes Soundfont integration into an user's executable file.

Not all code could be ported. There is code floating around for M$ BASIC Professional Development System v7.1 and for Visual Basic for DOS v1.0 (thought of as the M$QB v5) which has a few things like currency data type, "DIR$()" function and the ISAM database support, which are not portable to QB64. Cannot load "LIB" nor "QLB" files created by QuickBASIC compiler, or for "QBX" program that came with BASIC PDS v7.1. The source code for those has to be recompiled by QB64. QB64 Phoenix Edition is not an event-driven programming language, is not an object-oriented programming language (yet) and doesn't support kits to create GUI programs as known so well on later versions of Visual Basic for Windows.

The user has to be aware of some feats with QBasic in particular. For example, what relies too much on old BIOS and MS-DOS interrupts because it was refactored in WindowsXP and M$ expected programmers then to use Win32 API calls instead. Programs that have too much of words like "ABSOLUTE", "DEF SEG", "DEF FN", "POKE", "SADD" etc. will have to be modified. A program that allows changing the "DATE$" or "TIME$", of course, cannot be ported to Linux. There are a few other things that have yet to be supported on Linux, like replicating AutoHotKey faking keyboard and mouse gestures with "_SCREENCLICK" and "_SCREENPRINT". That said, whatever a beginner or an intermediate BASIC programmer could come up with, QB64 Phoenix Edition could handle.

Please read the Wiki, in the "Frequently Asked Questions" for example to guard about games written in QBasic which use "FOR... NEXT" loops or the like for delaying. One of them was the "QBasic Nibbles" that came with that interpreter and the rest of MS-DOS v5. Should instead use "_DELAY" or "_LIMIT" to keep CPU usage sensible.

Download only from the provided link. As I've said, there are other "versions" of QB64 but they have different levels of "progress" and are by different teams. There is no "official" version of QB64; that has died because the original author, Galleon is no longer involved in the project. The Phoenix Edition development is still being guided by the rules he set forth before he retired. If a package such as DEB, RPM or other "popular file suffix" appears, don't touch it unless it does come from the QB64 Phoenix Edition.

Forum which has a link to be invited into Discord.

Note: I'm not advertising here and I'm not one of the contributors of QB64 Phoenix Edition. I'm only sharing an application which might make life easier for somebody coding in C++ or Python or something else, or might want to make a simple game or graphics/sound demonstration. Sorry if this is TL;DR

In case you're interested in creating programs with this system and want to run them in Slackware, the following libraries would be required:

libGL.so.1
libGLU.so.1
libX11.so.6
libc.so.6
libgcc_s.so.1
libm.so.6
libstdc++.so.6
libz.so.1

The last one, for "zlib" isn't actually listed by "readelf" but might be required for use of "_DEFLATE$" and "_INFLATE$", which are commands that mimic "gzip" functionality for strings. I've done the check on "qb64pe" executable itself built on Porteus and on at least two programs created with it.
__________

I patched "libqb.cpp" to use "zenity" instead of "xmessage" so an user program is able to report runtime errors on a different Linux distro. This is important for debugging. Originally QB64 was only for Windows but the first author decided to make it portable, and therefore the "MessageBox()" Win32 API call had to be covered for different operating systems. There was no way to acquire "xmessage" in the other distro, as unbelievable as this might seem. Its dialog is a bit ugly and might be too small for some of you who have large screens. After it's dismissed, a complaint (unrelated to the user program) could appear on the terminal, which is annoying. What if you want to use "zenity" dialog instead? ROFL Please tell me that you want to on KDE Plasma where everything else looks pretty and it seems to be what everyone wants. Then make the following changes:

Beginning with line 2612 there is this sequence:

Code: Select all

    if (type == MB_YESNO) {
// whatever
        static int status;
Change that "// whatever" to:

Code: Select all

                qbs_set(s,qbs_new_txt("zenity --question --window-icon=question --ok-label=YES --cancel-label=NO --no-wrap --title="));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt(title)));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt(" --text=")));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt(title)));
                qbs_set(s,qbs_add(s,qbs_new_txt(" : ")));
                qbs_set(s,qbs_add(s,qbs_new_txt(message)));
                qbs_set(s,qbs_add(s,qbs_new_txt("                         ")));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=0;
Starting on line 2640 there is another bunch of lines:

Code: Select all

    if (type == MB_OK) {
// change me
        system((char *)s->chr);
"// change me" should be modified to:

Code: Select all

                qbs_set(s,qbs_new_txt("zenity --error --window-icon=error --no-wrap --title="));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt(title)));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt(" --text=")));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt(title)));
                qbs_set(s,qbs_add(s,qbs_new_txt(" : ")));
                qbs_set(s,qbs_add(s,qbs_new_txt(message)));
                qbs_set(s,qbs_add(s,qbs_new_txt("                         ")));
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=34;
                qbs_set(s,qbs_add(s,qbs_new_txt("?"))); s->chr[s->len-1]=0;
Then rebuild QB64PE.

gnintilgyes
Black ninja
Black ninja
Posts: 73
Joined: 14 Sep 2022, 17:52
Distribution: Debian

QB64 Phoenix Edition - BASIC programming language

Post#2 by gnintilgyes » 17 Sep 2022, 05:41

This program creates a graphical window with the Porteus logo near the center which does color flares. I tried, in vain to make it just like the MATE menu button logo. I wrote a program more complex like this which gave me something a lot like the logo seen on the forums but with four tentacles. I didn't want to use "CIRCLE", desired to plot with trigonometric functions in order to get a more striking or "grainy" effect.

Code: Select all

option _explicit
dim as long ascr, colr
dim as single x1, y1, x2, y2, x3, y3, x4, y4
randomize timer
dim ke$, esc$
esc$ = chr$(27)
ascr = _newimage(800, 600, 32)
screen ascr
colr = _rgb(128, 192, 64)
x1 = 494: y1 = 246: x2 = 558: y2 = 340
x3 = 626: y3 = 330: x4 = 642: y4 = 274
x1 = x1 - 150
x2 = x2 - 150
x3 = x3 - 150
x4 = x4 - 150
do
    _limit 50
    colr = _rgb(randy(128, 32), randy(192, 16), randy(64, 8))
    circle(x1 + rnd, y1 + rnd), 150, colr, _D2R(0), _D2R(100)
    circle(x2 + rnd, y2 + rnd), 150, colr, _D2R(60), _D2R(180)
    circle(x3 + rnd, y3 + rnd), 150, colr, _D2R(120), _D2R(260)
    circle(x4 + rnd, y4 + rnd), 150, colr, _D2R(180), _D2R(320)
    ke$ = inkey$
loop until ke$ = esc$
end

function randy%% (centerval as integer, range as integer)
    static v as _byte
    v = int(rnd * range - (range \ 2))
    randy%% = centerval + v
end function
Image

gnintilgyes
Black ninja
Black ninja
Posts: 73
Joined: 14 Sep 2022, 17:52
Distribution: Debian

QB64 Phoenix Edition - BASIC programming language

Post#3 by gnintilgyes » 01 Nov 2022, 23:31

QB64PE was updated to v3.4.

It was long in coming, but now it's possible to write programs having the "professional" look dialog boxes, ie. "messagebox", "open file" dialog, "save file" dialog, folder picker, "input text" dialog, and color chooser. On Linux the "open file" dialog function supports the "recently-used.xbel" mechanism. Also there's a statement that allows the user to program a notification window, like the one that advises Internet connection on or off.

The fix I provided in the first post is no longer necessary LOL. Sorry if you liked "xmessage".

Erm, forgot to indicate something.

https://qb64.com/

This is the link to what is called the "QB64 official" edition. This is a different fork with different programmers, forums and roadmap from QB64 Phoenix Edition. This does have packages for 32-bit and 64-bit for Windows, MacOS and Linux, just like QB64PE. The lowest common denominator is C++ in both programming systems. It causes people to think "QB64" is divided, but it's the same as what they think about Linux...

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

QB64 Phoenix Edition - BASIC programming language

Post#4 by Rava » 02 Nov 2022, 06:41

gnintilgyes wrote:
01 Nov 2022, 23:31
QB64PE was updated to v3.4.
Thanks for that.

Do you mind creating a minimal module that has only the bare minimum of dependencies for QB64PE to run in Port 5.0x86-64 so that the user won't need 05-devel?

Also, how resources-hungry is QB64 compared to more modern script based solutions, e.g. python (is included in Port by default) or perl (not included by default)… or a simple sh or bash script?
Cheers!
Yours Rava

gnintilgyes
Black ninja
Black ninja
Posts: 73
Joined: 14 Sep 2022, 17:52
Distribution: Debian

QB64 Phoenix Edition - BASIC programming language

Post#5 by gnintilgyes » 02 Nov 2022, 18:26

I could create an XZM but QB64PE is being updated at least once a month. Let me see what I could do. It might have to wait until an issue with "freeglut" is resolved, because the commands are bumming out to measure the screen dimensions, while it works well on Windows because it uses a Win API call. :roll:

In other words, you'll have to hard-code the screen dimensions such as 1024x768 and not use "_SCREENIMAGE" function, for example.

This is only for those users most interested in programming fancy graphics, for games or for showing off some math discovery. Otherwise QB64PE provides a "mainwin", which is 640x480 if I'm not mistaken. No need to set it up "manually", by default all "PRINT" statements go in there but there are no scrollbars. Colors are supported easily, and it has limited monospaced font support; only one font at a time could be loaded and it's easy to go back to "_FONT 8", "_FONT 14" or whatever. Alternatively the program could be set to output directly to the terminal by putting "$CONSOLE:ONLY" (without double-quotation marks) near the top of the source code.

A possible barrier would be the "qb64pe" executable and the "internal" directory have to be on the same level. Therefore the executable just can't be dropped into "/usr/bin" unless that directory is also, and cannot be put in "/opt" because at least the "internal" directory needs to have write permissions for the "guest". The executable created by QB64PE of course could be guided into a writable directory, but I mean when that compiler needs to create its hundreds of text files and then call "g++".

The created executable file on disk is at least 1MB in size. A large project (before v1 QB64 used to be able to compile itself because a large part of it, especially the IDE was in BASIC code) could approach 10MB but rarely. In RAM it will depend the most on the loaded image and music files, and on large string variables. Be careful with what is copied into the clipboard!

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

QB64 Phoenix Edition - BASIC programming language

Post#6 by Rava » 02 Nov 2022, 19:38

gnintilgyes wrote:
02 Nov 2022, 18:26
I could create an XZM but QB64PE is being updated at least once a month. Let me see what I could do. It might have to wait until an issue with "freeglut" is resolved
Take your time…
Cheers!
Yours Rava

gnintilgyes
Black ninja
Black ninja
Posts: 73
Joined: 14 Sep 2022, 17:52
Distribution: Debian

QB64 Phoenix Edition - BASIC programming language

Post#7 by gnintilgyes » 16 Nov 2022, 22:05

Well, the point-release is out, v3.4.1

One issue fixed specifically in Linux: no more worrying about placing apostrophes or double-quotation marks as part of a string variable which is the message text of one of the new dialog-creation functions! Yeah right! Let's see if somebody more used to Unix/Linux than Windows could find a way to break it.

Sadly, for those who have really big viewports for your computer, and consider the 640x480 too small for your taste, you will have to insert a short delay before "SCREEN" is used to create the main program window. A race-condition was found in the process of using "_DESKTOPWIDTH" and "_DESKTOPHEIGHT" to get the maximum screen dimensions, and with "_SCREENIMAGE" to refer to the desktop view by "handle". Right after using any of those functions, and before calling "SCREEN" statement, the programmer must place a "_DELAY 0.5". (Might need a longer delay but this programming system is not for you if you like to complain about stuff like that. The "_MESSAGEBOX" for example takes a few seconds to come up. Wait for convenience.) What's worse, if the screen to create is rather large, a further "_DELAY 1" or longer delay is required to give the graphics system time to draw the window completely. Otherwise a few statements to print text and to draw to the screen will be missed.

This race condition doesn't happen on Windows because Win API calls are used instead to figure out the desktop extents. :/

Another thing to watch out is to not make the rectangle larger than the "immediately usable" screen space. For example I have a laptop which has only 768 pixels vertically. So I cannot have an user program screen that is larger than 670 pixels, according to the top or bottom panel of the D.E. Especially KDE Plasma or certain flavors of XFCE which love super-large panels to display the clock, app launcher buttons, main menu etc., this count has to be figured out and make sure to use that amount or less; greater than that causes graphics at the top of the screen to be lost: it seems to be scrolled up and out of view.

I would like "equal treatment" for Linux and MacOS users as well as Windows about some features of QB64PE and that's why I'm holding creating a module yet.

gnintilgyes
Black ninja
Black ninja
Posts: 73
Joined: 14 Sep 2022, 17:52
Distribution: Debian

QB64 Phoenix Edition - BASIC programming language

Post#8 by gnintilgyes » 23 Nov 2022, 20:19

LOL one of the developers didn't know there was such a thing as "xrandr" to get screen dimensions on Linux. However is it different for Wayland?

The library counterpart to "xrandr" terminal program is in libX11.so, isn't it? :facepalm:

In addition to "_DELAY" also use "_SCREENEXISTS". Windows users don't have to deal with that.

I had good intentions presenting this; it could be the easiest way to quickly come up with a graphics-and-sound demonstration. However this might be a better solution to one who uses a web browser regularly:

https://qbjs.org/

A few people like me who know about BASIC dislike OOP. They are willing to "pay the price" of putting up with the antiquated programming language which just receives minor adjustments to it, instead of having to learn Python, "allegro", "cairo" or something else like that just to get kewl graphics, and another set of libraries to play some OGG file while the hero moves around inside some home-made RPG.

That's what I mean, like dragon-drop on Linux won't be supported for a while because there are "too many" desktop environments! I understand that, and I also understand some people want to set much larger screens than VGA resolution. However I still would like "equal treatment" if it's possible for hobbyist freeware.

Post Reply