Page 7 of 8

Re: Pictoric (was: New conversion algorithm)

Posted: Wed May 20, 2020 8:27 am
by Symoon
Although I'm usally not a huge fan of AIC or dithering (nice on small screen captures, sometimes painful on larger screens), I have to say all this work is really amazing. You guys are really talented in finding all the possible best combinations of colours, and doing this so fast!

When I was converting monochrom pictures from PC Something like 22 years ago, I also used to work first on the original picture palette, colors and contrast (all manual, using Paint Shop Pro 3!), to simplify the conversion step.
Keep up the good work!

Re: Pictoric (was: New conversion algorithm)

Posted: Wed May 20, 2020 8:28 am
by 8bit-Dude
ibisum wrote: Wed May 20, 2020 7:45 am 8-bit Dude - I hope you've got some plans to add MacOS/Linux support in the future - if so this is something I'd be happy to help with. I haven't used a Windows system in years and would much rather avoid Wine/VM's if possible .. but that said, I'm happy to help get things working on MacOS/Linux.

And then, the inevitable question: what would it take to add Z80 support and turn this into a true unity situation, where C64 and ZX Spectrum and CPC6128 and Atmos devs can just use the One True Toolkit to Rule Them All .. I guess I can answer that question myself with a bit of code-reading, so off I go ..
To support MacOS/Linux, we would either need binaries or (better) convert to Python scripts the following tools:
Exomizer, MADS compiler, dir2atr, sidreloc, psid64, c1541, sprpck, png2bmp, luajit, (OSDK) header, tap2dsk, old2mfm, ym2mym
That is just to build disks. Then we need the emulators and trackers for each platform.

As for Z80 and 6809 based systems, it is the goal once the major 6502 platforms are all done (NES, BBC/Electron, 7800).

Re: Pictoric (was: New conversion algorithm)

Posted: Wed May 20, 2020 11:49 am
by sam
Symoon wrote: Wed May 20, 2020 8:27 am Although I'm usally not a huge fan of AIC or dithering (nice on small screen captures, sometimes painful on larger screens), I have to say all this work is really amazing. You guys are really talented in finding all the possible best combinations of colours, and doing this so fast!
I think AIC can give some nice pictures. See for instance the samples (below) I just built using the next version of PictOric using my 3x3 oric-special ordered-dither matrix. Imagine a "Breakout clone" with these images (possibly dimmed) as background with lots of colorful "AIC 3,6" sprites representing the ball, the bricks and the paddle moving around. :shock: 8)
Samples of AIC 3,6 images
Samples of AIC 3,6 images
Contact Sheet-1.png (226.15 KiB) Viewed 8265 times

Re: Pictoric (was: New conversion algorithm)

Posted: Wed May 20, 2020 12:00 pm
by ibisum
Just seeing these kinds of pics on an Oric fills me with such delight .. its amazing. All the disappointment at attribute clash in the games of the 80's just melts away and is replaced with inspiration for what can be done next .. well done guys!

I wonder .. if we were to make a SuperOric one day ("Oric Next"), might we include a co-processor option, say a raspberry-0 like the ZX Next, that would allow for realtime rendering of these kinds of graphics .. ?

Re: Pictoric (was: New conversion algorithm)

Posted: Thu May 21, 2020 7:13 pm
by sam
Hmm I'm facing a philosophical issue. Is AIC=n,n a legit AIC mode ? I mean this is technically possible, but do Oric-users consider it as a legitimate couple of colors, or is this abusing the AIC definition ?

BTW: couple 3,6 is very great. One does hardly produce bad AIC pictures with it from my test cases.

Re: Pictoric (was: New conversion algorithm)

Posted: Thu May 21, 2020 7:51 pm
by Dbug
sam wrote: Thu May 21, 2020 7:13 pm Hmm I'm facing a philosophical issue. Is AIC=n,n a legit AIC mode ? I mean this is technically possible, but do Oric-users consider it as a legitimate couple of colors, or is this abusing the AIC definition ?
I'm not sure I understand the question, but for me as long as:
- All the attributes are one left side (non in the middle of the screen)
- The sets of colors are the same, alternated over pairs of lines
- And the invert bit is used to generate a second set of two different colors
then that's AIC.
Does not matter which colors you use, or if the PAPER color was changed as well.

I wrote a bit about AIC, not sure if that helps: http://www.osdk.org/index.php?page=arti ... T9#title17

Re: Pictoric (was: New conversion algorithm)

Posted: Thu May 21, 2020 8:46 pm
by sam
I mean: does the word "alternating" imply that the colors in the pair MUST be different. Asking differently, is the pair 1,1 a valid AIC mode? Alternating between red and red seem strange to me. (This is just a vocabulary/philosophy issue indeed.)

Re: Pictoric (was: New conversion algorithm)

Posted: Thu May 21, 2020 8:54 pm
by Dbug
The whole point is to get 4 possible colors per scan-line, so having PAPER=INK does not seem to bring any advantage other than making you lose 12 pixels on the left side of the screen (one of the advantages of leaving the PAPER to BLACK is that you only lose the 6 pixels for the INK change).

