10 replies to this topic

[Random Terrain]

Latest Version:

This is a fixed version where the little guy you move around has better fake/real collision detection. It no longer overlaps the playfield pixels like it did sometimes in the first version. It corrects itself as soon as it starts to happen, so the problem I had in the first version is eliminated. In other words, similar to what SeaGtGruff said below, it uses a combination of 'collision prevention' and collision detection to make the sprite behave properly. This is the smoothest sprite/wall collision I've seen in a bB program so far. Move the sprite around the playfield pixels and see for yourself.


Here's the .bin file to use with an emulator or Harmony cartridge:

 ex_sprite_with_ball_missile_and_collision_2011y_06m_16d_0425t.bin   4K   69 downloads


Here's the bB code:

 ex_sprite_with_ball_missile_and_collision_2011y_06m_16d_0425t.bas   31.53K   68 downloads




Old Version:

This is the first draft of an example program that has a sprite, a bouncing ball, a missile you can shoot, and a mix of real and fake collision detection.

Use the joystick to move the sprite. Press the fire button to shoot the missile. Press the reset switch to reset the program and toggle between two screens.


Here's the .bin file to use with an emulator or Harmony cartridge:

 ex_sprite_with_ball_missile_and_collision_2011y_06m_10d_0334t.bin   4K   50 downloads


Here's the bB code:

 ex_sprite_with_ball_missile_and_collision_2011y_06m_10d_0334t.bas   29.67K   40 downloads


I think it took about a week, but I finally got the ball to bounce around without screwing up and acting weird. I'm still not happy with the code. After trying all kinds of things, it started working, but I don't know why or how. If someone with a bigger brain can make it work using better code, I'd appreciate it.

The fake collision detection for the Player0 sprite using pfread works, but it's not as good as I'd like it to be. The sprite can overlap playfield pixels a little bit depending on how you move. Again, if anyone can improve on the code, please do so.

It would be nice if this example program was in better shape before I put it on the bB page.

Edited by Random Terrain, Mon Jun 20, 2011 11:32 AM.

[Random Terrain]

If nobody has any ideas right now, I'll put this on the bB page the way it is, then update it with better code in the future.

[ScumSoft]

I was working on something, but it doesn't work any better than your code does. It's fine for learning purposes as is.

[Philsan]

Random Terrain, on Fri Jun 10, 2011 2:02 AM, said:

Here's the .bin file to use with an emulator or Harmony cartridge:

Only now I realize you made a manual for Harmony cartridge.
You're the best!

[Random Terrain]

Philsan, on Sat Jun 11, 2011 2:50 AM, said:

Random Terrain, on Fri Jun 10, 2011 2:02 AM, said:

Here's the .bin file to use with an emulator or Harmony cartridge:

Only now I realize you made a manual for Harmony cartridge.
You're the best!

I didn't make it, I just made an adapted HTML version of the official PDF file for people who don't like to use PDF files. The page originally wasn't even going to have the manual on it:

http://www.atariage....74#entry2269074

ScumSoft, on Sat Jun 11, 2011 2:15 AM, said:

I was working on something, but it doesn't work any better than your code does. It's fine for learning purposes as is.

Thanks for trying. Maybe something will pop into one of our brains some time in the future to make it better.

Edited by Random Terrain, Sat Jun 11, 2011 10:08 AM.

[Random Terrain]

New version in first post.

An idea about how I could improve this program popped into my head when I was sitting in the car yesterday, so I tried it last night and it worked. It still has the same smooth movement as you slide around the 'walls,' but now the sprite won't overlap the playfield pixels.

[Random Terrain]

In case anyone was wondering, if some of the example programs I'm adding to the bB page are a little too advanced for beginners, I'm not going to worry about it. They'll eventually need this stuff. I wish I had this smooth fake/real wall collision a few years ago. Oh well, at least I have it now. It should be useful when I eventually make my adventure game. I might even be able to adapt part of the code to use with Seaweed Assault.

Edited by Random Terrain, Thu Jun 16, 2011 6:03 PM.

[Random Terrain]

Here are the example programs I have so far on the bB page:

Move Sprite

Sprite with Missile

Sprite with Ball

Sprite with Ball, Missile, and Collision

Sprite/Playfield Priority

Sprite Using Fixed Point Variables

Sound Example Using Data and Bankswitching



Can you think of others I should make before I go back to trying to get some games finished?

[SeaGtGruff]

Random Terrain, on Fri Jun 10, 2011 2:02 AM, said:

It no longer overlaps the playfield pixels.

If there's no overlapping of pixels, then it isn't "collision detection," because a collision occurs only when the pixels of two objects overlap. What you're doing is "collision prevention"! Now if you could just find a way to apply your algorithms to the transportation industry, you'd make the highway patrol and insurance companies very, very happy!

Michael

[Random Terrain]

SeaGtGruff, on Sun Jun 19, 2011 4:30 AM, said:

If there's no overlapping of pixels, then it isn't "collision detection," because a collision occurs only when the pixels of two objects overlap. What you're doing is "collision prevention"!

Oops. I reworded the first post so it would be more clear. It uses a combination of 'collision prevention' and 'collision detection' to make the sprite behave properly.

[abaudrand]

its very impressive even I don't catch how do you make it.