1. 3D-prototype / Ancients.ex
Lucius L. Hilley III writes:
> Reasoning, the polygon call is just to slow for practical
> use with multiple calls like this. The creator of this program
You should check out the amazing 13x speed-up that
Michael Bolin achieved by avoiding polygon().
I put his version of ancients.ex on the Euphoria Web page
yesterday.
> function even(atom a)
> return remainder(a, 2) = 0
> end function
> instead of
> return floor(a / 2) = a / 2
> my reasoning is that remainder is ONE fuction and
> you have a/2 then floor and another a/2 TOTAL of
> 3 commands not 1
Actually the compile-time optimizer converts floor(i/j) into *one*
machine-level divide when i and j are both integers,
and it further optimizes floor(a/2) into a single right-shift,
provided a is an integer. i.e. no separate "floor" operation
in these cases..
> Is there anyway that I might could write a sequence as
> a bitmap I would design the sequence to contain the
> format:
> sequence s
> s = {{palette info...}, {bitmap info.....}}
> This format conforms to the way you load a
> bmp_to_sequence. This could be helpful in creating
> bitmaps larger than screen size.
> This isn't possible using save_bmp(0, "file.bmp") or
> save_bmp({{0, 0}, {640, 480}}, "file.bmp").
You're referring to save_screen(), the new v1.5 routine
written by Junko. We'll consider adding the option to
take a palette and 2-d sequence passed in by the user,
rather than reading the image from the screen.
Actually we did consider it already, but we thought that
not many people would need this option,
and if they did, they could just write it to the screen
with display_image() and then call save_screen(). We never
considered the possiblity of saving images that are larger than
the screen.
Regards,
Rob Craig
Rapid Deployment Software
2. 3D-prototype / Ancients.ex
Hello all
I tracked down a couple of ways to speed up the
3d prototype program. One thing is the even function
is slightly faster using.
function even(atom a)
return remainder(a, 2) = 0
end function
instead of
return floor(a / 2) = a / 2
my reasoning is that remainder is ONE fuction and
you have a/2 then floor and another a/2 TOTAL of
3 commands not 1
I managed to reduce the screen() function
loops from -15 to 35 and 1 to 20 a total of 1,000 calls
with a if then filter of what you don't need.
to two loops that total 620 calls without the filter.
after his filter of what wasn't needed he only had
620 calls. It was calling or TRYING 380 that where
being immediately filtered out. WASTE of TIME.
FINAL Note. The remainder function had a GOOD
impact but the LOOP change which should have had
the LARGEST impact did nearly nothing.
Reasoning, the polygon call is just to slow for practical
use with multiple calls like this. The creator of this program
MUST find another means to draw the information if he/she
expects to gain any speed at all. I repeat THE Polygon call
must be DROPPED or REPLACED it is just to slow.
Speaking of which. Robert! Would you explain why the
polygon call is so slow.
My guess is because of it's power. IT is a powerful command.
Just like Windows is powerful BUT usually compared to DOS
it's speed it Stinks. :)
One more thing. For me to reduce the 1,000 try/call loops to
620 try/call loops to EXTREME effort. I had to do lots of
examining of what numbers were and weren't being used.
If anyone would like a copy of my "values.ex" program which
contains both the original 1,000 try/call loops with filter and
my 620 try/call loops without filter just ask.
Have fun
--Lucius Lamar Hilley III
-- E-mail at luciuslhilleyiii at juno.com
-- I can only support file transfers of less than 64K.
