Collisions

[jbs30000]

Has there been any upgrades lately? Mainly, with the asymmetrical multiplayer kernel can you check for collision(player1, player5)?

 

It's been over a year since I've done anything and it didn't really work, but I heard it was being worked on. Thanks.

[+Gemintronic]

batari stopped working on the normal multi-sprite kernel. Several known issues exist. As far as I know you must use soft collisions for the virtual sprites.

 

His multi-sprite DPC+ kernel has gotten much more love. I don't use it but there's a good chance virtual sprites have proper collision.

[Cybearg]

Oh, will he never be working on that stuff again? :<

 

I guess no one else is willing to take up his mantle? Because it would be awesome to see new possibilities being added and the potential of everything expanded upon.

[+Gemintronic]

The whole point of batariBASIC was to be a stepping stone towards assembly. However, reality is complicated. The assembly guys are too busy with their own projects to make bB kernels. The bB guys are too grounded in BASIC to make the transition (to assembly).

 

Regardless of advantages and disadvantages I enjoy BASIC. I even enjoy the double limitations of both the hardware (2600) and software (bB). BASIC homebrew isn't for everybody, that's for sure!

[jbs30000]

Actually, I was thinking of the DPC+ kernel. It's just been so long I forgot the name.

 

And I have played around with assembly. I did the tutorials from Andrew Davie. Although searching, I see he's done more lately.

 

Anyway, is collision detection on the DPC+ kernel still buggy for sprites 2 - 5? Thank you.

[iesposta]

...

 

Anyway, is collision detection on the DPC+ kernel still buggy for sprites 2 - 5? Thank you.

I only have ever used bB DPC+ kernel, and I haven't used it enough to answer your question.

I think I remember reading there is some way to see what collided with sprites 2-5.

One of the last things added was a way to color the missile differently when it is not horizontal with its player. It only seem to work for me when the missile was below the player, above was black.

Also defining a range of players to the same data was added.

Scrolling was going to be the next thing, but seemed to have stopped development about a year ago.

Some very impressive games can be done with the DPC+ bB tools we have now, but so far only a few have been completed.

[Cybearg]

You could do some kind of soft collisions, though it would, of course, take more processing power. Start at the location of the sprite, then check if something is within the range of spritex - 1/2 sprite width and spritey - 1/2 sprite height to spritex + 1/2 sprite width and spritey + 1/2 sprite height.

[+Random Terrain]

And I have played around with assembly. I did the tutorials from Andrew Davie. Although searching, I see he's done more lately.

 

Has he done more than what is here:

 

www.randomterrain.com/atari-2600-memories.html#assembly_language

 

I better get back to work if he's added more.

[+Gemintronic]

I think only Byte Knight would have a straight answer. He's done serious work with DPC+

http://www.atariage.com/forums/topic/201071-emr-ii-evil-magician-returns-upgraded-to-dpc/

 

I think he might even have some source in that topic. Maybe (if it's there) we could peek at his code to see how he handles collisions.

[jbs30000]

I guess session 25 is the only one that's new.

 

OK, and as for collisions, that last time I played around I had to use sprite locations to detect virtual sprite collisions (and that should be sprites 2-9 instead of 2-5, my mistake).

 

One last question then. When was the last time the DPC+ kernel was updated? The last time I did anything with bB was about 8 months ago.

Edited February 17, 2013 by jbs30000

[Byte Knight]

I think only Byte Knight would have a straight answer. He's done serious work with DPC+

http://www.atariage....pgraded-to-dpc/

 

I think he might even have some source in that topic. Maybe (if it's there) we could peek at his code to see how he handles collisions.

 

My workaround is to check sprite x and y positions for overlap using temp variables. The example is for a collision between player1 and player0, but you could use it for any of the players. The routine will return a temp1 value of 200 if there is a collision. I'm sure there's a more efficient way of coding this, but it works well.

 

pickupkey
temp3=player1x+6:temp4=player1y+14
temp5=player1x:temp6=player1y
gosub pickup
if temp1<>200 then return thisbank
z{0}=1:temp1=0:r=%00000010:q=11
return thisbank

pickup
temp1=player0x+7:temp2=player0y+29
if temp5>=player0x && temp5<=temp1 then goto ypos
if temp3>=player0x && temp3<=temp1 then goto ypos
return thisbank
ypos
if temp6>=player0y && temp6<=temp2 then goto col
if temp4>=player0y && temp4<=temp2 then goto col
return thisbank
col
temp1=200
return thisbank

[+Gemintronic]

Couldn't that be a function like this:

 

 function softcol_player0
rem x1 as player0x, y1 as player0y, x2 as temp1, y2 as temp2, x3 as temp3, y3 as temp4, x4 as temp5, y4 as temp6
if player0x > temp5 then return 0
if temp1 < temp3 then return 0
if player0y > temp6 then return 0
if temp2 < temp4 then return 0
return 1
end

[jbs30000]

Yeah, the last program I was working on uses sprite positions to check for collisions.

 

So has there been any DPC+ kernel updates lately, or will there be? Just curious.

[+Gemintronic]

Yeah, the last program I was working on uses sprite positions to check for collisions.

 

So has there been any DPC+ kernel updates lately, or will there be? Just curious.

 

That's a question for batari. I know he had planned for more features regarding the DPC+ kernel. One was making the extra EEPROM on Melody boards accessible for graphic data.

[Byte Knight]

Couldn't that be a function like this:

 

 function softcol_player0
rem x1 as player0x, y1 as player0y, x2 as temp1, y2 as temp2, x3 as temp3, y3 as temp4, x4 as temp5, y4 as temp6
if player0x > temp5 then return 0
if temp1 < temp3 then return 0
if player0y > temp6 then return 0
if temp2 < temp4 then return 0
return 1
end

 

That's good thinking! I hadn't thought to use the function command. This works better for my example:

 

pickupkey
temp3=player1x+6:temp4=player1y+14
temp5=player1x:temp6=player1y
temp1=pickup(f)
if temp1<>200 then return thisbank
z{0}=1:temp1=0:r=%00000010:q=11
return thisbank


function pickup
temp1=player0x+7:temp2=player0y+29
if player0x > temp3 then return 0
if temp1 < temp5 then return 0
if player0y > temp4 then return 0
if temp2 < temp6 then return 0
return 200

[+Gemintronic]

That's good thinking! I hadn't thought to use the function command. This works better for my example:

 

pickupkey
temp3=player1x+6:temp4=player1y+14
temp5=player1x:temp6=player1y
temp1=pickup(f)
if temp1<>200 then return thisbank
z{0}=1:temp1=0:r=%00000010:q=11
return thisbank


function pickup
temp1=player0x+7:temp2=player0y+29
if player0x > temp3 then return 0
if temp1 < temp5 then return 0
if player0y > temp4 then return 0
if temp2 < temp6 then return 0
return 200

 

Just to clarify for the studio audience, the lines:

temp3=player1x+6:temp4=player1y+14

 

and

temp1=player0x+7:temp2=player0y+29

 

refer to the far sides of the object being compared. (right?)

[Byte Knight]

Just to clarify for the studio audience, the lines:

temp3=player1x+6:temp4=player1y+14

 

and

temp1=player0x+7:temp2=player0y+29

 

refer to the far sides of the object being compared. (right?)