Yes VIC can - Demo

orion70 · Post by **orion70** » Mon Jul 25, 2011 2:26 am

Yes Dinorast, absolutely incredible... I'm dreaming of a graphic adventure in the style of the Pawn for the VIC-20 (see the green hills and river in the demo) - maybe no one will program it, but it's graphically feasible and this was not thinkable until now.

Oh, and welcome to the friendly forum

.

Dinorast · Post by **Dinorast** » Mon Jul 25, 2011 3:41 am

@tokra-yes you really done a great job !!! Computer Museum in Oldenburg is really good, definatly worth a visit, especially when you are so close. Thiemo really opened something nice-you can play around with all hardware displayed.

Is there more in the pipline from you ?

@orion70-thanks for the warm welcome !!! I knew the forum already longer before-but I only got a FE3 recently and now all my VIC20 memories are coming back again. What a lovely machine, especially with this extension.

Making the Pawn on the VIC would be really a challenge, cause its quite big, but makeable...

tokra · Post by **tokra** » Mon Jul 25, 2011 10:49 am

Dinorast wrote:Computer Museum in Oldenburg is really good, definatly worth a visit, especially when you are so close.

Not really close, 100km by car...

Is there more in the pipline from you ?

Not at the moment, at least not for the VIC. It has to be noted however that the ingenious picture-converter was done by Mike and while without that the graphics-mode would still exist, it would have nothing to show for it. Mike also was really helpful in development of all the graphics-modes that culminated in MAXIGRAFIK and MFLI.

Making the Pawn on the VIC would be really a challenge, cause its quite big, but makeable...

The graphics of Pawn are drawn, while the picture of the grass on the VIC was "just" a photo-conversion. A good graphician using the MFLI-mode may produce some nice results as well. However I don't think anyone would take the time to actually draw enough pictures in that mode so that an adventure game comes out of it. Also, one MFLI-picture takes up nearly all the memory of a 16K-expanded VIC. If you allow the game to run on 32K expansion it would still only have 16K for itself.

What would be quite possible with the MFLI-mode however would be a VIC-20 "Strip Poker"-type game

orion70 · Post by **orion70** » Tue Jul 26, 2011 12:25 am

tokra wrote:
Making the Pawn on the VIC would be really a challenge, cause its quite big, but makeable...
The graphics of Pawn are drawn, while the picture of the grass on the VIC was "just" a photo-conversion. A good graphician using the MFLI-mode may produce some nice results as well. However I don't think anyone would take the time to actually draw enough pictures in that mode so that an adventure game comes out of it. Also, one MFLI-picture takes up nearly all the memory of a 16K-expanded VIC. If you allow the game to run on 32K expansion it would still only have 16K for itself.

Maybe a stripped down version of the adventure, with static screens showing up at each location? It wouldn't take much of an effort to convert the original Pawn's graphics to MFLI pictures, instead of drawing new ones from scratch

.

tokra wrote:What would be quite possible with the MFLI-mode however would be a VIC-20 "Strip Poker"-type game

...and this has never been done for a VIC

.

RJBowman · Post by **RJBowman** » Tue Oct 25, 2011 8:05 pm

I'm looking at the demo, and the information about how the graphic mode works. I think that there is one more limitation that could be overcome.

The mode uses raster-synchronized changes to put different background, border, and auxiliary colors on each scan line. Nice trick.

And then you can put a different character color in each 4x16 pixel tile.

But I think that you can squeeze more character colors into the tiles.

One way would be to rewrite the color memory for the row for each scan line during horizontal blanking, but this might be more than the CPU can handle.

But I have seen a technique in the Imposiblator demo where the vertical screen position register is changed on each scan line so that the rows of characters/pixels don't necessarily have to be displayed in their normal sequence.

So you could use the colors from one row of color memory on one line, the switch to another row of color memory for the next scan line, and skip all over color memory.

