MINIGRAFIK batch processing suite

Basic and Machine Language

Moderator: Moderators

User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

Another one after quite a long time! :)

Sometimes it is necessary to use non-uniform distributed random numbers. One particular case are Gauss-distributed random numbers, i.e. when 'collected', they form the well-known bell curve.

A fairly known trick to produce these is to add up 12 random numbers with uniform distribution between 0 and 1, and subtract 6. This gives random numbers with a mean of 0 and a standard deviation of 1, and whose distribution for all practical purposes is indistinguishable from Gaussian randoms.

Well, let's see how this works out in MINIGRAFIK. ;)

The formula to stretch the range of z = -6 .. +6 to the x-coordinates 0.5 .. 159.5 (+.5 to account for the rounding into 160 'classes') would be X=159*(Z+6)/12+.5, the program below (download) omits the subtraction of 6 in the RNG-formula just to add it again for the scaling:

Code: Select all

1 Q=RND(-TI):CLR:DIMY(159):FORX=0TO159:Y(X)=192:NEXT:@ON:@CLR
2 Z=RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)+RND(1)
3 X=159*Z/12+.5:IFY(X)>0THENY(X)=Y(X)-1:@1,X,Y(X):GOTO2
4 GETA$:IFA$=""THEN4
5 @RETURN
As the program runs, one can see how the bell curve builds up. The 'noisy' shape is quite expected, as it takes much more drawn Gaussians to even it out.

Image
Last edited by Mike on Sat Jul 25, 2015 1:26 am, edited 8 times in total.
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: MINIGRAFIK batch processing suite

Post by darkatx »

That was fascinating and pretty quick too! Amazing seeing the Bell curve emerge out of twelve random numbers on such a tiny screen resolution!
Learning all the time... :)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

These days I had some fun porting a nice demonstration graphic from a C16/C116/+4 BASIC tutorial over to MINIGRAFIK (download). :mrgreen:

Code: Select all

10 GOTO28
11 :
12 X=0:Y=B:S=B*B:T=A*A*(2*Y-1):U=2*B*B:V=2*A*A:E=0
13 X1=MX+X:Y1=MY+Y:P1=X1>=0ANDX1<80:P2=Y1>=0ANDY1<192
14 X2=MX-X:Y2=MY-Y:P3=X2>=0ANDX2<80:P4=Y2>=0ANDY2<192
15 IFP1ANDP2THEN:@C,X1+X1,Y1
16 IFP1ANDP4THEN:@C,X1+X1,Y2
17 IFP3ANDP4THEN:@C,X2+X2,Y2
18 IFP3ANDP2THEN:@C,X2+X2,Y1
19 IFX=AANDY=0THENRETURN
20 F=E+S:D=0
21 G=F-T:IFABS(F)>ABS(G)THENF=G:D=1
22 G=E-T:IFABS(F)>ABS(G)THENF=G:D=2
23 E=F
24 IFD<2THENX=X+1:S=S+U
25 IFD>0THENY=Y-1:T=T-V
26 GOTO13
27 :
28 POKE646,13:@ON:@CLR:FORX=0TO159STEP2:@2,X,0TOX,191:NEXT:POKE36878,64:POKE36879,104
29 MX=40:MY=96
30 B=80:C=1:FORA=2TO22STEP4:GOSUB12:NEXT
31 A=24:C=0:FORB=0TO80STEP10:GOSUB12:NEXT
32 FORT=39TO0STEP-1:Y=2*SQR(6241-4*T*T)/3
33 IFT>27THENX=80+2*T:@3,X,96.5-YTOX,96.5+Y:X=80-2*T:@3,X,96.5-YTOX,96.5+Y:GOTO37
34 Z=2*SQR(3025-4*T*T)/3:X=80+2*T:@3,X,96.5+ZTOX,96.5+Y:X=80-2*T:@3,X,96.5+ZTOX,96.5+Y
35 IFT<25THENR=5*SQR(2401-4*T*T)/3:IFZ<RTHENZ=R:IFZ>YTHEN37
36 X=80+2*T:@3,X,96.5-ZTOX,96.5-Y:X=80-2*T:@3,X,96.5-ZTOX,96.5-Y
37 NEXT:FORP=-1TO0:GETA$:P=A$="":NEXT
38 RESTORE:FORT=1TO12:READC:POKE36878,16*C:FORS=1TO30:NEXT:NEXT:GOTO38
39 :
40 DATA 0,6,14,3,11,1,15,7,9,10,8,2
41 :
42 REM ** SATURN WRITTEN 2017-10-31 BY MICHAEL KIRCHER
The program draws Saturn with its rings:

