3D in demos - F030 vs Amiga 1200

[NovaCoder]

Originally Posted by StingRay

That is, quite frankly, far away from truth, most demos are 100% realtime.

I'm not just talking about animated movies, I'm thinking about pre-calculated things like lighting, physics and movement paths for objects in 3D scenes.

[StingRay]

And it still is far away from truth! First, not many demos use physics. And lighting is perfectly possible (and done) in realtime, same for movement paths, splines are used there and coding a fast spline routine isn't that hard. Precaclulated are most of the time sine tables (or other trig tables for that matter) but the "real" stuff is done in realtime.

[Bobic]

Kovacm: You might want to talk to Leonard from Oxygene about his demos. He's still around. Look here: http://leonard.oxg.free.fr/

[kovacm]

Originally Posted by pandy71

Plain A1200 is without FastRAM, memory speed limitations are similar or even worse than on Falcon,

...from start I am talking about A1200 with Fast RAM.

"are best Amiga 1200 demos with most complex 3D scenes BUT for STOCK A1200 (14MHz - with FastRAM)." link

Originally Posted by pandy71

DSP have different architecture thus even with 8 bit port can provide 16MIPS in terms dot product, vector transformations etc etc - data exchange probably is slower thus efficient 56000 use - push heavy calculations with relatively low data exchange rate will anyway add more to system than FastRAM with 68030/50MHz to A1200 thus they can't be compared unless you think about comparison not flame.

this is exactly why I ask what are best 3D demos on A1200 with FastRAM: I wan to see what coders manage to pull from both machines!

Originally Posted by pandy71

What new topic? tricks how to open border? 16 color LUT? 320x200? i mean sorry but just calculate how much time is wasted on ST to simulate Copper.
How many thing you need to emulate from Amiga on ST - and this is maximum for ST - be reasonable - i like ST too but...

hm... why you are talking about "How many thing you need to emulate from Amiga on ST" when your original replay was about 3D:

Originally Posted by pandy71

If you really want compare 3D graphics, compare or plain Amiga 500/600 with ST

I replay to this: "we can open new topic but I think that ST is faster with 10% faster CPU and interleave video memory (and movem.l)..." and I was talking about 3D speed!

so I do not understand why did you post bunch of pictures... ?!?

Originally Posted by pandy71

[kovacm]

Originally Posted by Bobic

Kovacm: You might want to talk to Leonard from Oxygene about his demos. He's still around. Look here: http://leonard.oxg.free.fr/

I am not sure if Oxygene code anything for Amiga... Oxbab from Oxygene is coder for Amiga... right?

@Frog
@UberFreak

thanx both, I will check demos and nfo files

and I will bring out my A1200 (I need to find FastRAM upgrade) to check all this demos on real hardware!

[pandy71]

Originally Posted by kovacm

...from start I am talking about A1200 with Fast RAM.

"are best Amiga 1200 demos with most complex 3D scenes BUT for STOCK A1200 (14MHz - with FastRAM)." link

but STOCK A1200 is without Fast RAM - thus requirement is contradictory.

Originally Posted by kovacm

this is exactly why I ask what are best 3D demos on A1200 with FastRAM: I wan to see what coders manage to pull from both machines!

Once again - unless Falcon not use DSP as GPU that's fine but without source we can't verify if DSP is used or not. Pears to peaches (as apple is tm)...

Originally Posted by kovacm

hm... why you are talking about "How many thing you need to emulate from Amiga on ST" when your original replay was about 3D:

But A1200 is plain 2D machine where Falcon can be seen as 2D + 3D (hardware multiply + other features in DSP really can gain nice offload from main CPU) - emulation as most of efforts form ST is related how to beat Amiga (i mean how emulate non existing HW on MC68K).

Originally Posted by kovacm

I replay to this: "we can open new topic but I think that ST is faster with 10% faster CPU and interleave video memory (and movem.l)..." and I was talking about 3D speed!

so I do not understand why did you post bunch of pictures... ?!?

This one is quite clear - as you stated no flame wars but then starting new one then you have result - once again - ST need to emulate basic things that are available on Amiga as HW implementation - i see no point to start after 25 years discussion is 10% higher CPU clocking will give (or not) any gain over Amiga.
Not sure but can you provide similar topic on dedicated ST forum where some Amiga guy starting similar topic.

We can only compare something that is comparable - ST and A500 can't be compared as they are not comparable.

btw - once again - 3D even in software must be rendered at final buffer - this is my point with pictures - video buffers and video output capabilities are so different that it is really hard even to think about honest ST comparison with A500.

