Sprite priority on display.

[Shatterhand]

When using slices, you can use InFront (also InfrontB and InfrontF for Dual Playfied slices) to determine if sprites will be drawn on front or behind the bitmap.

I couldn't find how to do it with the Display library. When I try to use it, I get a "no currently used object" .

Is there any way to do this with the Display library, or am I doing something completely wrong here?

[Daedalus]

I haven't worked in that depth (pardon the pun) with the Display library; however the developer documents have information on priorities so it should be possible to do it "manually", i.e. by poking the playfield priority register (BPLCON2, $DFF104). I don't know if there's more to it, but that's worth a shot anyway.

Setting the playfield priorities (from the Amiga hardware reference manual).

[Shatterhand]

From what I understand of that link, I should set all bits of the BLPCON2 register to 0 to have both playfields to have priority over the sprites

I found out there's a command to alter the BLPCON2 (also BLPCON3 and BLPCON4) values.

DisplayControls CopList#, BPLCON2, BPLCON3, BPL CON4

You have to set the value of all 3 registers everytime you use this command. As Blitz manual says the default value of BLPCON3 is $C00 and BLPCON4 is $11. So, to test the command, I tried this:


DisplayControls 0,$00,$c00,$11

and nothing happened, sprites were still over both playfields.

I tried a random value to see if the command just wasn't working or if the value I input was wrong, so I tried

DisplayControls 0,$1234,$c00,$11

and then I get the sprites in front of the back playfield but behind the front playfield -exactly what I wanted , which is kinda funny.

I'll do more testing messing with this register, since it's clear I understood something wrong here, but at least I got my code to do what I wanted it to do by pure dumb luck. I hope I didn't mess anything else.

[Daedalus]

Ah yes, I remember that command now, good stuff. So long as you don't mess with the values in the other registers you should be fine, just remember it's a 16-bit word so don't write anything over $FFFF to it. BPLCON2 only controls the priorities of the fields and sprites so unless there's some other undocumented use of the remaining bits you shouldn't affect anything else.

As for the values, my interpretation is that you should write binary %00100000, since you need to set playfield 2 behind the sprites (which is %100 in table 7-2). Looks like you got lucky But try out setting bit 5 ($0020) to see if that works.

[Shatterhand]

Yeah, at first I just wanted to test the command, and putting all sprites behind both playfields would show me it was working.

DisplayControls 0,$0020,$c00,$11 gives all sprites in front of both playfields........

[Daedalus]

Hmmm... Looks like I'm misinterpreting things too then. Now that I think of it, maybe bit 6 needs to be set too. I took it that setting playfield 2 priority to 0 put it at the back, but if it puts it at the front, that would explain the sprites being in front too...

Try $0060 instead (bits 5 and 6 set). That might put playfield 1 in front, letting playfield 2 have the sprites in front of it but all behind playfield 1.

[Shatterhand]

Didn't work.

I need to leave now, so I can't do further tests for now (Later I'll tinker a little bit more with this), but it looks like that documentation is listing the priority inverted.

the $1234 worked because all I need to make it work is $0004, which is 100 for bits 0-2. The documentation states this would make the Playfield1 have less priority than all sprites, but it seems to be doing exactly the opposite. With $0004 it worked as I wanted.

I think bit 6 will not do nothing on blitz, since the command Displaybitmap will tell which bitmap will be drawn on front and which one will be drawn on back. Maybe this will go over any set you try to do manually.

[Daedalus]

Hmmm, maybe the documentation is indeed reversed then. Not the first time that's happened... But, as you say, it could also be that bit 6 is being overridden by Blitz. Good investigation work!

[Shatterhand]

Thank you for reminding me the words "Reversed" and "Overridden" in english

[Havie]

Found this thread as I'm trying to make sprites go behind bobs but whatever value I put into Displaycontrols makes no difference.

Before you ask, I am using the Display library and I got the same error you did using InFront. I am multiplexing the sprites but this shouldn't make any difference (I think). I had basically gone thorough the process in this thread before I found it but I don't get what the Hardware manual means about using a single bitplane:

Be careful:
-----------
PF2P2 - PF2P0, bits 5-3, are the priority bits for normal (non-dual)
playfields.

But doesn't explain...help!!!

[Shatterhand]

Originally Posted by Havie

Found this thread as I'm trying to make sprites go behind bobs but whatever value I put into Displaycontrols makes no difference.

