1. 1.5a Oops!
- Posted by Lucius L Hilley III <luciuslhilleyiii at JUNO.COM> Jun 15, 1997
- 658 views
- Last edited Jun 16, 1997
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!
- Posted by Michael Packard <lgp at EXO.COM> Jun 16, 1997
- 668 views
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
- 666 views
- 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
- 634 views
- 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!
- Posted by Lucius L Hilley III <luciuslhilleyiii at JUNO.COM> Jun 19, 1997
- 682 views
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
- 678 views
- 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