Re: Pictoric (was: New conversion algorithm)

Posted: Thu May 21, 2020 9:43 pm
by sam
Paper is always black for AIC in my conversions (see above). When I write AIC=n,n I don't mean paper=inc=color #n, but odd line ink is color #n and even lines ink is color #n as well. So my question reduces to: can we tell that monochrome pictures are actually proper AIC ? Or should I stick to different colors in the pair to when converting a gray-scale picture for instance.

Re: Pictoric (was: New conversion algorithm)

Posted: Fri May 22, 2020 7:37 am
by Dbug
can we tell that monochrome pictures are actually proper AIC ? Or should I stick to different colors in the pair to when converting a gray-scale picture for instance.
It's a hard to answer question, so I will give an alternative answer: Ultimately it all depends of what the usage is for!

If the user plans on moving stuff over the picture, in different colors, then you probably want your monochrome picture to be converted in a way that still makes it possible to move the things over it.

If the picture is destined to be scrolled horizontally, then you need to have a special care for where the attributes are so the picture stayed displayed properly when scrolled (that's the nice thing with AIC, attributes don't move and everything's fine)

If the plan is just to display a static picture with as much as quality as possible, then you can do pretty much whatever you want.

Personally I like that we call AIC a specific type of implementation, because that makes things easier to discuss with people.

It would be annoying that people start calling AIC anything that does not behave like AIC as it was implemented in Impossible Mission, Skooldaze, or Stormlord.

Re: Pictoric (was: New conversion algorithm)

Posted: Fri May 22, 2020 11:45 am
by ibisum
Its all just "Advanced Oric Graphics" techniques, isn't it .. and I mean, AIC seems to have interesting fringe applications among the scrolling/blitting problems.

I'd love to have the .TAP files for all of these images, so I can dig into the bytes in a debugger and see for myself how the bits are set, one by on.

Re: Pictoric (was: New conversion algorithm)

Posted: Fri May 22, 2020 1:22 pm
by Dbug
ibisum wrote: Fri May 22, 2020 11:45 am Its all just "Advanced Oric Graphics" techniques, isn't it .. and I mean, AIC seems to have interesting fringe applications among the scrolling/blitting problems.
It's different takes on the same issue indeed :)

The main thing is that my calling different methods with different names, it makes it easier to communicate with people, specially when you try to cooperate with people willing to do graphics with you, it's much easier to narrow down what they can do or not.

It's a bit like on the C64 where they have standardized names of things: FLI is not SHI, which is different from IFLI, MCI, MultiColor or HiRes

See http://studiostyle.sk/dmagic/gallery/gfxmodes.htm for some examples and descriptions.

Re: Pictoric (was: New conversion algorithm)

Posted: Fri May 22, 2020 2:00 pm
by sam
Am I right to say that as long as you just modify the ink on the first column, and only use the invert bit on other columns, this is AIC ? Then for the color tuple to use is another matter that doesn't really matter the "AIC" label. Colors 7,7 and 7,3 are as valid pairs as is 6,3 (here I mean ink1,ink2).

Re: Pictoric (was: New conversion algorithm)

Posted: Fri May 22, 2020 3:04 pm
by Dbug
A is for Alternated (on scanlines), and IC for "Inverted Colors".

If you repeat the same set of colors on two lines, yes technically you could claim they are alternated, but no, I would not call that AIC because that does not provide any benefit of any kind.

Now, having a part of the screen where you alternate between RED and YELLOW ink, and another section where you alternate between CYAN and GREEN, sure, that still counts as AIC. And even if nobody does not that, alternating PAPER also counts as AIC.

What does not count as AIC is:
- Using the same colors twice
- Using colors that are the same when inverted
because these are just rhetorical usages that does not seem to bring any benefit.

Now, if that can make you happy, we could call that SAIC (Sam AIC) or EAIC (Extended AIC) or SAME :)

Re: Pictoric (was: New conversion algorithm)

Posted: Fri May 22, 2020 7:42 pm
by sam
Oh, I just want to avoid writing misleading infos in the README.

You say "Using colors that are the same when inverted", which I interpret as c1+c2!=7.

This might look restrictive since this doesn't lead to repeating consecutive lines. The first line allows colors (paper,ink) = (0,c1) and (7,c2) while the second line allows (0,c2) and (7,c1). None of these colors are the same.

Here are example of such images. (Ok the image quality could be better)
Image09.tap.png
Image09.tap.png (3.87 KiB) Viewed 8117 times
Image12.tap.png
Image12.tap.png (3.59 KiB) Viewed 8117 times
ImageA3.tap.png
ImageA3.tap.png (3.45 KiB) Viewed 8117 times
Well. Anyway here is the set of tested colors pairs that corresponds to your definition (never twice the same , no complementary colors):

Code: Select all

pair   odd   even
1       6       3     
2       3       2     
3       5       3     
4       6       2     
5       3       1     
6       6       5     
7       2       1     
8       6       4     
9       5       1     
10      4       2    
11      5       4    
12      4       1    
Am I missing some ?

(I removed the symmetrical pairs as well as color 7 to improve colorfulness.. but this might not be a good idea, I don't know.)