I have just a few questions involving these two topics. Thanks in advance for answering my questions.
I understand the basics of making a screen 13 virtual memory page, such as PSETing to it and POINTing to it. put when the "virtual flip" happens, I don't understand how it works. Also, is there a way to PUT and GET from the virutal page?
Involving Libraries...
Is the .BI file nesessary? I've seen turtorials that say to do it, and others that don't even mention it.
in the "Set Paths" option in quick basic, rather than typing in /L (your lib here) in MS-DOS, can you just type in the file path to your library there?
How do you type in multiple flie names in zones in the "Set Paths" option?
Thanks!
Help... screen 13 virtual memory and a few library questions
- Michael Calkins
- Veteran
- Posts: 76
- Joined: Tue Apr 05, 2005 8:40 pm
- Location: Floresville, Texas
- Contact:
I assume you are talking about the video memory pages that you can manipulate with the SCREEN and PCOPY statements?? This wouldn't be virtual memory... Maybe you are referring to something else... Screen 13 only has 1 video memory page...I understand the basics of making a screen 13 virtual memory page, such as PSETing to it and POINTing to it. put when the "virtual flip" happens, I don't understand how it works. Also, is there a way to PUT and GET from the virutal page?
For screen modes that allow multiple pages, I think the VGA hardware is instructed somehow to switch what part of memory it uses for the screen?? I'm not sure. The BIOS Int 0x10 functions allow video memory pages, but how exactly it works, I don't know.
Here is some code that demonstrates video memory pages:
Code: Select all
DEFINT A-Z
z = &H1000
SCREEN 0, , 1, 1
CLS
COLOR 15, 1
PRINT "A"
SCREEN 0, , 0, 0
CLS
COLOR 7, 0
PRINT "a"
DEF SEG = &HB800
PRINT HEX$(PEEK(0)), HEX$(PEEK(1))
PRINT HEX$(PEEK(z)), HEX$(PEEK(z + 1))
To get or put to a specific page, just make it the active page.
But screen 13 only has one page... Are you using some library to emulate multiple pages for it? If so, could you please state what library, and someone with experience with it can help you....
I don't use QB 4.5, but if it's like anything else, the include file (like a .h file in C) is just a file that gets copied into your source at compile time.Is the .BI file nesessary?
#include <whatever.h>
is the same as copying the contents of the file into your code at that spot. include files contain declarations of functions, etc, that your code will use. I'm not sure, but I imagine they are necessary (either in an included header file, or in your code itself). I imagine there would be link time problems without them?
Regards,
Michael
Bring on the Maulotaurs! oops...
I like to slay Disciples of D'Sparil...
I like to slay Disciples of D'Sparil...
- Codemss
- Veteran
- Posts: 124
- Joined: Sun Jun 24, 2007 6:49 am
- Location: Utrecht, The Netherlands
- Contact:
Well. There is, somewhere in memory, a large portion of bytes which holds the screen data. You can manipulate them with POKE and PEEK. If you set DEF SEG = &HA000, and then poke at 320 * y + x, and with the colour as argument, you have a faster alternative for pset. Example:
(pset) POKE y * 320 + x, colour
(point) colour = PEEK(x* 320 + x)
You can optimize this by making a LUT with 200 integers which mulitplies with 320. Then you don't have to multiply, but you can simply use y as the index for the array.
It is the fastest if you use a pointer that starts at zero, but ends at 64000(=320*200, so at the right bottom of the screen). So every time you increase this pointer by one, the pixel that will be affected by that poke, is one to the right. And every 320 times the pointer moves to the beginning of the next row of pixels.
(Something I found out by looking at a heavily optimized rotozoomer is that can be a normal integer, but it will work only when compiled then. It is very weird: compiled the integers dont give an overflow error, so you can always try to replace long integers by normal integers before compiling, this speeds everything up A LOT. I used this much by making optimized demo effects and it is really great)
Back to the point
When you want to get rid of flicker, you have to make a screen buffer. That is just a large array with 32002 integers, that you set def seg to:
DEF SEG = VARSEG(array(0))
Then you poke to it, and then you can PUT at the screen.
Almost forgot: you got to dimension the array. There are two ways:
1. Use GET (0, 0) - (319, 199), array(0)
2. Dimension them by hand:
array(0) = 320(this can be another value too, but only smaller, but this is only if you want a smaller screen buffer. If you do this, I have to mention that the pointer moves to the next row every (x + 1) steps) * 8
array(1) = 199(again this can be smaller if you want a smaller screen buffer)
I hope you understood. This is pretty much all I know about screen buffers, pointers, peek and poke, memory in QB and optimizations.
(pset) POKE y * 320 + x, colour
(point) colour = PEEK(x* 320 + x)
You can optimize this by making a LUT with 200 integers which mulitplies with 320. Then you don't have to multiply, but you can simply use y as the index for the array.
It is the fastest if you use a pointer that starts at zero, but ends at 64000(=320*200, so at the right bottom of the screen). So every time you increase this pointer by one, the pixel that will be affected by that poke, is one to the right. And every 320 times the pointer moves to the beginning of the next row of pixels.
(Something I found out by looking at a heavily optimized rotozoomer is that can be a normal integer, but it will work only when compiled then. It is very weird: compiled the integers dont give an overflow error, so you can always try to replace long integers by normal integers before compiling, this speeds everything up A LOT. I used this much by making optimized demo effects and it is really great)
Back to the point
When you want to get rid of flicker, you have to make a screen buffer. That is just a large array with 32002 integers, that you set def seg to:
DEF SEG = VARSEG(array(0))
Then you poke to it, and then you can PUT at the screen.
Almost forgot: you got to dimension the array. There are two ways:
1. Use GET (0, 0) - (319, 199), array(0)
2. Dimension them by hand:
array(0) = 320(this can be another value too, but only smaller, but this is only if you want a smaller screen buffer. If you do this, I have to mention that the pointer moves to the next row every (x + 1) steps) * 8
array(1) = 199(again this can be smaller if you want a smaller screen buffer)
I hope you understood. This is pretty much all I know about screen buffers, pointers, peek and poke, memory in QB and optimizations.
Check out my site: <a href="http://members.lycos.nl/rubynl">Click here</a>
Hope you like it. Send some feedback if you want: <a href="mailto:basicallybest@live.nl">Mail me</a>
Codemss, before known as RubyNL
Hope you like it. Send some feedback if you want: <a href="mailto:basicallybest@live.nl">Mail me</a>
Codemss, before known as RubyNL
I played with this virtual screen some, but I have a few questions. I've been able to "PSET" to the virtual page by using poke, while playing with it, but now, do you happen to know a way to "PUT", and "GET" from the virtual screen? or is POKEing and PEEKing to it fast enough to forget about the other statements and not make a statment to mimic there functions?
- burger2227
- Veteran
- Posts: 2466
- Joined: Mon Aug 21, 2006 12:40 am
- Location: Pittsburgh, PA
Once you have the image, you can GET a boxed area. You can later PUT it anywhere within the screen area. You need an appropriate sized array for the job.
The screen buffer can hold the entire screen using BSAVE, but GET and PUT fall a little short of fullscreen in 13.
Ted
The screen buffer can hold the entire screen using BSAVE, but GET and PUT fall a little short of fullscreen in 13.
Ted
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
also these are the virtual memory pages;
----------------------------------1:
MyPset;
THESE 2 ROUTINNES ARE FASTER THEN USING MID$(MyScreen(Y%),X%+1,1)
For Drawing;
You must use assembly for faster paste.
Now;
The Result is 65 which is ASC(A) and after Dot Command;
TOLGABRCOK
I hope you get it... The Fixed String Storage Are Is your own home
-----------------------------------------------2:
use a file! Just use a file for storing some temp data, it can be used as a memeory too, but be carefull, you must access lots of time to there so not nice for hdd.
----------------------------------1:
Code: Select all
DIM MyScreen(199) as String * 320
Code: Select all
Sub Dot(X%,Y%,Z%)
ax& = x%
ay& = y%
Def Seg = Varseg(MyScreen(0))
Offset& = VarPtr(MyScreen(0)) + ax& + ay& * 320& 'Be carefull With Overflow Error!
Poke Offset&, Z%
def seg
End Sub
Function Pixel%(X%,Y%)
ax& = x%
ay& = y%
'Returns The Pxiel Value
Def Seg = Varseg(MyScreen(0))
Offset& = VarPtr(MyScreen(0)) + ax& + ay& * 320& 'Be carefull With Overflow Error!
k%=Peek(Offset&)
def seg
Pixel = k%
End Function
For Drawing;
Code: Select all
add& = 0
For y% = 0 to 199
For x% = 0 to 319
def seg = &HA000
p% = Pixel(x%,y%)
add& = add& + 1
poke add&, p%
next
next
def seg
Now;
Code: Select all
Dim SHared Virmem(9) as String * 10 'we have 100 bytes ! 10-10-10...
VirMem(0) = "TOLGAARCOK"
'Now Lets Use The Function Above
k% = Pixel(0,5) 'Note That it means 1,6!!!
Print K%
Dot 0,5,66
Print VirMem(0)
TOLGABRCOK
I hope you get it... The Fixed String Storage Are Is your own home
-----------------------------------------------2:
use a file! Just use a file for storing some temp data, it can be used as a memeory too, but be carefull, you must access lots of time to there so not nice for hdd.