Image

I (re-)used the ellipse drawing routines of the MG batch suite with a few alterations to make them work in multi-colour mode. They take their time though, but at least the ellipses themselves are mathematically correct (and are not faked by polygons as with the BASIC V3.5/V7 CIRCLE command!). The rings are drawn in the lines 32 to 37, and actually are quite fast at that. In BASIC, it's faster to draw filled circles/ellipses than just their outlines. :shock:

When the drawing has finished, press any key for an amazing neon effect!

Cheers,

Michael
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

This (slightly longer) post covers a MG tool package (download), which does huge global changes to a picture. To be more specific, the programs of this package facilitate to remap the colour sources. This comes in quite handy, if a draft done in MINIPAINT suggests it might be better to have another exterior border colour. It is also useful for outputs of PGM IMPORT and the ppm2cga converter (via the 'scrapfile' function of the CGA panning viewer), which by themselves only realise one possible mapping of the 4 displayed physical colours to the colour sources.

The package is only intended for use with strictly multi-coloured pictures. If you process pictures which contain hires foreground attributes, you'll get unexpected results.

Biggest, and most important tool here is REMAP itself. It takes source and target file names and remaps the colour sources. The assignments M(...)=... in the lines 11 to 14 determine, which colour source is mapped to what other colour source. By default, nothing happens (an example, which exchanges exterior border and background, is given below). REMAP checks for all foreground attributes to be the same colour and in multi-colour. It refuses to work, if the mapping cannot be done - for example, if the auxiliary colour happens to be orange, and this is supposed to be mapped to foreground, the video chip couldn't do this - REMAP then stops with an error message to tell you what went wrong. In general, it's always possible to exchange background with auxiliary colour, and foreground with border colour, respectively.

Multicolour pictures with differing foreground colours cannot be processed directly with REMAP. First, the foreground data is saved away and replaced by a single foreground colour. This is done with SPLIT. REMAP can then proceed with its task, provided the mapping of the foreground attributes remains unchanged (i.e. line 12: 12 M(1)=1 must remain so!). Finally JOIN rejoins (duh!) the processed 4-colour bitmap with the original foreground attributes.


Now for an example: the splash screen of "Spider vs. Doc Ock" as drawn by darkatx:

Image

Unfortunately, the picture features a black border, where a white border possibly might fit better to the scene. So let's go - at first, a glance of the colour sources in MINIPAINT:

Image

The colour numbers in MINIPAINT are offset by one (by a feature request to keep the colour keys grouped). For MINIGRAFIK, the background colour is #0, and white; the border colour is #2, and black, and the auxiliary colour is #3 and light blue. It is intended to keep the foreground attributes as they differ along the picture (red, yellow, green and even white are used) - i.e. we'll go and exchange background and border colour source. But first we need to separate the attribute data. Cyan (physical colour code 3) serves as replacement colour:

Code: Select all

LOAD"SPLIT",8

SEARCHING FOR SPLIT
LOADING
READY.
RUN
SOURCE? SPLASH.1
BITMAP? BITMAP
COLOUR? COLOUR
REPL. (0..7)? 3
We get this result:

Image

Now, REMAP can work upon the file "BITMAP" as this now only contains 4 colours. Lines 11 and 13 are prepared to exchange background and border colour:

Code: Select all

LOAD"REMAP",8

SEARCHING FOR REMAP
LOADING
READY.
11 M(0)=2
13 M(2)=0
RUN
SRC? BITMAP
DST? BITMAP2
When REMAP has finished (after one minute or so), the colour sources have been remapped. The picture still looks the same, just the video chip generates the physical colours inside the display frame from other bit patterns. But most important, the exterior border colour now is white, as was intended!

