graphics.e

new topic     » topic index » view thread      » older message » newer message

Curious about GRAPHICS.E.  It calls MACHINE_PROC or something like that for
everything.  Since the underlying code for these functions is already embedded in
the Euphoria interpreter, wouldn't it be more efficient to just have it directly
support the various graphics statements.  Wouldn't the extra time processing
strings instead of a number be made up for by not having to search through the
procedure list or whatever?  Or is that a portability thing?  A different
GRAPHICS.E might be designed that would be used in a Euphoria compiler if someone
can figure out how to do that efficiently?  Is there supposed to be a sound
function in there too?  These things just seem a bit strange to me, that's all. 
Just thinking,
                           - Robert McDougal
PS:  I tried to write a routine that directly did the graphic stuff (in assembly
language) about a month ago, and it bothers me greatly because (except for mode
19), I can't get the graphics to work right without using the BIOS routines for a
pixel.  They take WAY too long to do anything on my system.  (Probably too long
on any system.)  When I come across something that I can't get to work, it bugs
me forever until I can do it.  So can someone PLEASE PLEASE either try and
explain it to me (maybe you'll have better luck getting it through my skull), or
point me to some working asm code that sets a pixel, draws lines, whatever. 
(Most important, pixel setting.)  Thank you so much.


Free web-based email, Forever, From anywhere!
http://www.mailexcite.com

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu