Line Fill Effect in XB - an exercise in futility

[InfernalKeith]

Had an idea for a graphical "fill" that would fill up the entire screen very gradually, in a fluid way. My plan was to write it in BASIC, then compile it with Harry Wilhelm's compiler, to make it fill the screen quickly.

 

I devised the way to redefine the characters and had them just fill one screen row first. I had to switch to XB because I needed CALL CHARPAT... then I tried to compile and found out that CHARPAT isn't supported by the compiler. Rats!

 

Anyway, so here's a graphical depiction of what would be a really cool effect, only it's at glacial speed and therefore as exciting as watching dust accumulate.

 

Although... I think I may have just thought of a workaround, albeit a really clumsy one. More later.

 

 

100 REM  LINE FILL EFFECT
110 REM  KEITH BERGMAN 6/9/2012
120 DIM FLAG(32)
130 CALL CLEAR
140 FOR X=1 TO 32
150 CALL CHAR(X+64,"0000000000000000")
160 CALL HCHAR(12,X,X+64)
170 NEXT X
180 X=INT(RND*32)+1
190 IF FLAG(X)=1 THEN 180
200 Y=INT(RND*2)+1
210 CALL GCHAR(12,X,C)
220 IF Y=1 THEN 380
230 FFLAG=16
240 C$=CHR$(C)
250 CALL CHARPAT(ASC(C$),Z$)
260 T$=SEG$(Z$,FFLAG,1)
270 IF T$="F" THEN 340
280 T$=CHR$(ASC(T$)+1)
290 IF T$=":" THEN T$="A"
300 Z$=SEG$(Z$,1,FFLAG-1)&T$&SEG$(Z$,FFLAG+1,16-FFLAG)
310 CALL CHAR(C,Z$)
320 CALL HCHAR(12,X,C)
330 GOTO 180
340 FFLAG=FFLAG-2
350 IF FFLAG>0 THEN 240
360 FLAG(X)=1
370 GOTO 180
380 FFLAG=15
390 GOTO 240

[sometimes99er]

100 CALL CLEAR:$="10125256D6DEDFFF"::DIM X(31)
110 FOR A=0 TO 7::CALL CHAR(33+A,SEG$(P$,A*2+1,2))::NEXT A
120 R=INT(RND*32)::CALL HCHAR(12,R+1,X(R)+33):(R)=X(R)+1+(X(R)>6)::GOTO 120

Edited June 27, 2012 by sometimes99er

[sometimes99er]

100 FOR A=1 TO 8::CALL CHAR(32+A,RPT$("FF",A)):$(A)=RPT$(CHR$(32+A),28)::NEXT A
110 FOR A=1 TO 24::FOR B=1 TO 8::DISPLAY AT(A,1)$(B); ::NEXT B::NEXT A::CALL CLEAR

Edited June 27, 2012 by sometimes99er

[Tursi]

I don't know the limitations of the compiler, so maybe this won't compile either, but this version is faster and doesn't need charpat (it works in TI BASIC). It does use a lot more memory though, storing both the strings and double the number of flags (one flag for each nibble plus one for 1-base). I kept your line numbering as much as possible to make it easier to see what I changed.

 

Although, it's faster, but running them side-by-side, it's not MUCH faster. Still not really watchable.

 

One thing I observed while running this was that the temporary strings cause the garbage collector to be run pretty often, so I tried to minimize them by combining string manipulation statements. Based on the Classic99 heatmap, this version needs to run garbage collection a little over half as often.

 

100 REM  LINE FILL EFFECT
110 REM  KEITH BERGMAN 6/9/2012
115 REM  TURSI'S ATTEMPT AT OPTIMIZING
120 DIM DC$(32),FLAG(65)
130 CALL CLEAR
135 HEX$="0123456789ABCDEF"
140 FOR X=1 TO 32
145 DC$(X)="0000000000000000"
146 FLAG(X*2)=15
147 FLAG(X*2+1)=16
150 CALL CHAR(X+64,DC$(X))
160 CALL HCHAR(12,X,X+64)
170 NEXT X
180 X=INT(RND*32)+1
185 Y=INT(RND*2)
186 FPOS=X*2+Y
190 IF FLAG(FPOS)<=0 THEN 180
260 SPOS=FLAG(X*2+Y)
280 T$=SEG$(HEX$,POS(HEX$,SEG$(DC$(X),SPOS,1),1)+1,1)
290 IF T$<>"F" THEN 300
295 FLAG(FPOS)=FLAG(FPOS)-2
300 DC$(X)=SEG$(DC$(X),1,SPOS-1)&T$&SEG$(DC$(X),SPOS+1,16-SPOS)
310 CALL CHAR(X+64,DC$(X))
330 GOTO 180

 

Most of the complexity here is actually introduced by BASIC lacking access to video RAM - since essentially all you are doing is incrementing VRAM bytes. Ideally we put this into TF or assembly and it should fly.

[rocky007]

mmmh...still so slooow

 