Image

Finally, we recombine the result in "BITMAP2" with the original foreground data:

Code: Select all

LOAD"JOIN",8

SEARCHING FOR JOIN
LOADING
READY.
RUN
BITMAP? BITMAP2
COLOUR? COLOUR
TARGET? SPLASH.2
... and here's the result:

Image

... :mrgreen:

Cheers,

Michael
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

I was not alone in having the need to solve the aforementioned issue... ;)

Lemon 64: Tool To Recolour Characters
mrr19121970 wrote:I was hoping that CHARpad would do this, but it doesn't. Anyone know of a tool to recolour multicolor CHARSETS ?

ie

Transparent
Char Colour
MC 1
MC 2

I want to change one of these attributes to another (say swap MC1 and Char Colour)
dyme wrote:charpad 2.0 has edit->multi-colour pixel swap
in the menu
mrr19121970 wrote:Fantastic! This is exactly what I needed. I didn't find it myself
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

A tool to import save files from Commodore Artist has been released over there in the "Collecting and History" section, in the thread "Commodore Artist Save Files".
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

Well... the Saturn demo program I posted some time ago featured a 'fake' latitude and longitude grid, but of course this can be made right for a serious application... here's a globe grid with a variable tilt angle (download):

Code: Select all

10 DIMS(90):GOTO26
11 :
12 B=W*B:IFD>=ETHENE=E+F
13 IFRTHENI=D:D=R:GOSUB20:U=C:V=S:D=I
14 GOSUB20:GOSUB18:I=X:J=Y
15 D=D+K:IFD>ETHEND=E
16 GOSUB20:GOSUB18:@G,I,JTOX,Y:I=X:J=Y:IFD<ETHEN15
17 RETURN
18 X=S*A:Y=C*B:IFRTHENZ=U*Y-V*X*W:X=U*X+V*Y/W:Y=Z
19 X=M+X+.5:Y=N-Y+.5:RETURN
20 Z=D-F*INT(D/F)
21 IFZ<QTHENS=S(Z):C=S(Q-Z):RETURN
22 IFZ<HTHENS=S(H-Z):C=-S(Z-Q):RETURN
23 IFZ<TTHENS=-S(Z-H):C=-S(T-Z):RETURN
24 S=-S(F-Z):C=S(Z-T):RETURN
25 :
26 Q=90:H=180:T=270:F=360:W=5/3
27 FORZ=0TO90:S(Z)=SIN({PI}*Z/180):NEXT
28 :
29 INPUT"TILT ANGLE";D:GOSUB20:C3=C:S3=S
30 :
31 POKE36879,8:POKE646,1:@ON:@CLR
32 :
33 FORPH=-90TO90STEP15:P1=0:D=PH:GOSUB20:C1=C:S1=S
34 FORL=-180TO180STEP5:D=L:GOSUB20:C2=C:S2=S
35 GOSUB47:IFP1ANDP2THEN:@1,X1,Y1TOX2,Y2
36 P1=P2:X1=X2:Y1=Y2:NEXT:NEXT
37 :
38 FORL=-180TO180STEP15:P1=0:D=L:GOSUB20:C2=C:S2=S
39 FORPH=-90TO90STEP5:D=PH:GOSUB20:C1=C:S1=S
40 GOSUB47:IFP1ANDP2THEN:@1,X1,Y1TOX2,Y2
41 P1=P2:X1=X2:Y1=Y2:NEXT:NEXT
42 :
43 G=1:M=80:N=96:A=57:B=57:D=0:E=360:R=0:K=5:GOSUB12
44 :
45 GETA$:ON-(A$="")GOTO45:@RETURN:END
46 :
47 X0=C1*S2:Y0=S1*C3-C1*C2*S3:Z0=S1*S3+C1*C2*C3
48 P2=(Z0>=0):IFNOTP2THENRETURN
49 X2=57*X0+80.5:Y2=96.5-95*Y0:RETURN
50 :
51 REM ** MG GLOBE GRID WRITTEN 2018-05-13 BY MICHAEL KIRCHER
With a tilt angle of 30° you get this result. Positive angles tilt the 'north' pole of the globe towards the observer:

