PhotoChrome v6

GFA, ASM, STOS, ...

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

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

Re: PhotoChrome v6

Postby calimero » Sun Nov 08, 2015 9:18 pm

AtariZoll wrote: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.


I was think about pre-defined (pre-calculated) graphics that include both background and sprites just to avoid calculation on fly but I only now realise that there would be massive amount of image data for entire game (plus two images for one real screen)...!

btw Mgif is awesome! :)
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 9:53 pm

...a word of warning - the default colour count cap is 256 even if you don't specify a limit, so if you feed in a truecolour image (especially one that was resized/filtered) it will have thousands, and the histogram chop to 256 on the input side will result in a poor conversion.

So pay attention to colour counts going in (look at the report it offers when it starts) and play with the colour count cap until the image looks ok. If you can afford the time you can set a high cap (e.g. 1000+) and leave it running longer.

You can also pre-reduce the input image to something more manageable e.g. 256 cols - but don't bother unless it's a good reducer (and doesn't dither - must avoid dithering).

I'll upload a couple more samples using high colour caps (Grimrock!) later, if I can get back to the machine tonight.

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 11:09 pm

Here's one converted from Grimrock, using STE palette. Produces 98 distinct colours.

Final:

composite00.png


Interlaced fields:

ilfield1.png
ilfield0.png


Deinterlaced fields:

field1.png
field0.png
You do not have the required permissions to view the files attached to this post.

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 11:23 pm

Tried a few more which turned out ok.

So to answer the question - yes, dungeon-mastery games with lots of colours seem doable. Amiga or otherwise.

Combining with colour changes (horizontal split or full cpu hog) would help too with mixing content.

Use sophisticated compression. Keep the fields deinterlaced and stored as 8bit nibble pairs then LZ? the result. Reinterlace during decompression to get the complementary bitplane gfx back.

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

Re: PhotoChrome v6

Postby dml » Mon Nov 09, 2015 12:18 am

The last test finished. This one produced 113 colours.

Final:

composite00.png


Interlaced:

ilfield0.png
ilfield1.png


Deinterlaced:

field1.png
field0.png
You do not have the required permissions to view the files attached to this post.

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

Re: PhotoChrome v6

Postby calimero » Mon Nov 09, 2015 11:24 am

Wow! I must try it on real hardware tonight! So this kind of display does not use almost nothing CPU (two fields with 16 colors)?

So burden now would be on decompressing images... Is it possible to somehow compress further GIF 16colors file? (your examples have around 20KB converted to GIF 16colors)

But you still need to pre-calculated images for "only background" and than for "background + enemy" (and for each enemy you would need to do same pre-calculated images - there would be like thousand of images...).

---

maybe this kind of Point&Click adventure would be mora suitable for this technique!

https://www.youtube.com/watch?v=aT4-SQ-70lA
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 » Mon Nov 09, 2015 11:40 am

calimero wrote:Wow! I must try it on real hardware tonight! So this kind of display does not use almost nothing CPU (two fields with 16 colors)?


Just 16 colours, and 2x 4plane bitmaps yes. No CPU.

calimero wrote:So burden now would be on decompressing images... Is it possible to somehow compress further GIF 16colors file? (your examples have around 20KB converted to GIF 16colors)


GIF uses LZ form of compression which is just one of many dictionary types. They all try to use the smallest encoding for the most common values, with the largest encoding for the least common. The algorithm is sometimes a bit less important than how the data is stored, and making sure related data is stored together, to benefit reuse in the dictionary.

You can LZ the two bitmaps separately or combine them and LZ together. My previous post recommended bitplane->nibble translation (chunky) first, then combine nibbles to bytes, then LZ the bytes. Or just LZ the two sets of nibbles but this might be a bit algorithm sensitive if its (wrongly!) expecting to compress patterns of bytes for some reason.

Regardless - don't LZ the bitplanes directly. Bad dictionary coherence. Bad compression.

calimero wrote:But you still need to pre-calculated images for "only background" and than for "background + enemy" (and for each enemy you would need to do same pre-calculated images - there would be like thousand of images...).


Actually no - it should work the same way as it did for the texture sets needed for ST-Doom.

You collect all of the graphics together into a 'textureset', with representative use. i.e. the number of pixels dedicated to scenery should approximate its importance (there are lots of way to do this but a quick hack can involve just duplicating 'important' content a few times).

You then generate a superpalette for all of it together. Then convert all of the graphics to that superpalette, using the colour map produced by the tool (2 fields for everything). Then you can combine all the gfx without conversion.

If you want *more* colours still, you can go a bit further. Generate the gfx in overlapping context groups (say, 8 groups for a really challenging game) and store each graphic once, with its own colour map. Then remap the gfx to the active palette group when it is in use. This way, irrelevant gfx don't have to pollute the colours needed by relevant stuff vs the same background (e.g. bg==fg1, bg==fg2, but fg1!=fg2).

Since the gfx will need decompressed anyway, some table remapping won't hurt that much in comparison.

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

Re: PhotoChrome v6

Postby dml » Mon Nov 09, 2015 11:44 am

BTW there is a -ccmode for texturesets, but I can't remember how it works just now so you'll be stuck with producing PI1s until I take a closer look again :)

