One year of Phoenix Forums!

[SMcNeill]

I can't see how you'd have a problem with non-BASIC things being added, considering we have a plethora of underscore commands which were not used in BASIC. Not to mention MEM, which is an object of sorts, that also did not exist in BASIC.

I guess it's all a matter of perspective. To me, the underscore commands ARE part of our language -- just modern extensions to expand the old QB45 capabilities (let's be honest, who the heck would want to make games and such at 320x200 screen resolution anymore??) -- and they're something that evolved organically over the last 20 years of development of QB64. Since I knew QB45, I had a starting point into the language here, and then I could slowly learn and incorporate the new stuff as I needed it.

On the other hand, I see QBJS as a new language that is working from the very beginning with a premise of *combining* QB-commands and JavaScript, meaning that to use it properly, someone would have to have a basic understanding of both languages. For me, I'd have to learn *both* the BASIC-base *and* the QBJS-base, before I could make use of it. It's just not something I'm personally interested in learning and doing. As I've mentioned previously, I have several PCs which are off-line and don't even have a browser installed on them, making QBJS *not* the proper tool to use with them.

And kindly don't get me wrong: I have *nothing* against QBJS. In fact, I'm quite impressed at what dbox has managed to create and maintain, and I'm looking forward to see it grow and develop in the future. That's why we have a subforum here for it, and why I dedicated part of our server space when vince asked, so that a set of forums could be set up and dedicated to QBJS fully: https://qb64phoenix.com/qbjs/

QBJS just isn't a tool that I need for myself, but I'd encourage anyone else who's interested to give it a try and see if it'd be useful for them. For me, personally, I need portable EXEs which I can move from one machine to another, and QB64 gives me that, while QBJS gives the flexibility of moving from browser to browser.

The biggest problem I see with QBJS is the same style problem as I see with development for Linux -- it's impossible to test for all the different user bases out there. There's one simple reason why I tend to code exclusively with Windows in mind for my personal needs -- things tend to just work. An EXE on my PC will run on my Laptop, my neighbor's Windows machine, my cousin's windows machine, and my Aunt Sally's Windows machine. On Linux, that's not always true at all, as Mint might not run while Ubuntu will, and Archlinux is always questionable, with questions about KDE vs Gnome vs rootbeer vs limes.... Too many individual configurations and components which might -- or might not -- be supported, making it hard to actually say, "This works on Linux." QBJS has that same difficulty in development -- too many browsers out on the market which people are using which might, or might not, support any given feature. dbox, like us, tests and tries to make things as universal as possible, but no matter how hard you try, there's going to be folks who won't be able to make things work.

For me, personally, a Windows EXE file is what I need, and for that, I'm thankful for QB64PE -- but I'm also thankful that folks have choices so they can choose what suits their needs the most. A metric socket isn't much use on an imperial nut.

[mnrvovrfc]

Some of you have to update your files about Arch Linux and descendants. Because it's getting more stable, and especially with Wine, better compatible with Windows programs than Debian-based right now. I would never recommend Debian for anything for somebody who needs to run decade-2000 developed software. Especially not games, with the heavy reliance on "winetricks" because lately the guys at Arch Linux aren't even updating it. As the Debian devs move into "Bookworm" they broke a lot of stuff because compatibility with Windows is not their priority. In fact, it's not the priority of any Linux distro makers, but somehow Arch could get it right largely because they revise Wine "staging". Debian goes with "repacks" on the last "stable" version of Wine.

It's not perfect. Many Windows programs prefer Windows. It's frustrating when working with a music plug-in and the stupid thing refuses to show the GUI which is essential in knowing what has to be done and what to adjust. The app could throw an exception instead attempting to load one of its modules. It's frustrating as well having to buy an expensive music-creation application to see if the support in a strange operating system is good enough. "Just get REAPER, now there's a native Linux version of it!" When I purchased my license for REAPER, it was at v2 and there was no Linux version, had to use the Windows version through Wine. It has worked out pretty good for me so far on Fedora 36 MATE and Spiral Linux KDE. I had the license through v3 but I'm probably not going to load that any longer -- there is no need. Since then they raised the price of the non-commercial license, making sure I'm not interested in buying any longer. I could barely afford my Internet connection.

There is another problem with using the Linux version of REAPER. Just like Ardour, MusE and any other Linux app, the user is stuck using plug-ins for Linux! Cannot use the plethora of Windows VST plug-ins, and Wine cannot help there. Although half of them are buggy and ordinary with the sound, but why I cannot just use it? Now there's this Yabridge which is nice but without Wine it's not appealing to me. Before that I had to deal with Carla being buggy as hell, cooperated only in a 64-bit-only operating system where I couldn't install Wine.

