Jump to content

Photo

Smooth Collisions using Ball instead of PFREAD


9 replies to this topic

#1 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,032 posts

Posted Tue Aug 7, 2018 4:05 AM

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.bas.png
 
Attached File  smoothcollision.bin   4KB   11 downloads
 
Attached File  smoothcollision.bas   3.15KB   9 downloads
 
Multi-Sprite version here: http://atariage.com/...ttach_id=587763


#2 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,697 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Aug 7, 2018 4:56 AM

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



#3 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • 243 posts
  • Location:Senatobia, MS

Posted Tue Aug 7, 2018 8:07 AM

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.

#4 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 9,032 posts

Posted Tue Aug 7, 2018 11:17 AM

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



#5 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,697 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Aug 7, 2018 11:21 AM

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



#6 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 9,032 posts

Posted Tue Aug 7, 2018 11:27 AM

 

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.



#7 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 9,032 posts

Posted Tue Aug 7, 2018 2:07 PM

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.

Attached File  smoothcollisionms.bas   3.71KB   8 downloads

 

smoothcollisionms.bas.png



#8 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • 243 posts
  • Location:Senatobia, MS

Posted Tue Aug 7, 2018 3:15 PM

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.

#9 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 9,032 posts

Posted Tue Aug 7, 2018 3:26 PM

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



#10 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,697 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Aug 7, 2018 4:26 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users