Amiga OCS vs Amiga AGA (020)
category: general [glöplog]
Whether those "generic C code + chunky buffer + C2P + mp3-music" demos are worthwile, is highly subjective.
Quote:
Whether those "generic C code + chunky buffer + C2P + mp3-music" demos are worthwile, is highly subjective.
I think we can safely say that about 99% of the stuff released on Amiga these days. :)
- Where is the AGA equivalent of "darkroom" ?
- Where are the CD32 demos ?
- Why are C64 demos more interesting than Amiga ones since 15 years ?
- Where are the CD32 demos ?
- Why are C64 demos more interesting than Amiga ones since 15 years ?
Quote:
- Where is the AGA equivalent of "darkroom" ?
For me it's Pygmy's G-Force, although it requires fast ram & is less aesthetically pleasing. Your mileage may vary.
(The only _really_ epic vanilla-1200 release imho is Nexus 7)
Quote:
- Where are the CD32 demos ?
Hanging out with the C64GS demos.
Quote:
- Why are C64 demos more interesting than Amiga ones since 15 years ?
A larger and more varied (and dedicated) group of people have spent more years playing around with the platform limitations and aesthetics.
I'd love it if the re-animated OCS scene manages to get anywhere close to that creativity & productivity. :)
I'm with Loaderror on this one. I think the AGA chipset has a lot to offer relative to OCS from a demo effect perspective, apart from more and smoother colors. Just a few things I find particularly game-changing:
- Being able to cover the whole screen with sprites.
- Palette double buffering: much more flexible copper chunky.
- 64-bit fetchmode: means you can have many colors / high resolution without being bogged down by bitplane DMA.
Also, contrary to what absence and yzi seem to suggest, the CPU is a lot faster, as long as you stay within the 256-byte instruction cache (which is usually not a problem for core loops):
- Twice as high clock rate
- Most instructions take half as many cycles or less
- 32-bit operations and memory access at no extra cost compared to 16-bit
Sure, fastmem makes data access much faster, but the situation is nowhere as ridiculous as on the A500, where even executing instructions is hampered by DMA traffic. In this respect, the A1200 feels closer to the ideal conceptual model of multiple independent processors working together. The A500 CPU/blitter "parallelism" is a joke (of the bad kind).
So IMHO a plain A1200 is a quite nice demo platform. The lack of demos compared to A500 mainly comes down to tradition, or as Slummy so nicely puts it:
- Being able to cover the whole screen with sprites.
- Palette double buffering: much more flexible copper chunky.
- 64-bit fetchmode: means you can have many colors / high resolution without being bogged down by bitplane DMA.
Also, contrary to what absence and yzi seem to suggest, the CPU is a lot faster, as long as you stay within the 256-byte instruction cache (which is usually not a problem for core loops):
- Twice as high clock rate
- Most instructions take half as many cycles or less
- 32-bit operations and memory access at no extra cost compared to 16-bit
Sure, fastmem makes data access much faster, but the situation is nowhere as ridiculous as on the A500, where even executing instructions is hampered by DMA traffic. In this respect, the A1200 feels closer to the ideal conceptual model of multiple independent processors working together. The A500 CPU/blitter "parallelism" is a joke (of the bad kind).
So IMHO a plain A1200 is a quite nice demo platform. The lack of demos compared to A500 mainly comes down to tradition, or as Slummy so nicely puts it:
Quote:
And there's also more people out there who (at least think they) have some idea about what's possible on the A500, so there are more faces to rub my brilliance all over.
i would love a few dedicated CD32 demos, as mentioned above the Akiko chip was designed to provide a speed up without the cost of adding fastram, sure it's no miracle chip, but the example of Doom on vanilla A1200 vs CD32 using Akiko provided a 50% speedup.
If any coders could push this chip in a demo I would gladly put it on my CD32 demo CD I've just released.
http://cd32covers.blogspot.co.uk/2017/04/unofficial-cd32-release-4-decades-of.html
If any coders could push this chip in a demo I would gladly put it on my CD32 demo CD I've just released.
http://cd32covers.blogspot.co.uk/2017/04/unofficial-cd32-release-4-decades-of.html
Good !
That said, I've just released the source code for "Catabasis" so that anyone can verify what a mess can be a 16+16 (+16 for sprites) AGA dual playfield parallax scroller with big bus fetch mode: http://aminet.net/demo/aga/CCNCatabasisSrc.lha
That said, I've just released the source code for "Catabasis" so that anyone can verify what a mess can be a 16+16 (+16 for sprites) AGA dual playfield parallax scroller with big bus fetch mode: http://aminet.net/demo/aga/CCNCatabasisSrc.lha
Quote:
A500, where even executing instructions is hampered by DMA traffic
I think it's not hampered if you stick to 4 bitplanes, but that sucks yes.
Thanks for the source! :)
From the Catabasis source:
"That way, you can have most effects done in vblank interupt, running always at 50Hz whatever happens, and a triple buffer still managed at main thread level, running at any fps. classic."
This is so what I've wanted to do for several demos, but I always get lots of artifacts! Most likely because in my setup the audio interrupt interrupts the vblank interrupt making the stuff in the vblank interrupt not getting set on time before the frame starts.
From the Catabasis source:
"That way, you can have most effects done in vblank interupt, running always at 50Hz whatever happens, and a triple buffer still managed at main thread level, running at any fps. classic."
This is so what I've wanted to do for several demos, but I always get lots of artifacts! Most likely because in my setup the audio interrupt interrupts the vblank interrupt making the stuff in the vblank interrupt not getting set on time before the frame starts.
btw cool stuff in the source readme. I like the polyfiller part too. I ended up using the bfins instruction to draw particles in our previous demo. It can draw multiple bits wide particles quite easily. Probably a bad idea performance wise, but framerate was ok (on 060 lol).
Quote:
Why are C64 demos more interesting than Amiga ones since 15 years ?
I wouldn't call scrolling bitmaps for two hours interesting...
@amigajay
To my knowledge the Akiko custom chip is pretty useless for c2p (chunky to planar conversion) due to the fact it is not a DMA chip (!).
So the coder basically has to write chunky data in its registers to read then planar converted data back and at last finally has to write them to chip ram.
Very slow process compared to other techniques.
The Amiga CD32 is however an interesting machine for the demo coder ... ;)
Quote:
i would love a few dedicated CD32 demos, as mentioned above the Akiko chip was designed to provide a speed up without the cost of adding fastram, sure it's no miracle chip, but the example of Doom on vanilla A1200 vs CD32 using Akiko provided a 50% speedup.
If any coders could push this chip in a demo I would gladly put it on my CD32 demo CD I've just released.
To my knowledge the Akiko custom chip is pretty useless for c2p (chunky to planar conversion) due to the fact it is not a DMA chip (!).
So the coder basically has to write chunky data in its registers to read then planar converted data back and at last finally has to write them to chip ram.
Very slow process compared to other techniques.
The Amiga CD32 is however an interesting machine for the demo coder ... ;)
Quote:
- Why are C64 demos more interesting than Amiga ones since 15 years ?
I think you'll find that Amiga was a more interesting platform up until 2009 or something, when the C64 started getting more releases again.
There are several different reasons why different platforms suffer dips in releases.
One is timing: The C64 dudes had made careers and powered through the first hard years of raising toddlers and all of a sudden they started having more free time on their hands. The Amiga 500 scene is a few years younger, and the A1200 scene younger still. Personally, I think the A500 scene has been gaining momentum since, oh, 2012?
Then it's platform diversity: A C64 is a C64. The only major difference is in the SID chip version. When nostalgia/creativity strikes, joning a C64 crew or bringing one together is relatively easy: everyone's got the same computer and the same frame of reference.
Amiga is split into a plethora of different models and hardware configurations, ranging from the "standard" (half meg expanded) A500 to PPC, and everything inbetween. Someone's view of Amiga demo creation might be banging the metal on an old Kickstart 1.2 machine while someone else thinks of using Photoshop-style graphics software on a Cybervision 64 card.
The third is sentimentality. The Amiga was a "middle computer" for a lot of people on their way from the C64 to the PC. When going back to their roots, a lot of people who were active on the Amiga scene back in the 90s realize that their first love was the C64, which means that's the machine of choice for their current scene activities.
@ AlienTech
Yeah sure it's slower but as a 'bonus' chip compared to a stock A1200 it helps, btw these tests were on ADoom and Doomattack, I can confirm I did a test disc on a CD32, gives upto 6fps instead of 4fps using Akiko c2p of course in practicality it's useless to help much but the point of a 50% speed up against still stands.
Your last comment is intriguing, do you have anything planned along the lines of something for the CD32?
Quote:
To my knowledge the Akiko custom chip is pretty useless for c2p (chunky to planar conversion) due to the fact it is not a DMA chip (!).
So the coder basically has to write chunky data in its registers to read then planar converted data back and at last finally has to write them to chip ram.
Very slow process compared to other techniques.
Yeah sure it's slower but as a 'bonus' chip compared to a stock A1200 it helps, btw these tests were on ADoom and Doomattack, I can confirm I did a test disc on a CD32, gives upto 6fps instead of 4fps using Akiko c2p of course in practicality it's useless to help much but the point of a 50% speed up against still stands.
Your last comment is intriguing, do you have anything planned along the lines of something for the CD32?
Quote:
Most likely because in my setup the audio interrupt interrupts the vblank interrupt making the stuff in the vblank interrupt not getting set on time before the frame starts.
If you play your audio with period 124, there are exactly (i.e. close enough) 573 samples per (long!) frame. Thus, you can feed your audio buffer in the vblank interrupt, so you don't need an audio interrupt.
heheh thanks! I will try with vblank interrupt and period 124 and audio buffer 573. In my 4ks I start sound in the audio buffer, but then the buffer size is 65536. I never really heard the glitch, but maybe if I tried to make a tune without too much happening on the first beat it would be very noticeable.
If I don't have interlace enabled, are all frames long? If it improves accuracy I could alternate between different buffer sizes or periods perhaps
If I don't have interlace enabled, are all frames long? If it improves accuracy I could alternate between different buffer sizes or periods perhaps
hang. I meant to say "I start audio in the blank interrupt" above. Not "I start sound in the audio buffer" :)
About having glitches with double/triple buffer set from vblank:
As I understand, vblank interupts starts at the end of the frame, not on top, and I could have glitches If I switched my copperlist too soon in cop1lc at the begining of vblank: It could be activated "after or before" the coming top of frame in that case. So I do a bit of computation at the begining of vblank (like recomputing parralax scrolls values ), then I set cop1lc, which is then activated on top of next frame... no cop1jmp because It is useless, and trash the blitter write pointer (known hardware bug).... there must be a thread about it on ADA.
As I understand, vblank interupts starts at the end of the frame, not on top, and I could have glitches If I switched my copperlist too soon in cop1lc at the begining of vblank: It could be activated "after or before" the coming top of frame in that case. So I do a bit of computation at the begining of vblank (like recomputing parralax scrolls values ), then I set cop1lc, which is then activated on top of next frame... no cop1jmp because It is useless, and trash the blitter write pointer (known hardware bug).... there must be a thread about it on ADA.
@amigajay
Yes and no :)
No in the sense that I am more an OCS coder.
Yes in the sense that I do believe the Amiga CD32 has very interesting specs for demos. I would personally develope a tech demo exploiting for example the cd and the full motion video expansion module (rather than the Akiko chip), combined with the AGA chipset of course.
How you would design a dedicated demo for the machine? In case you can contact me by email ... .
By the way congrats for your collection of demos for the Amiga CD32!
Quote:
Your last comment is intriguing, do you have anything planned along the lines of something for the CD32?
Yes and no :)
No in the sense that I am more an OCS coder.
Yes in the sense that I do believe the Amiga CD32 has very interesting specs for demos. I would personally develope a tech demo exploiting for example the cd and the full motion video expansion module (rather than the Akiko chip), combined with the AGA chipset of course.
How you would design a dedicated demo for the machine? In case you can contact me by email ... .
By the way congrats for your collection of demos for the Amiga CD32!
Quote:
Quote:- Where is the AGA equivalent of "darkroom" ?
For me it's Pygmy's G-Force, although it requires fast ram & is less aesthetically pleasing. Your mileage may vary.
tbh, G-Force can run on ECS as well, and I think there's an OCS version, too. Works great on my A600/020 at least.
Quote:
If I don't have interlace enabled, are all frames long? If it improves accuracy I could alternate between different buffer sizes or periods perhaps
Better be on the safe side and set bit 15 of DFF02A. If your demo is started from an interlaced screen, you have 50/50 chance of getting long or short frames otherwise.
Buffer size 573 is accurate enough (it drifts about 1ms per minute). But you might want to alternate appropriately between 572 and 576 in order to write only longwords to the audio buffer.
Quote:
Quote:A500, where even executing instructions is hampered by DMA traffic
I think it's not hampered if you stick to 4 bitplanes, but that sucks yes.
Well, that's just the bitplanes. The CPU still must fight with the blitter and copper for DMA slots. Luckily, the copper always wins. ;)
I see a lot that i could weigh in on, but I honestly have neither the time nor the inclination, but there was one comment made that prompted me to offer this little tip:
I might recommend a comination GIMP and PersonalPaint for better results.
It might be a bit more involved, but once you have a nice work flow it should be far easier too.
Quote:
Use photoshop and downconvert graphics to 8-bit to save time.
I might recommend a comination GIMP and PersonalPaint for better results.
It might be a bit more involved, but once you have a nice work flow it should be far easier too.
I am actually using Gimp and Blender. That's part of the reason why there is almost no graphics or 3d in the two last demos we made. Also I'm sometimes using Vim for editing code for ultimate self torment. I'm thinking that if I stick to them I will get used to them though. Obviously they have some powerful features.
On Amiga I'm using Brilliance for some retouching and creating organized palettes. Also using ImageFX for converting 24-bit to HAM8. I made a converter in the demo too that loads ppm and convert to HAM8, but it's dead slow and not as nice quality as when using ImageFx's algorithm.
On Amiga I'm using Brilliance for some retouching and creating organized palettes. Also using ImageFX for converting 24-bit to HAM8. I made a converter in the demo too that loads ppm and convert to HAM8, but it's dead slow and not as nice quality as when using ImageFx's algorithm.
Quote:
I am actually using Gimp and Blender.
Traitor. :)
