Denial

Posted: **Thu Jun 02, 2011 3:07 am**

GreyGhost wrote:I went a little crazy last night and made this slide slow. All but one are black and white. Btw, I like fantasy art.

http://www.freedrive.com/file/1458209

Cool!

I loaded the Ninja into MINIPAINT and turned it into a coloured picture:

Here are the workstages as slide show.

Posted: **Thu Jun 02, 2011 5:41 am**

It's a Vic coloring book.

Posted: **Mon Jun 06, 2011 2:07 pm**

Or "Paint by Number", heh.

In the same comic style I did the Smurf and Ghostbusters picture (both in the slide show) and also the Mickey Mouse picture, which is stored on the MAXIGRAFIK disk.

Black as background(!) is used for the line art, in hires mode, which then is colourated. Where possible, the hires attribute is kept for maximum resolution. Only where two or more colours other than black meet in a attribute cell, or an area should be painted into one of the upper 8 colours (implying use of the auxiliary colour), it is necessary to change that cell into multi-colour.

The contents of an attribute cell changed from hires to multi-colour will appear in false colours, so some re-painting is necessary there. Auxiliary and border colour should be carefully chosen to represent the most often used colours other than black in multicolour cells, and the foreground colour is helpful to work out details in the remaining colours.

Posted: **Mon Jun 06, 2011 4:39 pm**

Here's a couple I have worked on in multicolor:

http://www.freedrive.com/file/1462205

http://www.freedrive.com/file/1462206
(If this one is too racy, let me know and i will take the pic out. I figured PG at best.)

But you are right Mike, with the right color choices and some help from Minipaint, you can produce some beautiful work.

Posted: **Tue Jun 07, 2011 1:25 am**

Cool! This way, we can produce intro screens à la C64 / Spectrum for our games - or even tape covers! Once again, if only we had these tools back then...

Posted: **Tue Jun 07, 2011 10:02 pm**

Nice pics! Maybe we should open a thread for everybody's MINIGRAFIK creations?

Here's another picture I made. As always it's original hence the very limited colors. Hires just produces much nicer results IMO and it's hard to make natural color transitions with 8x16 chars especially since the only original color per cell must be in the lower 8 colors. Every time I experiment with multicolor I always slowly turn it into hires because it looks better, and, in the end, the result is...well, like this.

download

p.s. Hope my spelling doesn't offend anyone.

Posted: **Wed Jun 08, 2011 6:05 am**

Creepy... that looks like me in the morning mirror.

Posted: **Wed Jun 08, 2011 12:02 pm**

I used the following program to convert the splash screen of 'Realms of Quest 3', as can be found on pixeljoint, back to MG file format:

(download)

Code: Select all

10 PF$="INPUT.PPM":TF$="RESULT.PRG"
11 G=8:F=1:B=0:A=7
12 :
13 LF$=CHR$(10):NU$=CHR$(0):OPEN2,8,2,PF$+",S,R"
14 GOSUB26:PRINTLI$:IFLI$<>"P6"THENCLOSE2:STOP
15 GOSUB26:PRINTLI$:IFLI$<>"80 192"THENCLOSE2:STOP
16 GOSUB26:PRINTLI$:IFLI$<>"255"THENCLOSE2:STOP
17 PRINT"HEADER OK. PRESS KEY."
18 GETA$:IFA$=""THEN18
19 POKE36879,16*G+8+B:POKE36878,16*A:POKE646,8+F:@ON:@CLR
20 FORY=0TO191:FORX=0TO79
21 GET#2,R$,G$,B$:GOSUB31
22 NEXT:NEXT:CLOSE2
23 GETA$:IFA$=""THEN23
24 @SAVETF$,8:@RETURN:END
25 :
26 LI$=""
27 GET#2,A$:IFA$<>LF$THENLI$=LI$+A$:GOTO27
28 IFLEFT$(LI$,1)="#"THEN26:REM IGNORE COMMENT LINES
29 RETURN
30 :
31 C=ASC(G$+CHR$(0))
32 REMIFC=90THEN:@0,2*X,Y
33 IFC=255THENPOKE646,8+1:@1,2*X,Y
34 IFC=24THENPOKE646,8+2:@1,2*X,Y
35 IFC=42THENPOKE646,8+6:@1,2*X,Y
36 IFC=0THEN:@2,2*X,Y
37 IFC=225THEN:@3,2*X,Y
38 RETURN

