Smooth Collisions using Ball instead of PFREAD

[+Gemintronic]

This is a smooth collision demo using the ball. This has advantages and disadvantages compared to other techniques. Just thought I'd offer up another option.

UPDATE: R.T. found there's still some drag when wall sliding. If anyone wants to take a stab at improving this I'm all ears!

A problem: The 2600 registers collisions where two graphical objects draw over eachother. This can lead to a flickering effect when the sprite is repeatedly placed and displaced from the collision point. As well simply reverting to the last known free x/y coordinates can leave the player feeling stuck unless they manually reverse direction and continue.

A solution: Use the ball as a collision detector and mask the rebound effect with the player sprite. Alternate which directions are strictly checked for collisions every other frame. This allows for smooth wall sliding.

Example controls: FIRE to show ball over sprite to see the ball hides the rebound effect. LEFT/RIGHT/UP/DOWN to move player/ball combo.

Secondary points of interest: Use of binary digits in counter to alternate frames. Use of constants that make colors human readable and easily swappable for PAL values. Clearing of 8 boolean flags by setting the containing variable to 0. Using boolean flags so each collision type need only call collision() routine once per main loop. Setting ballx/bally to the same value on the same line for leaner result come compilation time.

smoothcollision.bin

smoothcollision.bas

Multi-Sprite version here: http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=587763

[+Random Terrain]

When you move diagonally against a wall, the sprite slows down a lot. Is there a way to keep the speed the same?

[+Lewis2907]

Gemintronic,

 

I haven't looked at the code yet, but do you have Multisprite version and of course I always for 32k or 32kSC. Thanks if you have this (or have to build it). From what I have played via my cell phone it may help with the game I am working on.

[+Gemintronic]

@Random Terrain: Short answer is I don't know. I can see a slight slowdown when wall sliding. Something in my brain or my bB setup is making this slowdown less pronounced for me. The ball is still using simple move into and then warp out of playfield collision - at least some of the time. That could explain the slow down. I'm all for someone improving the ball movement/collision code and still using the "player0 at last ball collision-less coordinate" technique.

 

@Lewis2907: The basic premise works for multi-sprite. The nasty change is missiles and the ball are only one pixel high. This might mean you have to use, say, a missile for the top and the ball as the bottom collision detector. The amount of ROM or extra memory shouldn't effect the way this works. If it does please tell me. By the way this is my answer to your code request with that multi sprite collision demo I showed you in another topic.

[+Random Terrain]

@Random Terrain: Short answer is I don't know. I can see a slight slowdown when wall sliding. Something in my brain or my bB setup is making this slowdown less pronounced for me. The ball is still using simple move into and then warp out of playfield collision - at least some of the time. That could explain the slow down. I'm all for someone improving the ball movement/collision code and still using the "player0 at last ball collision-less coordinate" technique.

 

I'll have to play with the code in a couple of months. I need to finish converting an Atari BASIC book to work with batari Basic before I start working on anything else.

[+Gemintronic]

 

I'll have to play with the code in a couple of months. I need to finish converting an Atari BASIC book to work with batari Basic before I start working on anything else.

 

Nah, this ain't work putting on your plate. That Atari BASIC conversion sounds amazing! I've tried to port QuickBASIC code to bB and failed several times. Perhaps someday I'll ask for tips converting between BASIC dialects.

[+Gemintronic]

Gemintronic,

 

I haven't looked at the code yet, but do you have Multisprite version and of course I always for 32k or 32kSC. Thanks if you have this (or have to build it). From what I have played via my cell phone it may help with the game I am working on.

 

Here is a multi sprite version. Quick and dirty - I just commented major changes.

smoothcollisionms.bas

 

[+Lewis2907]

Thanks. I was working on it today during some downtime and made some progress. I will definitely look at it more today or tomorrow.

 

I forgot about RT porting Atari Basic. Maybe he should post some of it for us who are novice like me and more advanced like you and the others to try it out and provide feedback. I'm sure he will have a nice product when he is done with it.

[+Gemintronic]

I forgot about RT porting Atari Basic. Maybe he should post some of it for us who are novice like me and more advanced like you and the others to try it out and provide feedback. I'm sure he will have a nice product when he is done with it.

 

Being a former software tester I can tell you things at this stage need an unnatural combination of dead end user instinct and professional developer experience to distill that feedback. I'm sure R.T. will clue us in when things are ready

[+Random Terrain]

Here's the link:

 

atariage.com/forums/topic/273661-batari-basic-a-self-teaching-guide-book-does-anyone-else-want-one/

 

I'm not porting anything, just converting a book about Atari BASIC so it will work with batari Basic. It's for people who don't know anything about BASIC and want to learn BASIC while they learn about batari Basic at the same time. The book relies heavily on PRINT, so I have to rewrite a lot of it.

[+Gemintronic]

Still unable to get the bB default multisprite inline assembly pfread or bogaxs multisprite pfread routines to work. I tried again to use my secondary object as collision event technique instead.

 

This one uses the ball hidden within the lower half of the player sprite. Because the jerky collision rebound of the ball is hidden the player sprite is left out of the equation and stays stable. It also separates left/right and up/down input detection on alternate frames to allow the smooth gliding Random Terrain likes

 

This is not a commented example: more of a proof of concept.

mssmooth.bas

[+Lewis2907]

Thanks for sharing this may work for something else I have in mind as well. Hopefully you can get this to work out the way you want it to, thanks.