Graphics 8 Fedora Hat

bfollett · 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

devwebcl · 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

bfollett · 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

dmsc · 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

ClausB · 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.

bfollett · 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

flashjazzcat · March 1, 2015

NTSC machines spend more time interrupted by the VBLANK, so there are marginally fewer cycles available to mainline code.

Rybags · March 1, 2015

The cycle loss in most cases due to refresh and graphics DMA will make NTSC slower than PAL.

fujidude · March 1, 2015

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

flashjazzcat · March 1, 2015

I fancy you'd want to disable the interrupts as well.

Edited March 1, 2015 by flashjazzcat

bfollett · 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

Rybags · 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.

JamesD · 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)

fujidude · 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.

JamesD · 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.

JamesD · 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.

dmsc · 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:

fujidude · 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.

JamesD · March 2, 2015

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

JamesD · March 2, 2015

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

JamesD · 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.

JamesD · 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.

bfollett · March 2, 2015

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

JamesD · March 3, 2015

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

JamesD · March 3, 2015

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

Graphics 8 Fedora Hat

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members