forum.defence-force.org

Thanks for the rapid answers, I hugely appreciate this amazing level of support!

The bitmap was generated with:

PictConv -f7 -d0 -o2 river256.png river.raw

I managed to get the bitmaps saved on the disk using header.

header river.raw build/river.com $A000

I wrote onto disk together with CC65 code:

tap2dsk -iVIEWER.COM build/viewer.tap build/river.com build/viewer.dsk

Inside viewer (cc65 code) I set the PAPER and INK as follows:

for (y=0; y<100; y++) {
POKE((unsigned char*)(0xA000+((2*y+0)*40)+0), 16); // Black Paper
POKE((unsigned char*)(0xA000+((2*y+1)*40)+0), 16); // Black Paper
POKE((unsigned char*)(0xA000+((2*y+0)*40)+1), 3); // Alternate INK color: Yellow
POKE((unsigned char*)(0xA000+((2*y+1)*40)+1), 6); // Alternate INK color: Cyan
}

But the result is not right, I get the attached picture.
Original looks like this (map river): http://8bit-slicks.com/?page_id=56

Not sure if anything went wrong, but for AIC graphics I could only get decent results drawing things by hand.

It is not really a graphic mode, so you need some experimentation to get nice results.

I think it would be easier to develop the game (one phase, for instance) in black and white and then, once things are working, start trying to get AIC mode work.

Sprite drawing routines should be adapted, but that is nearly all, and I am sure some great results can be achieved by adapting the circuit by hand.

Oh I see: PictConv is not a magic conversion tool, it just makes it easier to convert stuff that is Oric compliant. It basically automates the placement of invert bits, detecting if something should be ink or paper, etc... but if your picture is not Oric compliant, you will get garbage.

There's a reason why the picture I linked was neatly aligned on multiple of 6, and drawn with actual specific colors on specific blocs of bytes: I paint all my oric graphics on a software that allows me to draw with a 6 pixel wide grid, and I do respect the constraints.

The only "magic" mode is the Sam mode (-f6), but that one is pretty much only usable for static images that don't get modified, like a title picture, because you have zero control on where attributes go.

Generally speaking, that's the philosophie difference between the CC65 and OSDK toolchains, CC65 tries to handle as many things as possible, tries to be as portable as possible, while the OSDK just tries to let you be able to be as efficient as possible on the Oric.

Alright, it makes sense now. I think I will write Python script adapted to the needs of my game.

Short update on the python convertor.

I started by producing a screen with red/blue alternating lines, and then switch [on/off], [normal/inverted] the groups of 6x2 pixels.
That gave me a kind of "palette".

In GIMP, I used cubic interpolation to reduce this palette to 27 colours.

Rescaling my original image to 40x100, I then substitute with the equivalent groups of pixels and get something that "roughly" looks like the original.

Next step will be to sub-divide the groups of 6x2 into groups of 2x2, and get more colour variations within each block.

I managed to get better detail by going to 2x2 pixel blocks.

Still quite rough, but I think I am getting somewhere...

You can also use Libpipi library / The Pimp program by Cacalabs


Here is a result

I followed the instructions on this page: http://caca.zoy.org/wiki/libpipi/oric
But I get a garbash screen... Does the file need to be in specific format/size to work with pipi.exe?

Remember that the libpipi algorithm is also present in pictconv (it's the Sam mode).

Possible to do that without modifying that much the source image :




But as Dbug or others said before I definitely think it would be better to modify the source image a bit first to make it more oric-compliant.

Yeah, for best results I would remove the background gradient and have the logo use a non-antialiased font.

Generally speaking, vertical color changes are fine, horizontal ones, not that much

That SAM mode is not bad, once you get the hang of it...

To draw some sprites, I will need to sacrifice a 6 pixel block before and after the sprite, to change atttributes. Is that correct?
(Thus my choice of a black race track...)

The biggest problem with the sam mode is that there is no control about where the attributes are placed, so technically they could be in the middle of your track, with a mix of black ink and black paper, so when drawing the sprites you don't really know which colors to reset to on the right side.

Maybe with some pre-processing of the picture you could move the attributes so they are pushed to the left or right of the track borders?

Exactly, I am onto it already!
For example, I noticed that some black areas of the map correspond to inverted white paper.
I am trying to push attributes to the edge, as you are suggesting.