Grebnedlog

I realize that the OP might not have been very clear, so I worked up a demo to illustrate the problem as I see it. The bb 1.1d program imitates the style of a Donkey Kong-like platform game to show what's happening. A fuller explanation is contained in the source comments, but the basic idea here was to build a basic game framework that would benefit from multiple simultaneous collision detection for the virtual players (and actually 'breaks" without it). I'm hoping someone with experience can run it, take a look at the code, and explain what's going on (and maybe even propose a solution). - Press the joystick left and right to move the "1' sprite. - Press and release the fire button to shuffle the starting platforms for all sprites. - Sprites should be able to move through ladders. - Sprites should not be able to move through walls or gaps. - The Bug: When a sprite is overlapping a ladder, all sprites on platforms below it ignore walls and gaps. Thanks. multi_pf_collisions_test.bas multi_pf_collisions_test.bas.bin

Not sure about reading them, but playfield drawing for DPC+ seems to be intact in the 1.1d version of batari I'm using (if you're referring to pfhline, pfvline and pfpixel, at least).

Hi. Hoping someone out there can offer some insight on how the 'collision(playfield,player1)" kernel option currently functions in batari's 1.1d DPC+ kernel. As I understand it, a collision between a virtual player1 sprite (player1-9) will return a y-value in temp4 1). Is the value returned in temp4 the Y of the pixel that collided, or the origin Y of the player sprite (i.e. line zero of the defined sprite). From experiments, it seems like the former, but after some strange results have me wondering if I'm understanding it properly. 2). When does the collision test take place? Is the value returned in temp4 four obtained during a drawscreen or is it a test that runs independent of it (perhaps during vertical blanking)? 3). In either case of 2, what will the resulting value in temp4 be if two virtual sprites are in contact with the playfield simultaneously during a single drawscreen? I assume the kernel will return only the value of the first scanline to be drawn in a collision state, but is there any way to gain some control over that, or perhaps a workaround during v-blank to identify two (or more) sprites in a playfield collision state? I've tried turning bits on and off to track which sprites have collided, but that hasn't worked out well so far. It seems the main obstacle is that new playfield collisions with sprites on later scanlines won't be recognized so long as the earlier sprite is still in collision. Thanks.

Thanks for the help! I suppose the reason I was asking is because I am trying to understand how the player1-9 pointers (color and player) work in the DPC+ kernel. It seems trivial to set read and write to those pointers in the base kernel, and even though the DPC+ includes the capability for 'player1-x' definitions (well, for shape, not for color so far), it seems to me like it might be useful to be able to get and set those pointers directly to achieve effects like palette-swapping, universal color themes, scrolling sprite data, targeted mid-sprite displays, etc. (I realize that this is quite a leap from my earlier question, but as you said the solution to that one is not interesting on its own.)

Is it possible to point to values in a player-defined data statement to color the lines in the player sprites instead of using the "player0color:...end" and "player1color:..end" coloring method? The idea here would be to write one master table of colors and then use a data pointer to select the start and end values, and incrementally color each line in the sprite. For example, instead of this: on x goto ColorScheme1 ColorScheme2 ColorScheme3 ColorScheme1 player1color: $DA $DA $DA $AE $D8 $D8 end goto EndColorSchemes ColorScheme2 player1color: $1A $36 $52 $52 $50 $52 end ColorScheme3 player1color: $a4 $a6 $44 $46 $36 $38 end EndColorSchemes Could we do this something similar to this... data all_color_schemes $DA, $DA, $DA, $AE, $D8, $D8, $1A, $36, $52, $52, $50, $52, $A4, $A6, $44, $46, $36, $38 end ... and then define the high and low pointers for various conditionals? I don't think this is possible using the basic framework ( at least, not without using RAM to store the color value of each sprite row), but wondering if there is some custom assembly that might do the trick. Failing that, is there a way to do it the first way, but in the style of a traditional comma-delimited data statement, if only to cut down on the long scrolls while coding multiple color schemes? For instance: on x goto ColorScheme1 ColorScheme2 ColorScheme3 ColorScheme1 data p1scheme1 $DA, $DA, $DA, $AE, $D8, $D8 goto EndColorSchemes ColorScheme2 data p1scheme2 $1A, $36, $52, $52, $50, $52 end goto EndColorSchemes ColorScheme3 data p1scheme3 $A4, $A6, $44, $46, $36, $38 end EndColorSchemes Thanks for any guidance.

Hi! I have a bug report about missile color and a question regarding collision detection for bB v1.1d. I've added COLUM0 and COLUM1 variables to (sort of) control missile color. The colors won't work while the missile is on the same scanline as a player but it should work fine otherwise. This patch has three files: DPCstartup.asm, DPCplusbB.h and custom/bin/custom2.bin. Unzip into the includes folder. Some of this isn't tested very well so let me know if there are any issues. I've noticed that the missile default color works as expected for COLUM1 and COLUM0 on the scanlines that come after their respective sprites. But for COLUM0, the colors will default to 0 (black) on non-player0 scanlines that come before it. I've included a small program to demonstrate this (move joystick up and down to change the vertical position of the sprites. DPCMissileColor.bas.bin DPCMissileColor.bas What value is returned in temp4 if two virtual sprites are colliding with the playfield after the same drawscreen? This happens fairly often in a program I am trying to write, and whenever it does, temp4 doesn't seem to return any of the virtual players y-coordinates (nor "0", nor "255"). I would try to trace the address myself, but unfortunately I am a novice at Stella Debugger. Is it possible to write a post-collision statement in batari basic that accounts when two or more virtual sprites are colliding with the background simultaneously (i.e. "if temp4 = [some value] then..." Thanks!