100 CALL CLEAR
110 DIM A$(16)
111 DIM F(32),G(32)
112 DIM B$(32)
120 FOR I=1 TO 15
130 READ A$(I)
140 NEXT I
150 FOR I=1 TO 32
165 CALL CHAR(65+I,B$(I))
160 B$(i)="0000000000000000"
170 CALL HCHAR(12,I,65+I)
175 F(I)=1:: G(I)=1
180 NEXT I
185 I=INT(RND*31)+1 ::  P=G(I)+INT(RND*2)
190 C$=SEG$(B$(I),1,16-P)&A$(F(I))&SEG$(B$(I),18-P,P-1)
195 CALL CHAR(65+I,C$)
200 B$(I)=C$
210 F(I)=F(I)+1  :: IF F(I)=16 THEN F(i)=1::G(i)=G(i)+1
220 GOTO 185
500 DATA 1,2,3,4,5,6,7,8,9,A,B,C,D,E,F

[InfernalKeith]

Nice! As you can see, my programming "style" consists of running head-first into a brick wall over and over until it eventually falls down. In my defense, I coded that at 3am after working all day.

 

My next goal is to move the line of tiles down to row 24, then come up with a flag at which point we "fill" the tile in row 24 with an FFFFFFFFFFFFFFFF character and start the "liquid fill" (or, as it's been looking to me while I stare at it, the snowfall) on line 23, etc. Eventually we could fill the whole screen.... maybe in a month.

 

The trick is, one half of the tile could be at F (completely filled in) and the other is almost certain to be incomplete, which will lead to gaps. My idea (untested as of now) is, when one side fills, just redraw the whole tile as a filled square and move up one. It may look clumsy at BASIC speed, but - like the "hopping pixel" effect when you change a line in the chardef from 4 to 5 - at high speed it will just add to the liquid "pouring" effect I'm envisioning.

[Tursi]

Nice improvement, Rocky! I think you changed the behaviour a bit, though, it leaves gaps when it builds up. But the lookup table concept is definately a nice improvement.

 

The effect sounds pretty cool, Keith, I think I can see it working.

[rocky007]

yes Tursi, i made a big error in my code

so here it a new version, more optimised ( with very very little shorcut ):

 

100 CALL CLEAR
110 DIM A$(50),Y$(15),Z$(15)
113 DIM F(65),G(65)
115 DIM B$(32)
120 FOR I=1 TO 16
130 READ A$(I)
140 NEXT I
141 FOR I=1 TO 8
142 READ Y$(I)
143 NEXT I
144 FOR I=1 TO 8
145 READ Z$(I)
146 NEXT I
150 FOR I=1 TO 32
165 CALL CHAR(100+I,B$(I))
170 CALL HCHAR(12,I,100+I):: next i
175 FOR i=1 to 64 :: G(i)=8 :: f(i)=1 :: NEXT I
200 C=int(rnd*64)+1 :: A=int(C/2)
210 C$=Y$(G(A))&A$(F(A*2))&A$(F(A*2+1))&Z$(G(A))
220 F(C)=F(C)+1
230 IF F(c)>16 THEN G(A)=G(A)-1 :: F(A*2)=1::F(A*2+1)=1:: IF G(A)=0 THEN G(A)=1::F(A*2)=16::F(A*2+1)=16
235 CALL CHAR(100+A,C$)
240 GOTO 200
500 DATA 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F
510 DATA "",00,0000,000000,00000000,0000000000,000000000000,00000000000000
520 DATA FFFFFFFFFFFFFF,FFFFFFFFFFFF,FFFFFFFFFF,FFFFFFFF,FFFFFF,FFFF,FF,""

 

Just to see how slow TI basic is :

 

 

10 A$="FFFFFFFF"
20 FOR I=1 TO 1000
30 C$=A$&A$&A$
40 NEXT i

 

This code take 41 sec to finish

 

10 A$="FFFFFFFF"
20 FOR I=1 TO 1000
30 C$=RPT$("F",&RPT$("F",&RPT$("F",
40 NEXT i

 

Result : 2 minutes 10 sec

 

10 A$="FFFFFFFF"
20 FOR I=1 TO 1000
30 C$=SEG$(A$,1,&SEG$(A$,1,&SEG$(A$,1,
40 NEXT i

 

Result : 1 minute 50 sec.

Edited June 10, 2012 by rocky007

[RXB]

Rocky TI Basic runs all variables from VDP memory.

The Numeric and Strings and the program and disk buffers and cassette all run from the same VDP memory.

Now the problem gets worse in TI Basic vs Extended Basic as every single byte of program requires multiple times of VDP access.

GPL is forced to fetch each program byte from VDP multiple times to process the next command so one command could mean 8 times to access.

So commands like A$=RPT$ & RPT$ & RPT$ are the worst commands to stack together in one line.

 

Extended Basic (or RXB) or any XB versions only use VDP to store a program if less then 12K if I remember correctly.

I do have a utility in RXB to force XB (BASIC) programs into RAM so they run faster in RXB.