What extra features does VARPTR provide?

[mnrvovrfc]

So how's using STR$ inside draw routines bad and when does it come into play slowing things down? The speed of today's hardware really masks some of these things for me. I used to avoid DRAW because it was so darn slow but these days I've been having fun with it.

If you keep your strings short as possible. Because with a million bytes to work with, it becomes noticeable even on the latest equipment. Steve ran an example that illustrated that concatenation is the classic performance robber, and this is true in other programming languages. Even extra "memcpy()" and "memmove()" commands in C are avoided wherever possible because they take time.

Remember the brilliant SaveImage() example that Galleon left us, which saves an image handle's picture to BMP file? The original source code uses concatenation (especially inside "py&" loop), which is unbearably slow to save an image as large as 1920x1020 or whatever else much larger than my laptop's screen. It could take five seconds or longer to save such a screen even in the version I fixed up which avoided concatenation and instead allocates a ridiculous amount of SPACE$() and uses the MID$() command to buffer things.

https://qb64phoenix.com/qb64wiki/index.php/SAVEIMAGE

VARPTR and VARPTR$ were black boxes to me that I never used, only got "Illegal function call" out of trying to make sense with them. It might make sense using it, involving a bunch of integers which values are constantly changed toward a fairly large string using them to set angle and scale and color for DRAW, or setting the tempo and volume and octave for PLAY.