What software does the Amiga NEED?

[TCH]

Originally Posted by pandy71

http://eab.abime.net/showthread.php?t=76969
Or in other words - there is no good picture converter supporting "dynamic" color changes - compared to ST Amiga can use Copper and CPU so results should be superior, with modern color quantization algorithms this should push Amiga to very high quality conversion IMHO.

My converter could do this. There's two approach to quantize an image to a copperlisted ILBM.

One is to quantize the image per N line pieces. This would result in a [(height / N) * no_colours] coloured image, which can be even more than 256, for example a 200 pixel tall picture quantized to 32 colours per 16 line would result in a 400 coloured picture. However, this can result in a slightly "striped" image, as the colours can differ in each N line tall stripe.

Second is to specify the limit of colours (N), then begin to count colours from the top left corner. Whenever in a line, this colour limit is surpassed by X number of colours, then a copperlist entry would be made, with X palette entries changed to the new colours. This method would produce a result identical to the original image, however this method assumes, that the relevant lines don't contain more colours than N-X, which is highly unlikely to happen in a picture, which have very much colours. The picture can be quantized first (for example to 256 colours), but then the other method can result in higher colour numbers. But this method will still won't produce stripes.

However, any method requires a copperlist chunk in the ILBM and a viewer, which can use it. Is this special chunk defined in any ILBM standard? I know about PCHG, but is that used in viewers?

[Nosferax]

Originally Posted by invent

Something to design game maps with? On the mac,pc,linux there is Tiled I haven't looked to see if the data can be somehow exported for Amiga's.

Not saying it will see the light of day any time soon, but it's in my plan to write a sprite/tile/animation package for one of my game project. I could release it open source when it's done. I've just received my A1200 from the UK and waiting for Amigakit to ship my ethernet and CF card kit. Once I've got them I'll start writing it.

[Pyromania]

I ++++ the idea of a new SSH client for Amiga. That would be nice to have.

[pandy71]

Originally Posted by jsr

My converter could do this. There's two approach to quantize an image to a copperlisted ILBM.

One is to quantize the image per N line pieces. This would result in a [(height / N) * no_colours] coloured image, which can be even more than 256, for example a 200 pixel tall picture quantized to 32 colours per 16 line would result in a 400 coloured picture. However, this can result in a slightly "striped" image, as the colours can differ in each N line tall stripe.

Second is to specify the limit of colours (N), then begin to count colours from the top left corner. Whenever in a line, this colour limit is surpassed by X number of colours, then a copperlist entry would be made, with X palette entries changed to the new colours. This method would produce a result identical to the original image, however this method assumes, that the relevant lines don't contain more colours than N-X, which is highly unlikely to happen in a picture, which have very much colours. The picture can be quantized first (for example to 256 colours), but then the other method can result in higher colour numbers. But this method will still won't produce stripes.

However, any method requires a copperlist chunk in the ILBM and a viewer, which can use it. Is this special chunk defined in any ILBM standard? I know about PCHG, but is that used in viewers?

Well, there are at least 3 types of "dynamic" formats, PCHG is one of them and some viewers support it fully, some "dynamic" formats are supported also on PC.

PCHG assume that color change need to be done during H Blank period and as such it is limited to maximum 10 - 12 but usually to 7 - 9 CLUT changes.
I assume that converter should be Copper/CPU wise - cycles available cycles counted and adopted also some changes may be done in overlapping fashion (i.e. CLUT not used in near 8 pixels) may be changed by Copper during normal video line.
Side to this there possibility to build special structure (pattern in BPLxDAT) and use more CLUT entries - if you look at Atari ST examples they look impressive and usually better than in Amiga approach (which should be not case). Clever color reduction for line (in interlace maybe 2 lines) with correct dithering should be sufficient to provide quasi true (12 bit) color (dreaming on hires).

[TCH]

Well then, which IFF chunk do you suggest for copperlist storing?

Is dithering possible between two distinct images? Because if we quantize the image per N lines, those will be different images.

[pandy71]

Originally Posted by jsr

Well then, which IFF chunk do you suggest for copperlist storing?

Is dithering possible between two distinct images? Because if we quantize the image per N lines, those will be different images.

I would go for PCHG as most "standard" - Dynamic Hires and SHAM are usually less future proof (AFAIK Dynamic hires from NewTek not use Copper at all).

I understand that dithering is a way to distribute quantization error (and this can be tuned psycho-visually to make it less unpleasant) - see Ulichney paper http://www.hpl.hp.com/research/isl/h...ngWithBlue.pdf also http://www.compuphase.com/riemer.htm - i assume lines can overlap and as such good converter should verify interline correlation but generally yes - line or group of lines can be considered as independent picture but it will be good to do line/group of lines overlapping in a wise way.
This is same issue as for HAM - normal dithering will give suboptimal results as quantization will be distributed trough HAM principle and usually is no longer correct dither but new error source (naive approach is to propagate error more to vertical direction as lines can be full independent where HAM pixels are linked - they depend from previous value and because full transitions require 2+1 pixels - problems are unavoidable - wise CLUT may help but correct dithering will be crucial).
I still searching for details about proprietary STORM dither used by Moovid.

[TCH]

