bfollett Posted February 28, 2015 Share Posted February 28, 2015 Try using my optimization on post #14. The result is the same http://manillismo.blogspot.com/2015/02/espiral-de-arquimedes.html I tried adding the lines you posted in post #14 to the code in post #8 but half the image comes out solid. Bob Quote Link to comment Share on other sites More sharing options...
devwebcl Posted February 28, 2015 Share Posted February 28, 2015 : 100 REM ARCHIMEDES SPIRAL v3 110 REM 120 REM ANALOG MAGAZINE 130 REM 135 rem pequennas optimizaciones "elegantes" 140 GRAPHICS 8+16:SETCOLOR 2,0,0 150 XP=144:XR=4.71238905:XF=XR/XP 155 rem FOR ZI=-64+160 TO 64+160 160 FOR ZI=96 TO 224 170 ZT=(ZI-160)*2.25:ZS=ZT*ZT 180 XL=INT(SQR(20736-ZS)+0.5) 185 rem la mitad? 0-XL 190 FOR XI=0 TO XL 200 XT=SQR(XI*XI+ZS)*XF 210 YY=(SIN(XT)+SIN(XT*3)*0.4)*56 220 X1=XI+ZI:Y1=-70-YY+ZI 225 X11=-XI+ZI 230 TRAP 250:COLOR 1:PLOT X1,Y1 231 PLOT X11,Y1 240 COLOR 0:PLOT X1,Y1+1:DRAWTO X1,191 241 PLOT X11,Y1+1:DRAWTO X11,191 250 NEXT XI: NEXT ZI 260 GOTO 260 Quote Link to comment Share on other sites More sharing options...
bfollett Posted February 28, 2015 Share Posted February 28, 2015 devwebcl, I'm a bit confused. I put your above code into Altirra and it's much slower than the code in post #8. Is that your full optimized program? Bob 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 1, 2015 Share Posted March 1, 2015 Hi!, devwebcl, I'm a bit confused. I put your above code into Altirra and it's much slower than the code in post #8. Is that your full optimized program? The code posted by devwebcl does not include the optimizations of not drawing the black parts, it redraws from bottom to front as the original, this is the reason it is slower. This combines the drawing optimizations with the idea of only calculate half of the function, and also adds some little optimizations of mine: precomputing ZI+160 and ZI+90, reversing the condition in the inner IFs. The runtime in TruboBasic XL, NTSC is 22min 8sec, PAL is 20min 46sec. Note that this plots exactly the same figure as the original. 100 DIM RR(320) 110 FOR I=0 TO 320:RR(I)=193:NEXT I 120 GRAPHICS 8+16:SETCOLOR 2,0,0:COLOR 1 130 XP=144:XR=4.71238905:XF=XR/XP 140 FOR ZI=64 TO -64 STEP -1 150 ZT=ZI*2.25:ZS=ZT*ZT 160 XL=INT(SQR(20736-ZS)+0.5) 170 ZX=ZI+160:ZY=90+ZI 180 FOR XI=0 TO XL 190 XT=SQR(XI*XI+ZS)*XF 200 YY=(SIN(XT)+SIN(XT*3)*0.4)*56 210 X1=XI+ZX:Y1=ZY-YY 220 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 230 X1=ZX-XI 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 250 NEXT XI:NEXT ZI 260 GOTO 260 1 Quote Link to comment Share on other sites More sharing options...
ClausB Posted March 1, 2015 Share Posted March 1, 2015 Now you have to fix the perspective. The original program does a poor job of it. One rule of perspective is that a circle in a horizontal plane, when seen from any elevation angle, becomes an ellipse with a horizontal major axis. This program shows the major axes tilted from upper left to lower right, creating an unnatural skew. Look at my post above to see how to calculate perspective. Quote Link to comment Share on other sites More sharing options...
bfollett Posted March 1, 2015 Share Posted March 1, 2015 Hi!, The code posted by devwebcl does not include the optimizations of not drawing the black parts, it redraws from bottom to front as the original, this is the reason it is slower. This combines the drawing optimizations with the idea of only calculate half of the function, and also adds some little optimizations of mine: precomputing ZI+160 and ZI+90, reversing the condition in the inner IFs. The runtime in TruboBasic XL, NTSC is 22min 8sec, PAL is 20min 46sec. Note that this plots exactly the same figure as the original. Pretty amazing getting a 3 hour runtime down to a little over 20 minutes. How come you show the PAL version running faster. I was under the impression that NTSC computers ran a little faster. Bob Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2015 Share Posted March 1, 2015 NTSC machines spend more time interrupted by the VBLANK, so there are marginally fewer cycles available to mainline code. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 1, 2015 Share Posted March 1, 2015 The cycle loss in most cases due to refresh and graphics DMA will make NTSC slower than PAL. Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 1, 2015 Share Posted March 1, 2015 (edited) The cycle loss in most cases due to refresh and graphics DMA will make NTSC slower than PAL. We can conclude then that NTSC machines will run code faster than a PAL system when Antic DMA is disabled on both? Edited March 1, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2015 Share Posted March 1, 2015 (edited) I fancy you'd want to disable the interrupts as well. Edited March 1, 2015 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
bfollett Posted March 1, 2015 Share Posted March 1, 2015 Does someone with a better understanding of the program know what lines of code would need to be changed to limit the program to a 256 pixel width instead of 320? The TI people are simply letting the program run as is and then multiplying the x and y pixel results by .75 to stay under the 256 pixels, but with the number of pixels plotted those extra multiplies are going to hurt speed a bit. Thanks, Bob Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 1, 2015 Share Posted March 1, 2015 With all DMA turned off and interrupts disabled, NTSC should have 15036.945 more cycles available than PAL per second - all up only about 0.92% faster. With VBlank interrupt enabled, almost half that advantage is lost. Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 1, 2015 Share Posted March 1, 2015 Hi!, The code posted by devwebcl does not include the optimizations of not drawing the black parts, it redraws from bottom to front as the original, this is the reason it is slower. This combines the drawing optimizations with the idea of only calculate half of the function, and also adds some little optimizations of mine: precomputing ZI+160 and ZI+90, reversing the condition in the inner IFs. The runtime in TruboBasic XL, NTSC is 22min 8sec, PAL is 20min 46sec. Note that this plots exactly the same figure as the original. 100 DIM RR(320) 110 FOR I=0 TO 320:RR(I)=193:NEXT I 120 GRAPHICS 8+16:SETCOLOR 2,0,0:COLOR 1 130 XP=144:XR=4.71238905:XF=XR/XP 140 FOR ZI=64 TO -64 STEP -1 150 ZT=ZI*2.25:ZS=ZT*ZT 160 XL=INT(SQR(20736-ZS)+0.5) 170 ZX=ZI+160:ZY=90+ZI 180 FOR XI=0 TO XL 190 XT=SQR(XI*XI+ZS)*XF 200 YY=(SIN(XT)+SIN(XT*3)*0.4)*56 210 X1=XI+ZX:Y1=ZY-YY 220 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 230 X1=ZX-XI 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 250 NEXT XI:NEXT ZI 260 GOTO 260 To run this on a CoCo 3 make these changes. Line 90 enables high speed mode and it uses a 16 color screen mode with the default palette. 90 POKE 65497,1 120 PMODE 4,1:HSCREEN 2:SCREEN 1,1 220 IF RR(X1)>Y1 THEN RR(X1)=Y1:HSET(X1,Y1) 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:HSET(X1,Y1) Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 1, 2015 Share Posted March 1, 2015 With all DMA turned off and interrupts disabled, NTSC should have 15036.945 more cycles available than PAL per second - all up only about 0.92% faster. With VBlank interrupt enabled, almost half that advantage is lost. So fater, but not a lot. Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 1, 2015 Share Posted March 1, 2015 Does someone with a better understanding of the program know what lines of code would need to be changed to limit the program to a 256 pixel width instead of 320? The TI people are simply letting the program run as is and then multiplying the x and y pixel results by .75 to stay under the 256 pixels, but with the number of pixels plotted those extra multiplies are going to hurt speed a bit. Thanks, Bob Line 170 centers the image by adding 160 and 90. 160 will have to be changed to 128. Line 100 and 110 expect 320 pixel wide screen. Those should have 320 changed to 256. XP appears to be number of pixels either side of center? (total guess) XR appears to be the screen x vs y ratio which has to be changed for the 256x192 screen I'd have to spend more time looking at it if that doesn't do the trick. Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 1, 2015 Share Posted March 1, 2015 To run this on a CoCo 3 make these changes. Line 90 enables high speed mode and it uses a 16 color screen mode with the default palette. BTW, it works but I don't know if it's how it should be done. Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 2, 2015 Share Posted March 2, 2015 Hi!, Does someone with a better understanding of the program know what lines of code would need to be changed to limit the program to a 256 pixel width instead of 320? The TI people are simply letting the program run as is and then multiplying the x and y pixel results by .75 to stay under the 256 pixels, but with the number of pixels plotted those extra multiplies are going to hurt speed a bit. The following program allows adjusting the size of the drawn picture, in line 100: 100 SX=144:SY=56:SZ=64:CX=320:CY=192 110 DIM RR(CX) 120 FOR I=0 TO CX:RR(I)=CY:NEXT I 130 GRAPHICS 8+16:SETCOLOR 2,0,0:COLOR 1 140 CX=CX*0.5:CY=CY*0.46875:FX=SX/64:FZ=SZ/64 150 XF=4.71238905/SX 160 FOR ZI=64 TO -64 STEP -1 170 ZT=ZI*FX:ZS=ZT*ZT 180 XL=INT(SQR(SX*SX-ZS)+0.5) 190 ZX=ZI*FZ+CX:ZY=CY+ZI*FZ 200 FOR XI=0 TO XL 210 XT=SQR(XI*XI+ZS)*XF 220 YY=(SIN(XT)+SIN(XT*3)*0.4)*SY 230 X1=XI+ZX:Y1=ZY-YY 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 250 X1=ZX-XI 260 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 270 NEXT XI:NEXT ZI 280 GOTO 280 The variables are:* CX, CY: Size of screen, in pixels. * SX, SY, SZ: Scales of the X, Y and Z components in pixels. For a smaller screen, simply divide each proportionally. For fun, this is a big and smoothed version: 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 2, 2015 Share Posted March 2, 2015 Can anyone here do this in Python? I know there isn't a Python for the Atari8, but I would love to see how this would be set up in it. I'm super newb in it and don't know how to use graphics yet. Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 2, 2015 Share Posted March 2, 2015 (edited) 100 SX=144:SY=56:SZ=64:CX=320:CY=192 For 256 wide screen multiply every scale variable on line 100 by 256/320 which is 0.8 and set CX to 256 Edited March 2, 2015 by JamesD Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 2, 2015 Share Posted March 2, 2015 (edited) Hi!, The following program allows adjusting the size of the drawn picture, in line 100: 100 SX=144:SY=56:SZ=64:CX=320:CY=192 110 DIM RR(CX) 120 FOR I=0 TO CX:RR(I)=CY:NEXT I 130 GRAPHICS 8+16:SETCOLOR 2,0,0:COLOR 1 140 CX=CX*0.5:CY=CY*0.46875:FX=SX/64:FZ=SZ/64 150 XF=4.71238905/SX 160 FOR ZI=64 TO -64 STEP -1 170 ZT=ZI*FX:ZS=ZT*ZT 180 XL=INT(SQR(SX*SX-ZS)+0.5) 190 ZX=ZI*FZ+CX:ZY=CY+ZI*FZ 200 FOR XI=0 TO XL 210 XT=SQR(XI*XI+ZS)*XF 220 YY=(SIN(XT)+SIN(XT*3)*0.4)*SY 230 X1=XI+ZX:Y1=ZY-YY 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 250 X1=ZX-XI 260 IF RR(X1)>Y1 THEN RR(X1)=Y1:PLOT X1,Y1 270 NEXT XI:NEXT ZI 280 GOTO 280 The variables are:* CX, CY: Size of screen, in pixels. * SX, SY, SZ: Scales of the X, Y and Z components in pixels. For a smaller screen, simply divide each proportionally. For fun, this is a big and smoothed version: fedora.png To run this on a CoCo 1/2 in Extended Color BASIC make these changes. Line 90 enables high speed mode. Line 101 sets the proper scale for 256 pixel wide screen. Feel free to substitute the numbers produced on line 101 for the constants on line 100. I'm just being lazy or I would have done it. Line 130 sets the RG6 graphics mode on the 6847, clears the high res screen and then displays it in the black & green color set. Lines 240 and 260 were modified to use the CoCo pixel routines. I did test this but accidentally hit the OFF key on VCC while looking for the BREAK key so there is a chance this code may have a typo. 90 POKE 65495,1 101 SX=.8*SX:SY=.8*SY:SZ=.8*SZ 130 PMODE 4:PCLS:SCREEN 1,1 240 IF RR(X1)>Y1 THEN RR(X1)=Y1:PSET(X1,Y1) 260 IF RR(X1)>Y1 THEN RR(X1)=Y1:PSET(X1,Y1) For slightly more speed you can renumber the program starting at line 0 and incrementing by 1.Do this by typing the following line at the command prompt after you have entered and debugged the code. RENUM 0,0,1 *edit* That may only speed up code that uses GOTO and GOSUB, I haven't tested it on this but it was something I regularly did with my own code as a kid when I was trying to speed things up. Edited March 2, 2015 by JamesD Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 2, 2015 Share Posted March 2, 2015 I forgot to change line 100 so that 320 is 256.Thanks to bfollett for pointing it out on the code I posted in the TI area. Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 2, 2015 Share Posted March 2, 2015 Line 130 sets the RG6 graphics mode on the 6847, clears the high res screen and then displays it in the black & green color set. Actually, it's the B&W color set. Been a long time since I programmed a CoCo in BASIC. I was going to attach a photo but I guess I can't do that. Quote Link to comment Share on other sites More sharing options...
bfollett Posted March 2, 2015 Share Posted March 2, 2015 (edited) Actually, it's the B&W color set. Been a long time since I programmed a CoCo in BASIC. I was going to attach a photo but I guess I can't do that. There's a "More Reply Options" button at the bottom right hand corner when you are entering a post. That's where the option to post a picture is located. Bob Edited March 2, 2015 by bfollett Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 3, 2015 Share Posted March 3, 2015 (edited) Actually, it's the B&W color set. Been a long time since I programmed a CoCo in BASIC. I was going to attach a photo but I guess I can't do that. Edited March 3, 2015 by JamesD Quote Link to comment Share on other sites More sharing options...
JamesD Posted March 3, 2015 Share Posted March 3, 2015 (edited) CoCo 3, default palette, 320x192 (I think that's the vertical resolution)640x192, haven't adjusted all the parameters yet Edited March 3, 2015 by JamesD Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.