| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Questions about Basic-statements and logic
Hi,
//PW is DIM-table to {1,2,4,8,16,32,64,128}
210 B1 = PW(7-D0)
212 B2 = PW(R7)
214 B3 = PW(7-D1)
220 P1 = (PEEK(W+B) AND B1) / B1
222 P2 = (PEEK(W+A) AND B2) / B2
224 P3 = (PEEK(W+C) AND B3) / B3
I changed 220, 222 and 224 to:
220 P1 = (PEEK(W+B) AND B1)
222 P2 = (PEEK(W+A) AND B2)
224 P3 = (PEEK(W+C) AND B3)
and added the lines:
226 IF P1=B1 THEN P1=1
227 IF P2=B2 THEN P2=1
228 IF P3=B3 THEN P3=1
but it seems slower. IF..THEN slower than the divides. I guess Basic is doing alot of logic for this and waste more cycles. any ideas what to do to remove the divides?
I first thought of doing a lookup table, but that doesnt. In worst case I have to poke or read data statements of shift-opcodes, but are there any other ways?
Thanks. |
|
... 15 posts hidden. Click here to view all posts....
|
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Thanks for the comments.
TNT: i made an array of this now.
JackAsser: yes. i should look more into the operators. i made three attempts at an asm version allready, and failed. so, i go to basic code and come back to asm after some time. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Seriously?
yup. it might still make sense for c*base however, as you probably compile it - and a half decent compiler should make "real" integers from them (basic boss does it at least) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
482 bytes compiled which is smaller than the asm version and is very slow indeed:
1 G=8192:H=16191:M=53265:POKEM+7,PEEK(M+7)OR8:POKEM,PEEK(M)OR32:FORI=GTOH
2 POKEI,0:NEXT:FORI=1024TO2023:POKEI,1:NEXT:POKEM+15,0:DIMZ%(255,7):FORK=0TO255
3 FORL=0TO7:Z%(K,L)=0:IF((2^L)ANDK)=(2^L)THENZ%(K,L)=1
4 NEXT:NEXT:FORX=0TO31:POKEG+X*8,INT(RND(1)*256):NEXT:S=0:FORY=0TO198:E=S
6 IF(YAND7)=7THENS=S+320
7 V=G+S+((Y+1)AND7):W=G+E+(YAND7):A=-8:B=0:C=0:FORX=1TO318:N=7-((X-1)AND7)
8 U=7-(XAND7):T=7-((X+1)AND7):IFN=7THENA=A+8
9 IFU=7THENB=B+8
10 IFT=7THENC=C+8
11 P=Z%(PEEK(W+A),N):Q=Z%(PEEK(W+B),U):R=Z%(PEEK(W+C),T):I=V+B
12 IF((PANDQ)+R)AND1THENPOKEI,PEEK(I)OR2^U
14 NEXT:NEXT
15 GOTO15
i removed some of the tables in this version to make it shorter. the asm version takes 512b. which i suppose can be reduced a bit further. i dont know if anyone can reach the 256b range. no linear framebuffer is hell. :P
(ref. Chaotic Subsystems) |
| |
Street Tuff
Registered: Feb 2002
Posts: 88 |
hey rudi. i'm down to 332 bytes with something that looks similar to your results from your asm routine. 301 bytes without random initialisation. i think i cant reduce it any more. maybe some bytes here and there. 256 is atleast for me not doable with my approach.
http://www.daupara.de/rule106.rar |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
nice Street Tuff, i think you can get 256b if you process 256 pixels per row instead of 320 like i do in mine? i dont know how your chain works so i dont know how to fix it. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
This thread tickled me, I couldn't resist writing my own version.
Here it is a different approach and 192 bytes:
https://www.dropbox.com/s/qh2yb562u96qi0s/eca.zip?dl=0 |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Fresh: cool! that's how it should be done, and runs fast too |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
indeed, but the patterns doesnt seem as chaotic as they shoould be but thats just my gut feeling. |
| |
bugjam
Registered: Apr 2003
Posts: 2589 |
Created an entry for it: ECA.
Cheers! |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
There were room for further (little) improvements: this final version is 7 bytes shorter and a bit faster.
In the same zip there's another binary: in that version the rule is incremented every frame (starting from 106) so you get some kind of a "slideshow".
https://www.dropbox.com/s/0vxogaeacllylsp/eca2.zip?dl=0 |
| Previous - 1 | 2 | 3 - Next |
