I was playing with water again today and came across this, so I thought I would put it here. It shows random streams of water pouring down. I first had PSET but changed to filled-in CIRCLE with an oblong shape for each drop. One important thing I finally learned is how to make a random number between a certain negative number and a positive number, just make both a positive and a negative and add them together. Took me long enough. LOL

Hello all,

I am currently working on a Raylib wrapper. However I can't get it to show a image on the screen. Every time I do, it crashes the program.

Color issue is figured out. Need to figure out how to load and draw image functions aren't working properly.

Full wrapper code: https://github.com/gAndy50/Qb64Wrappers/...aylib42.bi

Wrapper code

I just wrapped up a new faster edition of my string math routines. Jack provided another source of string math code from Treebeard. Treebeard's structure have many, may subs and functions. If you added it to your routines, you would add 50 subs/functions to work with addition, subtraction, multiplication, division, and square root calculations. Now you only need to call one sub for each of those, and then those 5 subs call the other subs and functions. In my original string math, which did not include square root, everything was contained in one sub. YOU called one sub, using an operator like "+", "-", etc. and the string math operation was returned. That's a lot less clutter when adding such a routine to function in another program.

So...

Which method do you guys prefer, and what pros and cons do you see in both if SEVERAL are needed to complete a library?

For me, it's the following.

SUBS and FUNCTIONS:

Pros:
Easier for the developer to work with when debugging.
Fewer problems or no need at all to clear variables.
Advantage to passing variables by reference. It's a neat trick to change the names without additional renaming statements.
Faster to code, provided you use TYPES for many passed variables to cut down on the variable lists passed.
Can be identified in the editor (IDE) easily enough if a prefix is used for each like SUB Smath_Mult, SUB SMath_DIV, etc.

Cons:
Harder for the user to find their own program subs and functions n the mix.
Cluttered SUB/FUNCTIONS lists to sort through in the IDE.
Requires multiple CALL arguments instead of just a single call the library sub like CALL StringMath().


------------------------------------------------------------------------------------------------------------------------

GOSUBs in a single SUB

