1. 1.5a Oops!
The instability in my program turned out to
be a typing error.
BTW. pixel() is about 2 times as fast as
use a direct poke() to screen 19 (Hex 13).
--Lucius Lamar Hilley III
-- E-mail at luciuslhilleyiii at juno.com
-- I support transferring of files less than 60K.
-- I can Decode both UU and Base64 format.
2. Re: 1.5a Oops!
On Sun, 15 Jun 1997, Lucius L Hilley III wrote:
>
> The instability in my program turned out to
> be a typing error.
Bahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha!
Michael Packard
Lord Generic Productions
lgp at exo.com http://exo.com/~lgp
A Crash Course in Game Design and Production
http://exo.com/~lgp/euphoria
3. Re: 1.5a Oops!
- Posted by Michael Bolin <michaeltom at GEOCITIES.COM>
Jun 18, 1997
-
Last edited Jun 19, 1997
> BTW. pixel() is about 2 times as fast as
> use a direct poke() to screen 19 (Hex 13).
I tried it, and got the following results:
Doing an entire row at once, poke() was a little bit faster.
Doing it pixel by pixel, poke() was more than 5 times as fast.
How did you get your result?
Michael Bolin
4. Re: 1.5a Oops!
- Posted by Robert Craig <robert_craig at COMPUSERVE.COM>
Jun 18, 1997
-
Last edited Jun 19, 1997
Lucius Hilley reports:
> BTW. pixel() is about 2 times as fast as
> use a direct poke() to screen 19 (Hex 13).
Michael Bolin reports:
> I tried it, and got the following results:
> Doing an entire row at once, poke() was a little bit faster.
> Doing it pixel by pixel, poke() was more than 5 times as fast.
In the mode 19 single-pixel case, poke() and pixel() are both fast.
poke() should generally be faster, but the time may be dominated
by the time to create the {x, y} coordinate sequence needed
by pixel(color, {x,y}), or by the calculation of the poke address:
base + y * 320 + x. People should show the exact loop that they used
to measure the time.
Those who are benchmarking should also keep in mind that
cache effects, particularly on a Pentium system, can be
very strong. An experiment that you can try is to write a loop
that compares memset() of 300 bytes into video memory while
in mode 19, with memset() of 300 bytes into a
general memory address that you get from allocate().
You should see a big difference. Data written to general
memory can be cached, and the Pentium uses a "write-back" cache
which makes memory writes faster.
I found it was 6x faster to memset general memory
than mode 19 video memory. The slowness of video
memory enables the Pentium to execute a few more
register-based instructions for *free* while it
waits for the slow writes to finish. This kind of thing
could make Euphoria competitive with C in programs that
update video memory, since both languages will be slowed down
by the same number of writes to video memory, and Euphoria
may be able to complete a couple of extra interpreter
instructions for free in that time. On top of that,
Euphoria's memset() and mem_copy() are as fast as anything you
can do in C.
Regards,
Rob Craig
Rapid Deployment Software
5. Re: 1.5a Oops!
On Wed, 18 Jun 1997 20:52:26 +0000 Michael Bolin
<michaeltom at geocities.com> writes:
>
>
>I tried it, and got the following results:
>
>Doing an entire row at once, poke() was a little bit faster.
>Doing it pixel by pixel, poke() was more than 5 times as fast.
>
>How did you get your result?
My results show pixel() faster.
I can change the way I poke() but I can't change
the way I use pixel().
How did you get YOUR results?
--Lucius Lamar Hilley III
-- E-mail at luciuslhilleyiii at juno.com
-- I support transferring of files less than 60K.
-- I can Decode both UU and Base64 format.
6. Re: 1.5a Oops!
- Posted by Michael Bolin <michaeltom at GEOCITIES.COM>
Jun 19, 1997
-
Last edited Jun 20, 1997
> My results show pixel() faster.
> I can change the way I poke() but I can't change
> the way I use pixel().
>
> How did you get YOUR results?
It will depend on where you are drawing pixels. If you are plotting
in random positions, pixel() may be faster because you don't need to
calculate an address every time.
If you are drawing in some sort of sequential order, you can simply
add an offset to the address, which is much faster.
Michael Bolin
