A.D.A. Amiga Demoscene Archive

I see most (all?) demos seem to dump the OS right away without hesitation. When targeting machines with 68060's, it doesn't seem like the OS would really take much CPU time away from the demo, so is there another reason for dumping the OS besides a tiny bit of extra horsepower?

I guess it depends on what you know already (and laziness). If you don't kill the OS you'd need to code everything in a system friendly way. If you're used to banging the hardware directly then it's easier to just kill the OS and do your usual stuff.

Some demos are system friendly with support for RTG and/or AHI.

I used to have a quite system friendly setup with RTG/Cybergraphics support, double buffering and all handled by the system calls. Amiga-M would work and everything. In there everything was done using chunky to planar though and this essentially mean you become locked to less than or equal to 25 fps for all effects. I wanted to mess around with bitplanes, copper and sprites and have a chance at > 25 fps effects so I needed something new.

I had a go at creating a completely system friendly demo which still uses some hardware such as copper/sprites when doing Neonsky. I figured that with 060 the system overhead would not cause any serious problems.

I found the system is hogging sprite 0 for the mouse pointer at all times. You can still use it, but whenever the user moves the mouse, sprite 0 will also move no matter what you were using it for.

Building dynamic copper lists using the system API was really sluggish too so I ended up with poking some pointers in some system struct somewhere to make it use my own copper list behind the scenes. It didn't feel like it was the correct way to do things.

I felt I spent more time on trying to figure out system's display inner workings instead of coding effects so I dropped the system for any display tasks. Still I'm keeping it up so it can be used for harddrive loading etc.

Haha. Well, based on hacking around, going through the OS is often a lot more work than hitting the registers.


Did you ever exceed this?


So for fast C2P and other display hacks (and especially if you want all sprites) then that part of the OS has to go. But it's convenient for IO (which makes sense).

Thanks a lot for the insights.

"Did you ever exceed this?"

In some of the new demos Neonsky, Negative Process and Hexel there are a few fullscreen effects which are more than 25 fps. Note that they don't use c2p!

-- rant mode on --

Our first demo system was assuming all effects would be CPU only and have an 8 bitplane 320x192 c2p conversion before display. I could basically never have >25fps because the c2p would always spend 1 whole frame just doing the conversion.

In this setup, even I just wanted to scroll a logo across the screen or move an overlay around, it would not be smooth because it couldn't make use of hardware scrolling or sprites. After changing my demo system to allow use of custom chips I could get >25fps for effects not requiring c2p.

I lost the RTG support in the process though. As RTG/Custom chip effects don't mix all that well. Still for me the "Real" Amiga is A1200 with 060 so I don't have any great motivation for doing anything on a more powerful platform :) (just like people who grew up with OCS don't really care for AGA even).

-- c2p hacks --

I'm using Kalms' c2p routine which is really good. Still there might be others that are faster?

I believe Skarla (and Haujobb?) is doing some special trick where the c2p is happening while the DMA is off (in the top and bottom parts of the letterboxed screen). The reason is that while the DMA is off the copy speed to chip ram should be faster than normally. This trick may only work on certain fast CPUs such as 060. At least the bottleneck in the c2p needs to be the copy to chip RAM. And the c2p needs to finish in this interval.

With this setup, perhaps > 25fps effects are possible? I don't know

HAM6 C2P only needs 4 bit planes and on AGA could provide lores true colour C2P in only hires modes with only a slight loss of quality. That means only doing a couple of merges and should amount to something like four cycles per pixel.