Jump to content
Gemintronic

Smooth Collisions using Ball instead of PFREAD

Recommended Posts

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.
 
[attachment=587717:smoothcollision.bas.png]
 
[attachment=587718:smoothcollision.bin]
 
[attachment=587719:smoothcollision.bas]
 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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.

[attachment=587763:smoothcollisionms.bas]

 

[attachment=587764:smoothcollisionms.bas.png]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

[attachment=607207:mssmooth.bas]

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...