ALL PRIORITY MODES

[José Pereira]

Hello.

 

We put priority in bit 0 to 3 of 623.

Soo, it's 1,2,4,8

 

But, as a 4bit- 0000 to 1111, you'll get 16 different numbers.

 

0000 - The Stuff of the 23 colours.

0001 - Priority1

0010 - 2

0100 - 4

1000 - 8

 

But the other ones, different combinations, diffrent decimal numbers.

0011, 0101, 0110,00111, 1001, 1010, 1011, 1100, 1101, 1110, 1111.

 

Someone knows how this will work on real machine, if we put this values into poke 623,...

 

Thanks,

José Pereira.

[Tezz]

From mapping the Atari....

 

623 26F GPRIOR

 

Priority selection register, shadow for 53275 ($D01B). Priority

options select which screen objects will be "in front" of others. It

also enables you to use all four missiles as a fifth player and

allows certain overlapping players to have different colors in the

areas of overlap. You add your options up as in location 559,

prior to POKEing the total into 623. In this case, choose only one

of the four priorities stated at the beginning. BAK is the

background or border. You can also use this location to select

one of GTIA GRAPHICS modes nine, ten, or eleven.

 

Priority options in order Decimal Bit

Player 0 - 3, playfield 0 - 3, BAK

(background) 1 0

Player 0 - 1, playfield 0 - 3, player 2 - 3,

BAK 2 1

Playfield 0 - 3, player 0 - 3, BAK 4 2

Playfield 0 - 1, player 0 - 3, playfield 2 -3,

BAK 8 3

Other options

Four missiles = fifth player 16 4

Overlaps of players have 3rd color 32 5

GRAPHICS 9 (GTIA mode) 64 6

GRAPHICS 10 (GTIA mode) 128 7

GRAPHICS 11 (GTIA mode) 192 6, 7

 

It is quite easy to set conflicting priorities for players and

playfields. In such a case, areas where both overlap when a

conflict occurs will turn black. The same happens if the overlap

option is not chosen.

With the color/overlap enable, you can get a multicolor player

by combining players. The Atari performs a logical OR to colors

of players 0/1 and 2/3 when they overlap. Only the 0/1, 2/3

combinations are allowed; you will not get a third color when

players 1 and 3 overlap, for example (you will get black instead).

If player one is pink and player 0 is blue, the overlap is green. If

you don't enable the overlap option, the area of overlap for all

players will be black.

In GTIA mode nine, you have 16 different luminances of the

same hue.

[Rybags]

To put it simply, don't use the other combinations except in rare cases where you might want a Priority conflict to get Black.

[snicklin]

I found out the other day not to use the different combinations, just have the 1 bit set. It's a bit inflexible isn't it? Oh well....

[atariksi]

I found out the other day not to use the different combinations, just have the 1 bit set. It's a bit inflexible isn't it? Oh well....

 

Or have 0 bits set (GPRIOR mode 0). In this mode, the priority is:

 

(Top) P0 <- P1 <- PF0 <- PF1 <- P2 <- P3 <- PF2 <- PF3 <- BAK

 

of course P0/P1 ORs with PF0/PF1 and P2/P3 ORs with PF2/PF3 colors.

[José Pereira]

Hello.

It's me again.

Thank all for your help.

Yes, I know all that of 1,2,4,8 and 0 priority numbers.

But I was wondering what I could get with the other possible numbers.

 

In what you are saying, something I don't understand.

 

This picture (Horrible I know, just trying to be fast):

 

NINJA -PM0 and his Weapon PM1 on Multicolour mode

Enemy - PM2 and his clothe PM3 " "

Simply Priority 1 (Over all PFs.+Backgr.)

 

If ninja have priority over Enemy then Ninja(PM0/1) and if Enemy has the priority, simply PM0/1 to Enemy and Ninja's change to PM2/3.

 

But here comes the questions, in the LN particular case the Players overlap eachother. So, will this have anything in the colours, when they overlap?

 

 

 

 

 

 

ANOTHER QUESTION:The other possible decimal numbers all give black on all overlap places conflict(in all, all, no other lost/masked trick)? But what you mean of conflict? Only between PMs overlap or also with PMs.+PFs?

[Rybags]

You can't get conflict with Players over Players, except Missiles if being used as 5th Player.

Player priorities among Player 0 to 3 are set and remain regardless... of course there's the multicolour Player option that causes mix rather than overlap but only with 0/1 and 2/3 pairs.

 

