OpenEuphoria

Re: Graphics

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Nov 28, 1998
• 524 views

Molasses noticed that in SVGA modes, the top part of the screen is much
faster, than the 3/4 lower part of the screen.

This is due to banking. Euphoria uses Watcom graphics routines. This has
some advantages and some disadvantages. An advantage is, there are fast, and
real native support for most video cards and offcourse any other card
through the VESA interface. Another advantage is that those routines are
solid, and well-tested by many.

However, in the downside comes in the interface part. By default, they set
the banking back to the beginning after every call to pixel (). But first
what is banking. In SVGA modes, the memory we need to store the screen (the
video memory) is more than 64K and since silly dos can't handle segments (is
this the right word ?) larger than 64k right, we need to specify which part
of memory the 64kb we *can* acces resemble to.

The rest of the memory is handled by the Causeway Dos-extender built-in in
Euphoria, so we dont have that problem there, however your video card is in
control of your video memory, and the 64kb boundry does exist there.

Banking means, you tell the video card, that the 64kb video memory present
equals the first 1/4 part of the screen, *or* the second 2/4. Actually you
can make it equal to any 64kb part of the screen, just not all at once in
SVGA modes, since they need much more than 64kb to store their data.

Now, you must wonder, why does the pixel routine reset the banking back to
the beginning after every call ? Well, this is for those cases when you use
machine code, or in any way mess with the banking yourself, how would the
interpreter know that you changed the bank ? It can't so it uses an
convention, which is: before using pixel () makes sure that the banking is
reset to the beginning, and your routines can trust on it, the banking will
always be set to the beginning, no matter what graphics routine of Euphoria
you called.

Is this much speed loss ? Well, for speed it is best to store the whole
screen and 'blit' it to the screen anyway.
In Euphoria terms this would mean: use display_image to refresh the screen
with the 'virtual' screen. For most cases you could just use an sequence to
store this virtual screen. If you need more speed, you use one of the
graphics libraries, however remember the cost. You 1) cant' use any of the
standard graphics routines 2) you can't use two libraries at the same time,
3) you risk stability. So if you really need the speed, get a good graphics
video-independent graphics library. But before im called proselytizer (i've
cut and paste this word  again, I wont name the implied graphics library.

Ralf