PhotoChrome v6

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1962
Joined: Sun Jul 31, 2011 1:11 pm

Re: PhotoChrome v6

Postby Eero Tamminen » Wed Oct 14, 2015 7:55 pm

The images look marvelous.

Are the bad pixels at left & right in overscan something Hatari specific or do they show also on real HW? (I know that the bad pixels at bottom of overscan are lines that aren't visible on normal monitors, so one could think of that as "Hatari issue"...)

The program doesn't work on STE with EmuTOS, it says: "sorry - this mode only works on standard STE machines". ("\r\n" after that message would be nice.)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Wed Oct 14, 2015 8:39 pm

CiH wrote:Works a treat on Hatari. :D


That's a good start :)

Usual caveats though - it's hard to be sure when it's working under emu. Almost no chance in windowed modes. There are 10 different ways to get a nice flicker without getting the extra colours. It can be done in fullscreen with some care over vsync & buffer flip technique. And good weather.

Even I have stare at it for a while and prod things to know if its working, and I'm supposed to know what it looks like :)

CiH wrote:A viewer that is ahead of the current PCS maker, like your style! Also it is nice and quick.


Not ideal, but 'dribs and drabs' as they say...

CiH wrote:I guess this is down to TOS detection, as 'computer said no' very politely on my normal emulation of TOS 2.06 / STE. I had to load a TOS 1.62 ROM image in its place to run the viewer.


The MSTE issue is really a blitter hardware timing thing. It needs extra special noppage. There is space reserved for it but until I have a tame MSTE for tests there's not much point in trying to do the fix.

The TOS 206 thing is probably just a stupid mistake with cookies or filesystem. I'll check it later.

I may try a similar MegaST-boosted mode (since it has a blitter) just for fun but not until I'm free. Still got a thing to finish on f30!

Cheers!

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Wed Oct 14, 2015 8:44 pm

Eero Tamminen wrote:Are the bad pixels at left & right in overscan something Hatari specific or do they show also on real HW? (I know that the bad pixels at bottom of overscan are lines that aren't visible on normal monitors, so one could think of that as "Hatari issue"...)


Left/right is probably my fault. I think only 408 pixels are 'reliable' on all kit and all emus. The current profile converts all 416 pixels but it's easy enough to reduce if need be. It looks ok on my STE.

I convert and display 272 lines and there can be a few more technically visible. I'll reserve some margin in the viewer just in case.

The viewer was rapidly knocked out last 2 evenings so a few glitches like this are likely. It will get tidied up, so thanks for the notes.

Eero Tamminen wrote:The program doesn't work on STE with EmuTOS, it says: "sorry - this mode only works on standard STE machines". ("\r\n" after that message would be nice.)


It's just checking _MCH cookie contents based on the reference I looked up in a hurry. Might be wrong though. :) I'll look more carefully later.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Oct 15, 2015 9:28 pm

Ok the site has been updated with a new release v6.21.

http://www.leonik.net/dml/sec_pcs.py

This includes the new convertor with some bugfixes - it can now export images compatible with the beta viewer, which is also included with samples. The TOS binaries have been rebuilt.

One sample image included with example commandline to convert it.


Viewer is the same - fixes are still due for TOS 2.06.

Viewer only supports mode #1 (STE blitter-overscan) images for now. Use an old PCS viewer for old mode #0 (ST/STE 320x200) images meantime. The tool spits out mode #0 images by default unless fed a profile for some other type.

Keep in mind mode #1 is just an example 'super displaymode' intended as a guide to making new modes. There is room for plenty more modes for different kinds of STs. I'll add source for the viewer soon - should have done it this evening really if I had been organized.

The manual has not been modified - needs a few tweaks for recent changes to the package, filenames etc. but 99.9% ok.

User avatar
AtariCrypt
Captain Atari
Captain Atari
Posts: 389
Joined: Fri Mar 14, 2014 5:04 pm
Location: Lancashire, England
Contact:

Re: PhotoChrome v6

Postby AtariCrypt » Fri Oct 16, 2015 6:15 pm

I'm eager for MSTE support throughout here. This is an amazing project. Those results there are mind-blowing!

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Sat Oct 17, 2015 9:25 am

I think FrankB has a MSTE so maybe I can get him to do a few tests. Won't be for a while though - need to catch up with another project for a bit, and will do a few more fixes for next release.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Postby calimero » Sat Oct 31, 2015 8:34 am

Just to confirm: on ST CPU time is completely used while displaying PhotoChrome image?

I just wondering if PhotoChrome display e.g. 320x100 pixel image than there will be 100px horizontal lines left (plus border lines) to use CPU on other stuff ... like game logic? :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Sat Oct 31, 2015 9:12 am

Hi!

The real purpose of PCS6 is to provide a tool that allows 68k coders to make new/custom display modes without having to deal with the conversion problem, and for anyone to convert image for those modes after they have been made. So there are two answers to this question :)

Yes - the examples I posted use nearly all of the CPU time. But these are just an example using combinations of new features. If you want an image that uses 100 lines and leaves CPU free then it will do that too. In fact the easiest thing to modify is the line count. You can customize everything down to the pixel timings, resolution and colours available.


The main things shown by the recent examples are (a) more image fields and (b) combining STE blitter with overscan to get higher colour density on left/right overscanned images.

The point of (a) is to demo conversion and display technique whereas (b) is to demo the use of user conversion profiles (csv files) plus a bit of extra STE HW trickery of course :)