The definition "conflict" - easy. Just look at the table showing priority sequence and compare if you have multiple bit setting. If one says "PL2 and PL3 on top of Playfield" but the other bitsetting says that Playfield is on top of PL2/3, then you have conflict.

Edited September 11, 2009 by Rybags

[José Pereira]

Thanks Rybags. I'm getting it.

 

For example 0011. Decimal number 3.

Bit 0 - (1) All PMs above PFs - Priority 1

Bit 1 - (1) PM0/1 -» PFs. -» PM2/3 -» Backgr. - Priority 2

 

If I put this two I'll get PM0/1 with and without priority with PFs, so eachtime they overlap PFs. I get black colour.

If I understand this, and I think i did this will be on all priorities in this way.

 

I have one idea, I have it, and with just the traditional priority numbers, but with this, oh,... I think you make my day!!!!.....

 

I'm going to do some study.

 

Thanks. You're great.

And A8, even with this GPRIOR and conflicts are a real wonderfull machine. An unique one.

I always wanted to know who was the brain(s) for this unreal/out of this world computer machine? How can someone think this kind of things!...

 

Any other old or more recent computer or Video Game System as something like this Priors Conflicts, Overlaps...?

 

Bye now,

José Pereira.

[José Pereira]

Hello.

It's me again.

Thank all for your help.

Yes, I know all that of 1,2,4,8 and 0 priority numbers.

But I was wondering what I could get with the other possible numbers.

 

In what you are saying, something I don't understand.

 

This picture (Horrible I know, just trying to be fast):

 

NINJA -PM0 and his Weapon PM1 on Multicolour mode

Enemy - PM2 and his clothe PM3 " "

Simply Priority 1 (Over all PFs.+Backgr.)

 

If ninja have priority over Enemy then Ninja(PM0/1) and if Enemy has the priority, simply PM0/1 to Enemy and Ninja's change to PM2/3.

 

But here comes the questions, in the LN particular case the Players overlap eachother. So, will this have anything in the colours, when they overlap?

 

 

 

 

 

 

ANOTHER QUESTION:The other possible decimal numbers all give black on all overlap places conflict(in all, all, no other lost/masked trick)? But what you mean of conflict? Only between PMs overlap or also with PMs.+PFs?

 

 

 

 

 

 

I thinked and no, in LAST NINJA, I will get so many conflicts, but these thing of the CONFLICTS may be usefull on other games.

 

 

I'll return to my old way.

 

Now it's time to reveal it!... I said I discouver. I am wondering how this takes me months...

 

Just see these picture with the two uggly Players.

 

PM0/1 to Ninja body and Weapons

PM2/3 to Enemy body and clothe

Using Multicolour I get a third colour on Enemy(PM for Shoes and Eyes and 3rd colour for the clothe).

In Ninja PM as Black for Body and another PM for the Weapon. Here I don't get Multicolour (All colours with black give us this colours on overlap). I get Brown and Black for the Nunchakus, Brown for the Staff and White for the Sword.

 

Only one colour that is the same in all the game. Pf0 - Black. Use PF0 for Enemy Weapon.

Normally use Priority 1(All Players priority over PFs.)

Normally Ninja PM0/1 and Enemy PM2/3 When they overlap, if Enemy has priority change Ninja to PM2/3 and Enemy to PM0/1.

 

 

Because PF0 (Ninja Weapon) it's Black, when it overlap Ninja body, it will be under Ninja body, but you don't see, because it's the same colour as Ninja Body.

Carefully use of the position of Ninja Weapon when overlap Enemy weapon.

 

Weapons always under Bodys.

Better than C64, because Ninja different colours for weapons.

Better than C64 - 3 colours for Enemy (I can get that coloured Enemys in LN2/3). O.k., no Hi-Resol. Sprites, but here we don't have any choice.

 

 

Only something like ten twelve shapes for Ninja Weapon1 and 2(Nunchakus - only 3/4). Only two Software Sprites in all the game.

 

 

