04-22-2024, 06:23 AM
The problem with adding code into QB64PE itself is that it has to try and account for all the endless possibilities when being in use. Let's take your SUB Wipe, for example.
How would that work on a text screen? A graphic screen? With all the various _PrintModes in effect? With 0 alpha colors set? With non-0 alpha colors? Do you wipe the text off an image and leave a black spot there? And on and on...
Which is why, sometimes, simple things like these are best left for the user to sort out and add to their own code. One of the best type "Wipe" routines is this simple snippet:
PCOPY 0, 1' make a copy of the screen
Print "Whatever you want on the screen"
SLEEP 'Give time for the user to see the screen. Delay and such also can work here, or a user input prompt...
PCOPY 1, 0 'restore the screen to the copy you made before
Now the above does a TRUE wipe of the screen. It restores images and everything to the exact same point as where it was before you printed on it and "ruined" it with a temp pop-up or whatnot.
Some things, users need to code for themselves, just to suit the flexibility of their own stuff. The command you've written above works -- as long as the COLOR matches the _BACKGROUNDCOLOR, _PRINTMODE isn't affecting things, _DEST isn't somewhere odd, the coordinates sent aren't ones which are off screen and error out, a "MONOSPACE" font is in use.... (and probably more things to account for that I'm just not thinking of).
It's all these various little things in play, that often lead to such overhead for a QB64PE command. It's quick and simple to write a routine to print a few rows of blank spaces in your own program, as you *know* which of those toggles and modifiers are and aren't in effect. As a generic language-level command though?? THAT'S got to take all the various options into account and error trap and respond to them!
And with all that said, the best place would probably be "Works in Progress", if you're looking for feedback for such functions to see what toggles/modifiers you might need to account for, to make an "universal-use" type command; and "Utilities" once you've got it perfected to what you think is worthwhile in sharing for others to use.
And once you make a whole collection, or "toolbox", of such utilities and wrap it all up together so someone can just $INCLUDE them into their code, then that whole collection can be moved into "Libraries" for folks to find and make use of.
How would that work on a text screen? A graphic screen? With all the various _PrintModes in effect? With 0 alpha colors set? With non-0 alpha colors? Do you wipe the text off an image and leave a black spot there? And on and on...
Which is why, sometimes, simple things like these are best left for the user to sort out and add to their own code. One of the best type "Wipe" routines is this simple snippet:
PCOPY 0, 1' make a copy of the screen
Print "Whatever you want on the screen"
SLEEP 'Give time for the user to see the screen. Delay and such also can work here, or a user input prompt...
PCOPY 1, 0 'restore the screen to the copy you made before
Now the above does a TRUE wipe of the screen. It restores images and everything to the exact same point as where it was before you printed on it and "ruined" it with a temp pop-up or whatnot.
Some things, users need to code for themselves, just to suit the flexibility of their own stuff. The command you've written above works -- as long as the COLOR matches the _BACKGROUNDCOLOR, _PRINTMODE isn't affecting things, _DEST isn't somewhere odd, the coordinates sent aren't ones which are off screen and error out, a "MONOSPACE" font is in use.... (and probably more things to account for that I'm just not thinking of).
It's all these various little things in play, that often lead to such overhead for a QB64PE command. It's quick and simple to write a routine to print a few rows of blank spaces in your own program, as you *know* which of those toggles and modifiers are and aren't in effect. As a generic language-level command though?? THAT'S got to take all the various options into account and error trap and respond to them!
And with all that said, the best place would probably be "Works in Progress", if you're looking for feedback for such functions to see what toggles/modifiers you might need to account for, to make an "universal-use" type command; and "Utilities" once you've got it perfected to what you think is worthwhile in sharing for others to use.
And once you make a whole collection, or "toolbox", of such utilities and wrap it all up together so someone can just $INCLUDE them into their code, then that whole collection can be moved into "Libraries" for folks to find and make use of.