10 January 2017, 05:28 | #1 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Sprite priority on display.
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? |
10 January 2017, 12:31 | #2 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,351
|
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). |
10 January 2017, 14:52 | #3 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
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. |
10 January 2017, 15:17 | #4 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,351
|
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. |
10 January 2017, 15:28 | #5 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
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........ |
10 January 2017, 16:00 | #6 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,351
|
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. |
10 January 2017, 16:23 | #7 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
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. |
10 January 2017, 16:27 | #8 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,351
|
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!
|
10 January 2017, 16:44 | #9 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Thank you for reminding me the words "Reversed" and "Overridden" in english
|
21 August 2019, 23:07 | #10 |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,895
|
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!!! |
21 August 2019, 23:13 | #11 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
|
|
22 August 2019, 00:13 | #12 |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,895
|
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. Last edited by Havie; 01 September 2019 at 10:38. |
22 August 2019, 00:25 | #13 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
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. |
22 August 2019, 15:10 | #14 | |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,895
|
Quote:
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. |
|
22 August 2019, 16:09 | #15 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
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 |
22 August 2019, 17:24 | #16 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,351
|
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. |
22 August 2019, 17:25 | #17 |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,895
|
In The Zone now!
Tried your suggestion already but made no difference - don't understand why as these are genuine sprites??? |
22 August 2019, 20:11 | #18 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,351
|
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.
|
22 August 2019, 23:03 | #19 |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,895
|
Could you show me this in code as I don't understand what you mean...sorry, being a bit thick.
|
23 August 2019, 02:22 | #20 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Code:
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 But keep in mind I was working with DUAL PLAYFIELD and this made sprites go BETWEEN playfields, not all way to back. Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Changing sprite images in long display lists | phx | Coders. Asm / Hardware | 2 | 12 March 2016 20:13 |
MagicMenu Task Priority | NovaCoder | support.Apps | 2 | 10 February 2013 10:42 |
More settings in priority panel | Thom87 | request.UAE Wishlist | 2 | 24 January 2008 15:23 |
priority resets after reset | jrom | support.WinUAE | 0 | 10 April 2004 16:05 |
|
|