1. Graphics help
I've been working on scrollbars in Dos32Lib, and I've got a question.
Redrawing the scrollbars displays a lot of "flashing" as the graphics are
redone. This is something which I would rather avoid.
As far as I can understand, you can avoid this by copying the current screen
to a second video page, write to that page, and then display the page when
the update is complete. This assumes that your computer actually has enough
video memory to support multiple video pages. I *think* the term is
"double-buffering".
I attempted something like this in my TextGUI, but I have a couple of
questions.
Other than a couple of added tests, I assume that the only real added cost
is that of copying the current screen to another oprtion of video memory. If
this has to be done using xxxx_image, then there's a lot of overhead
associated with translating from pixels to sequences and back again. Can
this be avoided by using peek/poke? What modes does this work in?
Does anyone have any suggestions here? If there is a large overhead, I'll
just skip it and live with the mediocre graphics.
Along those lines, as cool as the Java look and feel is, the graphic
overhead associated with it seems counterproductive to the goal of the
library - to let it run on older, slower machines. So there's a good chance
that I may change the L&F to something simpler that can be rendered much
faster. 
-- David Cuny
2. Re: Graphics help
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Nov 15, 1998
-
Last edited Nov 16, 1998
>Does anyone have any suggestions here? If there is a large overhead, I'll
>just skip it and live with the mediocre graphics.
David, why dont you just use a graphics library.
We've discussed this before. There are a number of big advantages:
1) You dont have to re-invent the wheel: it saves you time/effort.
2) Most are 99% ASM it is simple 4 to 5 times *faster*
3) Because it uses ASM it is usually also much more memory efficient.
4) Their interface although not as simple as just a pixel () and get_pixel
() is much more powerfull and effective.
5) Already two libraries provide true-color modes already, and pete's
doesnt' even use banking no more..
Euphoria is simply too slow at SVGA modes, and cant handle true color modes.
And although true color is a bit overdone, you at least want SVGA modes. So,
if you want Dos32lib to look as good as real windows (*look* I said) and
still perform reasonable on a normal pentium, you either have to get your
hands dirty in the ASM or use a library.
Ralf
3. Re: Graphics help
David Cuny writes:
> I've been working on scrollbars in Dos32Lib, and I've got a question.
> Redrawing the scrollbars displays a lot of "flashing" as the graphics are
> redone. This is something which I would rather avoid.
If it's mainly a problem of "flicker" and not overall slowness,
there are some techniques you can try. (Maybe you've
thought of these already):
1. When updating an area of the screen, try to calculate the
final picture of what it should look like before drawing it.
Avoid displaying the intermediate stages. For
example if you are moving an object, like a scroll bar, from
point A to point B, an obvious solution is
to "blank" it out at position A and redraw it at B. This will
cause flicker as the monitor will sometimes refresh when
the bar is blanked out, before it has been redrawn. There
would be far less flicker if you could redraw the image of
the whole updated area in "one shot". i.e. draw the bar including
some trailing "blank" pixels, to wipe out the previous image
of the bar.
2. You might be able to update just the ends of the scroll bar, not the
whole bar, to effectively move it.
3. You might wait for the vertical blank period of the monitor
before updating the screen. There's some machine code for
that around somewhere.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Re: Graphics help
- Posted by Keith Krepps <kkrepps at ALINK.COM>
Nov 15, 1998
-
Last edited Nov 16, 1998
I think Rob may be referring to this Dave. (His last point.)
http://www.harborside.com/home/x/xseal/euphoria/
Check out the bottom of the tutorials page.
-----Original Message-----
From: Euphoria Programming for MS-DOS
[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of Robert Craig
Sent: Sunday, November 15, 1998 5:24 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Graphics help
David Cuny writes:
> I've been working on scrollbars in Dos32Lib, and I've got a question.
> Redrawing the scrollbars displays a lot of "flashing" as the graphics are
> redone. This is something which I would rather avoid.
If it's mainly a problem of "flicker" and not overall slowness,
there are some techniques you can try. (Maybe you've
thought of these already):
1. When updating an area of the screen, try to calculate the
final picture of what it should look like before drawing it.
Avoid displaying the intermediate stages. For
example if you are moving an object, like a scroll bar, from
point A to point B, an obvious solution is
to "blank" it out at position A and redraw it at B. This will
cause flicker as the monitor will sometimes refresh when
the bar is blanked out, before it has been redrawn. There
would be far less flicker if you could redraw the image of
the whole updated area in "one shot". i.e. draw the bar including
some trailing "blank" pixels, to wipe out the previous image
of the bar.
2. You might be able to update just the ends of the scroll bar, not the
whole bar, to effectively move it.
3. You might wait for the vertical blank period of the monitor
before updating the screen. There's some machine code for
that around somewhere.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
5. Re: Graphics help
- Posted by David Cuny <dcuny at LANSET.COM>
Nov 15, 1998
-
Last edited Nov 16, 1998
Thanks, all, for the hints.
I've decided to drop the Java look and feel. It looks cool, but I've been
spending far too much time on form over function. Dos32Lib now has a GUI
"inspired" by the Smalltalk/Athena/GEM/Mac widget set (read: flat, ugly, and
functional).
-- David Cuny
6. Re: Graphics help
Ralf Nieuwenhuijsen wrote:
> David, why dont you just use a graphics library.
> We've discussed this before. There are a number of big advantages:
>
> Euphoria is simply too slow at SVGA modes, and cant handle true color modes.
> And although true color is a bit overdone, you at least want SVGA modes. So,
> if you want Dos32lib to look as good as real windows (*look* I said) and
> still perform reasonable on a normal pentium, you either have to get your
> hands dirty in the ASM or use a library.
>
Ralf:Which one do you consider the fastest? How about the easiest to use?
Thanks
Irv
7. Graphics help
- Posted by Greg90462 at aol.com
Sep 21, 2002
--part1_3b.2cdcd271.2abe4fff_boundary
Hey everybody,
I am here because I would like to know how to make
graphics in euphoria, If anybody knows a lot about graphics in euphoria
please e-mail me.
thanks,
Greg
--part1_3b.2cdcd271.2abe4fff_boundary
<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>Hey everybody,
<BR>
<BR>
I
am here because I would like to know how to make graphics in euphoria, If anybody
knows a lot about graphics in euphoria please e-mail me.
<BR>
<BR>
<BR>thanks,
--part1_3b.2cdcd271.2abe4fff_boundary--
8. Re: Graphics help
- Posted by Greg90462 at aol.com
Sep 22, 2002
--part1_4b.23aa9ff5.2abf356f_boundary
Hey EUforum,
I need graphics a game! so if you can help me please
do so.
Thanks,
Greg
--part1_4b.23aa9ff5.2abf356f_boundary
<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>Hey EUforum,
<BR>
<BR>
I
need graphics a game! so if you can help me please do so.
<BR>
<BR>
<BR>
<BR>Thanks,
--part1_4b.23aa9ff5.2abf356f_boundary--
9. Re: Graphics help
- Posted by Greg90462 at aol.com
Sep 22, 2002
--part1_cc.1222d7b1.2abf3b3a_boundary
HEY IRV,
THANKS
--part1_cc.1222d7b1.2abf3b3a_boundary
<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>HEY IRV,
<BR>
--part1_cc.1222d7b1.2abf3b3a_boundary--
