Swapped everything over to hardware images, and suprisingly, it makes very little difference compared to what I have above.  Maybe a 10-20% increase in this case, and I wouldn't swear to that.


Best I can tend to max out with is about 140 FPS on my laptop.   

If you're wanting to speed it up, here's what I'd suggest:


This routine here is very unoptimized and inefficient.  You're drawing each letter every time you need it and then freeing the image that you drew it on over and over repeatedly.  I can see why you're going this route -- you've got multiple colors to deal with -- but here's my suggestion:

Make a single sprite array once for processing and keep it for the length of the program's running.

STATIC I(3,255) AS LONG
IF I(0,0) = 0 THEN
    FOR colors = 0 to 3 '4 rows of letters for the 4 colors possible in the program
        FOR characters = 0 to 255 '256 columns for the letters.
            I(colors, characters) = _newimage(8, 16, 32)
... stuff
END IF

Now, instead of passing a char$, you'd be passing the ASCII value of your character, and instead of passing c, you'd simply be passing d.  The whole IF d = 0 ELSEIF , ELSEIF, ELSEIF, ELSE block could be removed, and you'd get rid of the slow Mid$(s$(i), j, 1) and replace it with a simple ASC(s$(i),j).  There'd be no redrawing of each letter over and over, and no need to constantly allocate and free memory in the program. 

I haven't tried it, but from what I can tell looking over the code, I imagine that your bottleneck in performance is in the above routine, and I think this could fix it.  ;)

thank you so much.  I'm working on a time calculator with precision to the second and trying to convert years to seconds. A LONG doesn't allow more than 10 years or so. Thanks again

Pass it a date and timer and it calculates a timestamp for use.

Because it is however a "variable" do you have some trick that you use to be sure "zoom" doesn't change in value?

Make it a CONST.

Const Zoom = 2

Hi ya NcNeil
I have been away for awhile a much needed break from programming in general.

Excel went downhill after the .XLS format was obsoleted.
  Excel was my go to for number crunching because I could do graphs easily with maths

As far as I know, XLS never got obsoleted.  It just got upgraded to XLSX, which is a specially named ZIP folder which holds the XLM files inside it along with all your resource files like embedded fonts, sounds,  and graphics. 

When did XLS get obsoleted?  Did I miss something?  (As I said, I don't hardly ever use Excel or Power Point -- almost all my work is always in Word.)

Hey Steve I was thinking - uh oh, get ready...

...and I know you're infinitely busy already, all thoughts and prayers going your way. That said, can I humbly encourage your QB64 Bible project to hit the issue of floating point math next? Even if it wasn't the next chapter you were going to write, we need something final on this question once and for all. It comes up way too often in the forums. The proper write-up should minimize out-of-house references, and be something written entirely by us, for us -  and you're the guy to do it Steve. The challenge is to write it out *so good* that it answers every question that ever came up about floating point math in qb64.exe, and also anticipates every future question that may arise. Do whatever you want to do, but make this section stand perfectly alone, and write it soon. No references to other chapters, just a stand alone gospel on QB64's float.

This might make the overall project feel less daunting. Do chapters by demand. Do float while it's fresh. Invest the 10,000 keystrokes and you'll save us all 100,000. Pretty Virginia Please.

The problem with floating point stuff is that *even I* -- as unbelievable as that sounds -- am still learning more about how it behaves and what its quirks are all the time.

Here's a quirk I just picked up on a little while ago that made me just close my QB64 window and give up on things for a while:


i is a single, and it's value isi -1.9.  x## is a float -- much more precision to work with than a trifling single, so the value should be the same easily.  Right??

  [ You are not allowed to view this attachment ]  

WRONG!!

By passing a SINGLE into a SUB/FUNCTION that looks for a _FLOAT, the value can change just because the variable type used to store that value changed!!

Who would've ever thunk that??  Especially since we're going from low precision floats to high precision floats.  I could almost understand if a float held a value that a single couldn't, but in this case, I'm just blown away by the value change.

Floating Point wierdness....

Can *anyone* ever really write a end-all testament to describe all the oddness that it can perform??

I don't know if I can ever again trust a loop that involves incrementing by decimal values.

Maybe a knee-jerk reaction, but I find myself wondering, looking at any kind of loop like that, if there is unintentional short-changing of the loop (or an opposite "over-loop"?) by an iteration.

It's always a possibility.

FOR i = -1 TO 1 STEP 0.1

NEXT

In the above, even if we add a line that sets i to being exactly 0.9, we can't be certain that the increment won't make it's value 1.00000001 -- which is greater than 1 and will xit the loop one step early!

The only way to be certain we get that final loop is by adding a tolerance level into the code for floating point imperfections:

FOR i = -1 TO 1.01 STEP 0.1

NEXT

The end point is now great enough to absorb the error, but not large enough to allow an extra increment to pass.

---

I still say the absolute best solution, when possible, is to just avoid the floating point imperfections entirely.

FOR i = -10 TO 10 'use integers when possible
  iDec = i /10 'only convert to the floating point value when necessary
NEXT

It's why the banks track how many PENNIES are in your account, and not how many dollars.  The results are displayed as dollars, but all the calculations are in pennies.

Notice how the fix can also be applied for Doppler's problem as well: