Bob manager

[tehKaiN]

Description

Adds manager for blitter objects, a common functionality found in almost every game. Closes #46.

Motivation and Context

Managing movable and blittable objects by typical ACE's blitter functions is horribly slow and suboptimal - this manager allows to do it more efficiently.

ACE inclusion self-assessment

Are there significantly different solutions to same problem? If so, is it the most common/generic one?

It can be copper-driven or interrupt-driven queue-based, but this one is the most typical approach.

Are other solutions better and should ACE incorporate it instead of this change in the long run?

Other implementations can't be dropped into any codebase. Copper-driven approach could heavily conflict with raw-mode copperlists (e.g. one from scrollbuffer). Interrupt-driven could use code of this implementation, if needed, but it takes performance hit from interrupt-handling overhead.

Is given functionality needed or nice to have for most of games? Is it used often in tandem with ACE?

Yes. All my games use it. Almost all of Amiga games use bobs.

Is it small/simple enough to not require much maintenance?

Not that small and simple, but quite decoupled - even has its own blitter code.

Is the functionality related to a core Amiga concept?

Yes, blittable objects, or bobs.

Is it entirely, or its ACE interface, written by core ACE team or frequent contributors?

Yes.

Is it a building block or dependency for other parts of code? How much coupling there is between this part and rest of ACE code?

Almost no coupling - only memory allocation etc. I don't see scenario of other ACE things depending on it, unless it's going to be interrupt-driven expansion of the system (perhaps done within the component itself) or some high-level generic part of ACE.

Does it allow making significantly better games at reasonable performance cost?

Yes. Way better bobs with better performance.

Is most of the code first-party?

All of it.

Does it require additions/changes/removal of some other parts of ACE functionality/tooling for its use?

No.

How Has This Been Tested?

Tested across different LMC games:

• Germz
• Chaos Arena
• Aminer (WIP)
• OpenFire (WIP)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [x] My code follows the code style of this project.
• [ ] My change requires a change to existing documentation.
• [x] My change requires a new chapter in documentation's tutorial.
• [ ] I have updated the documentation accordingly.

I'll add docs when I get to the relevant chapter.

[Vairn]

Tested and working with the AGA ACE Branch. Just make sure you mention that it needs to be used with an INTERLEAVED bitmap for the front and back buffers.