Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
dim vscreen(640,480)
- Thread starter shanley06
- Start date
qbasicking
Programmer
no
Your array is way to big, I believe that it can not be larger than 16383.
Why do you need an array so big? You can easily save the screen by using two or three GET arrays
Your array is way to big, I believe that it can not be larger than 16383.
Why do you need an array so big? You can easily save the screen by using two or three GET arrays
qbasicking
Programmer
well, you could use virtual memory
OPEN "file.tst" FOR BINARY AS #1
FOR x = 1 TO 640
FOR y = 1 TO 480
a% = POINT (x, y)
PUT, 2 * x * y, a%
NEXT
NEXT
CLOSE
I assume you want to save the screen in your array
OPEN "file.tst" FOR BINARY AS #1
FOR x = 1 TO 640
FOR y = 1 TO 480
a% = POINT (x, y)
PUT, 2 * x * y, a%
NEXT
NEXT
CLOSE
I assume you want to save the screen in your array
- Thread starter
- #4
qbasicking
Programmer
You will notice that this is pretty damn slow. If you need it to be very quick then I would take three huge arrays of 16383
GET the screen in sections and BSAVE them, but this will only work if you do not need to edit the array
GET the screen in sections and BSAVE them, but this will only work if you do not need to edit the array
- Thread starter
- #6
yeah, its really slow, but i'm only using 10x10 sized sprites so its fast enough right now. what i'm doing is i'm save a whole black screen to a file and then i have some subs i made that will "draw" to that screen so i can do pae flipping in any screen. i alsoo have something like the GET command and the BLOAD command put together, but its a little different. since i couldn't figure out how to PUT the sprites on the virtual page, i decided to make my own graphics file that i convert all my graphics to and then i sorta load them up at the coordinates i want, but it loads them up on the virtual screen. my graphics save really slow but they load up alot faster than .bmp files do and its alot less complicated
The maximum array size is 128 kilobytes without the /AH flag to QB. However, the array can have at most 32,767 indices. It is impossible to create an array large enough to store all of [tt]SCREEN 12[/tt] (640x480), however your 640x48 array should have worked. I will assume that you meant to type 640x480 
The data for [tt]SCREEN 12[/tt] requires 192 kilobytes to store, which is out of range even with the /AH flag (it uses so much memory that you can't do anything else). However, you can process it using an arrays of 96 kilobytes working with half of the screen at once. In general, though, [tt]SCREEN 12[/tt] is not a good choice for fast graphics because of the way the planes are laid out. To store a pixel on the screen, QB must go through all 4 planes and for each one load a byte, modify one bit in the byte, and store it back. It's a little bit lower overhead when using PUT since it can store one bit from a row of pixels at once to a plane, but it's still very inefficient for anything. In my opinion, [tt]SCREEN 12[/tt] should be reserved for static user interfaces -- graphics which do not need to be updated in realtime.
The data for [tt]SCREEN 12[/tt] requires 192 kilobytes to store, which is out of range even with the /AH flag (it uses so much memory that you can't do anything else). However, you can process it using an arrays of 96 kilobytes working with half of the screen at once. In general, though, [tt]SCREEN 12[/tt] is not a good choice for fast graphics because of the way the planes are laid out. To store a pixel on the screen, QB must go through all 4 planes and for each one load a byte, modify one bit in the byte, and store it back. It's a little bit lower overhead when using PUT since it can store one bit from a row of pixels at once to a plane, but it's still very inefficient for anything. In my opinion, [tt]SCREEN 12[/tt] should be reserved for static user interfaces -- graphics which do not need to be updated in realtime.If you need a resolution of 640X480 you better use a SVGA mode. Despite the annoyance of bank switching, it's much faster than SCREEN12, and it offers you up to 8 pages you can switch, so no need to dimension big arrays.
Some people have made pure QB 3d renderers in SVGA (check my page for a source).
The biggest problem with SVGA modes is the ordinary QBasic graphic instructions don't work, so you should write them from scratch or use a library as UGL Antoni
Some people have made pure QB 3d renderers in SVGA (check my page for a source).
The biggest problem with SVGA modes is the ordinary QBasic graphic instructions don't work, so you should write them from scratch or use a library as UGL Antoni
It's important to decouple renderer from graphic display program. I know people who have written complex raytracing programs which can handle arbitrary image sizes and pixel bit depths, and they got around the display mode problem by simply not displaying the result. Instead, they dump it to a file, and then display it from a Windows program.
I agree for a very detailed raytracer issuing a few "shoots" after several minutes of calculation. But wrong approach for realtime, where every microsecond counts... Antoni
Wrong! The QB implementations of SCREEN 12 always switch the four planes to put a pixel and thus they are slow. But screen 12 has some weird circuitry, latches, ALUS, and up to 4 write modes you can combine to do things very fast. See the articles about graphics programming by Michael Abrash at Dr Dobb's Journal..
But it is so complicated.. I don't thing it's worth learning. Vesa mode 101H does 640x480x256 in a much easier way. Antoni
But it is so complicated.. I don't thing it's worth learning. Vesa mode 101H does 640x480x256 in a much easier way. Antoni
I know all about it, actually I've read Abrash's Black Book, but QB can't properly take advantage of most of those tricks. Anyway, as far as I am concerned, the art of realtime graphics is somewhat lost now that we have 3D accelerators to take care of it for us. Not that it's trivial to do with 3D accelerators, but the old tricks are all somewhat deprecated. Still fun to play with, but I wouldn't spend huge amounts of time doing [tt]SCREEN 12[/tt] graphics quickly. At this point, if I want anything high-res with decent performance, I will be using an existing infrastructure such as Win32 GDI or DirectX.
Anyway, the tricks for working with [tt]SCREEN 12[/tt] are mostly very specialized and do not provide a general solution to the problem.
Anyway, the tricks for working with [tt]SCREEN 12[/tt] are mostly very specialized and do not provide a general solution to the problem.
- Thread starter
- #14
I know all about it, actually I've read Abrash's Black Book, but QB can't properly take advantage of most of those tricks. Anyway, as far as I am concerned, the art of realtime graphics is somewhat lost now that we have 3D accelerators to take care of it for us. Not that it's trivial to do with 3D accelerators, but the old tricks are all somewhat deprecated. Still fun to play with, but I wouldn't spend huge amounts of time doing [tt]SCREEN 12[/tt] graphics quickly. At this point, if I want anything high-res with decent performance, I will be using an existing infrastructure such as Win32 GDI or DirectX.
Anyway, the tricks for working with [tt]SCREEN 12[/tt] are mostly very specialized and do not provide a general solution to the problem.
Anyway, the tricks for working with [tt]SCREEN 12[/tt] are mostly very specialized and do not provide a general solution to the problem.
- Status