Author Topic: collisions in axe  (Read 3467 times)

0 Members and 1 Guest are viewing this topic.

Offline parserp

  • Hero Extraordinaire
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1455
  • Rating: +88/-7
  • The King Has Returned
    • View Profile
collisions in axe
« on: September 13, 2011, 08:59:50 pm »
I am learning axe from 83 basic and I don't know how to detect collisions between sprites and sprites and non moving objects.
Would you use a different method for detecting them? Should I use a lot of pxl-test 's or judge it based on position or some other handy way
that I am not aware of?     ???
« Last Edit: September 13, 2011, 09:04:22 pm by parser padwan »

Offline chattahippie

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +27/-0
  • Super Member! :D
    • View Profile
Re: collisions in axe
« Reply #1 on: September 13, 2011, 09:47:37 pm »
Welcome to Omnimaga... you should introduce yourself.
Try using pixel collision ( pxl-test() )
Just checking the x&y values of the object to be tested to every other object works for games without many walls or a bunch of the same objects.
The first would be the easiest if you have many differently programmed objects

Also, I think that every command in Axe uses (x,y) unlike BASIC, which is normally (y,x)

Personally, I program enemies and walls super simple, have one AI that checks to see if it is in collision with my player for every enemy on the screen, and I usually define the walls as the borders of the screen (cause I'm lazy :P ).  This works well for me, and if you are using data arrays (all that {pointer} stuff), then it should be fairly simple for collisions (at least for enemies).

Hope that helped! ;D
Good luck!


Offline Happybobjr

  • James Oldiges
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2325
  • Rating: +128/-20
  • Howdy :)
    • View Profile
Re: collisions in axe
« Reply #2 on: September 13, 2011, 11:10:34 pm »
For collision checking, I personally use multiple buffers.

Lets say there were 3 aspects of my game
* Main char actor
* Enemies
* Walls and ground and stuff

I then make 3 app variables in the ram to hold each.
I then only draw each to their own buffer (I actually normally have the main character in L6 for speed reasons)
After that I do the Pixel testing in a rectangular fashion.  (if things only move one pixel per frame, many times you can checker board it.)
When all that is said and done, I add the buffers to L6 and dispgraph.


I hoped my poorly said explanation helped.
Please realize that there is no right and wrong way to do collision testing.  There is no amazingly easy and efficient way to do it.
School: East Central High School
 
Axe: 1.0.0
TI-84 +SE  ||| OS: 2.53 MP (patched) ||| Version: "M"
TI-Nspire    |||  Lent out, and never returned
____________________________________________________________

Offline LincolnB

  • Check It Out Now
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1115
  • Rating: +125/-4
  • By Hackers For Hackers
    • View Profile
Re: collisions in axe
« Reply #3 on: September 13, 2011, 11:22:21 pm »
Here's a paper BuilderBoy wrote one time (and I hope he doesn't mind my publishing it here):


Collisions (by BuilderBoy):

In most every physics based game, you will need a way to tell when you character runs into something.  Whether that entails being able to stand on a platform, stopping when you hit a wall, or falling into a Portal.

First off, it is often better to detect whether or not your next position is a hit, rather than to move your object, see if its hit, and then move it back (although it can make more sense).  Collision methods vary highly based on your terrain, and your character design.  


Tiled Collision (pixel by pixel)

In Portal, the terrain is made up of tiles and the character is a single tile.  To check whether or not the next position will be inside a wall, i go through several steps:

If MovingDown
   Check pixels below each bottom corner
Else
   Check pixels above each top corner
End
if Either pixel checked is solid
   Set Y velocity to 0
End

If the same is done for the x direction, you would get a diagram that looks somthing like this

---------
--*---*--
-*00000*-
--00000--
--00000--
--00000--
-*00000*-
--*---*--
---------

Which shows the pixels you would test for all posible directions.  Note that this design fails once velocity is greater than 1 pxl/frame.  If you are programing in an enviromnent that doesnt permit you the luxury of such fine movement, some modifications will have to be made:

If MovingDown
   Check pixels on bottom corners
Else
   Check pixels on top corners
End
While Either pixel is solid
   Move character in increments of 1 in the oposite direction of velocity