A few great coders have done/are doing cool things with it already (none of them I really expected at all!) so I'm looking forward to more of that :)


Related to your question - It does need some additional modes for coders who don't really want to get into display coding at all - e.g. those who want a titlescreen for their new game - but even these should be examples, because everyone wants something a bit different or at least can be modified a bit. I'll get time to add these later.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: PhotoChrome v6

Postby AtariZoll » Sat Oct 31, 2015 9:43 am

applecrypt wrote:I'm eager for MSTE support throughout here. This is an amazing project. Those results there are mind-blowing!

Maybe it could be little more colors on MSTE at 16 MHz and cache off (with on it will never work properly) . But question is is it worth of effort, since number of MSTE owners is not big. Speed gain will be small - max some 15%, I guess because most CPU time is read RAM and write to shifter.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4350
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: PhotoChrome v6

Postby DarkLord » Sat Oct 31, 2015 12:45 pm

dml wrote: A few great coders have done/are doing cool things with it already (none of them I really expected at all!) so I'm looking forward to more of that :)


If you build the tools Doug, they will code...

(got a Wayne's World 2 flashback going on strong here!). :lol:
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Postby calimero » Sun Nov 01, 2015 8:22 pm

@Dlfsilver mention in other thread that e.g. Eye Of Beholder require at least 32 colors to be playable.
I wonder if it would be possible to combine PhotoChrome display with Dungeon Master like game? I believe that there would be enough CPU time left for game itself if screen for PhotoChrome display would use e.g. 100 lines and other 100 lines at bottom would be used (in normal 16 colors mod) for menus, characters, controls... UI elements in general.
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: PhotoChrome v6

Postby AtariZoll » Sun Nov 01, 2015 9:22 pm

calimero wrote:@Dlfsilver mention in other thread that e.g. Eye Of Beholder require at least 32 colors to be playable.
I wonder if it would be possible to combine PhotoChrome display with Dungeon Master like game? I believe that there would be enough CPU time left for game itself if screen for PhotoChrome display would use e.g. 100 lines and other 100 lines at bottom would be used (in normal 16 colors mod) for menus, characters, controls... UI elements in general.


The problem is that generating hi-color video needs lot of CPU time. Some quality anim. needs even more power than some 8 core modern CPU.
So, I would say only some adventure with static graphic, or Space Ace type short anims - using mass storage of course.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
CiH
Atari God
Atari God
Posts: 1136
Joined: Wed Feb 11, 2004 4:34 pm
Location: Middle Earth (Npton) UK
Contact:

Re: PhotoChrome v6

Postby CiH » Sun Nov 01, 2015 9:32 pm

@Dlfsilver mention in other thread that e.g. Eye Of Beholder require at least 32 colors to be playable.
I wonder if it would be possible to combine PhotoChrome display with Dungeon Master like game?

http://www.atari-forum.com/viewtopic.php?f=68&t=24166&hilit=more+colours+on+st

There's always possibilities from this thread. Doesn't have to be PhotoChrome to get more colours on a stock ST/STE. I remember this one was looking at improving the number of colours onscreen for a relatively low CPU cost, so suitable for games and demos.

Also what is Anima up to with his version of this technique?
"Where teh feck is teh Hash key on this Mac?!"

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Postby calimero » Mon Nov 02, 2015 1:28 am

Dungeon Master is quite static game:
- you can move two tiles each second
- enemies have 2-3 sprites of animation changing two times in second
- there is no scrolling or any extensive animation

It would be cool if entire Dungeon Master would have 512 or 4096 color graphics :)
graphics could be rearrange somehow like this:

Eye of the Beholder 2_4 copy.png
You do not have the required permissions to view the files attached to this post.
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: PhotoChrome v6

Postby AtariZoll » Mon Nov 02, 2015 9:04 am

Even that other way with low CPU usage during displaying needs too much CPU power to calculate proper fields to get quality displaying.

Things are that real limit is count of colors in 1 horizontal line - you can change palette in every line at about 50% CPU time cost. This is used actually in many games and demos, and some have over 50 colors at once on screen - not counting sky gradients and similar. As on given example picture: on top part you have one palette, then other for controls. But to perform calculated on fly animation with more than 16 colors at once ... - problem is that there may be 2 different sprites in same horizontal line, with different colors, and then 16 is not enough.
But I think that we should start new thread about ideas, and let this to be what is started.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Tue Nov 03, 2015 9:17 am

I think the most practical solution (without a ton of pain) is to use the technique linked by CiH. It's guaranteed to work - at least to produce extra colours which are common to all graphics (walls, sprites etc.) and don't need managed at runtime. But a good outcome depends on the colours to be generated so success level can't be determined without trying it. An easy fix for some cases is to partially de-saturate the whole palette. This almost always improves colour generation, partly because you can't easily 'mix' to produce primary (or saturated) colours. Mixing always impacts saturation.

Anyway apart from this I still think it would be possible to use the palette switching technique and manage colours for this at runtime. It would just be very difficult to do well. You could split the 16-colour palette into smaller banks and manage the banks separately but it would be hard to make use of the horizontal information in the images to apply the needed colour changes. Each sprite would need to rewrite the bank for its own purposes.

So I think a combination of palette-banking and a (very lightweight, low fidelity) convertor pass would be needed for each sprite update. It would take a decent amount of CPU to modify the window. There might be enough time for such a game, but it would be a very tight fit.

I looked into similar problems when working on the ST version of Apex - realtime conversion of RGB after edits, with a higher fidelity background pass to repair errors that build up from the quick updates. It's quite hard but not impossible to do.


Still the complimentary-colours method I first described in the link via CiH (and which Anima provides his own variation of with his web based convertor) is probably going to get decent result with a lot less effort, and fewer restrictions on what can be displayed, how and when.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Postby calimero » Tue Nov 03, 2015 10:12 am

^
is there any ST project that make use of this technique (two fields technique for more colors) ?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Tue Nov 03, 2015 10:23 am

calimero wrote:^
is there any ST project that make use of this technique (two fields technique for more colors) ?


I believe there are some older cases which have done it manually (hand stippling colours into graphics which are then strobed - a difficult and laborious job!).

As for using the automated technique - I think there are just the demos I posted in 2012 (the STE scrolling playfield examples with Metal Slug gfx), and the ST Doom engine demo I posted a year or two ago (which shows 60+ colours in this way).

You can also convert your own gfx using Anima's site, or using my standalone tool (which is built into PhotoChrome).

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Postby calimero » Tue Nov 03, 2015 11:26 am