And I just has another idea; the horizontal position register could be adjusted on each scan line so that the regions of character color wouldn't necessarily have to line up from one scan line to the next.

But the mind-blowing software that could take a full color image and optimize it for a 16-color row-shuffling, boundry-sliding, memory map would be beyond my comprehension. Could it be done?

Mike · Post by **Mike** » Wed Oct 26, 2011 1:26 am

And then you can put a different character color in each 4x16 pixel tile.

The colour resolution for MFLI is already 4x8 pixels for multicolour attribute cells (and 8x8 for hires cells).

One way would be to rewrite the color memory for the row for each scan line during horizontal blanking, but this might be more than the CPU can handle.

That has already been done one year ago by tokra and me, with 1 pixel height attribute cells. With pure software, you are restricted to 72 pixels screen width. See here.

But the mind-blowing software that could take a full color image and optimize it for a 16-color row-shuffling, boundry-sliding, memory map would be beyond my comprehension. Could it be done?

With a small hardware mod, 208x256 full screen, 3 global colours per raster, 1 pixel height attribute cells and free choice between multi-colour and hires for each cell are possible. See here.

tokra · Post by **tokra** » Wed Oct 26, 2011 1:24 pm

What Mike said

Plus

But I have seen a technique in the Imposiblator demo where the vertical screen position register is changed on each scan line so that the rows of characters/pixels don't necessarily have to be displayed in their normal sequence.

So you could use the colors from one row of color memory on one line, the switch to another row of color memory for the next scan line, and skip all over color memory.

Interesting idea, as far as I can see the vertical screen position always shifts two scanlines. So keeping the switch between $9400 and $9600 after each single line full color resolution would be possible, however the problem would be that color memory would be full pretty fast, in fact it would need to be just as big as the bitmap itself. With only 1K color-RAM you would only get a resolution of about 88x88 into that, much less than the 72x256 mode with on-the-fly color-RAM update achieves.

And I just has another idea; the horizontal position register could be adjusted on each scan line so that the regions of character color wouldn't necessarily have to line up from one scan line to the next.

I actually had that thought as well a while back and discussed it with Mike. But since you can only shift half-char the effect is negligible and not worth the effort.

But keep the ideas coming

RJBowman · Post by **RJBowman** » Mon Oct 31, 2011 8:50 pm

Mike wrote:With a small hardware mod, 208x256 full screen, 3 global colours per raster, 1 pixel height attribute cells and free choice between multi-colour and hires for each cell are possible. See here.

Really? Why the hell didn't Commodore's engineers make that "small hardware mod" back when they originally designed the machine?

Mike · Post by **Mike** » Tue Nov 01, 2011 3:24 am

RJBowman wrote:Really? Why the hell didn't Commodore's engineers make that "small hardware mod" back when they originally designed the machine?

SRAM was quite expensive at that time (and still is to DRAM in comparison) and the C64 was already in the final stages of development.

The display routine for VFLI images requires cycle exact code.

On my PC notebook, converting an image to VFLI takes two minutes. Imagine how long that would have taken on a VIC-20, if it had been even possible to acquire or store away the original true-colour data.

In short: the CBM engineers did not and could not have that use case in mind, when they designed the VIC-20.

RJBowman · Post by **RJBowman** » Sun Dec 02, 2012 11:56 pm

What happens when you put black & white images into this software?

Mike · Post by **Mike** » Mon Dec 03, 2012 12:26 pm

RJBowman wrote:What happens when you put black & white images into this software?

Binary images (i.e. only black and white pixels) are exactly reproduced.

Greyscale images are dithered to from all available colours so the overall impression still is that of nonchromatic colours. An example can be seen in the Waterfall image here (bottom left).

That is not an unusual way to reproduce greyscales. The monitor you're most probably looking at right now displays these greys from little red, green and blue dots of equal intensity put side by side. Also, most colour ink jet printers mix medium greys from their yellow, cyan and magenta cartridges instead of dithering from black only.