but got a bit hung up this morning on where SCRBUF was coming from.
I guess it's a RAPTOR constant ?
It is for the "text layer" or "particle buffer layer" - GGN is assuming you're using this 4-bit object for your background platforms/level layout. If you're not you simply have to grab the address of the source gfx data (that pointed to by your backdrop object) and adjust your calculations when peeking to suit bitdepth.
It also hadn't clicked that each item in the OP is a layer in it's own right - and that makes things easier to understand.
If you wish to think of it that way and it helps, sure. The display on screen is produced a line at a time effectively as a collage, or rather a series of thin collage slices. As I said above, design your game using the features that raptor makes easy for you and everything becomes easier. You can use CD 1 vs 1, 1 vs many, many vs many. It's very simple, clean and efficient as the GPU takes care of it for you.
Does the size of the graphic in the OP affect the performance or is it just number of items in the OP that causes slow down ?
Consider how the screen is produced. For every line of the display, the OL is traversed and the image built up for all objects that appear in that line*. Ideally you will want to limit this number where possible. Object height obviously impacts as well as a taller object will appear in more lines. Your plan to have a single background image for the whole level layout obviously saves heaps of bandwidth here but with the added complexity of hand-coded CD.
IMO, when it comes to a game like Manic Miner, people might expect pixel-perfect collision detection if they're used to experiencing that in previous games. Bounding box might either feel a bit unfair or too cheap when the player sprite animates and phantom collisions are seen or toes poke through platforms etc.
*You can use branch objects for OL efficiencies, but that's something you might only want to bother with towards the end of a project if there's a fine line between a locked framerate or the OP shitting the bed.
EDIT: If I were making a game of this type, I'd definitely stick with doing everything object-based. Clearly having a screen full of speccy-like 8x8 objects would be unrealistic - the OP would go into meltdown. But with some clever object design, use of much more chunky, larger but still reusable lumps of platform, there would be a happy compromise between simplicity of coding, object count and level design. Pixel-perfect collision detection would still be a challenge and it might be that I'd have to have to adjust the hitbox per frame to suit the gfx (but more sensibly, just design the graphics and animation in a way that bounding box works well).
Edited by sh3-rg, Wed May 10, 2017 5:45 AM.