1. Virtual Screens
------=_NextPart_000_001E_01BE8F13.BD2DD280
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sorry if this is a little "elementary", but could someone explain =
briefly what a virtual screen is and the benefits of using it? Thanks.
Gandrew
------=_NextPart_000_001E_01BE8F13.BD2DD280
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Sorry if this is a little=20
"elementary", but could someone explain briefly what a virtual =
screen=20
is and the benefits of using it? Thanks.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
------=_NextPart_000_001E_01BE8F13.BD2DD280--
2. Re: Virtual Screens
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Apr 25, 1999
-
Last edited Apr 26, 1999
Don't feel sorry, we all need to learn this stuff _somewhere_, and the list
server is a pretty good place for it.
First of all, you should know that what you see on the screen in stored in the
video memory.
The video memory is just a part of memory that works like normal memory, in
which bytes represent either palette values, or RGS
values.
The palette modes use a list of 'color indexes' of which each index is
associated with a RGB-value. (RGB= RedGreenBlue)
The contents of this memory is automatically (by either windows or your bios)
sent to the monitor through the videocard a number
of times per seconds. This happens independently / in-the-background of your
program.
It could thus occur that the video memory is sent to the monitor, during a
drawing operation.
Say you were drawing a line, it could thus occur that we see the line get drawn.
In cases where we draw multiple layers of graphical data every frame, there
would be lots of flickering and unwanted see-through
effects.
Consider the case of a platform game, where first the background is drawn, then
the 'tiles' and 'objects' and then the 'actors'.
This is when we use a 'virtual screen'. On a virtual screen we do all this
drawing, after which we copy the 'finished' drawing
to the video memory.
Even hear a slight flickering could occur. (with older video cards, that is).
For this a small ASM trick, that 'waits' for a
screenupdate, should help. This offcourse does slow down your program.
A virtual screen is, in other words, just an allocated piece of memory, that is
copied to the video memory at our command.
"At our command" is preciously the obvious benefit of the method.
Now you could wonder why we don't wait for a screen update, and then do all the
drawing directly to the screen.
This is because the drawing of a frame usually takes more time than interval
between screen updates.
And you don't want to lower screen updates, since the higher the number of
updates, the more 'stable' and 'steady' the screen
looks.
Something very important with PC, since we tend to spent a lot more time, from a
much closer position, behind our monitor, than
we do behind a television (with a refresh rate of about 30-50 I believe)
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
----- Original Message -----
From: Andrew Gainey
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Sent: zondag 25 april 1999 19:04
Subject: Virtual Screens
Sorry if this is a little "elementary", but could someone explain briefly what a
virtual screen is and the benefits of using it?
Thanks.
Gandrew
3. Re: Virtual Screens
A virtual screen is a imaginary screen in memory that is larger than than
the real physical screen. You can then draw on this screen and transfer a
part of this virtual to your physical screen. In other words this would
be like sliding a small window ( your physical screen ) on big huge
( virtual screen ) window and looking thru the small window to see where
it was setting on the large window.
Bernie
4. Re: Virtual Screens
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Apr 25, 1999
-
Last edited Apr 26, 1999
Oops, I really messed up my spelling, though according to the spelling-checker
it would be correct.
Oh well..
> Don't feel sorry, we all need to learn this stuff _somewhere_, and the list
> server is a pretty good place for it.
> First of all, you should know that what you see on the screen in stored in the
> video memory.
> The video memory is just a part of memory that works like normal memory, in
> which bytes represent either palette values, or
RGS
RGS --> RGB
> values.
> The palette modes use a list of 'color indexes' of which each index is
> associated with a RGB-value. (RGB= RedGreenBlue)
> The contents of this memory is automatically (by either windows or your bios)
> sent to the monitor through the videocard a
number
> of times per seconds. This happens independently / in-the-background of your
> program.
of times per second.
> It could thus occur that the video memory is sent to the monitor, during a
> drawing operation.
> Say you were drawing a line, it could thus occur that we see the line get
> drawn.
> In cases where we draw multiple layers of graphical data every frame, there
> would be lots of flickering and unwanted
see-through
> effects.
> Consider the case of a platform game, where first the background is drawn,
> then the 'tiles' and 'objects' and then the
'actors'.
>
> This is when we use a 'virtual screen'. On a virtual screen we do all this
> drawing, after which we copy the 'finished' drawing
> to the video memory.
> Even hear a slight flickering could occur. (with older video cards, that is).
> For this a small ASM trick, that 'waits' for a
Even hear --> Even here
(those English words just sound alike too much)
> screenupdate, should help. This offcourse does slow down your program.
>
> A virtual screen is, in other words, just an allocated piece of memory, that
> is copied to the video memory at our command.
> "At our command" is preciously the obvious benefit of the method.
preciously --> precizely
> Now you could wonder why we don't wait for a screen update, and then do all
> the drawing directly to the screen.
> This is because the drawing of a frame usually takes more time than interval
> between screen updates.
..than the interval between screen updates does.
> And you don't want to lower screen updates, since the higher the number of
> updates, the more 'stable' and 'steady' the screen
> looks.
> Something very important with PC, since we tend to spent a lot more time, from
> a much closer position, behind our monitor,
than
with a / with the
> we do behind a television (with a refresh rate of about 30-50 I believe)
we spent ...
Ralf N.
I promise I'll review my mails next time I sent them.
5. Re: Virtual Screens
Good explanation...
I'd like to clarify that the contents of video memory are sent to the
monitor by hardware on the video card. By and large, it's not something
that Windows or the BIOS actively concerns itself with. The only thing
Windows or the BIOS have to do with this is to set the desired video mode.
Joe
-----Original Message-----
From: Ralf Nieuwenhuijsen [SMTP:nieuwen at XS4ALL.NL]
Sent: Sunday, April 25, 1999 3:02 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Virtual Screens
Don't feel sorry, we all need to learn this stuff _somewhere_, and the list
server is a pretty good place for it.
First of all, you should know that what you see on the screen in stored in
the video memory.
The video memory is just a part of memory that works like normal memory, in
which bytes represent either palette values, or RGS
values.
The palette modes use a list of 'color indexes' of which each index is
associated with a RGB-value. (RGB= RedGreenBlue)
The contents of this memory is automatically (by either windows or your
bios) sent to the monitor through the videocard a number
of times per seconds. This happens independently / in-the-background of
your program.
It could thus occur that the video memory is sent to the monitor, during a
drawing operation.
Say you were drawing a line, it could thus occur that we see the line get
drawn.
In cases where we draw multiple layers of graphical data every frame, there
would be lots of flickering and unwanted see-through
effects.
Consider the case of a platform game, where first the background is drawn,
then the 'tiles' and 'objects' and then the 'actors'.
This is when we use a 'virtual screen'. On a virtual screen we do all this
drawing, after which we copy the 'finished' drawing
to the video memory.
Even hear a slight flickering could occur. (with older video cards, that
is). For this a small ASM trick, that 'waits' for a
screenupdate, should help. This offcourse does slow down your program.
A virtual screen is, in other words, just an allocated piece of memory,
that is copied to the video memory at our command.
"At our command" is preciously the obvious benefit of the method.
Now you could wonder why we don't wait for a screen update, and then do all
the drawing directly to the screen.
This is because the drawing of a frame usually takes more time than
interval between screen updates.
And you don't want to lower screen updates, since the higher the number of
updates, the more 'stable' and 'steady' the screen
looks.
Something very important with PC, since we tend to spent a lot more time,
from a much closer position, behind our monitor, than
we do behind a television (with a refresh rate of about 30-50 I believe)
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
----- Original Message -----
From: Andrew Gainey
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Sent: zondag 25 april 1999 19:04
Subject: Virtual Screens
Sorry if this is a little "elementary", but could someone explain briefly
what a virtual screen is and the benefits of using it?
Thanks.
Gandrew
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download.html
