+Philsan Posted January 23, 2011 Share Posted January 23, 2011 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 23, 2011 Share Posted January 23, 2011 Was anything figured out in this thread: http://www.atariage.com/forums/topic/171652-player0-behind-player1/ Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 23, 2011 Author Share Posted January 23, 2011 (edited) 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 January 23, 2011 by Philsan Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 23, 2011 Share Posted January 23, 2011 (edited) 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 January 23, 2011 by RevEng Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 23, 2011 Author Share Posted January 23, 2011 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 23, 2011 Share Posted January 23, 2011 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 23, 2011 Share Posted January 23, 2011 (edited) 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 January 23, 2011 by RevEng 2 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 23, 2011 Author Share Posted January 23, 2011 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... Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 23, 2011 Share Posted January 23, 2011 (edited) 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 January 23, 2011 by RevEng 1 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 23, 2011 Author Share Posted January 23, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 24, 2011 Share Posted January 24, 2011 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.randomterrain.com/atari-2600-memories-batari-basic-commands.html#objects (Scroll down to Related Links.) Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 24, 2011 Author Share Posted January 24, 2011 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... Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 24, 2011 Share Posted January 24, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 24, 2011 Share Posted January 24, 2011 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.