The other Enemys and moving objects are PMs. (See the C64 version, when the Dragon fires, the waterfall, the bird, The Magic Fountain, Objects to catch, you don't have Enemy on this screens, and on A8 you can have it, if you use DLIs and put them on another lines).

 

 

You may think that no possible, because I must have PMs. to colour thgings. O.K. Yes, and no!...

First the Enemys only appear in 50/60% of the total game screens, and here you can use Priority 2 (only Ninja above Pfs.).

But also on screens with Enemy if they are on diffrent lines.

Another thing, it's that I only have one colour that has to be the same for all the screens (PF0 - Black, because of the Enemy Weapons). I can say you that I have some screens by now, and all seen and know how and where I'll put DLIs. and PMs.

 

I also have done some redesign of the Status Area (Many colours on letters) and you'll see all the objects and Weapons coloured with their real colours.

 

 

 

But another great thing can become true.

I can get with the using of PMs and with Prioritys numbers simple change in concrete place and/or PMs. changing numbers the Ninja walking on the floor with or without Priority over the screen graphics.

Another simple trick it's if I use GPRIOR0, Ninja Body (Black), doesn't get Overlap (Black always loose), so simply put of GPRIOR0 let Ninja be cover by PF0/1 but will walk on the Grass (PF2), Over Trees PF3(Brown) and Backgr.(The walkway). Or if Ninja is PM2 it can walk Under all the objects (This only work untill the middle of the first Level, Because Ninja it's only 1PM, it's untill he catches his first Weapon).

Ninja can simply walk on all the screen. And what is really great here, is that you just have 2 Software Sprites, so more simple fast, where are the MASKS? No need. Just Software Sprites for Enemy 2 Weapons.

 

 

I've taken and almost all Ninja/Enemy/SKeletor/Ghost/Magic Fountain/BIrd/Waterfall by now.

Also all the weapons for the Control Panel.

 

Some minor problems with the Status Panels, but nothing impossible.

 

 

 

 

O.K.! I have one problem:

When Ninja goes Up you don't see the Eyes and Hands, but when he moves down you see them. The hands, they can be Black, like the Enemy It has the hands with the same colour as the Body), but the Eyes. But I have a solution. I Have the other Ninja Missile free (the ones from the Weapons), I can Put in on the Eyes. I'll get one problen, sometimes Brown, and other White. But it will not be many of a problem (The Eyes it's just one Pixel and only when Ninja moves down, you probably almost never see it). But if some good coder have the solution, it will be great.

 

 

As you all know, I'm not a programmer so I'll try to the screens, objects on this basics. If someone wants to helps, GREAT. If some coder want to do with me GREAT. If some has better ideas GREAT. But not the ones that I'm trying to do as I want. Or I cannot do this!...

 

 

I have get all of this. If no one will code it or give ideas, no problem. I'll do LN1/2/3 and even the version from the Soa's Editor. Even if this takes me years.

This idea I have, it's so simple that have nothing that cannot work. Memory it's not a problem. Cartridge release (HOW GREAT IT WAS), but even Multiload, no problem. The other one from Poland done the screens of one Level of LN2 (The Sewers) and they load in Emulator almost instantly (By the way, I've been there on Atarionline PROJECT "LAST NINJA" and I got all his stuff with "disabled" message).

 

 

 

Your Atarily,

JOSÉ AGOSTINHO LOPES PEREIRA GODINHO.

 

LAST NINJA

I'LL BE BACK WITH SOMETHING MORE!!!!!!!!!!!!...............................

[Bryan]

Here's something odd... If PRIOR is $18, then the stacking of these pixels:

 

a: 5th Player missile pixel (should be top)

b: PF0 pixel

c: Player 3 pixel (bottom)

 

is promoting PF0 to the top over Player 5. Player 3 is never visible because it is behind PF0 but when Player 3 is removed, Player 5 resumes its position on top. In other words, the priority of Player 5 is not completely fixed in all priorities. Now, to find a good use for this...

 

 

In the picture, PF0 is the blue box. The white stripe is a missile in 5PL mode. The missing dot is where P3 (the multi-color line) crosses beneath PF0.

Edited September 26, 2009 by Bryan

[PeteD]

That type of thing would be useful for what José is trying to do by plotting a copy of the foreground "shape" into P3 and drawing a "sprite" in Pm5. Of course you're still limited to the size it's of any use for. Does it work on all the playfields or just PF0?

 

 

Pete

[Bryan]

That type of thing would be useful for what José is trying to do by plotting a copy of the foreground "shape" into P3 and drawing a "sprite" in Pm5. Of course you're still limited to the size it's of any use for. Does it work on all the playfields or just PF0?

 

 

Pete

 

Here's a picture showing PF0,1, and 2 and all 4 players.

 

Only PRIOR mode $18 yields unexpected behavior, giving Player 5 a dual-priority at the top and bottom.

[José Pereira]

That type of thing would be useful for what José is trying to do by plotting a copy of the foreground "shape" into P3 and drawing a "sprite" in Pm5. Of course you're still limited to the size it's of any use for. Does it work on all the playfields or just PF0?

 

 

Pete

 

Here's a picture showing PF0,1, and 2 and all 4 players.

 

Only PRIOR mode $18 yields unexpected behavior, giving Player 5 a dual-priority at the top and bottom.

 

 

Hello all!

 

Bryan can you post here your program listing or the file?

You use an Emulator or a real machine?

 

First: You use Priority 2 with 5th Player enabled (2+16). And with this: P0/1-»5th Player-»All PFs-»P2/3-»Backgr.

Soo, how that 2PLs. are only on top of one PF. That two have to be P0/P1, right?

 

Second: Can you simply do the P0/P1/P2/P3 without DLIs. (Normal size, and just one P0, one P1 and soo on), please.

 

Third: You are using ANTIC mode 4 or E (Gr.12 or 7)?

 

Fourth: Not important, but try to use for example yellow, pink,... (different type of colours for each PLayer).

 

Something here doesn't fit. It is not only one bug (if it is a real bug!...), I count two bugs: when 5th PLayer overlap other Players in the Playfield and P0/P1 doesn't have priority with all the PFs.

 

 

P.S. - Another thing, that came to my mind in this momment: Do what you show here, but without PFs, just Pls. overlap 5th PLayer.

Have you try with other priority numbers?

 

 

Thanks for your attention.

Jose Pereira.

[José Pereira]

That type of thing would be useful for what José is trying to do by plotting a copy of the foreground "shape" into P3 and drawing a "sprite" in Pm5. Of course you're still limited to the size it's of any use for. Does it work on all the playfields or just PF0?

 

 

Pete

 

PeteD, can you explain better what you have in mind, try to use some easy English... How this can help me, for example, in all my Last Ninja thoughts and ideas?

 

Thanks.

Jose Pereira.

[PeteD]

José,

 

I doubt it's really as useful as I first thought for LN as you limited to the 1 Player (P5) so don't get much width coverage (any "sprite" you wanted to mask would have to fit in P5). The general idea was to put a single colour copy of the foreground (a tree for example) into P3. Using the bug as shown above in Bryan's pictures anywhere P3 was would mask P5 and let the PF data show through. Of course you'd have to move P3 and change its data all the time as well as the "sprite" moved around the screen, so making it even less useful.

 

 

 

Pete

[Bryan]

Hello all!

 

Bryan can you post here your program listing or the file?

You use an Emulator or a real machine?

The screen grab is from an emulator, but it does the same thing on real hardware. Unfortunately, I don't have time to test it further right now.

[PeteD]

I posted a snippet from the Altirra blog over in the Vs thread where the strange happenings he found with the priority logic hardware seem to follow exactly what you've found so it does seem to be a known thing in so far as it's "meant" to do it

 

 

Pete

[José Pereira]

That type of thing would be useful for what José is trying to do by plotting a copy of the foreground "shape" into P3 and drawing a "sprite" in Pm5. Of course you're still limited to the size it's of any use for. Does it work on all the playfields or just PF0?

 

 

Pete

 

Here's a picture showing PF0,1, and 2 and all 4 players.

 

Only PRIOR mode $18 yields unexpected behavior, giving Player 5 a dual-priority at the top and bottom.

 

 

I posted a snippet from the Altirra blog over in the Vs thread where the strange happenings he found with the priority logic hardware seem to follow exactly what you've found so it does seem to be a known thing in so far as it's "meant" to do it

 

 

Pete

 

 

I'm back with this one. As Pete says it's common and very well knowing.

 

Pete, I can't find this post you mention, even on the ALTIRRA Blog (maybe I'm blind).

Thanks.

Jose Pereira.

[PeteD]

Here it is again..

 

First, the error. It pertains to the fifth player, or P5 above. The fifth player is a mode enabled by PRIOR[4] where the four two-bit missiles take on the color of the seldom used playfield 3 instead of using the individual player colors, thus allowing you to move the missiles together to make a fifth 8-bit player. The way this is actually implemented in the priority logic is simply to OR the missiles into PF3 instead of P0-P3, which means that it acts just like PF3. This is the only way that more than one playfield signal can be set, and as it turns out, PF3 wins. The one case that matters is the PRIOR[3:0]=1000 mode, where the players split the playfield. This leads to the weird result that the fifth player is covered by players unless PF0 or PF1 is underneath, in which case P5 shows up on top. Weird.

 

 

And the link to the page so you can read it in context.. http://www.virtualdub.org/blog/pivot/entry.php?id=243

 

 

Pete

[José Pereira]

Here it is again..First, the error. It pertains to the fifth player, or P5 above. The fifth player is a mode enabled by PRIOR[4] where the four two-bit missiles take on the color of the seldom used playfield 3 instead of using the individual player colors, thus allowing you to move the missiles together to make a fifth 8-bit player. The way this is actually implemented in the priority logic is simply to OR the missiles into PF3 instead of P0-P3, which means that it acts just like PF3. This is the only way that more than one playfield signal can be set, and as it turns out, PF3 wins. The one case that matters is the PRIOR[3:0]=1000 mode, where the players split the playfield. This leads to the weird result that the fifth player is covered by players unless PF0 or PF1 is underneath, in which case P5 shows up on top. Weird.And the link to the page so you can read it in context.. http://www.virtualdub.org/blog/pivot/entry.php?id=243Pete

 

 

Hello. First, this of 5th Player on top of all PFs. it is not only on 1000, but in all Priority modes. If you put 5th Player above Backgr., when other Player Overlap it acts as PF3. But if it above a PF (not only PF0/1 but all PFs.) it will above Pfs.

 

That's why in GPRIOR1 PMs/PF0,1,2,3(5th player) if 5th Player it's above Any PF. the new GPRIOR1 it's Players->5thPlayer->All PFs.

And in GPRIOR2 PM0/1->All PF0,1,2,3(5th Player)->PM2/3 if 5th Player above any PF the new GPRIOR2 it's P0/1->All PFs->P2/3

In GPRIOR4: All PMs.->All PFs.->(5th Player) will be 5thPlayer->All PFs->P0/1/2/3

GPRIOR8: PF0/1->All PMs.->PF2/3->5th Player will be 5thPlayer->PF0/1->All Ps.->PF2/3

And finally in GPRIOR0:PM0/1 interacts with PF0/1->PF2/3 interacts with PM2/3 -> 5thPlayer will become like if 5thPl. overlaps any PF: P0/1->5thPl.->PF0/1->(PM2/3withPF2/3).

 

This last one will be usefull if you for example don't want that your P0/1 when overlapping PF0/1 don't get the 3rd colour you simply put the 5th Player on the Midlle.

 

 

(Another thing I discouver is that if one of your PF/PL. is BLACK colour than on the Multicoloured Sprites or in GPRIOR0 BLACK+Any other colour=Allways the other colour. In Ored colour Black colour always loose to the other one, and you'll never get a 3rd colour.

 

 

I Have notice this sometime ago, as you can see in this text I take from the book "ATARI PROGRAMMING VOL.1" in www.atariarchives.org :

 

"Any other caveats? Yes. The missiles still act independently as far as the collision registers are concerned. And the Atari documentation claims that the priority of the new "player" is the same as that of Playfield 3, but that's only partially true. In particular, when considering which playerhas priority, it is true that the fifth player behaves according to the chart. But, strangely enough, the fifth player alwayshas priority over anyplayfield color. This might imply some interesting consequences for a creative game designer."

 

 

But this Came again when I talked about All Priority Modes and Enable MULTIPLE BITs SET.

And then came Bryan with the strange effect on GPrior0.

[José Pereira]

That type of thing would be useful for what José is trying to do by plotting a copy of the foreground "shape" into P3 and drawing a "sprite" in Pm5. Of course you're still limited to the size it's of any use for. Does it work on all the playfields or just PF0?

 

 

Pete

 

Here's a picture showing PF0,1, and 2 and all 4 players.

 

Only PRIOR mode $18 yields unexpected behavior, giving Player 5 a dual-priority at the top and bottom.

 

 

 

 

 

Sorry, wrong click.

 

I think I now can explain this picture of Bryan.

First I think it is not GPRIOR 18(Mode2+16(5th Player enable)). But it is GPRIOR 24.

Why, because if you see carefully, first the 2first PLmayers(Bottom ones) go under PFs. (They are P0/1) and the Bottom two only above the bottom PF, that is PF2, soo, this two last ones are P2/3.

And using Priority8 gives you PF0/1->All PMs.->PF2/3. But as I explain above if your 4Missiles together as 5th Player Overlap any PF They will be allways be above any PFs. And this is what you see with the 5th Player (the vertical white line).

But why the 5th Player disappears when Overlap PFs. and Pl. and also why P2/3 disappear when they are above PF2/3 in Prioruty 8.

Easy, because you have a conflict here. PF3 it is the lowest one, soo all Players above it, but then 5th Player above PFs become above all Players. Now you have something like: ABOVE+BOTTOM=RESULT. And result it's like: + (+) - (=) 0. And here 0 it is PFs. If you have a conflict between Pl. and P5, what you have left the PFs. So, the computer gives you the PFs. on that overlap area.

 

If you do this logical operation, you can easilly see that this conflict will not be possible in any other Priority Mode (I think, if I'm right).

 

 

Hope this help any one?

 

 

Greetings.

José Pereira.

[José Pereira]

 

 

Sorry, wrong click.

 

I think I now can explain this picture of Bryan.

First I think it is not GPRIOR 18(Mode2+16(5th Player enable)). But it is GPRIOR 24.

Why, because if you see carefully, first the 2first PLmayers(Bottom ones) go under PFs. (They are P0/1) and the Bottom two only above the bottom PF, that is PF2, soo, this two last ones are P2/3.

And using Priority8 gives you PF0/1->All PMs.->PF2/3. But as I explain above if your 4Missiles together as 5th Player Overlap any PF They will be allways be above any PFs. And this is what you see with the 5th Player (the vertical white line).

But why the 5th Player disappears when Overlap PFs. and Pl. and also why P2/3 disappear when they are above PF2/3 in Prioruty 8.

Easy, because you have a conflict here. PF3 it is the lowest one, soo all Players above it, but then 5th Player above PFs become above all Players. Now you have something like: ABOVE+BOTTOM=RESULT. And result it's like: + (+) - (=) 0. And here 0 it is PFs. If you have a conflict between Pl. and P5, what you have left the PFs. So, the computer gives you the PFs. on that overlap area.

 

If you do this logical operation, you can easilly see that this conflict will not be possible in any other Priority Mode (I think, if I'm right).

 

 

Hope this help any one?

 

 

Greetings.

José Pereira.

 

 

 

Here I am again.

 

For now we have four strange things:

1- GPRIOR0.

2- Priority conflits that gives you Black colour.

3- 5th Player dual Priotity.

4- My above explanation when PF,PL. and 5thPl. overlap.

 

 

I think like me many of you doesn't know some of this strange/weird results, soo, I thpnk it's very important/usefull this kind of Posts.

 

 

And, do you know if all of the Emulators support this four strange Priorities?

 

 

I've been thinking if there is a possibility of having another possible conflict, but in a logical way, I don't any other...

 

With so many surprises and strange/weird things... I'll never say NO, YOU CANNOT HAVE MORE!!!...

 

 

 

Bye now,

José Pereira.

[Bryan]

24 = $18

[José Pereira]

24 = $18

 

 

 

Sorry. Stupid I am... I'm still more in Decimals.

 

Sorry,sorry,...

José Pereira.

[analmux]

Hmmm, this is an interesting question....

 

I did some small tests in Basic.

 

It seems there are other PRIOR values with surprises.

 

First:

It seems PRIOR = 5 or 7 makes no difference. The same when bit3 or 4 is turned on: PRIOR = 13 or 15, 21 or 23, 29 or 31 all give the same effect pairwise, thus: (PRIOR = 5) = (PRIOR = 7), (PRIOR = 13) = (PRIOR = 15), (PRIOR = 21) = (PRIOR = 23) and (PRIOR = 29) = (PRIOR = 31).

 

 

Second:

 

If we f.e. do PRIOR = 10 or 26 (or binary: 000x1010) we have the following priority conflict:

bit 1 says PM0/1 > PF > PM2/3 > BK

bit 3 says PF0/1 > PM > PF2/3 > BK

Then: Combination of Player2 and Missile0 will become black, BUT it seems this 'black' has a priority level of its own. The black will vanish when drawing PF0/1 on top of it.

 

Now, when PRIOR=26: "5th player mode selected", we have another strange effect:

(f.e.) Combination of Player3 and Missile1 (Here missiles in 5th colour mode: i.e. =PF3): The colours will MIX (or-effect), just like in PRIOR=0 mode (or PM 3rd colour mode!).

 

 

Third:

 

If we do PRIOR = 12 (i.e. binary: 00001100) we have

bit 2: PF > PM > BK

bit 3: PF0/1 > PM > PF2/3 > BK

This results into: PF2/3 <> PM

Now: Only PF2/3 + PM2/3 will give black

Partial Priority scheme: PM2/3 < PM0/1 < PF2/3, however, PM2/3 + PF2/3 will give black REGARDLESS of whether PM0/1 is inbetween.

 

 

...and this is not all...

 

It seems PRIOR has its own 'dark world of logic'

Edited October 14, 2009 by analmux