Jump to content

Photo

Graphics 8 Fedora Hat


124 replies to this topic

#26 bfollett OFFLINE  

bfollett

    Dragonstomper

  • 508 posts

Posted Sat Feb 28, 2015 3:04 PM

 

Try using my optimization on post #14. The result is the same

http://manillismo.bl...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

Attached Thumbnails

  • bug.png


#27 devwebcl OFFLINE  

devwebcl

    Stargunner

  • 1,122 posts
  • Location:Chile

Posted Sat Feb 28, 2015 3:07 PM

:

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



#28 bfollett OFFLINE  

bfollett

    Dragonstomper

  • 508 posts

Posted Sat Feb 28, 2015 4:49 PM

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



#29 dmsc OFFLINE  

dmsc

    Chopper Commander

  • 247 posts
  • Location:Viņa del Mar, Chile

Posted Sat Feb 28, 2015 9:38 PM

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


#30 ClausB OFFLINE  

ClausB

    Stargunner

  • 1,384 posts
  • Location:Michigan

Posted Sun Mar 1, 2015 7:33 AM

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.



#31 bfollett OFFLINE  

bfollett

    Dragonstomper

  • 508 posts

Posted Sun Mar 1, 2015 8:14 AM

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



#32 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 12,579 posts
  • Location:United Kingdom

Posted Sun Mar 1, 2015 8:19 AM

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

#33 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,103 posts
  • Location:Australia

Posted Sun Mar 1, 2015 8:34 AM

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



#34 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,642 posts
  • Location:United States of America

Posted Sun Mar 1, 2015 11:35 AM

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 by fujidude, Sun Mar 1, 2015 11:35 AM.


#35 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 12,579 posts
  • Location:United Kingdom

Posted Sun Mar 1, 2015 11:56 AM

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

Edited by flashjazzcat, Sun Mar 1, 2015 11:56 AM.


#36 bfollett OFFLINE  

bfollett

    Dragonstomper

  • 508 posts

Posted Sun Mar 1, 2015 12:07 PM

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



#37 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,103 posts
  • Location:Australia

Posted Sun Mar 1, 2015 3:46 PM

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.



#38 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Sun Mar 1, 2015 5:02 PM

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)



#39 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,642 posts
  • Location:United States of America

Posted Sun Mar 1, 2015 5:34 PM

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.



#40 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Sun Mar 1, 2015 5:35 PM

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.



#41 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Sun Mar 1, 2015 5:37 PM

 

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.



#42 dmsc OFFLINE  

dmsc

    Chopper Commander

  • 247 posts
  • Location:Viņa del Mar, Chile

Posted Sun Mar 1, 2015 9:52 PM

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:
fedora.png

#43 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,642 posts
  • Location:United States of America

Posted Sun Mar 1, 2015 10:28 PM

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.



#44 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Sun Mar 1, 2015 11:15 PM

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 by JamesD, Sun Mar 1, 2015 11:23 PM.


#45 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Mon Mar 2, 2015 9:05 AM

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:
attachicon.giffedora.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 by JamesD, Mon Mar 2, 2015 9:13 AM.


#46 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Mon Mar 2, 2015 10:53 AM

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.



#47 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Mon Mar 2, 2015 5:08 PM

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.



#48 bfollett OFFLINE  

bfollett

    Dragonstomper

  • 508 posts

Posted Mon Mar 2, 2015 5:46 PM

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 by bfollett, Mon Mar 2, 2015 5:46 PM.


#49 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Mon Mar 2, 2015 6:22 PM

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.

FedoraVcc.jpg


Edited by JamesD, Mon Mar 2, 2015 6:31 PM.


#50 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,571 posts
  • Location:Flyover State

Posted Mon Mar 2, 2015 6:29 PM

CoCo 3, default palette, 320x192 (I think that's the vertical resolution)

FedoraVccCC3.jpg


640x192, haven't adjusted all the parameters yet
FedoraVccCC3640.jpg


Edited by JamesD, Mon Mar 2, 2015 6:46 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users