Page 2 of 6

Re: CC65 to DSK

Posted: Thu Dec 20, 2018 3:17 pm
by 8bit-Dude
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/ $A000

I wrote onto disk together with CC65 code:

tap2dsk -iVIEWER.COM build/viewer.tap build/ 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):

Re: CC65 to DSK

Posted: Thu Dec 20, 2018 4:30 pm
by Chema
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.

Re: CC65 to DSK

Posted: Thu Dec 20, 2018 7:02 pm
by Dbug
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.

Re: CC65 to DSK

Posted: Thu Dec 20, 2018 11:32 pm
by 8bit-Dude
Alright, it makes sense now. I think I will write Python script adapted to the needs of my game.

Re: CC65 to DSK

Posted: Sun Dec 23, 2018 2:43 pm
by 8bit-Dude
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.

Re: CC65 to DSK

Posted: Sun Dec 23, 2018 4:40 pm
by 8bit-Dude
I managed to get better detail by going to 2x2 pixel blocks.

Re: CC65 to DSK

Posted: Sun Dec 23, 2018 4:45 pm
by 8bit-Dude
Still quite rough, but I think I am getting somewhere...

Re: CC65 to DSK

Posted: Sun Dec 23, 2018 11:14 pm
by peacer
You can also use Libpipi library / The Pimp program by Cacalabs

Here is a result
(7.85 KiB) Downloaded 230 times

Re: CC65 to DSK

Posted: Mon Dec 24, 2018 2:36 am
by 8bit-Dude
I followed the instructions on this page:
But I get a garbash screen... Does the file need to be in specific format/size to work with pipi.exe?

Re: CC65 to DSK

Posted: Mon Dec 24, 2018 8:57 am
by Dbug
Remember that the libpipi algorithm is also present in pictconv (it's the Sam mode).

Re: CC65 to DSK

Posted: Mon Dec 24, 2018 4:34 pm
by romualdl
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.

Re: CC65 to DSK

Posted: Mon Dec 24, 2018 5:29 pm
by Dbug
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 :)

Re: CC65 to DSK

Posted: Tue Dec 25, 2018 6:55 am
by 8bit-Dude
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...)

Re: CC65 to DSK

Posted: Tue Dec 25, 2018 9:45 am
by Dbug
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?

Re: CC65 to DSK

Posted: Tue Dec 25, 2018 10:59 am
by 8bit-Dude
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.