PhotoChrome v6

GFA, ASM, STOS, ...

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

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

Re: PhotoChrome v6

Post by calimero »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

...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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Post by calimero »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: PhotoChrome v6

Post by calimero »

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: 763
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Post by Anima »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 1460
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: PhotoChrome v6

Post by troed »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 763
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Post by Anima »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: 763
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Post by Anima »

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: Texas, USA

Re: PhotoChrome v6

Post by EmpireAndrew »

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: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

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: Texas, USA

Re: PhotoChrome v6

Post by EmpireAndrew »

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!
User avatar
mrbombermillzy
Captain Atari
Captain Atari
Posts: 365
Joined: Tue Sep 13, 2016 9:24 am

Re: PhotoChrome v6

Post by mrbombermillzy »

Just thought Id ask Doug...any chance of 'patching' photochrome to calculate for TT Low/Med resolutions and maybe an option for higher line colour counts (e.g. 64-256)? I dont necessarily need the display program, if that helps. :)

Im currently working on a TT display system and need support tools for test/analysis. Ive coded a few myself, but would prefer to not overlap/reinvent the wheel with what you have done for the ST/e. Would be great if its a case of changing a few constants here and there. On the other hand, if its going to be nearer a complete overhaul, I will understand!
EmpireAndrew wrote: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?
Incase you are still wondering (or for anyone else who comes to this thread for the answer) it runs on TOS1.62 but not 2.06 for the STe.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

It might be possible to use PCS to generate TT images already. Although I'd need to know a bit more about how your stuff works before I can say for sure.

It accepts a kind of script that defines the display layout and it might just be a case of populating that with the right info.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1958
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: PhotoChrome v6

Post by Cyprian »

dml wrote:It accepts a kind of script that defines the display layout and it might just be a case of populating that with the right info.
can you describe it more?
I did some tests with beam sync on the TT. It works in the same manner as on the ST and finally the raster is stable.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
mrbombermillzy
Captain Atari
Captain Atari
Posts: 365
Joined: Tue Sep 13, 2016 9:24 am

Re: PhotoChrome v6

Post by mrbombermillzy »

PM sent to Doug with the details! ;)
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3621
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Post by dml »

Cyprian wrote:
dml wrote:It accepts a kind of script that defines the display layout and it might just be a case of populating that with the right info.
can you describe it more?
I did some tests with beam sync on the TT. It works in the same manner as on the ST and finally the raster is stable.
Hi,

I will dig into it and find a working example. I didn't release the last version of PCS with the 8bpl support in it (and some other things I didn't document) - but I'm pretty sure I did have it working and tried some Falcon experiments before I left it alone.

The script works exactly the same way as for the ST/E. Just some values change and the output format is different, with higher bitdepths. So the user guide PDF will be a good guide on how to use it. There's a section in the PDF covering the syntax.

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

Re: PhotoChrome v6

Post by dml »

Cyprian wrote: can you describe it more?
So I had a look at the code and came to the conclusion that it's 95% doing what is required. But there is an option missing to allow interleaving of two sync schedules for odd/even lines. This will be required if updating less than an entire palette per scan (PCS usually assumes 1 or more palettes per line, not half-a-palette e.g. 128 changes of 256 active).

If you want to write colours 0-127 on even lines while writing 128-255 on odd lines, this schedule-interleaving option will be required. Without it, you will either be limited to 128 colour indices active in the whole image. Otherwise you can write out a sync schedule manually for every single scanline of 480, which will result in a giant text file. :)

So I'll probably incorporate an option for interleaving schedules to make this more usable. Apart from this v6.40 can already generate multipalette images with 256 colour palettes at up to 8:8:8 RGB at any resolution, as required.


There is some documentation on how to program a sync schedule (minus the schedule-interleaving thing I described above and minus the TT changes) starting on page 42 of the v6.26 user guide, called "Custom Conversion Profiles" and the section after it "File Formats/Export" on P45.


Note: The export format changes a bit from what is documented when using palette colour depths 6 and upwards. Normally palettes are stored as 16-bit (4:4:4) for ST/E. Colour depth 5 is special in that it is usually represented by two interleaved fields at 4:4:4 so the export format remains the same.

For colour depth 6 and up, the exported palettes become 32bit little-endian, 8:8:8 (B:G:R:0) on the assumption you're going to post-process it somehow. However the bitmaps are always exported as n-plane, Atari interleaved even when exporting 256col bitmaps. So for TT you'd need to P2C the bitmaps to get a chunky version of the images.

Other than this, things remain the same as documented for ST/E.
Post Reply

Return to “Coding”