End

---------
---------
--*000*--
--00000--
--00000--
--00000--
--*000*--
---------
---------

Instead of checking to see if the next position is solid, and preventing the character from ever going there, this method uses a different aproach.  Move the character always, and if they are inside an object, move the character in the oposite direction until they are no longer inside the wall.  It works for high velocities, but can make other physics difficult in certain scenarios (I don't use this method in Portal because the physics involving Portals would get a lot more complicated, with time fragments and such...)

Rough Terrain:

With rough terrain, it adds a level of difficulty in any game.  Especialy because it often also needs another level of physics to calculate the rebound angle or somthing (elastics will be covered in the next section).  The principles behind collision is very much the same however.  If you want to be simple, set the collision points of your character to the 4 corners of its bounding box, and have it behave just like a tile.  The collsion methods from the previous section should work well assuming you have an accurate way to test pixels of the screen.  If you can make sure pxlTest will not accidentaly detect your own pixels, or that the character doesnt destroy its own terrain, pxlTest is a very very fast way to test solidity in Basic games.  You can also write your own pxlTesting roughtine if you are using tilemaps and matrixes, and would look somthing like this:

*pxl to be tested x,y
*assuming tiles of 8x8 starting
[A](iPart(x/8)+1,iPart(y/8)+1

And if you are using Axe, since all data is in a list, more somthing like this:

*Assuming map width of 12
{L1+(x/8)+(y/8*12)}
*which simplifies to
{y*12+x/8+L1}  (i belive, axe optimisations are not my strong suit)

If your character is not a tile, collision become a little more time consuming, but not exceedingly more difficult.  Originaly, we were only testing 2 pixels per direction, but if we had a 8x8 sphere, we might want to up that to 6pxls per direction.  SOmthing like this

------------
------------
-----OO-----
---OOOOOO---
---OOOOOO---    
--OOOOOOOO--
--OOOOOOOO--
--*OOOOOO*-- 1
---OOOOOO---    Not a surface because there is no ledge for the sphere to rest on
---*-OO-*--- 2
-----**----- 3
------------

The genral rule is that you would need 2 pxlTests for every level of pixels your character could stand on.  Since the original character was a box, there was only 1 surface, the bottom, and we tested both sides.  But on this sphere, we have 1 2 3 surfaces on any given side





Hope that helps. Also, there are a few concepts you need to be familliar with to understand some of the posts in the thread, such as multiple buffers, simple physics and tilemapping, all three of which have their respective tutorials in the Tutorial page. I wrote the buffer one, BuilderBoy wrote the physics ones, and Yunhua98 wrote the tilemapping one, so yeah. Good luck!
« Last Edit: September 13, 2011, 11:23:54 pm by buttsfredkin »
Completed Projects:
   >> Spacky Emprise   >> Spacky 2 - Beta   >> Fantastic Sam
   >> An Exercise In Futility   >> GeoCore

My Current Projects:

Projects in Development:
In Medias Res - Contest Entry

Talk to me if you need help with Axe coding.


Spoiler For Bragging Rights:
Not much yet, hopefully this section will grow soon with time (and more contests)



Offline parserp

  • Hero Extraordinaire
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1455
  • Rating: +88/-7
  • The King Has Returned
    • View Profile
Re: collisions in axe
« Reply #4 on: September 14, 2011, 10:35:39 pm »
Wow, thanks for all the replies, and the very in depth explanation.   ;D

Offline LincolnB

  • Check It Out Now
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1115
  • Rating: +125/-4
  • By Hackers For Hackers
    • View Profile
Re: collisions in axe
« Reply #5 on: September 15, 2011, 10:00:08 am »
Also, keep in mind that there are a great number of methods for collision detection, to fit different needs. If you need help with collisions for a specific project, you could announce the project and ask for help in a new thread.
Completed Projects:
   >> Spacky Emprise   >> Spacky 2 - Beta   >> Fantastic Sam
   >> An Exercise In Futility   >> GeoCore

My Current Projects:

Projects in Development:
In Medias Res - Contest Entry

Talk to me if you need help with Axe coding.


Spoiler For Bragging Rights:
Not much yet, hopefully this section will grow soon with time (and more contests)