Animas online converter is down :(

but I will try with your tools. PhotoChrome v6 does not run on Falcon, right?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Tue Nov 03, 2015 11:48 am

calimero wrote:Animas online converter is down :(

but I will try with your tools. PhotoChrome v6 does not run on Falcon, right?


The 'basic' version does work on a Falcon but the CC generator & related options (needed for this type of conversion) is only built into the PC version, and runs on multiple threads to complete in a decent timeframe. The calculations involved are quite expensive so it would be very very slow on a Falcon.

I'll take a look at it after work and see which options are needed. I've not touched it in a while now. There are 3 modes - one produces images (paired PI1s for viewing on STs), another produces maps + tilesets for scrolling playfields, and the third produces texture sets (e.g. for Doom). It's best to play with the images first to get a feel for things as the other two are more complicated to decode & use.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Postby calimero » Tue Nov 03, 2015 12:09 pm

ok, thanx!
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Sun Nov 08, 2015 4:30 pm

Hi, I was busy during the week and then forgot to do this.

But then I looked at it today and noticed the build on my site had the CryptoChrome options disabled - it's a config option when I compile everything. So I have uploaded a new build (same place, same link - just called 'RC2' instead of 'RC1' this time) with CryptoChrome features re-enabled.

http://www.leonik.net/dml/files/pcs621rc2.zip

If you can grab that meantime, I'll post some basic samples soon.


Just running the tool with defaults will give you a decent looking 'composite' image quickly but the result can be flickery when displayed for real. Using the settings carefully (and affording a lot more compute time) will produce similar results with less flicker. But it takes some practice and results vary with the material.

As an example - the texture set for the ST Doom demo took me about 1 hour to convert using this thing, on a fast PC (final high quality conversion). I could have done it much quicker but I could afford the time and just set it going overnight with high settings.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Sun Nov 08, 2015 4:52 pm

Here is a simple test with one EOTB screen. AF didn't let me attach the .pi1's but they get produced along with the preview PNG images.

Sample commandline used:

./pcs -ccmode 1 eotb2.png -ccrounds 8 -ccthreads 6 -ccincap 128

'composite' is the final preview image. The others are field previews, to help debug flickering areas and estimate interleave success generally. 'composite' is roughly what you should expect to see on an STE.

composite00.png


..and the fields, interlaced:

ilfield1.png

ilfield0.png


..deinterlaced:

field1.png

field0.png


'ccrounds' is the number of trial rounds - each one takes a while so don't set it too high unless you have the time. Also diminishing returns here.

'ccthreads' is for parallelism if you have a multicore machine. Reduce ccthreads according to your HW.

'ccincap' limits the input colour count, to speed up the process. More input colours means a lot more time. It's a histogram cap, so don't set it too low or you'll ruin the quality of the image. There are more options but I can't explain them tonight. another time...
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1962
Joined: Sun Jul 31, 2011 1:11 pm

Re: PhotoChrome v6

Postby Eero Tamminen » Sun Nov 08, 2015 5:57 pm

calimero wrote:^
is there any ST project that make use of this technique (two fields technique for more colors) ?


Maybe it's worth mentioning that for monochrome mode, there was Johan Klockars' Mgif image viewer & (DSP accelerated) manipulation program. It could produce 3 images from the original color image, that were floyd-steinberg dithered so that (grayscale conversion / dither) error was propagated between the images. When they were shown in loop, it gave very good grayscale impression and the image didn't flicker that badly (on 71Hz Atari mono monitor) when viewed from bit further. Mgif could also write the images so that they were pre-pended with minimal viewing program.

(I actually used that to view PovRay raytracing results on my mono monitor.)

I'm remember there being some mono-only programs/demos using the same/similar technique (don't remember their names), but naturally only for static pictures.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Sun Nov 08, 2015 6:45 pm

Yep the Apex viewers worked the same way on F030. All of those (incl. MGIF) use non-indexed colour so no palette needs to be hunted, but the display side of the trick works the same way for all.

The only difference here is that a near-optimal palette must be solved first.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest