MINIPAINT 1.2
Moderator: Moderators
-
- Vic 20 Devotee
- Posts: 269
- Joined: Mon Feb 04, 2008 6:06 am
Mummy when I grow up I want to be an artist like ral-clan.
That picture would look great in a Hobbit game. I must admit I never played the Melbourne House version but I love the book.
Change is inevitable except from a vending machine.
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
This is a more lengthy post, sorry.
I'm currently working on a more comprehensive manual for MINIPAINT, and a tutorial in there explains how to paint this picture.
The following reply tries to shed some light about what thoughts had gone into designing the user interface of MINIPAINT as of its current state:
It is not, that the aforementioned features are difficult to implement; the rub being more how to integrate them into the current version without making the user interface incoherent:
In one of your PMs you noted, that setting a hires pixel within a multicolour cell "destroys" that cell. While that notion is correct, it's really just one attribute bit (multi-colour enable) being changed, possibly also the foreground colour - both in the colour RAM. Most of the cell's bitmap is unchanged, and you can revert the cell to the former outlook by placing a multicolour pixel in colour 2, 3, or 4 (but not 1):
MP tries to infer the least necessary changes on attribute data, so the current pixel takes always precedence, and will appear as intended. A twice-wide "multi-colour" pixel in background colour can even be set without changing the colour RAM, so that indeed isn't done. That's why it's necessary to use colours 2, 3, or 4 to change back the cell. BTW, MINIGRAFIK uses the same logic.
As even the apparently "simple" pixel set function leads to these unpleasant attribute clashes, the effects of line, and flood fill would be even more disastrous. Since all work is done in the zoomed view, the user has no way to estimate what happens to parts of the picture not currently in view. At least with the current editing operations, all changes are local by nature, and can easily be reverted.
The Koala Pad input is indeed more suited to a sketchboard type editor, well, that's not what MINIPAINT attempts to be. But not all is lost: With MINIGRAFIK in the backhand, MINISKETCH should be fairly easy to implement, and will be able to exchange data with MINIPAINT. But as beta-tester you'll need to answer me some more detailed questions, Brent.
And the VIC doesn't have sprites. In an unzoomed view, I'd quite happy to use something like a crosshair, but that can't be done on a VIC-20 without attribute clashing again rearing up its ugly head.
The cursor in the zoomed view only gains its sprite-like appearance, because I actually found a way to blend it into the view without attribute clashing. Cost me some big hunks of thought to get *that* right.
Also, the cut/paste feature with DEL/INST should make it fairly easy to fill bigger parts of the picture with a colour, by filling a whole attribute block with that colour, cutting it and pasting the clipboard where necessary. That's how I sketched out a raw figure of the tree in my picture above, by preparing a checker-board pattern of black/orange in the top-left of the screen, to "mix" brown for the trunk, and branches of the tree.
Greetings,
Michael
Trees seem to be rather a prominent motif to draw with MINIPAINT, here's my humble attempt at it:Wilson wrote:Cool picture! Makes me really want to get some work done on Castle Rex. [...] Here's a pretty awful picture I made right before MINIPAINT 1.1 came out (also pixel-by-pixel):
I'm currently working on a more comprehensive manual for MINIPAINT, and a tutorial in there explains how to paint this picture.
The following reply tries to shed some light about what thoughts had gone into designing the user interface of MINIPAINT as of its current state:
At its heart, MINIPAINT is a pixel-oriented editor.ral-clan wrote:- Koala Pad support (which would also mean paddle etch-a-sketch type drawing as the Koala outputs its co-ordinates to the VIC like paddle input signals). [...]
- fill and line functions (if even possible).
It is not, that the aforementioned features are difficult to implement; the rub being more how to integrate them into the current version without making the user interface incoherent:
In one of your PMs you noted, that setting a hires pixel within a multicolour cell "destroys" that cell. While that notion is correct, it's really just one attribute bit (multi-colour enable) being changed, possibly also the foreground colour - both in the colour RAM. Most of the cell's bitmap is unchanged, and you can revert the cell to the former outlook by placing a multicolour pixel in colour 2, 3, or 4 (but not 1):
MP tries to infer the least necessary changes on attribute data, so the current pixel takes always precedence, and will appear as intended. A twice-wide "multi-colour" pixel in background colour can even be set without changing the colour RAM, so that indeed isn't done. That's why it's necessary to use colours 2, 3, or 4 to change back the cell. BTW, MINIGRAFIK uses the same logic.
As even the apparently "simple" pixel set function leads to these unpleasant attribute clashes, the effects of line, and flood fill would be even more disastrous. Since all work is done in the zoomed view, the user has no way to estimate what happens to parts of the picture not currently in view. At least with the current editing operations, all changes are local by nature, and can easily be reverted.
The Koala Pad input is indeed more suited to a sketchboard type editor, well, that's not what MINIPAINT attempts to be. But not all is lost: With MINIGRAFIK in the backhand, MINISKETCH should be fairly easy to implement, and will be able to exchange data with MINIPAINT. But as beta-tester you'll need to answer me some more detailed questions, Brent.
The main application for the original size view is to enable the user to judge the analog signal even without the preview. As the current cursor position is shown quite prominently within the zoomed view, I don't see any good reason to place a second cursor down there.- a dot on the mini hi-res display in the corner to reflect where your cursor is.
And the VIC doesn't have sprites. In an unzoomed view, I'd quite happy to use something like a crosshair, but that can't be done on a VIC-20 without attribute clashing again rearing up its ugly head.
The cursor in the zoomed view only gains its sprite-like appearance, because I actually found a way to blend it into the view without attribute clashing. Cost me some big hunks of thought to get *that* right.
I hope you both had tried out the auto-repeat functions accessible with the F-Keys, and left-arrow key. Then it's easy to draw long horizontal, and vertical lines without hammering away at the number keys.Wilson wrote:The first and second features would be nice for the laborious pixel by pixel work we did, but I think MINIPAINT is more for finishing converts made in the user's favorite drawing program.
Also, the cut/paste feature with DEL/INST should make it fairly easy to fill bigger parts of the picture with a colour, by filling a whole attribute block with that colour, cutting it and pasting the clipboard where necessary. That's how I sketched out a raw figure of the tree in my picture above, by preparing a checker-board pattern of black/orange in the top-left of the screen, to "mix" brown for the trunk, and branches of the tree.
Considering I didn't include a undo-function, this is a good advice in any case.saehn wrote:Looking good, hope you finish it. Don't forget to save periodically to different steps/stages! It's fun to see your work's progression when you're done. Also, backup regularly... data losses on time-consuming pictures are tragic.
Greetings,
Michael
Last edited by Mike on Fri Nov 30, 2012 6:51 pm, edited 2 times in total.
I have a KoalaPad too, BTW. MiniSketch sounds like an interesting development!Mike wrote:The Koala Pad input is indeed more suited to a sketchboard type editor, well, that's not what MINIPAINT attempts to be. But not all is lost: With MINIGRAFIK in the backhand, MINISKETCH should be fairly easy to implement, and will be able to exchange data with MINIPAINT. But as beta-tester you'll need to answer me some more detailed questions, Brent.
- Pedro Lambrini
- Vic 20 Scientist
- Posts: 1132
- Joined: Mon Dec 01, 2008 11:36 am
Having just bought a Koala Pad on fleaBay I, too, would love to see a 'Mini-Sketch. I've been looking for an accessible way go get into art on the Vic. It was actually the title screen of ROQ III that has sparked this interest!
"...That of the Eastern tribe being like a multitude of colours as if a rainbow had settled upon its brow..." Daniels 1:3
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
This is the prototype version after Brent, and I had exchanged some PMs:saehn wrote:I have a KoalaPad too, BTW. MiniSketch sounds like an interesting development!
Code: Select all
10 @ON:@CLR:V=36864:P=37152
11 S=PEEK(P-1):POKEP+2,127:T=PEEK(P):POKEP+2,255
12 L=(16ANDS)=0:R=(128ANDT)=0:IFNOT(LORR)THENF=0:GOTO11
13 X2=2*(PEEK(V+8)-8)/3:Y2=4*(PEEK(V+9)-8)/5
14 IFX2<0THENX2=0
15 IFX2>159THENX2=159
16 IFY2<0THENY2=0
17 IFY2>191THENY2=191
18 F=F+1:IFF>1THENF=1:@-L,X1,Y1TOX2,Y2
19 X1=X2:Y1=Y2:GOTO11
Unfortunately, Brent's Koala Pad showed some errant behaviour, while he simply wanted to draw horizontal, or vertical lines. Not only the "jitter", that had been talked about at other places in the forum regarding the POT inputs, but rather big glitches. One other slight inconvenience is the "cursor" inadvertently homing, when the stylus is lifted as the buttons are held down. However, I find it is rather tiresome to test out, and get somewhat more working versions without the real hardware at hand.
I post this simple program as starting point, maybe someone else could pick it up, and try to make a fully working equivalent of Koala Painter for the VIC.
Shane drew the title screen of RoQ III entirely within MINIPAINT.Pedro Lambrini wrote:It was actually the title screen of ROQ III that has sparked this interest!
Greetings,
Michael
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
1000th post ...
Well into my sixth year here at Denial, and this being my 1000th post, I found it appropriate to bring you yet another picture done with MINIPAINT.
Just let us all keep in mind, we're all having fun here, and it's our spare time we spend hacking away on the VIC, and playing games, and ...
Cheers,
Michael
(It's contained in the Pictures section of the MG batch suite)
Just let us all keep in mind, we're all having fun here, and it's our spare time we spend hacking away on the VIC, and playing games, and ...
Cheers,
Michael
(It's contained in the Pictures section of the MG batch suite)
Last edited by Mike on Thu Feb 20, 2014 4:14 pm, edited 3 times in total.
- Pedro Lambrini
- Vic 20 Scientist
- Posts: 1132
- Joined: Mon Dec 01, 2008 11:36 am
I own an Okimate 20 (and an Oki 10, too). If you still need Oki instruction book questions, just send me a message. And I have Koalapads, too (and the Animation Station and others).Mike wrote:Are there Denial fellows, which do happen to own an Oki 20, and would like to test the ported hardcopy program?
Back from Blockparty 2010,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
July 24-25 Commodore Vegas Expo 2010 -
http://www.commodore.ca/forum
and click on ComVEX
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Thanks again for the offer! As I had already pointed out in PM, I'll gladly come back to it, when the issues regarding a scan are solved.RobertBe wrote:I own an Okimate 20 (and an Oki 10, too). If you still need Oki instruction book questions, just send me a message. [...]
As for the recent discussions about game ports in other threads, the following logo just happened to fit - of course it's a long way from a title screen to a complete game, but who knows?
(contained in the Pictures section of the MG batch suite)
Last edited by Mike on Thu Feb 20, 2014 4:36 pm, edited 2 times in total.
I see these pictures, and here some of the music that has been made on the VIC and I tell myself, if only this level of programming were available in the early 1980s. But then I have to remember that the main limitation of making really good games on the VIC-20 was really the lack of RAM. So then if you were to add the extra RAM, the cost of the machine would probably be pretty similar to the C64, in which case the whole point is lost.