1. 3D-prototype / Ancients.ex
- Posted by Robert Craig <robert_craig at COMPUSERVE.COM> Mar 01, 1997
- 1084 views
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
- Posted by "Lucius L. Hilley III" <luciuslhilleyiii at JUNO.COM> Feb 28, 1997
- 1085 views
- Last edited Mar 01, 1997
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.