Pros:
All code contained in one easy to port sub routine.
Less project time working out passing variables; (e.g., GOSUB StringMult instead of String_Mult var1, va2, var3, etc.
Keeps the subs and function list in the editor clean, making it easier to navigate the program to which it is ported.

Cons:
More work making sure variable names do not conflict with other GOSUB routines, meaning  more need for unique variable names.
More work zeroing variables.
Possible stack space issues if too nested and a RETURN is missed.
Harder for the developer to work on in the IDE, although Alt arrow left indexing helps some.

--------------------------------------------------------------------------------------------------------------------------

Anyway, what other pros and cons come to mind and again, which method would you rather use as a library addition in your own programming projects?

Pete

Documentation public domain 08/15/2014:

Copyit v5.5a: File copy utility (PD 2014):

Copyit is a small yet powerful replacement to the DOS Copy and Xcopy commands.

"If it can't be copied with Copyit, it probably doesn't need to be copied."


Copyit55.zip for VBdos
Copyv9r5.zip for QB64

Attached Files

  COPYIT55.ZIP (Size: 200.05 KB / Downloads: 34)
  COPYV9R5.ZIP (Size: 586.99 KB / Downloads: 43)

While working on the tutorial site I decided the "Vectors, Angles & Rotation" lesson needed rewritten. Over the years I've had a few people point out that I was calculating these using methods much more difficult than needed. Also pointed out was some incorrect terminology I was using.

So, over the past week I went on a math quest to try and get these concepts correct. I decided to write a small library of routines to work with angles, vectors, and radians.

If you are mathematically inclined could you please take a moment to look over the code for any glaring errors I may have? Perhaps better ways of doing the math, my wording, etc.. I'm completely self-taught when it comes to higher math (Algebra II in high school) and don't always know the correct nomenclature to use. I believe I have it right this time from the week-long math brain-bender I went on.

These routines will be incorporated in the lesson and I plan to write a new lesson for creating and maintaining your own libraries using this one amongst others.

Well guys, all of us here on the development team are now happy to announce that we've officially released version 3.0 of QB64-PE!

Now, I can hear some of you already asking (and a few complaining) about, "Gosh Timmy, isn't that a large jump in version numbers suddenly?"

No.  No it is not. 

As we've explained in the past, the reason why we dropped back down to below 1.0 as our version number was simply because we weren't confident that what we were publishing was a stable release.  We branched off from the last development version that the old time had left behind, and were uncertain if everything they'd been working on was finished, or still a work-in-progress and unstable.  In our opinions, anything 1.0 and above should be considered a stable release and not one that's under constant development and bugfixes -- such as what we've had so far.  (Just look at our version history and you'll see what I'm talking about -- v 0.8 comes out, v0.8.1 is released 2 days later to patch something, v0.8.2 comes the next day as another bug fix...)

V3.0 should be a stable version, and shouldn't be subject to the same issue of constant repair.  We've finally incorporated all the old QB64 Team's work, verified it, and moved past it.  Everything from this point on is all us, and any new issues introduced into the source are entirely by us.  We've moved past the point of uncertainty over the past work that we've inherited, and we're ready to move forward and proudly say, "As far as we know, everything in here should be working as expected."  (Now, saying that, there's *still* some long established bugs and glitches that haven't all been ironed out yet, but those are "working as expected".  We haven't gotten around to fixing them yet, but as far as we know, we haven't added any new glitches into the matrix as of yet.)

So why'd we go from v0.8.2 all the way to v3.0?  

To indicate that we're an extension of the old QB64 and newer than their last release.  The last version from the QB64 Team was v2.0.2 -- we've built upon that, and finally gotten what we consider to be a stable version.  v3.0 seems like a fitting name for the new release, don't you guys think?

Quote: This is the first major release of QB64 Phoenix Edition. v3.0.0 was chosen to avoid overlapping with the existing QB64 v1 and v2 versions. QB64 Phoenix Edition v3.0.0 is compatible with QB64 v2.0.2.
Enhancements

• #122, #125, #130, #132 - Several improvements to the Help display in the IDE - @RhoSigma-QB64
  
• #136 - Several naming and visual changes to reflect the "Phoenix Edition" branding - @RhoSigma-QB64
  • The executable is now named 
    qb64pe
     on Linux and Mac and 
    qb64pe.exe
     on Windows.
    
• #139 - The files written to ./internal/temp are now buffered in memory and only written out when a build is requested - @RhoSigma-QB64
  

Bug fixes

• #127 - Fixed linking of static libraries on Windows - @mkilgore
  
• #126 - The math evaluator in the IDE will no longer crash when dividing by zero - @mkilgore
  
• #131 - 
  setup_lnx.sh
   was fixed to properly call 
  make clean
   - @GeorgeMcGinn
  

I was playing with alternate means draw filled circles and had the most success with the following routine.

the basic algorithm is simple:  determine the center of the circle , plot the y axis out to the distance or R (negative to positive) and calculate X for each Y. Draw a line at X across the Y axis for each point of Y until there's a circle.

I was playing with a number of different methods to draw and do the calculations and the ones included here are good to share.

rcircle took  .8789062 to .9335938 seconds
dcircle took .6015625 to .6601562 seconds
dmcircle took .6015625 to .6601562 seconds

dcircle tended to get the best draw time on my computer, it had the same  range as dmcircle but it tended to be lower on average so certainly a win for the reference table but no clear advantage to using mem to access the look up table.

EDIT: typo corrected... better version of the rcircle sub is later in the thread

Hey guys, I just saw this from the IEEE:

https://spectrum.ieee.org/top-programmin...uages-2022

Looks like Python is #1 and C, plus two variants of C, are #2, #3, and #4. Okay, we sort of expected that much.

QuickBasic per se does not make the list, but Visual Basic strangely enough does. So that's something. The other interesting point, Visual Basic is more popular than some real stalwarts, like Fortran, Pascal, Lisp, Prolog, and Cobol.

That's something, at least. I find it hard to believe that today, VB is more popular than the various flavors of QuickBasic, but some of you probably know better than me about such things.

Hello everyone,
In the good old days we used PEEK and POKE to read and write on the screen address. See also the example below.

I'm trying to come to grips with the _Define keyword in QB64, as against the "traditional" DefStr, DefInt etc. They appear to do the same thing, but I'm sure I'm missing something, otherwise it wouldn't be there. Can someone elucidate please?