Page 1 of 1
need help desperately
Posted: Tue Apr 01, 2008 8:49 pm
by supersoldier1
hey guys.
I'm new to the qbasic thing, and was looking for some help with some stuff on screen 13. i've just started so pls feel free 2 help me....seriously
Posted: Tue Apr 01, 2008 8:51 pm
by supersoldier1
for example, i need helping moving an image that i made in screen 13. i jus want it to go upwards, but it doesnt, and when it finally moves a bit, all the colors mess up. help pls.
scrolling up
Posted: Tue Apr 01, 2008 11:45 pm
by Kiyotewolf
SCREEN 13
CLS
CIRCLE (30, 30), 15, 15
FOR Z = 0 TO 199
DEF SEG = &HA000
BSAVE "C:\IMG.SD", 320, 63999 - 320
BLOAD "C:\IMG.SD", 0
T! = TIMER: WHILE TIMER - T! < .1: WEND
NEXT Z
WHAT the heck?
Posted: Wed Apr 02, 2008 5:21 pm
by burger2227
Screen 13 can GET most of the screen. Why would you need to BSAVE and BLOAD an image? That is just plain silly and will not move the image easily! If you BSAVE the ENTIRE screen buffer, it will NEVER move!
Just GET the box area where the original graphic is and PUT it at another position. To erase the old image use a black filled box using the previous position coordinates. Then PUT it over and over at new positions erasing with a black box of same size. CLS may cause a blinking screen.
GET requires an array of around 26K elements so use DEFINT A-Z.
Ted
Posted: Wed Apr 02, 2008 7:46 pm
by supersoldier1
thx for the help

frame buffer
Posted: Sun Apr 06, 2008 1:26 am
by Kiyotewolf
Do you realize that using an array in the conventional memory is suicide? Once you allocate all that memory space you drop what's available for your program which also resides in conventional memory and risk a "OUT OF MEMORY " BSOD error..
The reason I have elected to use BSAVE/BLOAD is quite simple.
The refresh rate on DMI transfer of data in and out of hard drives now is hyper speed.. and..
If you did something like use a memory move routine coded in ASM, you use the Double precision ASM extended language that CRASHES the processor if you try to move in single byte precision.
YES,.. there is memory move routines coded in ASM, but they do not go far enough in precision to move single bytes, AKA odd numbers of bytes.
Once you do something daring like scroll left and right a single pixel, you will crash your program because the double precision ASM code will not work on odd memory addresses.
I have tried it and suffered through it extensively.
BSAVE and BLOAD will not do much harm at all, and pass by Windows (xp, vista..) without even phasing the computer, but an ASM routine that crashes will take down your entire program, everything in one blow.
Plus,.. it's so dang easy to use BSAVE too!
** catches breath.. **
** eats a cookie **
Well,.. my job is done here.. bai!
Kiyote Wolf
Posted: Sun Apr 06, 2008 8:53 am
by TmEE
x86 CPUs shoulnd not have any trouble moving 2/4/8 bytes form odd mem locations... 68K will give you Address Error, but not x86... none of the GFX routines i know would work if x86 wouldn't like odd addresses and even data...
Suicide?
Posted: Sun Apr 06, 2008 12:00 pm
by burger2227
I have made modules of over 130K with a 26K image array. NEVER have I gotten a Memory error. The key to making such large modules is the use of SUB programs. They dump the memory required when done.
If it was suicide, why is it allowed? Because it works. Screen Buffer works too, but it is usually used to save the entire image in Screen 13.
Note that you would need 3 BSAVEs in screen 12 to do the same thing without referencing the screen buffer area.
Ted