It works as PPM import, sort of - the prerequisite being the 3 global colours already have been identified in the picture, and the foreground colour does not produce any clashes. The subroutine at line 31 just compares the green component to decide which logical colour source is used to plot the pixel, and, in case of a foreground source, 'POKE646,...' first selects the correct physical colour.

GreyGhost wrote:Here's a couple I have worked on in multicolor

Those are really fine examples.

That must have been quite an effort to repaint the foreground areas, but the result surely is worth it!

Wilson wrote:Maybe we should open a thread for everybody's MINIGRAFIK creations?

Or even create a new section 'Design' for similar topics?

Hope my spelling doesn't offend anyone.

I suppose that topic had been discussed in an earlier thread just three weeks ago.

Posted: **Thu Jun 09, 2011 12:44 am**

rhurst wrote:Creepy... that looks like me in the morning mirror.

You and I both.

Mike wrote:I used the following program to convert the splash screen of 'Realms of Quest 3', as can be found on pixeljoint, back to MG file format:

Nifty! Can this handle mixed multicolor/hires? I had to screenshot->scale->fix->convert to monochrome->convert PGM->recolor three times making my last graphic. This would at least make that a little faster of a process.

Mike wrote:Or even create a new section 'Design' for similar topics?

Hey, good idea! If the number of creative releases as of late keeps up this would surely be justified. Maybe more people would be encouraged to try their hand at graphics as well?

I suppose that topic had been discussed in an earlier thread just three weeks ago.

Heh, yeah, I noticed that word come up a lot in this thread, and I couldn't resist the opportunity.

Posted: **Thu Jun 09, 2011 1:15 am**

Wilson wrote:Nifty! Can this handle mixed multicolor/hires? I had to screenshot->scale->fix->convert to monochrome->convert PGM->recolor three times making my last graphic. This would at least make that a little faster of a process.

The converter is specifically tailored to reconvert the RoQ3 splash screen.

If you want to expand upon this example to handle mixed hires/multi-colour, you'd use 160x192 as input resolution. That most probably requires two passes over the file: the first one to check which cells could be done in hires or require multi-colour - storing away the foreground/MC enable info for each cell, and the second pass doing the actual conversion.

Of course that critically depends on that the picture plays 'by the rules', i.e. keeps within the limits of the graphics mode, that MINIGRAFIK provides. The program still wouldn't convert arbitrary image data:

PGM IMPORT and PGM IMPORT MONO use a simpler model of the input data, either greyscale or bi-tonal, which can be converted reliably and where the output has a reasonable similarity to the input. Shaping a much more complex input - i.e. true colour data - into the limits of MG's graphics mode requires much more computing power - up to the point that the converter needs to be run on PCs to obtain the result in a bearable time.

Posted: **Wed Jul 27, 2011 6:16 am**

Hello everyone.

I thought I'd throw these programs out here for everyone to try out. I have been playing around with the original minigrafik and converted a couple of Mikes programs to work with it.

PGM Import Mono 128

Code: Select all

10 dimc%(1)
12 input"pgm file";pf$
13 input"target";tf$
14 input"foreground  1{left*3}";f
15 input"background  0{left*3}";g
16 input"border  0{left*3}";b
17 input"invert input  n{left*3}";yn$:c%(1+(yn$="y"))=1
19 lf$=chr$(10):nu$=chr$(0):open2,8,2,pf$+",s,r"
20 gosub32:printli$:ifli$<>"p5"thenclose2:stop
21 gosub32:printli$:ifli$<>"128 128"thenclose2:stop
22 gosub32:printli$:ifli$<>"255"thenclose2:stop
23 print"header ok."
24 geta$:ifa$=""then24
25 poke36879,16*g+8+b:poke646,f:@on:@clr
26 fory=0to127:forx=0to127
27 get#2,a$:@c%(-(asc(a$+nu$)>=128)),x,y
28 next:next:close2
29 geta$:ifa$=""then29
30 sys57809tf$,8,1:poke193,0:poke194,24:poke780,193:poke781,0
31 poke782,32:sys65496:@return:end
32 li$=""
33 get#2,a$:ifa$<>lf$thenli$=li$+a$:goto33
34 ifleft$(li$,1)="#"then32
35 return

