Denial

Nice tree!

I can see a great VIC-20 graphics adventure shaping up here!

ral-clan wrote:Hey! I finally sat down and tried MINIPAINT (in VICE). Here's the results of my 1 hour of use - drawn totally in MINIPAINT pixel by pixel:

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.

ral-clan wrote:Hey! I finally sat down and tried MINIPAINT (in VICE). Here's the results of my 1 hour of use - drawn totally in MINIPAINT pixel by pixel:

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.

This is a more lengthy post, sorry.

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):

Trees seem to be rather a prominent motif to draw with MINIPAINT, here's my humble attempt at it:



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:

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).

At its heart, MINIPAINT is a pixel-oriented editor.

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.

- a dot on the mini hi-res display in the corner to reflect where your cursor is.

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.

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.

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.

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.

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.

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.

Considering I didn't include a undo-function, this is a good advice in any case.

Greetings,

Michael

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.

I have a KoalaPad too, BTW. MiniSketch sounds like an interesting development!

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!

saehn wrote:I have a KoalaPad too, BTW. MiniSketch sounds like an interesting development!

This is the prototype version after Brent, and I had exchanged some PMs:
You can draw with the left button held down, and erase with the right button. The prototype doesn't show a cursor, and it can't load or save, but these functions could be added. But before that, a reliable means of reading out the Koala Pad needs to be found:

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.

Pedro Lambrini wrote:It was actually the title screen of ROQ III that has sparked this interest!

Shane drew the title screen of RoQ III entirely within MINIPAINT.

Greetings,

Michael

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)

That picture would make a fantastic new avatar for Boray.

Congrats on your milestone.

Nice picture. Thanks!

Nice picture. I downloaded it last night, loaded it with PRG Starter and then instantly took a screenie and set it as my desktop wallpaper! Thanks Mike!

Excellent picture, Mike!!! It really shows the power of this tool!!! I wish we had those artists and tools back in the days!!!

Mike wrote:Are there Denial fellows, which do happen to own an Oki 20, and would like to test the ported hardcopy program?

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).

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

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. [...]

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.

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)

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.