Multisprite Collision Detection (Player1 overlapping Player0)

[+Lewis2907]

Here is my attempt using "Player1 overlapping Player0" so far the flicker is very minmal. I think there maybe an issue with Players2-4. I haven't got that far yet to see if there is a way to get that to work. After reading / using Gemintronic code and post below it gave me a few ideas and the others I have read in the forum. Hopefully I am working down a feasiable path to have some non bouncy multisprite collision detection, thanks.

 

http://atariage.com/forums/topic/281617-smooth-collisions-using-ball-instead-of-pfread/

20180814 - SmoothCollision (WIP).txt

20180814 - SmoothCollision (WIP).bas.bin

[+Gemintronic]

Here is my attempt using "Player1 overlapping Player0" so far the flicker is very minmal. I think there maybe an issue with Players2-4. I haven't got that far yet to see if there is a way to get that to work. After reading / using Gemintronic code and post below it gave me a few ideas and the others I have read in the forum. Hopefully I am working down a feasiable path to have some non bouncy multisprite collision detection, thanks.

 

http://atariage.com/forums/topic/281617-smooth-collisions-using-ball-instead-of-pfread/

 

Trying to play around with example code and making it your own is great stuff! It's not always easy to assimilate others peoples ideas through code.

 

One thing we do things differently on is: I use two variables for the last known collisions free x and y. You use two variables for either 1 pixel forwards or (255) one pixel back. I guess this streamlines the actual sprite placement lines. But, you do lose flexibility when the player needs to move more than 1 pixel forward or backward. One pixel forward or backward might not be collision free either. The player could yank the controller in a direction that makes one of those two variables steer the sprite further into collision-land.

 

Also, the code changes remove the wall sliding that Random Terrain likes. Basically, instead of coming to a halt when you hit a wall you at least keep moving in the free direction.

 

It looks like you've noticed the weird offset between player0 coordinates and the virtual sprites. Both sprites are indeed overlapping. But, I can still see that one pixel smash into the playfield on collision. Perhaps making the masking sprite one pixel thicker all around would work. The collision detection sprite is always going to be moving 1 pixel into a wall so the masking sprite has to be 1 pixel bigger to cover that up.

 

Then again, using a sprite instead of a ball or missile for collision detection means the rest of the virtual sprites are guaranteed to flicker. Basically, no two virtual sprites can be on the same horizontal band. If player0 and player1 are on top of eachother player2-5 is gonna freak out and flicker if horizontally aligned. In my experiments each virtual sprite needs to be 2 pixels above or below the next virtual sprite.

 

Not pizzing on your code. Just noting the changes.. and, maybe extra stuff to put back in

[+Lewis2907]

Thanks for the feedback. I'm going to try and implement the part of your code now to try and make it smooth gliding. I had something sort of working, but I changed a few things around to get this out for feedback.

 

The way I did this was to try and keep it simple for us novice programmers. When I see ASM and more complex Bb ways it takes me a little longer to figure it out, because I'm still stuck on the old basic from the apple 2 computers back in the mid 80s when I was about 10 or so.

 

I always try to have it 32k to have as much space as possible for "bloated code" as Bogax pointed out. Then I try to find ways to reduce the code and save space.

 

