Jump to content
IGNORED

Changing priorities


Philsan

Recommended Posts

Was anything figured out in this thread:

 

http://www.atariage....behind-player1/

The problems are similar but different.

In that thread I asked a solution to have player1 always in front of player0 (it is useful if you want to make a game with only a multicolor sprite).

In this thread I ask for a solution to change player1 and player0 priority according to their Y position.

I think a programming solution must be found to swap player1 and player0 data and colors on the fly.

Edited by Philsan
Link to comment
Share on other sites

player0 always has priority over player1 on the 2600.

 

Your basic code needs to check which character's Y position is greater and use player0 for that character in the upcoming frame.

 

By the way, I tried the program and it's a nice start!

 

[edit - you beat me to answering your own question! :P]

Edited by RevEng
Link to comment
Share on other sites

player0 always has priority over player1 on the 2600.

 

Your basic code needs to check which character's Y position is greater and use player0 for that character in the upcoming frame.

 

By the way, I tried the program and it's a nice start!

 

Thank you!

 

Exactly, as witten in my previous post, a programming solution must be found to swap player1 and player0 data and colors on the fly.

But I think it is very difficult because when I do a GOSUB JANETFRAME0, colors and pixels are associated with a definite player.

 

JANETFRAME0

player1color:

$FA

end

 

player1:

111000

end

return

 

 

Link to comment
Share on other sites

The easiest solution would be to setup player0 and player1 as normal, and then do a y position check before your drawscreen.

 

If player1y>player0y the do a variable swap. The variables will include the sprite data pointers, the color list pointers, the player coordinates, and the player heights.

 

I'll see if I can get you an example later today, if someone doesn't beat me to it.

Link to comment
Share on other sites

Here's an example program which has a "prioritydrawscreen" subroutine that handles the conditional swapping. The main program deals with player0 and player1 as usual.

 

P0P1swap.basic.bas

P0P1swap.basic.bas.bin

 

Two things to be mindful of:

 

  • hardware collision detection is made unreliable, because during any one drawscreen the player may be player0 or player1. If hardware detection is really required the programmer should first compare the y positions to figure out which sprite is using player0.
     
  • attributes that are directly handled by hardware registers in bB can't be swapped this way, since they can't be read. I'm thinking mainly of the NUSIZ#, but it also applies to COLUP# if someone tries this technique without the playercolors kernel option.

 

Here's a version that includes 2 extra "player#nusiz" variables, to demonstrate how to fix the second point.

 

P0P1swap.NUSIZ.bas

P0P1swap.NUSIZ.bas.bin

Edited by RevEng
  • Like 2
Link to comment
Share on other sites

I don't need to use NUSIZ so the first example should be perfect (although I don't understand it...).

A very short code to solve a problem that seemed (to me) very difficult.

I think this code should be put in a repository of useful code snippets (for example this one).

 

EDIT

I have the problem of REFPx...

Link to comment
Share on other sites

I don't need to use NUSIZ so the first example should be perfect (although I don't understand it...).

 

EDIT

I have the problem of REFPx...

For REFPx, you can just take the NUSIZ example and do a global search+replace, so NUSIZ->REFP and nusiz->refp.

 

I think you probably understand the high level - if the player's sprite is higher on the screen than swap both player's information so player1 is used instead of player0.

 

The lower level details are less important to using the code, but the main two wrinkles here are:

 


  • 1) When you do a player0: or player0color: command in bB, what actually happens is some pointers change to point to a new section of ROM that has your data. So when it needs to swap data between the sprites, my code just swaps the player0 and player1 pointers.
     
    2) Whenever I do a swap before a drawscreen, I do a swap right after. If I didn't do that, the next time you manipulated player0x, it would actually contain the last frame's player1x information.

 

A very short code to solve a problem that seemed (to me) very difficult.

I think this code should be put in a repository of useful code snippets (for example this one).

I thought about it, but it may be a bit complicated for that thread, because the code needs to be modified differently if the player isn't using playercolors, etc.

 

For more complicated stuff, like this, player0/player1 swap thread, RT's individual pfscore colors, maybe we should we post links to individual threads in the code snipplets thread?

Edited by RevEng
  • Like 1
Link to comment
Share on other sites

Is that a kernel, minikernel, or module? I'm not exactly sure what it is or where to put it.

 

If you know of more things I should link to, please post them here or send me a PM.

 

Here's what I've added so far:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#objects

 

(Scroll down to Related Links.)

Link to comment
Share on other sites

It might be considered a module replacement, but it would probably be better to refer to it as an enhancement. That way it could be lumped with the other stuff we build to improve bB.

OK, I'll change that section from "Additional Kernels, Minikernels, and Modules" to "Additional Kernels, Minikernels, Modules, and Enhancements."

 

 

Thanks.

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