Player0 behind player1

[+Philsan]

Is it possible to have player0 behind player1?

It seems a stupid question, but in bB if you want only one multicolor sprite, this sprite is player1.

I need the multicolor sprite in front of the other singlecolor sprite.

[SeaGtGruff]

Is it possible to have player0 behind player1?

No, player0 always has priority over player1.

 

It seems a stupid question,

No it doesn't! It's a good, legitimate, I-want-to-do-something-and-I-need-to-know-if-it's-even-possible question!

 

but in bB if you want only one multicolor sprite, this sprite is player1.

I need the multicolor sprite in front of the other singlecolor sprite.

I can think of three possible solutions:

 

(1) Modify player0's graphics to cut out specific pixels as needed so that player1 shows through-- so it looks like player1 is in front of player0, even though player0 is really in front of player1.

 

(2) Use the multicolor option for both players, but define player1's color table such that it's a single color.

 

(3) Modify the std_kernel.asm file so player0 can be multicolor with player1 being a single color.

 

I copied std_kernel.asm to a new file called std_kernel_player0colors.asm, then changed it as follows:

 

If you define a constant named player0colors, the player1color table will be used for player0 instead of for player1. If you're also using the playercolors option, player0's color will be used for player1. In other words, the color control for player0 and player1 will be swapped.

 

The easiest way to use this kernel is to rename std_kernel.asm to something else, to keep a backup copy of it, and then rename std_kernel_player0colors.asm to std_kernel.asm.

 

Michael

 

Edit:

 

I haven't actually tested this yet, so let me know if it blows up!

std_kernel_player0colors.zip

Edited October 28, 2010 by SeaGtGruff

[+Philsan]

Thanks Michael.

 

I hope Fred will add to next bB's version the option to have a multicolor player0.

 

Regarding your workarounds, the first one is too complicated and with the second I lose another missile.

 

The third one could be a good solution but I need more explanations.

 

I understood that I have to use your updated kernel.

But exactly what do I have to change in my program?

I have the kernel option player1colors.

[+SpiceWare]

I imagine you'll get more display options once Fred adds support to bB for DPC+.

[RevEng]

The easiest way to use this kernel is to rename std_kernel.asm to something else, to keep a backup copy of it, and then rename std_kernel_player0colors.asm to std_kernel.asm.

Another easy way to use the new std_kernel.asm is to just copy it in the same directory as your .bas file.

 

bB will use asm files in this directory before the official ones.

 

I prefer this method, as it keeps the official bB dir clean.

[+Philsan]

The easiest way to use this kernel is to rename std_kernel.asm to something else, to keep a backup copy of it, and then rename std_kernel_player0colors.asm to std_kernel.asm.

Another easy way to use the new std_kernel.asm is to just copy it in the same directory as your .bas file.

 

bB will use asm files in this directory before the official ones.

 

I prefer this method, as it keeps the official bB dir clean.

Exactly what I have done, thanks to your previous teachings (if this kernel solves my priority problem, I need an updated version to fix bB PAL50 "less than 312 scanlines bug"!).

 

The problem is that I don't know what to change exactly in my program.

 

I don't undertand perfectly Michael's words:

If you define a constant named player0colors, the player1color table will be used for player0 instead of for player1. If you're also using the playercolors option, player0's color will be used for player1. In other words, the color control for player0 and player1 will be swapped.

[RevEng]

I don't undertand perfectly Michael's words...

It sounds like you just need to put this in your .bas:

 

const player0colors=1

 

And then use player1colors as usual, but they'll apply to player0 instead of player1.

[SeaGtGruff]

I don't undertand perfectly Michael's words...

It sounds like you just need to put this in your .bas:

 

const player0colors=1

 

And then use player1colors as usual, but they'll apply to player0 instead of player1.

