English Amiga Board Amiga Lore


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 04 November 2016, 20:20   #81
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,532
Quote:
Originally Posted by Thorham View Post
I'm pretty sure the copper can change one color every 8 lowres pixels if the screen depth isn't too high.
Copper require 2 cycles (first word instruction, second word data) - CPU theoretically can do this twice faster. Perhaps Meynaf is able to confirm (or not) this.

Quote:
Originally Posted by Thorham View Post
All that's needed is a viewer and a conversion step from the ST format to Amiga. Both seem pretty trivial to me.
Great statement - i will be happy to see such converter and viewer.
pandy71 is offline  
AdSense AdSense  
Old 04 November 2016, 21:45   #82
kovacm
Banned
 
Join Date: Jan 2012
Location: Serbia
Posts: 275
Quote:
Originally Posted by vulture View Post
Isn't it on a Falcon?
no, for ST: http://www.atari-forum.com/viewtopic...l+slug#p221071

it is only scrolling graphics without gameplay!
kovacm is offline  
Old 04 November 2016, 22:17   #83
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,962
Quote:
Originally Posted by pandy71 View Post
Copper require 2 cycles (first word instruction, second word data) - CPU theoretically can do this twice faster. Perhaps Meynaf is able to confirm (or not) this.
Does that mean you can change one color evey 4 lowres pixels? Anyway, to match the Atari software I think you only need one colore per 8 lowres pixels. Doing this with the copper is also better because it doesn't strain the CPU as much.

Quote:
Originally Posted by pandy71 View Post
Great statement - i will be happy to see such converter and viewer.
Well, it's hardly rocket science.
Thorham is offline  
Old 04 November 2016, 22:31   #84
kovacm
Banned
 
Join Date: Jan 2012
Location: Serbia
Posts: 275
Quote:
Originally Posted by Thorham View Post
Quote:
but even assuming Copper and 2 bitplanes so unthrottled Copper there is no software capable to provide such quality on 2 bitplanes - sad...
All that's needed is a viewer and a conversion step from the ST format to Amiga. Both seem pretty trivial to me.
yes, you could use DML software...
...

Pandy really have a point in this thread... it is something that I always repeat: ST programers are "better" since they "count" cycles to achieve something and they try really hard.

another problem with Amiga users is attitude: "I mean, you make it sound like the Amiga technically couldn't achieve images like this, which is clearly wrong" (by britelite). It is narrative that repeats over and over... Amiga hardware is so superior that nobody can touch it (results: endless MegaDrive, SNES vs Amiga threads) but epilog is that results (demoscene products) on, so inferior, ST are really close to Amiga. Britelite even "cheat" in Eighteen just to show that Amiga (for uneducated users) can show more sprites than ST.

so, yes, you could use DML converter for this...

Quote:
Originally Posted by Thorham View Post
No, but I'm not sure I want to
you should.

Last edited by kovacm; 04 November 2016 at 22:45.
kovacm is offline  
Old 05 November 2016, 01:17   #85
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 244
Quote:
Originally Posted by Thorham View Post
Does that mean you can change one color evey 4 lowres pixels? Anyway, to match the Atari software I think you only need one colore per 8 lowres pixels. Doing this with the copper is also better because it doesn't strain the CPU as much.


Well, it's hardly rocket science.
The copper can definitely change one colour every 8 lowres pixels (assuming no more than 4 lowres/2 hires bitplanes shown). The 2 clocks per move is the amount of DMA bandwidth used, but since the copper can only access odd cycles, it actually takes 4 colour clocks to do a move = 8 lowres pixels.
roondar is offline  
Old 05 November 2016, 01:18   #86
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 244
Quote:
Originally Posted by kovacm View Post
yes, you could use DML software...
...