I do like the ball and missile approach as it in Bb with no ASM (I think it's ASM free), but it was hard to use in a maze game, but I have an idea after playing with the codes to make the standard 8 by 8 Sprite work. It would be similar to overlapping, but shift the Sprite accordingly if it's not too noticeable if that makes sense.

[+Gemintronic]

The important thing (which I think you got) is that I am no master of batari BASIC: Just another user with weird ways of doing things. If something seems too complicated it's probably because I'm hardly understanding what I'm doing!

 

If a particular way seemed useful but too complicated I can try and enhance it. Smooth collisions is new territory for me as well

[+Lewis2907]

I blame RT lol ???. I prefer DPC, but since the flashback can't support it from a Bb perspective from what I have read and tried. I have settled with the Multisprite until that is fixed. My plan is to make a few games here and there for my grandkids to play, but I would like it smooth and polished as possible. Thanks again for the feedback. It helps me learn and think outside the box at times to see how close I can get to a solution.

[+Lewis2907]

I think the attached is what you mean. It stops the flicker of the player crashing into the wall and creates the space. I was playing with collision for player2-5, but that will take some work and thought / help. Anyways I think the attached code could be used to create a game where a person doesn't mind the flicker and has the ball and missiles avaiable. The option I am going to try is to use the ball / missiles from your code to get player2-5 (if possible) to have detection. I was playing with the shifting of the ball based upon direction. It looks promising so far. I have a few other ideas. Hopefully the code will help generate some multisprite collision detection, thanks.

 

***Edit***

 

Fixed the diagonal collision. There was no space when moving left or right and hitting a wall.

20180815 - SmoothCollision (WIP)v2.bas.bin

20180815 - SmoothCollision (WIP)v2.txt

Edited August 16, 2018 by Lewis2907

[+Gemintronic]

I think the attached is what you mean. It stops the flicker of the player crashing into the wall and creates the space. I was playing with collision for player2-5, but that will take some work and thought / help. Anyways I think the attached code could be used to create a game where a person doesn't mind the flicker and has the ball and missiles avaiable. The option I am going to try is to use the ball / missiles from your code to get player2-5 (if possible) to have detection. I was playing with the shifting of the ball based upon direction. It looks promising so far. I have a few other ideas. Hopefully the code will help generate some multisprite collision detection, thanks.

 

***Edit***

 

Fixed the diagonal collision. There was no space when moving left or right and hitting a wall.

 

To me the next step would be to use some of the three rectangle-like objects (ball, missile0, missile1) instead of a sprite as the collision mask. That would free up a sprite and prevent flicker.

[+Lewis2907]

I agree I was playing around with it using your code. The missile works great for a top and bottom of the Sprite as you can go to 4 and 8 pixel wide. The problem I ran into so far is the detection for the left and right side to have a true box around the Sprite. I'm still trying to think of a work around for that. Maybe shifting the ball or missile to help I'm left and right detection? This would be based upon a standard 8 by 8 Sprite. The taller the Sprite the harder the dectection in my opinion.

 

11111111 (missile) shifts based upon joy0up

00000000

00000000 (missile or ball) would shift for left and right collision.

00000000

00000000

00000000

00000000

11111111 (missile) shifts based upon joy0down

 

The above shift I think can be based upon the playfield pixel in relation to the size of the ball or missile for left and right. I'm thinking if you jump every other up or down based upon joy0up && joy0 (right or left). Hopefully I made sense of what I think can be done to get closer to true Multisprite Collision Dectection.

 

Pfread might work, but I ran into dectection issues when there is only one pixel. RT tried to help, but he said something about not having pfpixel makes it extremely difficult. Bogax has a code that use several different sprites, but it's in ASM and when I tried use 32k or 32kSC it wouldn't compile.

 

I plan to play around with this weekend for a few hrs and see if I can get something to work. I'm thinking a combo of everyone's work may work minus the ASM as I have no clue on how to use it let alone program in it.

[iesposta]

I don't know if this can be adapted by the multi-sprite kernel, but when you are ready to take the next step and use NUSIZ double and triple copies, my code checks what was hit and rearranges what's left over.

There is almost no information on shooting double or triple copies that many Atari 2600 games have.

 

I also don't know if the "trick" to address one virtual sprite after another is the same. In DPC+ the virtual sprites follow each other in actual RAM.

If it is not the same, simply undo the trick by instead of using an if-then loop, use Player2y, Player3y, Player4y, etc. instead of the if-then loop with Player2y[variable] ..

(Explanation: The "trick" is that Player2y[0] is Player2y, Player2y[1] is Player3y, Player2y[2] is Player4y, Player2y[3] is Player5y.)

 

The code I wrote and Random Terrain fixed, rewrote and commented is here:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_shooting_nusiz

[+Lewis2907]

If I'm understanding correctly. Your program / game could be converted over to Multisprite and Standard Kernel. Then maybe some of the code could help in with collision detection in Multisprite. If so I will try a shot at the Multisprite version you have and see what I can come up with, thanks.

[iesposta]

If I'm understanding correctly. Your program / game could be converted over to Multisprite and Standard Kernel. Then maybe some of the code could help in with collision detection in Multisprite. If so I will try a shot at the Multisprite version you have and see what I can come up with, thanks.

 

 

Yes.

Not just Multisprite but duplicate and triplicate copies of those virtual sprites. (It’s hard to calculate which virtual sprite copy has been hit.)

I only once used the Multisprite Kernel to make Flappy.

Under the hood it is similar to what became the DPC+ Kernel.

[+Lewis2907]

I think I know where your going with this option. If you can caculate the virtual sprite or sprites. Then in theroy you could calculate the collision?

[iesposta]

I think I know where your going with this option. If you can caculate the virtual sprite or sprites. Then in theroy you could calculate the collision?

 

I already figured it all out and programmed it in "batari Basic". It's on RT's website about "batari Basic" in the link above.

 

I was just suggesting that when you want a more advanced game that needs shooting virtual sprite copies, this code can help.

 

If you copy that code into bB, then you can see where it handles 3 copies, into 2 copies, into 1 sprite, and alternating rows have 2 copies, into one sprite.

 

This is the compiled basic:

ex_dpc_shooting_nusiz_copies.bin