Jump to content
IGNORED

Player0 behind player1


Philsan

Recommended Posts

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! icon_wink.gif

 

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 by SeaGtGruff
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 months later...

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 by jrok
Link to comment
Share on other sites

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...

 

post-23476-129479928146_thumb.png

 

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 by RevEng
Link to comment
Share on other sites

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...

 

post-23476-129479928146_thumb.png

 

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

Link to comment
Share on other sites

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...

 

post-23476-129480610584_thumb.png

PlayerPriorityTest.bas

PlayerPriorityTest.bas.bin

2600basic.h.txt

std_kernel.asm.txt

  • Like 1
Link to comment
Share on other sites

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...

 

post-23476-129480610584_thumb.png

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. :thumbsup:

 

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 by jrok
Link to comment
Share on other sites

  • 4 months later...

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 months later...
  • 7 months later...

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 by theloon
Link to comment
Share on other sites

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! :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...