That SCREEN 13 library was slow like a slug on my computer and driven my HDD mad
You have to work on it more...
First of all, as everyone said: forget that HDD thing! For loading you can use it, since then the disk cache does the dirty job (even on my old computer), but when saving it always uses the disk to not lose data. On the other hand you should think about it when only loading too since PEEKing a byte from memory is always much faster than doing the same thing from a file. But for example PEEKing 8 bytes or more is slower if you get them from the file in one chunk (a$ = STRING$ (8, 0): GET #1, , a$).
There was a game here what made the SCREEN 13 thing perfectly, but a bit not "fair" since it rewrote some parts of QB: Bubble Fight. The "unfair" thing was that it found the space where QB stores the segment of the video memory (Without ASM, only PEEKs and POKEs), and changed it when it was necessary to make page flipping. It produced 15 FPS on my computer.
There is a trick what i consider "fair" since it can be get from QB's help and a little of thinking (And NC's HEX wiever & some BSAVEd files, for example the pictures from QBPDraw). This is the "BLOAD cheat": You can load any file with it fast as the lightning if you know what is the header what you need to attach to the file. From the help it can be found out that BSAVEd files contain their original segment & offset and their size. This is 6 bytes. The actual header is 7 bytes, after viewing some QBP and QBM files (The output of QBPDraw) i could describe it completely: Starts with CHR$(253), then Segment, then Offset, and at last Size (Then i wrote an add - on to QBPDraw what can create a four letter custom header for the BSAVEd files using the not really needed Segment & Offset values
). So the cheat: open the file, and read it's first 7 bytes into the destination array. Then replace those 7 bytes to the appropriate BSAVE header (You only need to set the size: LOF(file)-7). After close it, and BLOAD starting at the array's 8th byte. When it is done, You can reopen it, and write back it's original first 7 bytes from the destination array.
Run it with a larger file (>5000 bytes), and you will be surprised
The main advantage of it is that you can load the file to any array this way fast, you won't need strings.
My other way of optimization is to cut out everything what is not really necessary. I wrote "pseudo - 3D" before since i originally started by writing a full engine, but the project i am working on did not need it. Many parts of the 3D could be pre - calculated, so i did them to make it faster. I could reach this way that i can put virtually unlimited number of triangles on the screen, only their size count (I tried it with an object with at about 50 small triangles, and there was no noticeable speed - loss. Only the number of graphic operations count).
And finally: to make subs and functions
Careful design can reduce the code size dramatically since there are many things in a program what are being done similary. But avoid them at speed - critical parts: at those codes calling subs can make the thing slow, not to mention that you will not see the code in one piece what makes optimization impossible.
I only noticed a few months before that QB has an integer divison operand. Very useful at speed. I am telling about it since i think it was not only me who did not know it since i had seen tons of FIX (a / 2) or INT (b / 5) style codes in many programs. Integer divison is the same as INT (a / b), but without floating point. You can make real rounding too (if you not need to be very accurate) by this scheme: (a + b \ 2) \ b
Why i am not posting anything on my project? This is because i do not want to create something like an unfinished Titanic: Everybody can see the code, and that it would be a great thing if it was finished - but it is not. Just a skew of a huge ship, but useless... The other thing is that coding is not the most important part of it: it will (and not only "will", it has already) huge amounts of unique graphic, and style (And i am planning to write music for it too but then i will have to create a sequencer since i could not find any what fit my needs and it's output format was documented somewhere). Because of this nobody would be able to finish it, since my style is mine, it can not be reproduced (I am not meaning here that i am perfect, but nobody knows how i am planned the things, and i think nobody can make graphics, sounds, and style "compatible" with mine, so it is impossible to finish this project without me. And every programmer has his or her own style: if anybody plans to write something really unique, then only he or she can make it finished even if there are many other people helping him or her...)
Back to the Screen 13 library: That keyboard handling is not really good. Once i tried a code working the same way on a computer equipped with Windows XP, it ran, but at exit the OS completely went mad that the only way to stop it was to pull the plug... That method has a bug: the keyboard only sends data when it sends a sign first that it has data what starts Interrupt 9. So at every manual call to Port H60 is a fault: the keyboard is not ready to send the data then. The only way of making a real multikey routine is to reprogram Interrupt 9 what is impossible in pure QBasic (without ASM). The only way to make multikey feeling is to use CTRL, ALT and SHIFT keys (These six keys can be accessed completely independently by reading the appropriate memory locations). This is possible with INSert, Caps Lock, Scroll Lock, and Num Lock too, but using these keys is not a really good idea...
(Note: i pre - wrote this in Notepad, so if anybody had replied to the subject before me, or i am not repliing to something, i am sorry... I have no time to read the topic when i am online)
