I know, I implemented something like this this once and it was indeed a major headache. Setting up the palette meant sprite colours ended up all messed up as a result and the whole thing ended up being complicated to use and maintain.

Must have drawn diagrams on how it should work at least a dozen times before I got it right!

Not to mention that blitting that extra bitplane in the correct place turned out to be surprisingly fiddly for something that should be the easy part of the whole thing.

^^^ THIS ^^^
Completely Concur - An absolute nightmare to implement with marginal gains in time.

I've written a 'method 2 like' for OCS on late '80 and the collateral effects (and limited planes usable) were so heavy that I never used it.

So opted for [odd/even scroll=same] and blit (method1) or better, if possible, DPF.

But sure a way to use it can be found, especially on AGA.

Well, on the multiplexer, basically:

step 1) you create a y-sorted list of all objects
step 2) you generate a dynamic copperlist where you write all that stuff into

I have to admit, coding the sorted list in asm almost ended up in me pulling my hair out.

Step 2 wasn't that hard then anymore, though.


If you have any further questions, feel free to ask.. :)

Did you do any X axis multiplexing?

No, since coding that that would be a whole other magnitude of pain (a.k.a. the "GOING SUPER GOLLUM" :D) and wasn't necessary for my engine.

I used the sprites only in addition to my BOBs, and for certain enemy formations which didn't need more than 2 in any line.

I have done horizontal multiplexing of sprite channels on my sprite background, but that's a static list.

Tackling an engine like that might be a nice project in the future, but at the moment I want to concentrate to finish my game, and as it is there is enough other stuff left to do at the moment... ;)

Well Geezer, you've 32bit sprites so the only possibility for x multiplex is for some background (with static list)
[SPRDAT is CPU/Copper usable only on 1x sprite fetch mode].

Or you have the same object pattern on the very same line?

Yeah if you think about rygar, enemies in the mid and low zones repeat across the x axis quite alot so i was thinking about trying repeating sprites with 1 channel.

Not wanting to dissuade you here, but that might difficult to pull of in a useful way :(

Not only do these sprites need to be on the exact same vertical position, but there can not any difference in image. Which means that they will all animate the same, even when you kill one and the other lives. This in turn means you need to dynamically choose sprites vs blitter use etc.

But it gets even worse :(

Even if you manage to fix all that, reusing sprites like this will probably need a dynamic copperlist which updates as you go along to keep all sprites in the right places. To be honest, I considered stuff like this and concluded that it's best to not try to move the copperlists entries around much if at all.

I'm not saying it's definitely not possible, but I see some real challenges on the road to freely relocated sprites using the copperlist I'm afraid.

Dont worry, i’m sticking with what i have.

I need to get a silly bob bug fixed tonight and thrn onto collision detection.

untested pseudo code:

Errrr... yeah sorta looks right for method 1

My actual code for method 2 palette is below.

What would you say if I said I was seriously considering making a YM card and I'd love this to be the first game to support it?

I dont know, if you like if someone will be try to optimised your code, but this code:
lsr.b #6,d2 ; Move bit 7 into bit position 1
and.b #1,d2
lsl.b #4,d2 ; then shift it up to bit position 4
can be replaced by and.b and lsr.b only, you dont need to use first shift. Same for d1 register. 2 instructions left x 256 times.

Sorry I don't know what one of those is? Happy to look into it though.

The code is only ever called once so isn't time critical. I never went back to optimise it so that's why it is like it is.

Another quick update here.

Last night I worked on fixing some things up like the background scrolling and doing bits of optimsations here and there.

This morning I've worked on integrating the hardware sprite animations.

Doing this has resulted in me losing a sprite or two though so I need to optimise some more.

There are factors in the scrolling which although look correct are not really doing what they are supposed to be, this is causing me to blit more words into the background than I should be... so I'm looking into it.

Another thing I plan on doing is some sort of blitter queue system so I can do all the blits in one go, this will hopefully enable me to mutli-thread the CPU to do other things.... all trial and error really.

https://youtu.be/CLXVCvcCxek

@mcgeezer

Have you decided against using copper skies? Personally, I think they were beautiful.

Looks mighty fine... :)

No, they're going back in. It is just I had to remove the temporarilly due to the sprite multiplexing. They'll be going back soon.

Cheers buddy. Give me a shout if you need a hand with anything (your game entry) and I'll be happy to take a look and help if I can.

I know I'm pedantic with my videos but here's another one and it's a good milestone as I fixed lots of performance bugs... 20 animated sprites scrolling through all levels!!!!!

I even added a bit Lazerhawk for you to enjoy on the journey.

https://youtu.be/-mdwiljTY-A

PS. Why Youtube does a shit encoding job on my videos I will never know.