I'll bet that if it weren't so doggone difficult to get "multilib" on 64-bit Slackware, even that implementation of Wine would be better than Debian's.

Also there's the urgency to move up from X-dot-org to Wayland visually, and from Pulseaudio to Pipewire with sound, making things a lot more complicated. Soon we will not be able to use our 10+ year old PC's anymore with a few Linux distros. Go into BlendOS download page and they tell you that you need a "modern" computer to work with the live ISO because they boast the latest GNOME v44 with all its memory-hogging tendencies.

This is for some of you who believe I defend Linux more than Windows. I would still have been on WindowsXP 32-bit if only one of the two Toshiba laptops I had, never failed me and I didn't have to throw them away. I would have never gotten past 32-bit Ubuntu Studio with my Linux experience and given a hoot anyhow about 64-bit. I wouldn't have been here talking to you about a 64-bit programming system.

[mnrvovrfc]

Dim result As Object   <-- What type is an Object?  It's not one from BASIC

This is possible in OpenOffice.org/Libreoffice BASIC. Last I checked was OpenOffice.org Writer v3 long ago LOL.

[bobalooie]

I'll bet that if it weren't so doggone difficult to get "multilib" on 64-bit Slackware, even that implementation of Wine would be better than Debian's.

Slackware is definitely an old-school distro; installing multilib was an adventure.

[aurel]

yeah ..the underscore commands are really ugly
and i don't see it in any other BASIC ..only in thinBasic with combination
like TBGL_SetPixel() or something like that

[Ultraman]

I have zero issues with Wine (I'm including Proton, Lutris, and Bottles since they're all forks of Wine), really. It runs the majority of my software at native performance and some of my games at native, if not better than native, performance. And I'm on Zorin, which is based on Ubuntu. I've been on it for a few months now and I don't feel the least bit tempted to move back to Windows. Even my DSLR works great in Linux as a webcam with full resolution and framerate. My VHS to digital USB device works right out of the box on Linux as well. Zero issues. Anything I can't accomplish on Linux I just use Shadow PC for. Mainly, that would be for my AI upscaling software, which does not have a Linux build and does not work in Wine. But I run AAA games on ultra settings with raytracing and even DLSS. No issues whatsoever and plenty of frames. I use Bottles for Epic Games and some Steam titles. Lutris works great for Ubisoft titles and any games that use a physical disc. Hitman: Blood Money works better on Linux than it does on Windows, surprisingly enough.

[mnrvovrfc]

No more whining. No worrying about finding enough users for one hobby product or another. So there are at least three branches growing apart and, hopefully at the same time, growing together. QB64 Phoenix Edition, QB64 "Official" edition and QBJS. May they all prosper.

[DANILIN]

Happy BirthDay

[Kernelpanic]

@Danilin - If you're going to do something, then do it.  [url=https://www.dict.cc/?s=it.][/url]

[Wiggums]

I don't remember if I announced it here on the forums, or not, but on April 1st I paid for and renewed our domain and servers for another year -- so QB64PE isn't going away anywhere anytime soon. 



Donations for the last year came up to about $210.00, and total renewal costs were about $260.00 (if anyone's interested), with the final $50.00 coming from yours truly.  Our costs are actually quite manageable, and that's even with me not trying to promote the Patreon or to spam anyone for donations, or sell advertising space or any of that other junk.  I truly don't foresee it being an issue for us to stay up and going for the indefinite future.

  Long life to QB64PE, whether or not it gets another update.

We'll be getting more updates.  It's just that the things folks are working on right now are rather large in scope and will take a bit for implementation and testing.  We're pushing for changes to the input library to help remove those unregistered and mismapped keystrokes (I think all the _BUTTON and _DEVICE inputs are fixed now, but there's still work ongoing for _KEYHIT, _KEYDOWN, and INKEY$).  The font library is being replaced and updated, which should do several things for us.  (Key is a basic increase in print speeds of anywhere from 200% to 600%, from initial testing.  PrintWidth is getting a fix, so it now calculates variable width string size about 900% faster.  Fonts are being cached better, printed faster, and hopefully will be rendering better with less cut-off, in the future.)

Both of those are MAJOR fixes and require a lot of work behind the scenes with QB64PE, so I hope folks can understand why we haven't pushed an updated version out for the last little while.  Hopefully the next update will come Soon(tm), but since we're all just hobbyists working on this in our spare time as life allows us too, don't expect any sort of release date or deadline to ever be announced.  It'll just get here when it gets here, and we all hope it's Soon(tm), just like the rest of y'all. 

I appreciate all the hard that people have put into keeping QB64 going.  Steve has helped me a lot in the past with sample code to work around slow line input calls.  The problem is probably fixed by now, but I'm still using his code.  Thank you!  Thank you!  Thank you!