1. Graphics
- Posted by Molasses <molasses at ALPHALINK.COM.AU>
Nov 27, 1998
-
Last edited Nov 28, 1998
------=_NextPart_000_000C_01BE1A5E.FAB88FC0
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all,
[ SVGA pixel ]
In a program I was using to test keyboard input I discovered the =
following "feature":
When in a SVGA mode, pixel writes much faster to the top part of the =
screen (the first 64k, it looks like).
Someone else might want to test this:
--
-- svga pixel bug
-- use arrow keys, ESC to exit
-- move up and watch speed boost
--
include graphics.e
object null,key,pos,step,temp
null =3D graphics_mode(257)
pos =3D {100,120}
step =3D 0.001 -- increase if too slow
key =3D 0
while 1 do
temp =3D get_key()
if temp !=3D -1 then key =3D temp end if
if key =3D 27 then exit
elsif key =3D 331 then pos =3D pos - {step,0}
elsif key =3D 333 then pos =3D pos + {step,0}
elsif key =3D 328 then pos =3D pos - {0,step}
elsif key =3D 336 then pos =3D pos + {0,step}
end if
pixel(15,pos)
end while
--
-- end code
--
[ Inbuilt graphics ]
Seeing as we are soon approaching a new version of Euphoria and people =
are suggesting changes, do graphics routines need to be built into =
Euphoria? They wouldn't be much slower if they weren't inbuilt and =
people who make games tend to use other graphics libraries anyway. Would =
this make EX.EXE much smaller?
-molasses
------=_NextPart_000_000C_01BE1A5E.FAB88FC0
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.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi all,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>[ SVGA pixel ]</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>In a program I was using to test =
keyboard input=20
I discovered the following "feature":</FONT></DIV>
<DIV><FONT size=3D2>When in a SVGA mode, pixel writes much faster to the =
top part=20
of the screen (the first 64k, it looks like).</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Someone else might want to test=20
this:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>--</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>-- svga pixel bug</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>-- use arrow keys, ESC to =
exit</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2>-- move up and =
watch speed=20
boost</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT =
size=3D2>--</FONT></DIV>
<DIV><FONT size=3D2>include graphics.e</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>object =
null,key,pos,step,temp</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2>null =3D =
graphics_mode(257)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>pos =3D {100,120}</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>step =3D 0.001 -- increase if too=20
slow</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>key =3D 0</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2>while 1 do</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>temp =3D get_key()</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>if temp !=3D -1 then key =3D temp =
end=20
if</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>if key =3D 27 then exit</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>elsif key =3D =
331 then pos =3D=20
pos - {step,0}</FONT></DIV>
<DIV><FONT size=3D2>elsif key =3D 333 then pos =3D pos + =
{step,0}</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2>elsif key =3D =
328 then pos =3D=20
pos - {0,step}</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>elsif key =3D =
336 then pos =3D=20
pos + {0,step}</FONT></DIV>
<DIV><FONT size=3D2>end if</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2>pixel(15,pos)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>end while</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>--</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>-- end =
code</FONT></DIV>
<DIV><FONT size=3D2>--</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2>[ Inbuilt graphics ]</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Seeing as we are soon approaching a =
new version=20
of Euphoria and people are suggesting changes, do graphics routines need =
to be=20
built into Euphoria? They wouldn't be much slower if they weren't =
inbuilt and=20
people who make games tend to use other graphics libraries anyway. Would =
this=20
make EX.EXE much smaller?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2>-molasses</FONT></DIV>
------=_NextPart_000_000C_01BE1A5E.FAB88FC0--
2. Re: Graphics
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
3. Graphics
- Posted by MAP <ddhinc at ALA.NET>
Mar 14, 1998
-
Last edited Mar 15, 1998
I took a spin around the webring earlier and noticed that a
great deal of the content was geared towards graphics and
gaming. Of course most (if not all) of it was based on the
dos version. Now that there is a windows version capable
of calling DLL's, I wonder if anyone has given any thought
to porting OpenGL to Euphoria? I'm not that familiar with
graphics programming as I've only dabbled in a couple of
programs in that area, but I think a high-quality
library like OpenGL could open up a whole new level of
possibilities for Euphoria programmers interested in
graphics. It would bring together the ease of Euphoria
programming with the raw performance of a compiled engine.
Any thoughts on this?
Christopher D. Hickman
4. Re: Graphics
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM>
Mar 14, 1998
-
Last edited Mar 15, 1998
On Sat, 14 Mar 1998, MAP wrote:
> I took a spin around the webring earlier and noticed that a
> great deal of the content was geared towards graphics and
> gaming. Of course most (if not all) of it was based on the
> dos version. Now that there is a windows version capable
> of calling DLL's, I wonder if anyone has given any thought
> to porting OpenGL to Euphoria? I'm not that familiar with
> graphics programming as I've only dabbled in a couple of
> programs in that area, but I think a high-quality
> library like OpenGL could open up a whole new level of
> possibilities for Euphoria programmers interested in
> graphics. It would bring together the ease of Euphoria
> programming with the raw performance of a compiled engine.
> Any thoughts on this?
>
> Christopher D. Hickman
I think this is a very good idea. With all the frustration I'm having
with the regular win32api, I'm ready to try something new. I downloaded
the OpenGL dll for Windows95 and was very impressed to find that header
files came with it! I'll try to convert the headers to Euphoria includes
and post the results when I'm done. OpenGL is also well supported on many
platforms. So now I won't have to worry about win95 specific calls that
don't work on NT. OpenGL also appears to be very well documented. :)
If you are interested in OpenGL, visit http://www.opengl.org and
http://www.sgi.com/Technology/openGL/
Later,
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |____|/ / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/xseal at harborside.com\/____/
5. Re: Graphics
Okay folks, I have an idea in mind for something I'd like to try
working on in Euphoria. But I've run into a couple problems. First off, I
want to display a map on the screen, among other things.
I've decided that 320x200 just is not high enough resolution to show
the detail I want without making the map huge. So I'd like to work in
640x480x256 or 800x600x256 mode. But the mouse does not work properly in
SVGA modes, and I want to be able to use it for input. So I'd be limited to
640x480x16, and 16 colors really isn't enough for the detail I want either.
So I'm looking for a way to break the VGA limit. I've come up with 2
possible solutions.
1.) Find SVGA mouse routines for DOS (or make some). I assume this can be
done, but I haven't seen any, and I wouldn't even know where to start.
(interrupt 33? write a custom driver using the serial port? don't know how
to do that anyway..)
2.) Program for Windows using DirectX.
So I'm looking at the DirectX software development kit, and it looks
great. But it's all written in C++, which is a foreign language to me. Is
there anyone here who can translate or write a library (wrapper?) for using
DirectX with Euphoria?
I noticed that Christopher mentioned OpenGL, but I don't know anything
about that one. Would it do what I want easier than DirectX?
Thanks,
Falkon
6. Re: Graphics
At 10:05 AM 3/15/98 -0500, you wrote:
>I want to display a map on the screen, among other things.
> I'd like to work in
>640x480x256 or 800x600x256 mode. But the mouse does not work properly in
>SVGA modes,
Hey...
I use a mouse in SVGA 256 mode all the time with no prob.
You need the mouse.e file as modified by Pete Eberlein.
I have e-mailed it to you direct, if anyone else needs it,
check my
I have to use mode 256 or 257, and must include the statement
use_vesa(1) in the initialization of my program before the
graphics_mode(256) statement.
Irv
-------------------------------------------------
Visit my Euphoria programming web site:
http://www.mindspring.com/~mountains
-------------------------------------------------
7. Re: Graphics
- Posted by MAP <ddhinc at ALA.NET>
Mar 15, 1998
In my last post I rattled on about OpenGL without
giving any of the other libs any mention. I'm perhaps
a bit biased in this regard because what little
experimentation I've done with a graphics lib has
been in OpenGL (under a GNU C compiler). I eventually
discarded the little project I was doing after some
headaches with the compiler. The other libs may be worth
looking at, like DirectX and Mesa. Perhaps eventually
there could be ports to multiple libs. Here's what
little info I gathered at the time tho when I was
looking at which one to try.
First Mesa. Mesa is a GNU project that emulates OpenGL.
Mesa's functions follow the same naming conventions as
OpenGL and uses the same scheme regarding the
"state"-driven model. Although Mesa is very simular to
OpenGL, it has a disclaimer about being compatible
with OpenGL. This may well have no bearing on Euphoria
programmers, because the calling conventions may be
identical, making it possible to use either lib
interchangably. If there are differences tho, here's where
the drawback could lie; OpenGL is supported by more
hardware drivers than Mesa (I assume this is accomplished
by the card maker distributing their own version of the
DLL). If you plan on distributing your program, there
could be potential conflicts with a user's driver. The
possible advantage of Mesa though is that you can freely
obtain the source code for it, where you'd have to obtain
a license for OpenGL if you had intentions of modifying
it for some reason.
(No license is required by either for applications
programmers using the libs)
DirectX. I've never worked with DirectX either, so I went
with what opinions I could find on it on the web.
John Carmack (the lead programmer for Quake and other games
by iD Software) cinched my decision on that idea. It's
just one man's opinion, but given his prominance as an
"expert" in this field, I'd say it carrie's considerable
weight. A post of his comments can be found at:
http://www.directx.com/carmack.htm
As far as other possible libs to look at, I simply wouldn't
know what to look for. I'm interested in learning more
about graphics programming, but for now this is a subject
better left those with more experience than me.
Christopher D. Hickman
8. Re: Graphics
Okay, since posting that earlier, I've gotten a couple of SVGA mouse
routines in Euphoria, but they still don't work. Well, actually they do.
What doesn't work are the get_pixel and save_image routines. And since
those are used by the mouse routines to get the pixels from under the
pointer that they can later be replaced, that's what was making me think
there was a problem with the mouse routines.
I suspect it is either something to do with my video card (ATI Rage II
3-D) or the actual screen reading routines. Funny thing is, the routines to
display to the screen work just fine when I use use_vesa, only the read ones
don't.
Problem is, the read routines act like I didn't use use_vesa. For
example, when I don't call use_vesa before I set screen mode 259, for
example, the screen only uses the top 80 lines of pixels instead of all 600,
and whenever something is displayed below y of 80, those lines are displayed
on top of the first 80 lines, but shifted about 64 pixels to the left for
each 80 pixels they should be below 80.
If I do call use_vesa first, the graphics are displayed properly, but
if I then get a block, say save_image( {0, 90}, {15, 115} ) for example, the
pixels that it actually reads are those at {735, 10}-{750, 35}.
This happens with all SVGA modes, only the offsets are different. For
mode 257 it's roughly 101 pixels height and offsets roughly 256 pixels
horizontally.
Anyway, like I said, this happens with both the read and write
functions if I don't call use_vesa first, but if I do then it doesn't happen
with the write functions, but it still happens with the read functions. I'm
wondering, is this just my video card or is it a bug in the Euphoria pixel
reading functions that they don't use_vesa like the write functions do?
Falkon
9. Re: Graphics
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Mar 15, 1998
-
Last edited Mar 16, 1998
Falkon writes:
> Anyway, like I said, this happens with both the read and write
> functions if I don't call use_vesa first, but if I do then it doesn't
> happen with the write functions, but it still happens with the
> read functions. I'm wondering, is this just my video card or
> is it a bug in the Euphoria pixel reading functions that they
> don't use_vesa like the write functions do?
Thanks for reporting this.
Euphoria depends on the WATCOM DOS graphics library.
WATCOM doesn't claim to support all graphics cards in SVGA,
just a large number of them. VGA modes should work on all
machines. Hopefully WATCOM will support more cards in the
future, but I don't know when that might be. use_vesa() helps
on some machines, but I guess it's not a complete solution
for you. You might try running your program under plain DOS,
outside of Windows and see if that works.
Regards,
Rob Craig
Rapid Deployment Software
10. Re: Graphics
Falkon, if you give me your email address, I'll send you my superrat,
a set of superVGA mouse routines that seems to work. Jiri
11. Re: Graphics
At 03:11 PM 98/03/15 -0500, Falcon wrote:
> Anyway, like I said, this happens with both the read and write
>functions if I don't call use_vesa first, but if I do then it doesn't happen
>with the write functions, but it still happens with the read functions. I'm
>wondering, is this just my video card or is it a bug in the Euphoria pixel
>reading functions that they don't use_vesa like the write functions do?
>
the same problem occurs in my computer, and in my friend's too.
and we found that sigvesa.com(memory resident) attached below
overcomes the trouble. please try with sigvesa.com. i just want to know
whether it also works well with your video card.
Bye-- from Lee, woo seob
begin 600 sigvesa.com
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
'$.OU7EM8PSP!
`
end
12. Re: Graphics
From: "BABOR, JIRI" <J.Babor at GNS.CRI.NZ>
>Falkon, if you give me your email address, I'll send you my superrat,
>a set of superVGA mouse routines that seems to work. Jiri
From: Lee woo seob <wslee at HHI.CO.KR>
>the same problem occurs in my computer, and in my friend's too.
>and we found that sigvesa.com(memory resident) attached below
>overcomes the trouble.
Thanks to all who offered suggestions. 10 points to Lee woo seob for
having the right answer! (though a different file) After downloading the
VBE interrupt function reference and spending all day peeking and poking and
playing with video ROM and converting hexadecimal words... All that
low-level stuff that I really don't know anything about... I finally thought
to check the video chip manufacturer's webpage.
Wouldn't ya know, there's a little TSR program called m64vbe.com that
translates the vesa instructions for the driver. A program that's supposed
to be a standard part of the driver package, but which the PC makers so
thoughtfully didn't bother to include with the PC.
So for anyone else with an ATI card based on the Mach64 chip who's
having problems, go to http://www.atitech.com and look around for the file.
For other cards, of course, it'd be different. Then just load the TSR
before you run your program and unload it afterwords. You could make a DOS
.BAT file like
;----------------------------
c:\ati\m64vbe.com vw vga s
cd c:\euphoria\source
ex myprog.ex
c:\ati\m64.com u
;----------------------------
to run your program, substituting the appropriate directories and program
names, of course. I believe those are the correct switches for Euphoria's
(Watcom's) VESA implementation. (memory aperture off, standard VGA crt,
single window)
And if you don't have problems with your card, but do write SVGA
programs, you might want to make a note like that in your program's
documentation somewhere if you distribute it. Perhaps under "Okay, I've got
a VESA driver loaded, why is it still not working?" in a readme file's
troubleshooting section.
Falkon, missing the days of DOS when all we needed was one driver file and
it came with the PC (and documentation.)