Exactly! I thought about just swapping STA COLUP0 and STA COLUP1, so player1colors would change player0 instead of player1 without having to do anything else, but then I figured it would be more "compatible" with the original kernel if I did it as an optional change. So if you use player1colors but do *not* define player0colors as a constant, the kernel will compile and work just like normal. But if you *do* define player0colors as a constant, the player1 colors apply to player0, and the player0 colors apply to player1 (if you're using both multicolored players).

 

Only thing is, it doesn't work yet, because I didn't make the change correctly. (I *told* you I hadn't tested it yet!) I'll fix it and post a demo of how to use it.

 

Michael

[+Philsan]

Only thing is, it doesn't work yet, because I didn't make the change correctly. (I *told* you I hadn't tested it yet!) I'll fix it and post a demo of how to use it.

Ah, that's why my player0 continually changes colors when player1 moves vertically!

[+Random Terrain]

Only thing is, it doesn't work yet, because I didn't make the change correctly. (I *told* you I hadn't tested it yet!) I'll fix it and post a demo of how to use it.

Will it have its own new thread? Seems like something I should link to from the bB page.

[jrok]

I've been attempting a kernel mod for this on my own lately, but the farthest I've gotten is to manually swap which player is colored. The trouble is that even after making the switch, player0 color table always aligns with player1's pointer. So in other words, player0 is colored, but it's color table is drawn at player1's y position rather than it's own.

 

From what I read above, it seems as if Michael's attempt had a similar problem. Where in the kernel is the y value of each color table set?

 

EDT: I attached a binary to demonstrate the result I'm getting. Press up-left or up-right and the fire button to jump.

p0color.bas.bin

Edited January 11, 2011 by jrok

[RevEng]

I started down the same road as SeaGtGruff, but after a while it became apparent I'd need to conditionally re-jigsaw much of the kernel to get it to work. It was easier just to make a second kernel (modified mostly with search and replacing) and enable each kernel conditionally based on the "player0colors" constant...

 

 

To use it, remove the .txt extension from the .asm file and add it your basic project's directory. Then add a "const player0colors=0" line to your basic file.

 

std_kernel.asm.txt

PlayerPriorityTest.bas

PlayerPriorityTest.bas.bin

 

[edit - fixed std_kernel.asm so player0y and player1y coordinates lined up together.

Edited January 12, 2011 by RevEng

[jrok]

I started down the same road as SeaGtGruff, but after a while it became apparent I'd need to conditionally re-jigsaw much of the kernel to get it to work. It was easier just to make a second kernel (modified mostly with search and replacing) and enable each kernel conditionally based on the "player0colors" constant...

 

 

To use it, remove the .txt extension from the .asm file and add it your basic project's directory. Then add a "const player0colors=0" line to your basic file.

 

 

PlayerPriorityTest.bas

PlayerPriorityTest.bas.bin

 

Ah, okay. Thanks! I think I understand the changes in the top kernel. But I guess what I was really curious about was whether there could be a full swap of the default kernel, where P0 is multicolered, M0 is sacificed, and monocolor P1 and M1 are both available. It seems as though in this kernel, the priority sprite and it's missile are both available, which makes M0 share the color table with P0.

PlayerPriorityTest.bas.bin

[RevEng]

Sure, that would definitely be better.

 

The only hitch here is we now need to change some of the memory locations around - player1colors takes up the memory that would normally be used by missile1height and missile1y, and now it needs to use missile0height and missile0y instead. So I've included the 2600basic.h file with that change. (be sure to stick in the directory with your basic file.)

 

Here's v2, with missiles from P0 being sacrificed...

 

PlayerPriorityTest.bas

PlayerPriorityTest.bas.bin

2600basic.h.txt

std_kernel.asm.txt

[jrok]

Sure, that would definitely be better.

 

The only hitch here is we now need to change come of the memory locations around - player1colors takes up the memory that would normally be used by missile1height and missile1y, and now it needs to use missile0height and missile0y instead. So I've included the 2600basic.h file with that change. (be sure to stick in the directory with your basic file.)

 

Here's v2, with missiles from P0 being sacrificed...

 

PlayerPriorityTest.bas

PlayerPriorityTest.bas.bin

2600basic.h.txt

 

 

D'oh! Okay, yeah, and this all actually makes a lot more sense, now. Wow, thanks for solving this one, RevEng! Maybe a final step would be to try to pretty-up the revised kernel (instead of switching between two full, separate kernels), but it works very well as is.

 

I think your solution should absolutely be included as a fully fledged kernel option if there is ever an official redraft of the standard kernel. I know that the desire to color the priority sprite (without losing both missiles) has come up quite often on these forums.

Edited January 12, 2011 by jrok

[RevEng]

Thanks! I figured if both you and Philsan were looking for it, then others might find it useful too.

[+atari2600land]

After playing with this, I realized that the score wasn't working properly. So I played around trying to get it to work, and instead of putting "score=score+1", I put in "score=score+10" and it worked as though I typed "score=score+1", increasing the score 1 point instead of the ten I put in. Why?

[RevEng]

Looks like I accidentally swapped p0 and p1 in the score too!

 

Here's the fixed version.

 

std_kernel.asm.txt

[+Random Terrain]

Looks like I accidentally swapped p0 and p1 in the score too!

 

Here's the fixed version.

 

std_kernel.asm.txt

Can you replace the old version of the file with the fixed version in your post here:

 

http://www.atariage.com/forums/topic/171652-player0-behind-player1/page__p__2180898#entry2180898

 

 

I link to that post from the bB page and some people may not scroll down.

 

 

 

Thanks.

[RevEng]

Can you replace the old version of the file with the fixed version in your post here...

Good point - the old version is replaced.

[disjaukifa]

Will this work with the multisprite kernel? Sorry to bring up an old thread but this question is relevant to a project I'm working on! Sorry I found a way to work around it but my question still stands.

Edited October 6, 2011 by disjaukifa

[+atari2600land]

Sorry to necropost, but I'm having a problem. Any time I use the files I downloaded here, this always comes up:

--- Unresolved Symbol List
pfcenter				 0000 ????		 (R )
pfwidth				  0000 ????		 (R )
scorefade			    0000 ????		 (R )

Why?

[+atari2600land]

I found a temporary work-around by putting this near the beginning of my code:

 const pfwidth=4	   

const scorefade=0

I'd still like to know why it gives me that stuff if I don't put this in my code, since it worked fine in a previous version of Visual bB.

[+Gemintronic]

I found a temporary work-around by putting this near the beginning of my code:

 const pfwidth=4	  

const scorefade=0

I'd still like to know why it gives me that stuff if I don't put this in my code, since it worked fine in a previous version of Visual bB.

 

Fred has been too busy with DPC+ stuff (I assume) to be futzing with old, working code.

 

If I had to take a guess it might be a change in DASM. When RevEng helped me with some recent issues he mentioned that some stuff had to be declared up top of your code because of changes to DASM. Meaning, some things that used to be OK to just be self-contained and happy in the minikernel or bB kernel may need to be declared manually in your bB code.

 

I see this as a silent but deadly trend. Kind of like those burritos I had 2 days ago.

Edited May 23, 2012 by theloon

[RevEng]

I found a temporary work-around by putting this near the beginning of my code:

 const pfwidth=4	  

const scorefade=0

 

Try it without the scorefade... I have a feeling that pfwidth is the only important one here.

 

The pfwidth thing is a bB constant that's used to flag how many data bytes across the playfield is to different parts of bB... it was added to bB after this kernel hack was posted. I expect your error is just the result of a minor mismatch between the new bB includes and this older bB kernel.

 

 

If I had to take a guess it might be a change in DASM. When RevEng helped me with some recent issues he mentioned that some stuff had to be declared up top of your code because of changes to DASM.

 

There are some issues with minikernels using labels before DASM has figured out if they're zero page or rom locations, but that's not the issue this time... might be the burritos, though!