Jump to content

Photo

Player0 behind player1


25 replies to this topic

#1 Philsan OFFLINE  

Philsan

    River Patroller

  • 2,700 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Thu Oct 28, 2010 3:35 PM

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.

#2 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,360 posts
  • Location:Georgia, USA

Posted Thu Oct 28, 2010 5:39 PM

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! Posted Image

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

Attached Files


Edited by SeaGtGruff, Thu Oct 28, 2010 5:40 PM.


#3 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 2,700 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Fri Oct 29, 2010 2:12 PM

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.

#4 SpiceWare ONLINE  

SpiceWare

    Quadrunner

  • 7,981 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Fri Oct 29, 2010 2:15 PM

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

#5 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Fri Oct 29, 2010 2:43 PM

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.

#6 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 2,700 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Fri Oct 29, 2010 3:01 PM


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.


#7 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Fri Oct 29, 2010 3:58 PM

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.

#8 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,360 posts
  • Location:Georgia, USA

Posted Sat Oct 30, 2010 12:19 AM

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

#9 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 2,700 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sat Oct 30, 2010 2:52 AM

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!

#10 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 24,320 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Oct 30, 2010 3:28 AM

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.

#11 jrok OFFLINE  

jrok

    Stargunner

  • 1,149 posts

Posted Tue Jan 11, 2011 1:27 PM

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.

Attached Files


Edited by jrok, Tue Jan 11, 2011 5:03 PM.


#12 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Tue Jan 11, 2011 8:32 PM

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

scratch.bas.bin_4.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.

Attached File  std_kernel.asm.txt   27.72KB   165 downloads
Attached File  PlayerPriorityTest.bas   972bytes   188 downloads
Attached File  PlayerPriorityTest.bas.bin   4KB   241 downloads

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

Edited by RevEng, Tue Jan 11, 2011 9:15 PM.


#13 jrok OFFLINE  

jrok

    Stargunner

  • 1,149 posts

Posted Tue Jan 11, 2011 9:17 PM

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

scratch.bas.bin_4.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.


Attached File  PlayerPriorityTest.bas   972bytes   188 downloads
Attached File  PlayerPriorityTest.bas.bin   4KB   241 downloads


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.

Attached Files



#14 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Tue Jan 11, 2011 10:25 PM

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

scratch.bas.bin_5.png
Attached File  PlayerPriorityTest.bas   1.1KB   206 downloads
Attached File  PlayerPriorityTest.bas.bin   4KB   256 downloads
Attached File  2600basic.h.txt   3.45KB   219 downloads
Attached File  std_kernel.asm.txt   27.72KB   143 downloads

#15 jrok OFFLINE  

jrok

    Stargunner

  • 1,149 posts

Posted Wed Jan 12, 2011 9:39 AM

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

scratch.bas.bin_5.png
Attached File  PlayerPriorityTest.bas   1.1KB   206 downloads
Attached File  PlayerPriorityTest.bas.bin   4KB   256 downloads
Attached File  2600basic.h.txt   3.45KB   219 downloads


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, Wed Jan 12, 2011 9:40 AM.


#16 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Wed Jan 12, 2011 10:28 AM

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

#17 atari2600land OFFLINE  

atari2600land

    Quadrunner

  • 7,803 posts
  • Happy birthday, Abe!
  • Location:Salem, Oregon

Posted Wed Jun 8, 2011 4:04 AM

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?

#18 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Thu Jun 9, 2011 9:24 AM

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

Here's the fixed version.

Attached File  std_kernel.asm.txt   27.72KB   189 downloads

#19 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 24,320 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Jun 9, 2011 2:32 PM

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

Here's the fixed version.

Attached File  std_kernel.asm.txt   27.72KB   189 downloads

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

http://www.atariage....98#entry2180898


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



Thanks.

#20 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Thu Jun 9, 2011 3:25 PM

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

Good point - the old version is replaced.

#21 disjaukifa OFFLINE  

disjaukifa

    River Patroller

  • 2,125 posts
  • Berzerker In Training
  • Location:Research Triangle North Carolina

Posted Wed Oct 5, 2011 9:50 PM

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 by disjaukifa, Wed Oct 5, 2011 10:24 PM.


#22 atari2600land OFFLINE  

atari2600land

    Quadrunner

  • 7,803 posts
  • Happy birthday, Abe!
  • Location:Salem, Oregon

Posted Wed May 23, 2012 1:56 AM

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?

#23 atari2600land OFFLINE  

atari2600land

    Quadrunner

  • 7,803 posts
  • Happy birthday, Abe!
  • Location:Salem, Oregon

Posted Wed May 23, 2012 3:41 AM

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.

#24 theloon OFFLINE  

theloon

    Quadrunner

  • 6,946 posts

Posted Wed May 23, 2012 3:32 PM

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, Wed May 23, 2012 3:34 PM.


#25 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,151 posts
  • bit player
  • Location:Canada

Posted Wed May 23, 2012 5:57 PM

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




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users