English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 01 May 2015, 02:42   #81
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
Quote:
Originally Posted by pandy71 View Post
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?
TCH is offline  
AdSense AdSense  
Old 01 May 2015, 16:45   #82
Nosferax
Registered User

 
Join Date: Apr 2015
Location: Beauharnois,Qc,Canada
Posts: 128
Quote:
Originally Posted by invent View Post
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.
Nosferax is offline  
Old 01 May 2015, 16:58   #83
Pyromania
Moderator

Pyromania's Avatar
 
Join Date: Jan 2002
Location: Chicago, IL
Posts: 1,785
I ++++ the idea of a new SSH client for Amiga. That would be nice to have.
Pyromania is offline  
Old 01 May 2015, 22:13   #84
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by jsr View Post
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).
pandy71 is offline  
Old 02 May 2015, 17:31   #85
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
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.
TCH is offline  
Old 03 May 2015, 01:48   #86
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by jsr View Post
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.
pandy71 is offline  
Old 03 May 2015, 12:46   #87
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
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?

Last edited by TCH; 03 May 2015 at 12:47. Reason: aa PCHG
TCH is offline  
Old 05 May 2015, 11:32   #88
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
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.
pandy71 is offline  
Old 05 May 2015, 23:10   #89
bonkers
Registered User
 
Join Date: Aug 2009
Location: Berkeley, USA
Posts: 15
Quote:
Originally Posted by Galahad/FLT View Post
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.
bonkers is offline  
Old 08 May 2015, 00:58   #90
Jack Burton
It's all in the reflexes!
Jack Burton's Avatar
 
Join Date: Nov 2009
Location: Wingkong warehouses
Posts: 156
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 !
Jack Burton is offline  
Old 09 May 2015, 00:35   #91
TenLeftFingers
Registered User

TenLeftFingers's Avatar
 
Join Date: Sep 2013
Location: Ireland
Age: 38
Posts: 783
+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.
TenLeftFingers is offline  
Old 09 May 2015, 21:10   #92
tolkien
AmigaMan

tolkien's Avatar
 
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 456
Source line debugger...source debugger...
tolkien is offline  
Old 13 May 2015, 21:53   #93
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 493
Quote:
Originally Posted by tolkien View Post
Source line debugger...source debugger...
MonAm (from DevPac) can do this if proper debug info is available (IIRC!!).
nogginthenog is offline  
Old 13 May 2015, 22:01   #94
tolkien
AmigaMan

tolkien's Avatar
 
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 456
Yes, and cpr from sasc. But we need modern c compilers and tools.
tolkien is offline  
Old 14 May 2015, 17:54   #95
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 919
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by tolkien View Post
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.
Samurai_Crow is offline  
Old 14 May 2015, 22:03   #96
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 493
Quote:
Originally Posted by tolkien View Post
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.
nogginthenog is offline  
Old 14 May 2015, 22:07   #97
tolkien
AmigaMan

tolkien's Avatar
 
Join Date: Oct 2012
Location: Castro Urdiales/Spain
Posts: 456
Dont know but seen we have hardly c99 support I doubt it.
tolkien is offline  
Old 20 May 2015, 09:41   #98
Hannibal
Registered User

 
Join Date: May 2015
Location: Kirkland, Washington, USA
Posts: 9
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)
Hannibal is offline  
Old 21 May 2015, 02:21   #99
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 919
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by nogginthenog View Post
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.
Samurai_Crow is offline  
Old 21 May 2015, 22:14   #100
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 493
Quote:
Originally Posted by Samurai_Crow View Post
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
Code:
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
Code:
        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
nogginthenog is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the best C software for Amiga crosswire Coders. General 4 21 February 2013 15:41
Amiga Future: Amiga Software Database (ASD) Beta 2 Online AndreasM News 0 12 January 2009 13:42
Amiga Software madduck Amiga websites reviews 4 21 October 2002 00:16
New/Used Amiga Software jmmijo MarketPlace 0 04 April 2002 23:30
PC -> Amiga Software Shagra request.Apps 4 21 September 2001 00:50

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:13.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.38636 seconds with 12 queries