The textureset mode just automates the batch conversion of all images and combined superpalette generation, plus the remapping tables needed to make the bitplane data from source image data. It also outputs some c2p data which isn't probably needed.

That mode was made for 3D use so it probably does mipmaps at the same time, I don't remember. That part can probably be stopped though.

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

Re: PhotoChrome v6

Postby calimero » Mon Nov 09, 2015 11:10 pm

Hey, thats really nice information. So everything is almost prepared for game! :)
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
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Postby Anima » Fri Feb 19, 2016 5:07 pm

dml wrote:54 palette swiches per line - that I believe is without overscan. Without overscan I can also do more.

I haven't analysed the colour references in the non-overscan mode but it could be anywhere between 56 and 64.

I think the most changes per line (with full overscan) was 48 on normal hardware. However I didn't search very hard so who knows.

Do you have a short code snippet for how the correct palette offset can be calculated using the x coordinate and the color index like there is for Spectrum 512? I am just asking because I am about to add multi palette switch modes to my retro image tool.

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

Re: PhotoChrome v6

Postby dml » Fri Feb 19, 2016 5:34 pm

Anima wrote:Do you have a short code snippet for how the correct palette offset can be calculated using the x coordinate and the color index like there is for Spectrum 512? I am just asking because I am about to add multi palette switch modes to my retro image tool.



I don't use a fixed formula with PCS6, but rather an external CSV table of rules - specifying a single scanline for the whole image, or groups of scanlines for different parts of the image. Mainly to allow people to make up new modes for which there is no timing formula yet.

So I can provide the original tables which yield the palette visible for each pixel x-coord, for each colour index - which is similar to having a formula for it. The table is different for each mode. The default mode is compatible with ancient versions of PCS (48 cc : 320x199 lines). The STE demos I posted more recently are with new timings / different table (52 cc : 400x272 lines).

I might have misunderstood the question though - if, so I can try again :-)

User avatar
troed
Atari God
Atari God
Posts: 1438
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: PhotoChrome v6

Postby troed » Fri Feb 19, 2016 5:39 pm

I found the CSV tables easy to work with at least. The 415x274 full-screen pictures in Closure, 50 palette changes per line, were done that way.

(Maximum x-resolution is wakestate dependent, 415 is in wakestate 2)

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

Re: PhotoChrome v6

Postby dml » Fri Feb 19, 2016 6:08 pm

Here are the CSV timing tables for the two modes.

'pcspct' = old (320x200) mode
'pcs62pct' = more recent experimental (400x272+blitter) display modes

I have documented the CSV files and output file formats in the manual for the 6.2 build - which I'm fairly sure did make it onto my site. Although sometimes I forget to do basic things like that...
You do not have the required permissions to view the files attached to this post.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Postby Anima » Fri Feb 19, 2016 6:13 pm

Ok, it seems that there are more questions now than before. ;)

The calculation I am talking about look like this:

Code: Select all

int find_index(unsigned int x, unsigned int c) {
    unsigned int t = 10 * c;

    if (c&1) t -= 5;
    else     t++;

    if (x < t)      return c;
    if (x >= t+160) return c + 32;
    return c + 16;
}


and has been taken from here.

However, it's been interesting to see different specs from you and troed regarding the colours per pixels (52/400 and 50/415). So the question is: is the old formula at least valid for the 48/320 colours per line mode or is it different compared to the original Spectrum 512 calculations because the Blitter is being used?

Questions over question... ;)

Update: I'll have a look into the CSV data you've posted. So I guess that can be put into a simple formula. It seems to be quite obvious that the distribution is relatively homogeneous due to the use of the Blitter, isn't it?

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

Re: PhotoChrome v6

Postby dml » Fri Feb 19, 2016 6:31 pm

Anima wrote:Ok, it seems that there are more questions now than before. ;)

The calculation I am talking about look like this:

Code: Select all

int find_index(unsigned int x, unsigned int c) {
    unsigned int t = 10 * c;

    if (c&1) t -= 5;
    else     t++;

    if (x < t)      return c;
    if (x >= t+160) return c + 32;
    return c + 16;
}


and has been taken from here.


Yes - so the CSV table is really a sort of expansion of that.

The CSV 'row' is the x-coordinate. The CSV 'column' is the colour index (0-15). The value at that table entry is the palette index relative to the first palette on the line.

So [0] = first palette on the line, [1] = second palette. [-1] = last palette of previous line (i.e. carried colours!). This rule is repeated for all lines in the 'group'. Most modes will need only one group. That's basically all it is.

