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
|
Not Categorized, Please Help
|
|
