13 replies to this topic

[Philsan]

Perhaps you've tried my program.
I would like to change priorities so sprites are in front or behind according to their Y positions.
For example:


This problem cannot be solved changing a priority register like A8 computers.
Is there a solution?

[Random Terrain]

Was anything figured out in this thread:

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

[Philsan]

Random Terrain, on Sun Jan 23, 2011 3:37 AM, said:

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, Sun Jan 23, 2011 4:01 AM.

[RevEng]

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! ]

Edited by RevEng, Sun Jan 23, 2011 4:06 AM.

[Philsan]

RevEng, on Sun Jan 23, 2011 4:04 AM, said:

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

[RevEng]

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.

[RevEng]

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   1.71K   63 downloads
 P0P1swap.basic.bas.bin   4K   82 downloads

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   1.98K   63 downloads
 P0P1swap.NUSIZ.bas.bin   4K   80 downloads

Edited by RevEng, Sun Jan 23, 2011 11:12 AM.

[Philsan]

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

[RevEng]

Philsan, on Sun Jan 23, 2011 11:57 AM, said:

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.

Philsan said:

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, Sun Jan 23, 2011 1:18 PM.

[Philsan]

Yes, I have undertood the higher level.
Regarding lower level (and code adjustments)... I have faith in you!

I agree with you that interesting threads like this or others (f.e. score customs fonts) should be linked somewhere.
Perhaps Duane could include them in his manual.

[Random Terrain]

Philsan, on Sun Jan 23, 2011 1:58 PM, said:

score customs fonts

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.randomter...ds.html#objects

(Scroll down to Related Links.)

[Philsan]

Random Terrain, on Mon Jan 24, 2011 1:25 AM, said:

Philsan, on Sun Jan 23, 2011 1:58 PM, said:

score customs fonts

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

Only Mike can answer this question...

[RevEng]

Its definitely not a kernel or minikernel, since its all data.

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

[Random Terrain]

RevEng, on Mon Jan 24, 2011 7:03 AM, said:

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.