Image

The grid separation is 15° for both latitude and longitude lines.

Now are there any astronomers around here in Denial who know where this type of grid might come in handy? :mrgreen:
User avatar
Noizer
Vic 20 Devotee
Posts: 297
Joined: Tue May 15, 2018 12:00 pm
Location: Europa

Re: MINIGRAFIK batch processing suite

Post by Noizer »

OK, thank you Mike for showing me this way
Valid rule today as earlier: 1 Byte = 8 Bits
-._/classes instead of masses\_.-
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

I toyed around with recursive graphics algorithms in the last days and checked out how to employ a somewhat more involved software variable stack to hold 'local' variables. This is an example of the Menger sponge fractal which runs on a VIC-20 with at least +8K RAM expansion. The fractal is iterated 2 steps (the graphics resolution wouldn't allow for more, anyway):

Image

Here's the BASIC program that draws the fractal (download):

Code: Select all

10 DIMS(9):P=0
11 POKE646,15:@ON:@CLR:FORY=0TO191STEP2:@2,0,YTO159,Y:@2,0,191-YTO159,191-Y:NEXT
12 POKE36878,32:POKE36879,104:X=36:Y=132:N=9:GOSUB15
13 GETA$:ON-(A$="")GOTO13:@RETURN:END
14 :
15 IFN>1THEN19
16 @1,X,Y+3TOX,Y+4:@3,X,Y+5TOX,Y+13:@1,X+2,Y+1TOX+2,Y+5:@3,X+2,Y+6TOX+2,Y+14
17 @1,X+4,YTOX+4,Y+6:@3,X+4,Y+7TOX+4,Y+15:@1,X+6,Y+1TOX+6,Y+5:@0,X+6,Y+6TOX+6,Y+14
18 @1,X+8,Y+2TOX+8,Y+3:@0,X+8,Y+4TOX+8,Y+12:RETURN
19 FORW=0TO2:FORV=2TO0STEP-1:FORU=0TO2
20 IFU=1ANDV=1ORV=1ANDW=1ORW=1ANDU=1THEN24
21 S(P)=X:S(P+1)=Y:S(P+2)=U:S(P+3)=V:S(P+4)=W:P=P+5:N=N/3
22 X=X+N*(6*U+4*V):Y=Y+N*(3*U-5*V-9*W):GOSUB15
23 N=N*3:P=P-5:W=S(P+4):V=S(P+3):U=S(P+2):Y=S(P+1):X=S(P)
24 NEXT:NEXT:NEXT:RETURN
25 :
26 REM ** MG MENGER SPONGE WRITTEN 2021-04-02 BY MICHAEL KIRCHER
The subroutine beginning in line 15 is recursively called by the GOSUB statement in line 22, and lines 21 and 23 operate upon the software stack. Lines 16..18 draw the volume element (voxel), a small cube with 3 visible faces to the front (red), side (blue) and top (yellow).

The most interesting aspect IMO though is, that the GOSUB in line 22 actually works as 'barrier' on the CPU stack, so the FOR loops in line 19 get re-instantiated even though they have the same loop variable name! The original version made the loops 'by hand' with IF ... GOTO constructs, the current version uses less code but nearly fills up the CPU stack.

There also exists a version that simply reads off the position of the 400 voxels from DATA lines. It runs roughly twice as fast (thus tells what the overhead is) but of course doesn't show anymore the recursive nature of the graphics algorithm.

A Happy Easter to all,

Michael
User avatar
chysn
Vic 20 Scientist
Posts: 1205
Joined: Tue Oct 22, 2019 12:36 pm
Website: http://www.beigemaze.com
Location: Michigan, USA
Occupation: Software Dev Manager

Re: MINIGRAFIK batch processing suite

Post by chysn »

Mike wrote: Mon Apr 05, 2021 1:28 pm The most interesting aspect IMO though is, that the GOSUB in line 22 actually works as 'barrier' on the CPU stack, so the FOR loops in line 19 get re-instantiated even though they have the same loop variable name!
Variable scope in CBM BASIC is almost as cool as the resulting image, which is pretty cool by itself.
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5

WIP: MIDIcast BASIC extension

he/him/his
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: MINIGRAFIK batch processing suite

Post by Mike »

in another thread, Mike wrote: Just a small teaser after the successful commissioning of a polygon fill routine, a.k.a. 'rasterizer' (download):

Image

The demo program simply churns out the vertical line segments that were extracted from the rasterizing algorithm in a post-processing step: [...]

... more to follow in the main thread about MG in the next days ... :mrgreen:
Several months later now, here is the original program I extracted the line segments from (download):

Code: Select all

10 M=20:DIMX(M),Y(M),Z(M):GOTO41
11 :
12 X0=X(0)
13 X1=X(0)
14 FORI=1TON
15 IFX0>X(I)THENX0=X(I)
16 IFX1<X(I)THENX1=X(I)
17 NEXT
18 X0=-INT(-X0):IFX0<0THENX0=0
19 X1=INT(X1):IFX1>159THENX1=159
20 IFX0>X1THENRETURN
21 FORX=X0TOX1
22 K=0
23 J=N
24 FORI=0TON
25 IFX(I)=X(J)ORNOT(X(I)<=XANDX<X(J)ORX(J)<=XANDX<X(I))THEN27
26 Z(K)=(Y(I)*(X-X(J))+Y(J)*(X(I)-X))/(X(I)-X(J)):K=K+1
27 J=I
28 NEXT
29 IFK<2THEN38
30 FORI=1TOK-1:Z=Z(I)
31 FORJ=I-1TO0STEP-1:IFZ(J)>ZTHENZ(J+1)=Z(J):NEXT
32 Z(J+1)=Z:NEXTI
33 FORI=0TOK-2STEP2
34 Y0=-INT(-Z(I)):IFY0<0THENY0=0
35 Y1=INT(Z(I+1)):IFY1>191THENY1=191
36 IFY0<=Y1THEN:@1,X,Y0TOX,Y1
37 NEXT
38 NEXT
39 RETURN
40 :
41 @ON:@CLR
42 READN:IFN=-1THEN45
43 FORI=0TON:READX,Y:X(I)=X/5+.5:Y(I)=Y/3+.5:NEXT
44 GOSUB12:GOTO42
45 FORP=-1TO0:GETA$:P=A$="":NEXT
46 @RETURN:END
47 :
48 DATA 12, 76,235,125,44,151,47,191,143,231,39,259,36,299,233,258,239,243,92,210,175
49 DATA 171,178,143,90,117,242, 3, 326,35,370,28,379,233,343,232, 9, 432,25,473,26,550
50 DATA 211,568,30,606,34,579,244,529,239,463,68,459,234,424,231, 3, 659,42,701,48,667
51 DATA 259,629,252, 20, 40,315,93,315,124,347,109,364,83,338,41,344,24,420,36,495,74
52 DATA 503,93,454,55,454,53,433,122,434,127,527,107,528,106,472,92,513,71,530,35,530,5
53 DATA 486,8,349, 18, 148,308,173,332,206,330,221,343,223,379,205,393,174,393,173,332
54 DATA 148,308,219,306,244,331,247,391,217,416,189,416,239,515,215,518,174,443,179,519
55 DATA 153,521, 12, 334,299,341,352,352,411,321,409,341,352,334,299,360,300,402,523
56 DATA 372,523,356,436,312,433,284,517,254,515, 9, 433,302,562,310,561,339,472,333,469
57 DATA 393,527,396,525,428,467,423,463,525,425,523, 3, 585,311,621,315,607,531,571,528
58 DATA 12, 647,319,679,321,672,411,757,328,786,329,784,357,692,434,776,519,773,548,746
59 DATA 545,667,451,661,539,631,535, -1
60 :
61 REM ** MG POLYGON FILL WRITTEN 2021-11-03 BY MICHAEL KIRCHER
As this code has all to do the line clipping and sorting, etc., it runs much slower than the demo I published earlier, with those extracted line segments - but here we have an implementation of a generic polygon fill algorithm (with 'even-odd' fill rule).

Greetings,

Michael
Post Reply