Jump to content

Photo

Changing priorities


13 replies to this topic

#1 Philsan OFFLINE  

Philsan

    River Patroller

  • 3,388 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Jan 23, 2011 3:06 AM

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:
screenshot1.png screenshot2.png

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

#2 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,179 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jan 23, 2011 3:37 AM

Was anything figured out in this thread:

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

#3 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 3,388 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Jan 23, 2011 3:59 AM

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.


#4 RevEng ONLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sun Jan 23, 2011 4:04 AM

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


#5 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 3,388 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Jan 23, 2011 4:11 AM

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



#6 RevEng ONLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sun Jan 23, 2011 4:25 AM

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.

#7 RevEng ONLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sun Jan 23, 2011 10:59 AM

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.

Attached File  P0P1swap.basic.bas   1.71KB   216 downloads
Attached File  P0P1swap.basic.bas.bin   4KB   199 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.

Attached File  P0P1swap.NUSIZ.bas   1.98KB   185 downloads
Attached File  P0P1swap.NUSIZ.bas.bin   4KB   193 downloads

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


#8 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 3,388 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Jan 23, 2011 11:57 AM

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

#9 RevEng ONLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Sun Jan 23, 2011 1:04 PM

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


#10 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 3,388 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Jan 23, 2011 1:58 PM

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.

#11 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,179 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jan 24, 2011 1:25 AM

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

#12 Philsan OFFLINE  

Philsan

    River Patroller

  • Topic Starter
  • 3,388 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Mon Jan 24, 2011 5:12 AM

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

#13 RevEng ONLINE  

RevEng

    River Patroller

  • 4,701 posts
  • Bitnik
  • Location:Canada

Posted Mon Jan 24, 2011 7:03 AM

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.

#14 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,179 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jan 24, 2011 3:48 PM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users