08-04-2004, 07:44 PM
Spotted Cheetah...
>>That SCREEN 13 library was slow like a slug on my computer and driven my HDD mad You have to work on it more...<<
It was slow probablly because you said you were testing it on a 33 MHZ. machine, which will run slow with pratically any pure QB proggies. As for your HD going mad, you might not of had a disk cache active, that would be the only thing I could think of that would cause the HD to react like that. But you seem skilled enough with computers that you would've already known this was the problem, so I don't know.
>>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.<<
Yeah, liike I mentioned in a previous post I might change this method to a PUT type method for copying the video buffer.
But like I also said, with all the machines I tried it on, the BLOAD/BSAVE method with a disk cache active was faster than using PUT.
>>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$).>>
Actually using bit logic is faster than peek!
>>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.<<
Yeah no one is going to completely agree what is fair and what is not fair. In a early post I listed a few things that I think is fair for labeling something pure QB, and SETVIDESEG seems fair to me.
Though I discovered SETVIDEOSEGMENT on my own by messing around with a program I wrote called FIP, which stood for File Info Pointer. It basically scanned memory until it found the bytes ''File_in'' or something like that, and would record the offset. Besides finding where QB stored it's graphics output address I've found various other goodies like where DEF SEG was and where to find current drive letters, files and their directories, and even the command line. Which everyone already knows anyways :)
But to get back to my lib, Cheetah, you make it sound like it's real slow which upsets me a bit, since I'd like to get a name out for it being one of the fastest pure QB libs out there. It uses alot of optimizing techniques that I think you overlooked, for instance,
in the sprite routine notice there is no LONG& integer calculations, also notice how I've took all the major calculations out of the deepest loops including DEF SEG which most routines don't do. all that together with trying to make it some what effecient too.
(I mean anyone could make it faster by unrolling loops, and converting the bytes to integers as LUTs, etc...but like I said I wanted to make the lib effecient too!)
So, anyways just check out the sprite blitting routine and try a different method of blasting the buffer if the current method isn't working well for your computer.
(You'll realize the speed my lib actually posseses :)
CYA.
>>That SCREEN 13 library was slow like a slug on my computer and driven my HDD mad You have to work on it more...<<
It was slow probablly because you said you were testing it on a 33 MHZ. machine, which will run slow with pratically any pure QB proggies. As for your HD going mad, you might not of had a disk cache active, that would be the only thing I could think of that would cause the HD to react like that. But you seem skilled enough with computers that you would've already known this was the problem, so I don't know.
>>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.<<
Yeah, liike I mentioned in a previous post I might change this method to a PUT type method for copying the video buffer.
But like I also said, with all the machines I tried it on, the BLOAD/BSAVE method with a disk cache active was faster than using PUT.
>>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$).>>
Actually using bit logic is faster than peek!
>>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.<<
Yeah no one is going to completely agree what is fair and what is not fair. In a early post I listed a few things that I think is fair for labeling something pure QB, and SETVIDESEG seems fair to me.
Though I discovered SETVIDEOSEGMENT on my own by messing around with a program I wrote called FIP, which stood for File Info Pointer. It basically scanned memory until it found the bytes ''File_in'' or something like that, and would record the offset. Besides finding where QB stored it's graphics output address I've found various other goodies like where DEF SEG was and where to find current drive letters, files and their directories, and even the command line. Which everyone already knows anyways :)
But to get back to my lib, Cheetah, you make it sound like it's real slow which upsets me a bit, since I'd like to get a name out for it being one of the fastest pure QB libs out there. It uses alot of optimizing techniques that I think you overlooked, for instance,
in the sprite routine notice there is no LONG& integer calculations, also notice how I've took all the major calculations out of the deepest loops including DEF SEG which most routines don't do. all that together with trying to make it some what effecient too.
(I mean anyone could make it faster by unrolling loops, and converting the bytes to integers as LUTs, etc...but like I said I wanted to make the lib effecient too!)
So, anyways just check out the sprite blitting routine and try a different method of blasting the buffer if the current method isn't working well for your computer.
(You'll realize the speed my lib actually posseses :)
CYA.