Slide Show 128

Code: Select all

10 @on:@clr
20 readn$:ifn$=""then:@return:end
30 sys57809n$,8,1:poke780,0:sys65493
40 geta$:ifa$=""then40
50 goto20
60 "add your data here"

Mike, I noticed that when you resize a line art picture that some of the pixels in the original PGM file turn gray. When you convert the picture it looses some of the detail that it had. By playing around with the 128 value in line 27 I was able to get some of this detail back. Any thoughts or ideas about making this value variable. Just wondering.

Also, wondering why the original author used double height character cells. Seems to me no matter which size you use the data size is the same, but with the single height characters you would have more control over the screen color. Only drawback I see is using up the entire character set.

Posted: **Wed Jul 27, 2011 11:53 am**

GreyGhost wrote:Any thoughts or ideas about making this value variable. Just wondering.

Well, those are BASIC programs - you can simply adapt them to your needs. It's quite easy to add an extra INPUT statement, where you can enter a different threshold.

Also, wondering why the original author used double height character cells [...] with [...] single height characters you would have more control over the screen color.

For double-height characters he only needed to initialise a 128 bytes 'text' screen, instead of 256 bytes. Anyhow, the original version of MINIGRAFIK didn't bother updating the colour RAM in the drawing commands. Only the @ON command accessed the colour RAM, initialising it to the current foreground colour.

I changed that behaviour when I rewrote MINIGRAFIK. @ON does not anymore initialise the colour RAM, that is done by @CLR instead. The point plot and line draw command also update the colour RAM to reflect the current foreground colour, but they only infer the least necessary changes so the pixel appears in the intended way.

I'd suggest you use the jump table at the end of the ROM to call the KERNAL load and save routines. This way they can profit from softloaded floppy speeders like SJLOAD. See here.

Posted: **Wed Jul 27, 2011 4:15 pm**

Ok, I have corrected the load and save portions of the programs above. Thanks for that.

Also, for the pictures in the slide show above to look correct, its best to select "yes" to invert the input in PGM Import Mono 128.

Posted: **Fri Oct 21, 2011 5:31 pm**

Hi, y'all.

This small utility, 'makeboot.prg' (... which has been added to the *.d64 of the MG batch suite ...), creates a boot loader, which first starts up MINIGRAFIK, and then a client program.

Code: Select all

10 DATA 1,18,12,18,-1,-2,158,32,52,54,50,50,0,0,0,169,1,166,186,160,0,32,186,255,169,10
11 DATA 162,88,160,18,32,189,255,169,0,162,61,160,32,32,213,255,134,43,132,44,32,240,32
12 DATA 169,1,166,186,160,0,32,186,255,169,-3,162,98,160,18,32,189,255,169,0,166,43,164
13 DATA 44,32,213,255,134,45,132,46,32,51,197,32,89,198,76,174,199,77,73,78,73,71,82,65
14 DATA 70,73,75:INPUT"NAME";N$:INPUT"YEAR";Y:DN=PEEK(186):S(3)=LEN(N$):S(2)=INT(Y/256)
15 S(1)=Y-256*S(2):OPEN2,DN,2,"BOOT,P,W":FORT=1TO99:READA:IFA<0THENA=S(-A)
16 PRINT#2,CHR$(A);:NEXT:PRINT#2,N$;:CLOSE2

The resulting file 'BOOT' should be placed first in the directory, so the main application can easily be run with 'LOAD"*",8/RUN' or autostarted in VICE. The year input appears as line number of a SYS statement, when the boot loader is LISTed. As an example of use, take a look into the *.d64 of 'The last VIC-20', written by orion70.

Greetings,

Michael

Posted: **Sat Oct 22, 2011 1:12 pm**

thanks man, that's very cool

Denial

MINIGRAFIK batch processing suite