The color picker and Paint3 subs (my contributions) pretty useful as well as save image code, wouldn't be hard to fix, Steve may have already!

https://qb64forum.alephc.xyz/index.php?topic=1651.0 Latest version works just fine with the changes to Function.  Just update your library.  ;)

I don't think you have to worry about that @Dimster.  The "official" QB64 project still has folks at the head of it who can always speak up and nix an idea or revert it from the repo.  There's nothing to stop you from paying someone to make you a personal version of QB64 with a _HelloWorld command built into it, as QB64 is completely open source -- but the official Dev team doesn't have to accept those changes in the repo.

There's not a lot of limitations that Galleon set on how to develop or expand QB64, but one of the main points was: You can't add/alter anything that will break backwards compatibility.  For instance, I've never been content with InstrRev terminating with a -1, like the rest of our commands which terminate with a 0.  Unfortunately, it's now documented in the wiki, and exists in such a manner in folk's code.  Changing it now would break their old programs, and so, it doesn't change -- even though I personally mod my own version of QB64 to always terminate with 0.

If you pay to add XYZ feature to the language, and the Devs allow that feature into the official repo, then nobody's going to be able to pay a larger bounty to undo it. 

Happy to help get you started, though I'm afraid that's about all I can do for you.  I just don't use Excel enough to have any real idea of it's syntax structure beyond the very basics which I shared above. 😉

You have my best wishes for the rest of the project!  👍

Just a few days ago, I had the misfortune of having to fill up my tractor's fuel tank from being almost empty.  400 gallons @ almost $5.00 per gallon...  And then a sinking feeling hit the core of my gut as I realized I was going to have to repeat such an experience dozens of times this year.  /cry

By the time this harvest season comes around in fall, I'm predicting that we're going to see increases in the price of staple foods by everything doubling, if not more at that time!

"And how's this ever rising inflating relate to QB64 and its development?", you guys ask.

It's all because I realize the Devs are people too!  They're going to be facing the exact same financial crunch as everybody else in the world, and QB64 is nothing more than a hobby project.  Who's going to have time to spend on hobbies, when they're working their ass off just to try and keep food on the table?!!

So, that's when an idea came to me that sounds like a Win-Win for everyone involved:  A QB64 Bounty List!

Got some extra cash laying around?  Are you, like me, one of those whose prepared no matter what the future brings?  I've had a lifetime to save and put aside for hard times, so I can comfortably coast through the next several years of my life and weather the increasing inflation.  Others aren't as fortunate -- such as some student struggling to make ends meet while working their way through college.  They might have skills to work on QB64 in places which I don't, but they simply don't have time to devote to working on things due to having to take a part-time job at McDonalds just to keep the bills paid.

So here's my proposal -- A "Bounty System", where people can pledge to donate $$$ for whatever fix, enhancement, or addition they wish to see for the QB64 language.  It'll give Devs a little extra cash for small projects, keep the development of QB64 going, and gives the user-base a chance to help guide what/where the language should go next.  It's a win-win for everyone!

To start us out, I'd like to place a bounty on the following issues:

1) $100 Bounty for a fix to each of the input commands we use.  As they currently exist, each of them is flawed in various ways.  For instance here's one to illustrate the problem with _KEYHIT:

DO
    k = _KEYHIT
    IF k <> 0 THEN PRINT k
    _LIMIT 30
LOOP

Run the above in the IDE, and hold down CTRL and press TAB.  The Tab key is a keycode 9 key.  When it goes down, it should print 9, when it comes up, it should print -9.  Instead, what we see is:  NO keycode for the down press.  Nada.  Zip.  QB64 simply does not report that tab key being depressed at all.  For the key release, it reports a value of -105 -- which is the I key!   CTRL-TAB is *both* unmapped AND mismapped. and it's an excellent example of the problem the command has.

I'll pay $100.00 to whoever wants to go in and fix _KEYHIT so that it maps all the possible keystrokes correctly -- for both up and down states, in the various operating systems we compile to.  I'll also offer $100.00 for the exact same fix to INKEY$ and _DEVICES, making a total of $300 for the three commands to be repaired fully.  From my memory, Inkey$ does the same mismapping of values and _DEVICES is completely screwed up with codes being nothing as they should be to maintain backwards compatibility  with older versions of QB64 (prior to version 1.0 when the glitch was introduced), and it doesn't read various keys at all.

2)  I'll also offer a $100.00 bounty for whomever wants to go in and fix our fonts for us.  The issue here is with various fonts being cut-off and not rendering properly.  I don't have an example ready at the top of my hand, but I'll dig one up of someone wants to tackle the issue.  Basically, with various fonts, letters get truncated off.  The bottom of the "g" might lose several pixels, or the top of an embellished T is completely cut off...   Fix that, earn $100.00

3) I'll also offer another $25.00 bounty for whomever wants to go in and fix our _LOADIMAGE command.  At the moment, it's impossible to load 256-color images -- they automatically convert over to 32-bit images.  It'd be nice for loadimage to work fully like its supposed to.  I think this should be a small fix (as we apparently load the image first and then convert them to 32-bit somewhere automatically), so it's a smaller bounty.

That's all my poor wallet can afford to place a bounty on at the moment, and as for me personally, I'm rather content with what QB64 can already do for me.  I'm not really pushing for any sort of "future development"  (besides a desire for someone to import a video playback library for us via a _LOADVIDEO command, or for someone to fully integrate a text-to-speech system for us), but I encourage any with a little extra cash to post their own "bounties" here for the Devs to look over and work on. 

QB64 is free.  Users don't pay anything for it; yet there's always a large list of things which people want added to it.  I see nothing wrong with offering a few $$$ towards enhancing or promoting development of the project.  The more people who are willing to donate and place bounties on things, the more Devs can treat QB64 as more than just an occasional hobby-project.

Is there anyone else out there willing to donate for a "fix" to something that's been bugging them?  Or willing to donate to have a feature added you've been dying for?  Is there anyone willing to pick up these Bounties and earn a little extra cash on the side, while helping the language grow and expand over time?

I guess only time will tell!

Code: QB64: [Select]

1. _HelloWorld

Your syntax is wrong.  PHEW!  For a moment there, I thought you'd found one of the hidden Easter Egg commands we've squirreled away in QB64!

You'll have to try a little better than that, I'm afraid.  😂🤣🤪

From your example, it'd just be a complication of values.

For x = 1 to 10
  For y = 1 to 10
     If Array(x) = Array(y) then
         Duplicate = Array(x)
         IF Array(x)=Array(y+1) then Tripiplicate = Array(x)
     END IF
etc etc

Isn't the above much easier to understand and follow than what you had?

Reminds me of the way we ended up doing "Hello World" back in high school where we tried our best to drive our teacher completely insane.

Imagine 30+ old Apple IIc computers running a program very similar to this one (no delays needed back then, of course!):

Dang that's fast! Whew!

I do miss the color of drop going to white at end.

How do we go to white at the end?  Is it something to do with this line?

        ElseIf d >= 3 Then
            c~& = _RGBA32(0, 255, 0, 190 - d * 5)

When d is greater than 18, aren't you dealing with a negative value alpha, which overflows back to repeating the same color palette normally?

What's going on here when d becomes a value like 77 (I noticed it that high with a few error debugging lines before)?  Is it somehow overflowing to alter other values than just alpha so that we end up more white than red?