For example i can set 640x400 on Amiga - i can even force this resolution to be less flicker (by shortening video frame on OCS or explicitly by reducing number of lines to be displayed on ECS) - or i can be nasty and use LCD as display thus no flicker at all, then i can draw 3D on such screen but still i can introduce color and this is out of ST capabilities - how we can compare this? Gain from memory organization on ST is mostly where chunky translation is used - then yes, ST will be slightly faster but do really that speed will translate to final effect? when you need push PSG vol register to emulate PCM channel for example?

Let me show this in that way - nice example [ Show youtube player ] vs very good [ Show youtube player ] or [ Show youtube player ] i like those ST demos, no doubt but i think that difference (some imperfections on ST) are obvious - and how to compare various taste? pears to peaches...

So sorry, no offense but we can't compare ST with A500 and we can't compare Falcon with A1200 - both comparisons will be simply unfair.

[Cyprian]

There are some myth around Falcon's memory bus (and Amiga also).

Originally Posted by kovacm

3. Falcon with 16bit bus, 16MHz, and 4 cycles RAM access have 8MB/s BUT VIDEL also access to same RAM. In truecolor 320x200 mode it will take up to 13% of RAM time: so you will have around 7MB/s (more info: http://rodolphe.czuba.free.fr/CT2/english/technic.htm)

not exactly true. Falcon's HiColor (16MHz pixelclock) mode needs 32MB/s bus bandwidth. From technical point of view Falcon has 8Mhz bus and Videl in order to minimize impact on CPU performance, gets data in 32bit chunks.

Regarding CPU, it has access to ST-RAM(chip-ram) every odd bus cycle. It means 4th CPU cycle access - 4Mhz. And It has Full Speed access to Fast-Ram.

Originally Posted by kovacm

4. Not sure about A1200 chip RAM and Fast RAM speed... ?? can anyone give a info?

Below you can find memory peformance test A1200

  BusSpeedTest 0.19 (mlelstv)   Buffer:     262144 Bytes, Alignment: 32768
  ========================================================================
  memtype   addr       op         cycle     calib         bandwidth
  chip      $000B0000  readw    1052.4 ns   normal       1.9 * 10^6 byte/s
  chip      $000B0000  readl    1051.8 ns   normal       3.8 * 10^6 byte/s
  chip      $000B0000  readm    1052.2 ns   normal       3.8 * 10^6 byte/

And for Falcon:

    NemBench v2.1 - precision CPU/FPU profiler.

    Linear 32bit read (ST-Ram)   -> 5.475 MByte/sec (~103%)
    Linear 32bit write (ST-Ram)  -> 6.660 MByte/sec (~103%)
    Linear 32bit copy (ST-Ram)   -> 3.336 MByte/sec (~103%)

Therefore according to NemBench and BusSpeedTest, Falcon has better memory performance.

[Bobic]

Originally Posted by kovacm

I am not sure if Oxygene code anything for Amiga... Oxbab from Oxygene is coder for Amiga... right?

Leonard wrote code for many different platforms including (Atari, Amiga, GBA, Win, etc).

[StingRay]

Originally Posted by kovacm

I am not sure if Oxygene code anything for Amiga... Oxbab from Oxygene is coder for Amiga... right?

Oxbab made Amiga stuff, so did Leonard. There are some nice Oxygene Amiga demos/intros from "back in the day" (TM).

[kovacm]

@pandy71

offtopic - I am curious: how these images are reproduced on Amiga?

My first guess is "Spectrum 512" in hi-res (palette changing trick)? right?

[mc6809e]

Originally Posted by kovacm

@pandy71

offtopic - I am curious: how these images are reproduced on Amiga?

My first guess is "Spectrum 512" in hi-res (palette changing trick)? right?

Probably a four bitplane hires screen with a new palette for each scanline.

Was there a hires version of Spectrum 512? I would have thought that the limit of changing one of four colors per run of 20 pixels would have made the technique almost useless.

[kovacm]

^ you can see how it will look like here http://pouet.net/prod.php?which=12237

"Each picture has a resolution of 640x400 and can contain up to 14.000 colors
out of a palette from 29.791 colors."

Probably a four bitplane hires screen with a new palette for each scanline.

one palette per scanline? I am sure that copper can do much better than this.

[pandy71]

Originally Posted by kovacm

@pandy71

offtopic - I am curious: how these images are reproduced on Amiga?

My first guess is "Spectrum 512" in hi-res (palette changing trick)? right?

Yes, good guess (educated one) - this is PCHG Hires Interlace - HAMLAB (converter) + MOSTRA (viewer) - some limitations make this good only for particular group of images (color changes should be oriented in vertical direction) - but for example city landscape is made from 611 unique colors.
Sometimes better effects can be achieved with hybrid solution: http://www.ximagic.com/q_index.html with HAMLAB (Ximagic Quantizer preproces image to reduced amount of colours, then HAMLAB trying to fit this in PCHG limitations - dithereing/noise shaping is extremally important and HAMLAB have some limitations also seems that is not very stable in terms of quality) - however using smart (psycho-visually tuned - shape recognition? - neural networks?) or at least decent modern (http://members.ozemail.com.au/~dekker/NEUQUANT.HTML , http://moonflare.com/code/scolorq/) color reduction algorithm horizontally oriented (to fit optimally in Copper limitations) with some direct hardware access (PCHG is a bit limited to made standard OS friendly - interlace offer less color changes on screen), probably those results can be much better, perhaps near perfect-optimal.

As there is no PCHG compatible viewer for PC (i don't know such viewer) , those pictures are changed from PCHG IFF to 24 bit png by HAMLAB - this can be seen as loss free conversion thus WYSIWYG.

http://ulozto.net/xFt2Afu2/pchg-7z some examples in PCHG IFF (thus Amiga or WinUAE required with at least freeware Mostra)

[pandy71]

Originally Posted by kovacm

^ you can see how it will look like here http://pouet.net/prod.php?which=12237

"Each picture has a resolution of 640x400 and can contain up to 14.000 colors
out of a palette from 29.791 colors."

This is not real interlace first (lines are not shifted by +- 0.5 V), temporal dithering is irrelevant and nasty cheating (highly subjective - person dependent) - number of colors is purely theoretical and this techniques are available for Amiga too but they are simply unpractical (some of them can be used more efficiently on AGA but not for displaying static but dynamic pictures - Copper chunky) - http://de4.aminet.net/gfx/conv/Ham32k.readme - Amiga guys are lazy

Originally Posted by kovacm

one palette per scanline? I am sure that copper can do much better than this.

one color change per 8 hires pixels - PCHG limit color changes to H Blank time thus no more than 7 - 9 per scanline and only for frame not field - OS friendly - manually Copper can do more (but not more than 50 few changes per scanline).

[kovacm]

^^
can I make one observation?

on ST, coders need, as you said "to emulate" (I would prefer phrase "to find way") to achieve Amiga capabilities. One of need was to display more than 16 colors onscreen so Atari coders find a way in 1987.: Spectrum 512 (http://www.asterius.com/atari/spectrum.html)

It is nice to see that Amiga coders adopt this idea. as I said before: I want to see how far coders manage to push limits of hardware boundaries

btw "manually Copper can do more (but not more than 50 few changes per scanline)" - copper will do this with 0% CPU time, and some bus time, right? and one more thing: how much bus time will consume hires with 4 bitplanes on OCS/ECS?

[pandy71]

Originally Posted by kovacm

^^
can I make one observation?

on ST, coders need, as you said "to emulate" (I would prefer phrase "to find way") to achieve Amiga capabilities. One of need was to display more than 16 colors onscreen so Atari coders find a way in 1987.: Spectrum 512 (http://www.asterius.com/atari/spectrum.html)

It is nice to see that Amiga coders adopt this idea. as I said before: I want to see how far coders manage to push limits of hardware boundaries

OK - as English is not my native thus excuse my mistakes.

Raster interrupts are OK - its nice that Atari ST coders adapted idea from Atari 400/800 and Commodore 64 - this provide impressive result considering Jack Tramiel cost reduction concept and limited amount of time to design ST.

Amiga is slightly different (more comparable to Atari 400/800 but there is no ANTIC and there are some fundamental differences how video data are processed) and most of this type operations is performed by Copper (with all pros and cons). Raster interrupts can be used on Amiga without problems (necessary HW exist ad trig particular behavior on CPU side) but in multitasking environment it is better to use dedicated HW that provide HW synchronization with time critical event (as nature of the multitasking systems is purely asynchronous).

Anyway Raster interrupt is CPU (especially modern one) not friendly and simply this is dirty (8 bit time) hack.

Originally Posted by kovacm

btw "manually Copper can do more (but not more than 50 few changes per scanline)" - copper will do this with 0% CPU time, and some bus time, right? and one more thing: how much bus time will consume hires with 4 bitplanes on OCS/ECS?

Yes - no one even doubt on this, this part of Amiga HW limitations are perfectly known however there is one thing you obviously missed - if Amiga start doing things in similar manner as ST we don't need to open 4 bitplane hires - we can use 2 bitplane hires and push data as ST. Very important thing - to avoid CHIP bus saturation we can relies on Fast RAM thus avoid (in most cases) mentioned problem. Overall we can do this like on ST but no one (except copper chunky) do this as it is done on ST side.

To conclude - you may assume that Lores 4 bitplanes/Hires 2 bitplanes are without speed limitation on CPU side (unless Copper/Blitter heavily used) - this is similar to ST. Also quite important difference is that Copper/CPU can manually feed BPLxDAT registers thus with lower number active bitplanes higher number color registers can be used (at least at some special cases and under some limitations) - this is not frequently used feature - in theory with clever pattern and temporal dither perhaps this can be used as substitute for tricky video mode - as HAM doesn't work in Hires (OCS/ECS) then we can't use HAM to improve this kind of functionality with software driven BPLxDAT (but we can in Lores) - not sure but as a technical concept probably you can do video fully pure software pumped (by CPU or Copper) just placing video data directly in BPLxDAT...

[kovacm]

nice. did not know that it use only 2 bitplanes. we should made one nice site about all this stuff!...

To conclude - you may assume that Lores 4 bitplanes/Hires 2 bitplanes are without speed limitation on CPU side (unless Copper/Blitter heavily used) - this is similar to ST.

on ST there is no CPU time left (almost) while displaying Spectrum512 images. you are saying that same thing is with Amiga?


btw this is offtopic but: what about PCHG animation/video? is anybody done this on Amiga?

on Atari STe, Mr. Petari made 50fps video playback from CF Card connected to ROM port.
Video is up to 416x228px, 48 colors per scanline, 50fps for flickering and additional perceptual colors (30000). Speed of CF card ROM port adapter is more than 3.5MB/s(!) but for video and sound 2.4MB/sec is enough.

[ Show youtube player ]

[ Show youtube player ]


btw2 do you have some reference that palette changing trick for displaying images are made on XL or C64 prior 1987.?

[pandy71]

Originally Posted by kovacm

nice. did not know that it use only 2 bitplanes. we should made one nice site about all this stuff!...

Hmmm i think that ST has only 3 video modes, 4 bpl 16 colors, 2 bitplanes 4 colors and mono - 1 bpl? So direct mode corespond to Atari ST 640x200 4 colors is Amiga Hires No Lace ie 640x200(256 on PAL) with 2 bitplanes and CPU have all own cycles available.

Originally Posted by kovacm

on ST there is no CPU time left (almost) while displaying Spectrum512 images. you are saying that same thing is with Amiga?

Same on Amiga. Same CPU, same bus limitations, slightly lower clock compensated by less power hungry tasks performed by HW.

Originally Posted by kovacm

btw this is offtopic but: what about PCHG animation/video? is anybody done this on Amiga?

Possible technically, probably no one is even interested as we can use HAM (at worst case SHAM or PCHG HAM).

[ Show youtube player ]

But as there is no good conversion software then HAM is far from perfect. On AGA all efforts was made to make real time transcoding ie not preconverted but convert on the fly (with decoding) video from different formats (such as MPEG and similar).

Originally Posted by kovacm

on Atari STe, Mr. Petari made 50fps video playback from CF Card connected to ROM port.
Video is up to 416x228px, 48 colors per scanline, 50fps for flickering and additional perceptual colors (30000). Speed of CF card ROM port adapter is more than 3.5MB/s(!) but for video and sound 2.4MB/sec is enough.


[ Show youtube player ]

[ Show youtube player ]

Same rule as previously and obviously when you use temporal dithering there is no 50fps also cinema source (film) is 24 fps - no reason to push over this especially that Amiga can change vertical frequency easily and create 24/48 fps modes to render such video without time jitter.
In case of Amiga - CHIP BUS seem to be limit - absolute maximum is hires 4 bpl, AGA is much better on this.

Originally Posted by kovacm

btw2 do you have some reference that palette changing trick for displaying images are made on XL or C64 prior 1987.?

Not sure - probably on those time people was focused on different aspects, later temporal dithering and similar tricks was introduced - i think break trough was related to widely variable high quality pictures (scans) mostly as GIF and JPG.

[kovacm]

Originally Posted by pandy71

Same on Amiga. Same CPU, same bus limitations, slightly lower clock compensated by less power hungry tasks performed by HW.

so copper can not on their own do palette changes? so 68000 also must be involved?

Originally Posted by pandy71

Not sure - probably on those time people was focused on different aspects, later temporal dithering and similar tricks was introduced - i think break trough was related to widely variable high quality pictures (scans) mostly as GIF and JPG.

on Atari demand for more colors on screen was because of 3D software, CAD 3D, to be able to show results as good as possible. (follow the link that I left few post above for more info)

[pandy71]

Originally Posted by kovacm

so copper can not on their own do palette changes? so 68000 also must be involved?

No, CPU or Copper can change content of any (Copper with some restrictions CDANG and OCS vs ECS+ differences) register also color registers - CPU only need to construct copper list and point copper to copper list rest is performed independently, additionally Copper and Blitter can be linked (Blitter modify Copper list which control Blitter)

http://eab.abime.net/226098-post7.html
http://ada.untergrund.net/forum/inde...um=4&topic=442

Originally Posted by kovacm

on Atari demand for more colors on screen was because of 3D software, CAD 3D, to be able to show results as good as possible. (follow the link that I left few post above for more info)

As i said previously - some of HW functionality already available in Amiga make Amiga developers more "lazy"