Pandy really have a point in this thread... it is something that I always repeat: ST programers are "better" since they "count" cycles to achieve something and they try really hard.
I am 100% certain that accomplished Amiga developers do exactly the same.
roondar is offline  
Old 05 November 2016, 10:33   #87
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Quote:
Originally Posted by pandy71 View Post
Copper require 2 cycles (first word instruction, second word data) - CPU theoretically can do this twice faster. Perhaps Meynaf is able to confirm (or not) this.
Copper can do a change every 8 lowers pixels, cpu is twice faster (not sure for 68000, i don't remember movem timings).

If my memory doesn't betray me, the ST can do 3 full palette changes per scan line (= 48 colors).
I see no reason why the Amiga wouldn't be able to use the exact same tricks.


Quote:
Originally Posted by roondar View Post
I am 100% certain that accomplished Amiga developers do exactly the same.
Some accomplished Amiga developers were Atari developers before.
The Atari is a really good school for 68k coding.
meynaf is online now  
Old 05 November 2016, 11:03   #88
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 244
Quote:
Originally Posted by meynaf View Post
Copper can do a change every 8 lowers pixels, cpu is twice faster (not sure for 68000, i don't remember movem timings).
I'm not too sure the 68000 is 2x as fast - movem writes or reads one word per 4 CPU cycles/long word per 8 cycles (plus between 8 and 14 cycles overhead per movem). If you count the reading as well as the writing, using it should take the same time as using the copper.

Quote:
Originally Posted by meynaf View Post
Some accomplished Amiga developers were Atari developers before.
The Atari is a really good school for 68k coding.
Of course. But that doesn't change that there are also accomplished Amiga developers who had no exposure to the Atari ST.

My point isn't to say that Atari ST developers are not good (in any way!), my point is that there are great Amiga developers as well. And personally, I don't feel that the chipset advantages mean you can really afford to be lazy. A bad piece of code on the Amiga will also create a bad result - blitter/copper or no.
roondar is offline  
Old 05 November 2016, 11:06   #89
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,962
Whether or not the CPU is faster than the copper doesn't really matter because of the limited chipset register bandwidth. I've written the color registers with a 50mhz 68030, and you're still limited to one color per 8 lowres pixels.
Thorham is offline  
Old 05 November 2016, 11:37   #90
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Quote:
Originally Posted by roondar View Post
I'm not too sure the 68000 is 2x as fast - movem writes or reads one word per 4 CPU cycles/long word per 8 cycles (plus between 8 and 14 cycles overhead per movem). If you count the reading as well as the writing, using it should take the same time as using the copper.
While some of this work can be performed during the horizontal blank (setting first color bank, preloading second), the 68000 is indeed probably not fast enough to do better than the copper.


Quote:
Originally Posted by roondar View Post
Of course. But that doesn't change that there are also accomplished Amiga developers who had no exposure to the Atari ST.

My point isn't to say that Atari ST developers are not good (in any way!), my point is that there are great Amiga developers as well. And personally, I don't feel that the chipset advantages mean you can really afford to be lazy. A bad piece of code on the Amiga will also create a bad result - blitter/copper or no.
We certainly agree on this.

Personnally I've found the Amiga to be more difficult to code on, but more rewarding, than the Atari.


Quote:
Originally Posted by Thorham View Post
Whether or not the CPU is faster than the copper doesn't really matter because of the limited chipset register bandwidth. I've written the color registers with a 50mhz 68030, and you're still limited to one color per 8 lowres pixels.
Are you sure it's 8 lowres and not 4 ?
A 50mhz 68030 can access chipmem every 28 clocks or so. That's around 1.7 Mhz, i.e. 4 lowres, 8 hires, 16 shres pixels.
This assumes, of course, that the cycles aren't used by anything else (like extra bitplanes).
If the limit is one color per 8 lowres pix, then the assumption that chipmem and chipset have same timing becomes wrong...
meynaf is online now  
Old 05 November 2016, 14:14   #91
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,962
Quote:
Originally Posted by meynaf View Post
Are you sure it's 8 lowres and not 4 ?
Yeah, I'm pretty sure. On Aga with double scan modes it's 16, I think.

I might be wrong, but it's pretty easy to verify. Just open a screen, and write $dff180 with alternating values in a loop. On a 68000 just unroll the loop. Shouldn't matter if you do it using an OS screen or a 'hit the hardware' screen.

Quote:
Originally Posted by meynaf View Post
If the limit is one color per 8 lowres pix, then the assumption that chipmem and chipset have same timing becomes wrong...
I thought that too, but it may indeed be incorrect.
Thorham is offline  
Old 05 November 2016, 14:24   #92
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,532
Color Clock is 3.58MHz and you can feed maximum 7.16MB over RGA/D bus - this is internal chipset design limitation (all except AGA where tricks similar to DDR are used to increase overall bandwidth) - some cycles may be available for CPU.
Above valid for NTSC, PAL is marginally slower ((4.43*4)/5).
And once again - problem is not in transfer speed (number of CLUT updates is identical on ST and Amiga as both systems suffer from same memory bandwidth limitations) but in quality of algorithms for color quantization and error distribution - on 2 bitplanes ST/STe is able to beat Amiga with 4 bitplanes and PCHG (as Dynamic Hires use CPU so it is more close to ST).
It is easy to verify - best Amiga graphic converter capable to do dynamic CLUT updates - HAMLab - is incapable to deliver same quality (perceived by observer) as http://www.leonik.net/dml/sec_pcs.py tool - we talking about lack of visible horizontal stripes (obvious problem with overloading CLUT changes - suboptimal color selection).
This is clearly visible on mentioned already 'elevation by The Electronic Knights' - those pictures are special class pictures very well suited to use Dynamic CLUT techniques (quite well balanced, plenty of luminance details but overall chrominance is very averaged - some contrasting chrominance is also well concentrated but at the same time not to diversified - all this lead to relatively small variance in color histogram, also color changes in vertical direction are almost penalty free).
pandy71 is offline  
Old 09 November 2016, 20:26   #93
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 146
Quote:
Originally Posted by Thorham View Post
No, but I'm not sure I want to
Some things to consider about improving the number of shades per colour channel.

Spectrum 512 images (Atari ST):






Spectrum 4k images (Atari STE):






Spectrum 29k images (Atari STE enhanced):






So there's clearly a difference viewing images with the flicker technique. You should have a look at them for sure.
AnimaInCorpore is online now  
Old 10 November 2016, 09:42   #94
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Images shown here don't flicker, but look more pixelated than on original screens. This applies for both Atari and Amiga images - HAM artifacts are less visible on CBM monitors because the relative big dot size makes some kind of natural antialias effect. Besides, video D/A characteristics aren't the same either.
So i'm not sure the comparisons are very meaningful (unless directly taking high quality photos of the screens themselves, of course).
meynaf is online now  
Old 21 November 2016, 22:24   #95
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,962
Quote:
Originally Posted by AnimaInCorpore View Post
So there's clearly a difference viewing images with the flicker technique. You should have a look at them for sure.
I can't, because I don't have an Atari ST Perhaps someone should just write a viewer
Thorham is offline  
Old 22 November 2016, 10:24   #96
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 146
Quote:
Originally Posted by Thorham View Post
I can't, because I don't have an Atari ST Perhaps someone should just write a viewer
This is on my list for my online graphics converter tool.
AnimaInCorpore is online now  
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
HAM6 on AGA in WinUAE displays incorrectly Photon support.WinUAE 12 29 March 2016 08:44
Converting JPG to HAM6/EHB with ImageStudio jman support.Apps 0 21 June 2011 17:42
Demonstration and Interview with Jan Derogee trackah123 Amiga scene 2 22 February 2009 13:19
Multiple HAM8 pictures? killergorilla support.Other 4 15 February 2007 14:41
First public demonstration of Dragon(Elbox) ppill News 15 09 December 2006 23:29

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 15:34.


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