** New Frontiers in VIC-Hires-Graphics, Part 11

[tokra]

Make sure the PPM-file has the required resolution (e.g. 104x256 for MFLI) and is saved as Binary WITHOUT compression (you can choose these when saving in IrfanView).

[siccoyote]

Thanks for your help, got a little confused as a previous thread said image.ppm rather than input ppm

But got it worked out I think, takes longer to load on the real thing than on Vice, but gives you much more time to react.

[Mike]

Nice still from Dragon's Lair! Who are the three dudes in the third image?

[siccoyote]

Nice still from Dragon's Lair! Who are the three dudes in the third image?

It's a promo picture for GTA V. When is someone gonna make a vic port?

Also the Top one is Mad Dog McCree if anyone doesn't know. Had to really boost the edges and saturation to get that popping.

[Mike]

Had to really boost the edges and saturation to get that popping.

O.K. It's one of the things I didn't include in the converter and also didn't feel the need for, because pre-processing is quite easily done on the PC for the most part.

The MFLI converter does miss out on the correct handling of gamma however. That's what I improved with the converter for VFLI over three iterations - the first try had really *bad* dithering, the second one implemented correct Floyd-Steinberg dither, but only the third version got gamma correct. Including gamma is a two-sided sword though: only then you get the colour balance for lowly saturated colours right and you don't have anymore stray pixels that 'light up' darker areas, however the VIC's palette seriously lacks darker versions of some colours - so if you don't preprocess the image (most likely, light it up a bit) you'll get lots of black patches.

[siccoyote]

Had to really boost the edges and saturation to get that popping.

O.K. It's one of the things I didn't include in the converter and also didn't feel the need for, because pre-processing is quite easily done on the PC for the most part.

Yeah I never really knew what I was doing with the options on other programs, preferable to pre-process it, been using Paint Shop Pro for that.

Only problem is have to keep typing in all those sys commands (also renamed the programs to '1' and '2') but eventually they were burned into my mind.

I don't think this is quite ready for making a strip poker game with yet, waiting 20 seconds or so to load the picture

[Mike]

I don't think this is quite ready for making a strip poker game with yet, waiting 20 seconds or so to load the picture

If you use SJLOAD with a JiffyDOS-enabled drive, things should speed up quite a bit.

Tokra and I use a C64SD Infinity on our VIC-20s and it's just so much more convenient transferring data between VIC-20 and PC with SD cards than having to 'master' a 5¼" disk with the PC and then load that with a 1541 (perhaps even without any built-in speeder). The firmware of the SD2IEC devices includes JD support.

[siccoyote]

I don't think this is quite ready for making a strip poker game with yet, waiting 20 seconds or so to load the picture

If you use SJLOAD with a JiffyDOS-enabled drive, things should speed up quite a bit.

Tokra and I use a C64SD Infinity on our VIC-20s and it's just so much more convenient transferring data between VIC-20 and PC with SD cards than having to 'master' a 5¼" disk with the PC and then load that with a 1541 (perhaps even without any built-in speeder). The firmware of the SD2IEC devices includes JD support.

Well I havea 1541 but that mostly stays in it's storage box, partly due to the speed but also I only have a couple of blank discs, I've been using the SD2IEC.

I guess if you were doing a card game would a half height picture be able to be stored in the top half of the screen (like The Pawn on the C64) while playing in the bottom Or would this need to be dedicated to being on screen then off again before you can continue to interact?
Though the CDI strip poker game cuts to a full screen MPEG1 video then back to a playscreen.

[Mike]

Or would this need to be dedicated to being on screen then off again before you can continue to interact?

That pretty much nails it. Displaying a MFLI image takes up the CPU to nearly 100% to shuffle bitmap data from the external memory into the VIC-20's on-board RAM - which is the only RAM the VIC chip can access, besides the character ROM! - and do the raster enhancements (3 new global colours each raster). The new data always arrives in time before the VIC chip does display it in each frame, so there's no flickering or the like. But we're limited to still pictures.

A bitmap of half the vertical size - 26x16 normal sized characters (416 in total) and also with raster enhancements - with a split 'text' screen below could probably be done with a specialised display routine and with some CPU time to spare. Just noone thus far bothered to implement it. Anyhow, tokra and I documented the theory behind those new graphics modes quite well I think - surely some volunteers might pick up the baton?