Before you ask, I am using the Display library and I got the same error you did using InFront. I am multiplexing the sprites but this shouldn't make any difference (I think). I had basically gone thorough the process in this thread before I found it but I don't get what the Hardware manual means about using a single bitplane:

Be careful:
-----------
PF2P2 - PF2P0, bits 5-3, are the priority bits for normal (non-dual)
playfields.

But doesn't explain...help!!!

How are you multiplexing the sprites with Blitz?

[Havie]

I found vsprites a few years back and have a working Doodle Jump game which I originally made with bobs (for the platforms) but was worried that it would be too slow so have made platforms bu using vsprites. Currently have around 20 sprites on screen but could have (and will have a few more). Perfect game for this as only one sprite on a line and big gaps between sprites,

Little Hav pointed out that Doodle jumps behind platforms hence my need to change sprite priority...

Problem with vsprites is there are no instructions so everything has to be gleaned from the two (very similar) examples.

[Shatterhand]

Oh my god. What is "Vsprites"?

In one hand, I think it could be the issue in this case ?

In the other hand, I would *love* to have a way to multiplex sprites in blitz without resourcing to write asm.

[Havie]

Originally Posted by Shatterhand

Oh my god. What is "Vsprites"?

In one hand, I think it could be the issue in this case ?

In the other hand, I would *love* to have a way to multiplex sprites in blitz without resourcing to write asm.

I didn't realise I was the only one who had found this code. I guess you would like access - will upload it to the zone when I get a mo...and start a new thread.

Also, although I couldn't get the priority working, I had a moment of clarity and doodle is now sprite too. Currently have 1 sprite doing all the platforms and 1 sprite for doodle. Still have 6 left - what an embarrassment of riches! Could this be the first Amiga game made entirely from sprites? Will upload a beta soon for testing on 500/600 as I currently have a 1200 030 as my main machine and I am aim for the game to be fast and smooth on a 500. I know you can use WinUAE (I do for programming) but don't trust it compared to real hardware.

The biggest issue is palette as sprites need a bit of planning and last time I tried loading palettes into palettes I couldn't get it to work so I copied the colours manually in to PPaint.

[Shatterhand]

By the way, I actually made it work. This thread was created while I was coding my first Amiga game, Quasarius.

But I remember the documentation actually listed the bits in reverse order. You just have to be careful because DisplayControls also mess with the AGA Palette. After I released my game I discovered the colors were all wrong on AGA machines because of this.

I just checked the code of that game, and indeed what's there is:

DisplayControls 0,$0004,$c00,$00

this worked for me using Dual Playfield, having sprites between playfields. I don't know if that's what you need though.

But yeah, I would love to see this "Vsprite" thing. Being able to properly multiplex sprites would be insanely useful for me

[Daedalus]

Hmmm, this reminds me, I also figured out the proper way to use DisplayControls back then when I was working on a Blitz tutorial. I'll have to check my code again, but I think it was something like the values being XOR'ed, meaning you needed to pre-XOR the values for them to match the table given.

There's a method for reusing the sprites further down the screen if that's any good to you? That gives you sprites 8-15, so doubles the number of sprites you can use, but the vertical area is limited and can't overlap the vertical area used by sprites 0-7.

[Havie]

In The Zone now!

Tried your suggestion already but made no difference - don't understand why as these are genuine sprites???

[Daedalus]

Just checked my code, and what I do is XOR the desired values with the defaults, then apply them with DisplayControls. Note that this is only for BPLCON2 and BPLCON4 - strangely BPLCON3 doesn't need it.

[Havie]

Originally Posted by Daedalus

Just checked my code, and what I do is XOR the desired values with the defaults, then apply them with DisplayControls. Note that this is only for BPLCON2 and BPLCON4 - strangely BPLCON3 doesn't need it.

Could you show me this in code as I don't understand what you mean...sorry, being a bit thick.

[Shatterhand]

BitMap 3,320,16,1
InitCopList 0,30,250,$36,8,32,-1
InitCopList 1,283,8,$01,8,2,-1
DisplayControls 0,$0004,$c00,$00
CreateDisplay 0,1

It's just this really. Nothing else.

But keep in mind I was working with DUAL PLAYFIELD and this made sprites go BETWEEN playfields, not all way to back.

There's a method for reusing the sprites further down the screen if that's any good to you? That gives you sprites 8-15, so doubles the number of sprites you can use, but the vertical area is limited and can't overlap the vertical area used by sprites 0-7.

Used this method in both Roadtrip in Santa Chaos. Still very limited.