Pictoric (was: New conversion algorithm)

The Oric video chip is not an easy beast to master, so any trick or method that allows to achieve nice visual results is welcome. Don't hesitate to comment (nicely) other people tricks and pictures :)
User avatar
Symoon
Archivist
Posts: 1874
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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!

User avatar
8bit-Dude
Pilot Officer
Posts: 98
Joined: Tue Mar 14, 2017 1:33 pm
Location: Japan

Re: Pictoric (was: New conversion algorithm)

Post 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).

sam
Officer Cadet
Posts: 52
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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 550 times
Last edited by sam on Wed May 20, 2020 12:12 pm, edited 2 times in total.

User avatar
ibisum
Wing Commander
Posts: 1282
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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 .. ?

sam
Officer Cadet
Posts: 52
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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.

User avatar
Dbug
Site Admin
Posts: 3332
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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

sam
Officer Cadet
Posts: 52
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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.)

User avatar
Dbug
Site Admin
Posts: 3332
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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).

sam
Officer Cadet
Posts: 52
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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.

User avatar
Dbug
Site Admin
Posts: 3332
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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.

User avatar
ibisum
Wing Commander
Posts: 1282
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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.

User avatar
Dbug
Site Admin
Posts: 3332
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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.

sam
Officer Cadet
Posts: 52
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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).

User avatar
Dbug
Site Admin
Posts: 3332
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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 :)

sam
Officer Cadet
Posts: 52
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

Re: Pictoric (was: New conversion algorithm)

Post 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 400 times
Image12.tap.png
Image12.tap.png (3.59 KiB) Viewed 400 times
ImageA3.tap.png
ImageA3.tap.png (3.45 KiB) Viewed 400 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.)

Post Reply