So I guess you can match the operation of the formula above by doing this:

palette_word_index = (csv_table[row=x,column=i] << 4) + i


Anima wrote:However, it's been interesting to see different specs from you and troed regarding the colours per pixels (52/400 and 50/415). So the question is: is the old formula at least valid for the 48/320 colours per line mode or is it different compared to the original Spectrum 512 calculations because the Blitter is being used?


The old formula for PCS is similar to Spec512, although not the same IIRC. It's been so long, I forget :-/ Probably best to go from the table when converting PCS specifically.

Blitter was only used in the recent 4xx*272 example mode. Early PhotoChrome didn't use blitter at all, so the pattern is quite irregular across a scanline.

(The example mode was at least partly a demo of how to make your own weird modes using the CSV feature, as much as a demo of using more colours!)


Anima wrote:Update: I'll have a look into the CSV data you've posted. So I guess that can be put into a simple formula. It seems to be quite obvious that the distribution is relatively homogeneous due to the use of the Blitter, isn't it?


That's correct - the blitter-based modes are much easier to compress into a formula should you need to do so! However beware a few colours are still updated by the CPU inside the overscan border period.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 666
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Postby Anima » Fri Feb 19, 2016 6:42 pm

Ah, I think it's clear now... due to the border opening synchronisation there's no easy formula but only Zuul CSV. :D

User avatar
EmpireAndrew
Captain Atari
Captain Atari
Posts: 444
Joined: Fri Jul 15, 2016 5:46 pm
Location: NYC, USA

Re: PhotoChrome v6

Postby EmpireAndrew » Sat May 04, 2019 9:32 pm

Did the viewer ever get an update to work on an STE with TOS 2.06?
When I run it on mine I get an error about only working on standard something or other(scrolls off screen) which I assume is due to TOS based on prior messages in this thread...

I created an image on the PC but obviously I can't view it on my Atari...

Speaking of creation, I downloaded 4 different jpegs to convert using the "slow" method given in the pdf doc, but only one completed successfully, the other 3 all suffered a cygwin exception and stackdump when in the phase "creating output file".
1977 VCS Heavy Sixxer (Boxed)
1990 Atari 1040STE, 4MB, UltraSatan, TOS 2.06, TT Touch -> Atari SC1435 Colour CRT Monitor
1991 Atari TT030, 2/64MB, Int 8GB Gigafile SCSI2CF, TOS 3.06, CaTTamaran Accelerator -> Atari TTM195 19" Mono CRT Monitor
1993 Atari Falcon030, 14MB, Int 8GB HDD, TOS 4.04 -> Atari PTC1426 Color CRT Monitor
Amiga, Mac, DOS, SGI, Sun, NeXTStation, PDA's and more!

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 May 05, 2019 10:56 pm

Hi, sorry I've been away from this for a while now so I'm going from memory here.

Crashes might be caused by Cygwin version compatibility problems. The exe *should* work with your installed Cygwin DLLs, but not guaranteed over the long term as they keep getting updated by the Cygwin folks. The DLLs I bundled alongside PCS shouldn't be used with an existing Cygwin install as it probably will break Cygwin - they're only provided for using PCS without Cygwin present.

I really should just convert the project to build statically under Visual C++ so the Windows exe doesn't need any DLLs, and be done with it.


Of course it could be a fault in PCS. The version I use myself is stable, at least with all the images i feed it. Maybe I need to post a new one. I don't know when I last posted it here.


As for the TOS issue - I'm not really aware of the details, or don't remember it. I'll make a note to investigate when I can. Sounds like it shouldn't be a hard thing to fix.

User avatar
EmpireAndrew
Captain Atari
Captain Atari
Posts: 444
Joined: Fri Jul 15, 2016 5:46 pm
Location: NYC, USA

Re: PhotoChrome v6

Postby EmpireAndrew » Mon May 06, 2019 1:25 am

Thanks for the quick reply!

I’d really appreciate it if the viewer could run on TOS 2.06 (at least I assume that’s the problem, it’s otherwise just a stock US STE).

I assumed the conversion program was using the included Cygwin that it came with?
1977 VCS Heavy Sixxer (Boxed)
1990 Atari 1040STE, 4MB, UltraSatan, TOS 2.06, TT Touch -> Atari SC1435 Colour CRT Monitor
1991 Atari TT030, 2/64MB, Int 8GB Gigafile SCSI2CF, TOS 3.06, CaTTamaran Accelerator -> Atari TTM195 19" Mono CRT Monitor
1993 Atari Falcon030, 14MB, Int 8GB HDD, TOS 4.04 -> Atari PTC1426 Color CRT Monitor
Amiga, Mac, DOS, SGI, Sun, NeXTStation, PDA's and more!


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests