Best way to mix blitting with copper and copper effects

[roondar]

I've been tempted lately (http://eab.abime.net/showthread.php?t=83043) to adapt my blitter routines to start the blitter using the copper instead of using the CPU.

But I'm running into a problem to solve and I'm wondering how other people deal with this. I've tried searching the forums and google, but can't seem to find any real information on it.

The problem is mixing copper effects (which usually need to be done at an exact beam position) and blitter waits using the copper (which could end at differing beam positions depending on DMA bus utilisation).

There are basically four main issues here and I've not solved them yet:

1. Playing modules usually means using a CIA interrupt, which can happen anywhere during a frame (seems to me this stops blitter nasty from being usefull, unless module players don't care about latencies that could end up being a dozen scanlines or more)
2. Even without interrupts, CPU usage will vary from frame to frame anyway - which makes predicting how long a blit lasts harder (unless you use blitter nasty mode, which in my experience tends to slow down things if the CPU is still doing useful work)
3. Waiting on the blitter could end up taking so much time a copper effect gets pushed 'down'. This is generally not really acceptable.
4. Some copper effects might have varying positions from frame to frame, which blitter waits have to take into account.

Now, I have not made any actual code yet (because I'm not sure how to fix the above and I'd like to have at least a basic idea before I get started). So my question is mainly: is there a 'best practice' for these kind of problems and are there any pointers anyone can give me to start tackling this?


I'd be grateful for any help here

Edit: the idea would be to use this technique on a basic OCS system, so no AGA or fastmem

Edit 2:
I've been thinking a bit and am now considering a copper list that's somewhat like this:

<set up blit 1>
WAIT blitter_finished
<set up blit 2>
WAIT blitter_finished
<set up blit 3>
SKIP VHPOS = effect_VHPOS-copper_skip_time-copper_wait_time
WAIT blitter_finished
WAIT VHPOS = effect
<effect>
<set up blit 4>
WAIT blitter_finished
<set up blit 5>
SKIP VHPOS = next_effect_VHPOS-copper_skip_time-copper_wait_time
WAIT blitter_finished
WAIT VHPOS = next_effect
<next_effect>
etc..

The idea being that the SKIP instruction can be used to allow the copper to execute the effect on time. However, this will only work if the blits running prior to the last blit running before an effect are never going to be delayed so much that the effect should've already happened.

I wonder if this is a viable approach?

[Lazycow]

Hi roondar,

you want to have the fastest blitter access while maintaining the highest flexibility. I don't think this is possible.

Either you want to have some super-effect on the Amiga, then you can try to finetune the copper, the blitter, the CPU and everything. But then the system is optimized to this effect and you lose your flexibility.

Or you want to have dynamic actions on the Amiga, then you can use the copper, the blitter, the CPU and everything dynamicly. But you have to isolate them to maintain the flexibility, which effectively preludes the use of dependant optimisations.

My hint for you is: Don't focus too much on optimizing the last cycles at blitter and copper control. Usually, the biggest potential for optimisations is located at the hligher levels of the algorithm.

[Samurai_Crow]

Agreed. Remember that Graphics.library uses an interrupt to queue the blitter. If you want to bang the blitter hardware and use the same interrupt, use QBlit.

[roondar]

I'm slowly comming round to that idea as well. I do tend to get a bit 'obsessed' with micro-optimisations, which is not always usefull.

Thanks for the advice.

As is, I've more or less decided to drop the copper blitting idea for now and I may or may not change my simple blitter code for an interrupt based approach instead (not for performance, but for easy of use and a personal preference to do so).