If we only can replace cca. 8 colour per scanline, then we have to quantize by the following algorithm: we have to quantize to maximum 32 colours per line and pair up the two palettes of the current and previous line by searching the closest colour in the previous scanline colours for all current scanline colours. After this, we have to find the 8 most distant pairs and those colours will be replaced, the rest will be untouched. Unless we're not quantizing a picture which will have entirely different palettes per line, then it will be okay. By this method, we can get 32 + (height - 1) * 8 colours, for example 1624 colour in a 200 pixel tall image. But still, if the colours which fallen out from the list of 8 most distant are also very distant, then the image will be completely ruined.

Or we can do a little different thing. We quantize per line, but we quantize two lines at once. (Except for the last line of course.) Like this: quantize(image, 0, 0, 319, 1) quantize(image, 0, 1, 319, 2) quantize(image, 0, 2, 319, 3) ... quantize(image, 0, 198, 319, 199) quantize(image, 0, 199, 319, 199)
With this method we can do dithering too.

However, what viewers or programs actually support PCHG?

[pandy71]

Most of viewers support PCHG (i tested mostra for example, ham lab can show and convert, visage, ppshow and more).

8 - 12 colors is valid for hires, for lowres limitations are significantly reduced - side to this HAM can be used, sprites etc - generally most advanced software should be able to do tricks similar to copperchunky/plasma effect - not sure if PCHG can be flexible enough...

IMHO counting colors on few lines is unavoidable as most of new color quantization algorithms trying to work on averaging method not independent pixels, side to this pattern errors detection/prevention is important (preventing dynahires stripes i.e. insufficient amount of colors).
Perhaps good approach is reduce size of picture to for example half lines and for example 8 - 40 transition of colors - this create crude low res color map that can be addressed by Copper/CLUT changes, side to this normal color quantization need to be apply but focused on details.

[bonkers]

Originally Posted by Galahad/FLT

What does Piccon need to be able to do that it currently can't?

I would like to have the same functionality as Piccon but being able to access it through the command line as well. The only functionality that I miss from Piccon is a way to generate ShadeTables and a way to generate palettes with other than linear spread of colour, would be ace if you could easily do it exponentially or as a sine.

Another thing that I would love would be to have a decent enough version of emacs. Now you can either run something that is to resource hungry, think I have 18.6, or something like memacs which lacks a few too many things. Never, found an editor that I like on Amiga sadly, CED, VIM or FrexxEd doesn't really cut it for some reason.

[Jack Burton]

A paint program with PCHG modes would be cool, but I guess it would be a lot of work to do it.

So instead, a cli program which could count the number of each line and then indicate those with more that 15 colors (the max allowed by HamLab) so that one could draw in 256 colors (out of 4096) with a paint program like Brilliance and then verify, thanks to this kind of scanline colour counting program, which scanline exceed the number of colour displayable by the PCHG format. It would help a lot !

[TenLeftFingers]

+1 the SSH client. Althoiugh sftp might be more useful in my case given I wont be administering machines so much as using them for remote mass storage. I shouldn't need a 4GB CF if I can sftp into a 1TB machjne.

And, that machkne could have a headless dropbox client running as a service so I effectively have a dropbox client on my Amiga.

[tolkien]

Source line debugger...source debugger...

[nogginthenog]

Originally Posted by tolkien

Source line debugger...source debugger...

MonAm (from DevPac) can do this if proper debug info is available (IIRC!!).

[tolkien]

Yes, and cpr from sasc. But we need modern c compilers and tools.

[Samurai_Crow]

Originally Posted by tolkien

Yes, and cpr from sasc. But we need modern c compilers and tools.

Agreed. We may have to work under AROS 68k to get decent debugger support though.

[nogginthenog]

Originally Posted by tolkien

But we need modern c compilers and tools.

Does anyone know if it's feasible to target LLVM/Clang to M68k? I had a quick look a while ago but I didn't see anything M68k-like.

[tolkien]

Dont know but seen we have hardly c99 support I doubt it.

[Hannibal]

Hey y'all,
one of the suggestions on here was a full toolchain with everything pre-configured (just add Kickstart roms).
I've just released such a thing - check it out here: http://www.pouet.net/prod.php?which=65625
I am particularly proud of the image converter - for example, the bob cutout functionality is very similar to what I used for Banshee over 20 years ago (as far as I can remember)

[Samurai_Crow]

Originally Posted by nogginthenog

Does anyone know if it's feasible to target LLVM/Clang to M68k? I had a quick look a while ago but I didn't see anything M68k-like.

There's no backend for 68k on LLVM yet. I want to write one but got no farther than starting a project on SourceForge.net. The backend for GCC isn't good either.

[nogginthenog]

Originally Posted by Samurai_Crow

There's no backend for 68k on LLVM yet. I want to write one but got no farther than starting a project on SourceForge.net. The backend for GCC isn't good either.

Have you seen this:
https://github.com/kwaters/llvm-m68k

I compiled it and it does work (Debian Linux). But any C function call fails...

test.c

typedef unsigned int uint32_t;
typedef char int8_t;

uint32_t foo(uint32_t x, int8_t y)
{
    return (x | (1 << 17)) + y;
}

clang -emit-llvm test.c -c -O2 -o test.ll
./llvm-m68k/build/bin/llc -march=m68k test.ll

test.s

        SEG     'main'
; GLOBAL foo
foo     PROC                            ; @foo
; BB#0:
        move.l  #131072, d1
        or.l    (a6), d1
        move.b  4(a6), d0
        ext.w   d0
        ext.l   d0
        add.l   d1, d0
        rts

        END