Repetition Restrainer - Collision Detection

[KevKelley]

I had gone through RT's site and examples and was able to get a repetition restrainer to work just like in the example, but only when using a check on joy0fire.

 

I had attempted to use the same code for collision detection between 2 sprites but I seem to having some difficulty, where the collision continues to be registered, so things like the score (or whatever I use) rapidly go up.

 

I had attempted to respawn one of the sprites and that would sometimes work. I had also considered using a check using a temp variable, as I had used something similar to prevent an action if it occurs too quickly below a certain y-coordinate. Maybe checking the coordinates before and after spawning and then award points or whatever.

 

I know that there are usually more than one way to do something but was wondering if I was overcomplicating things or if there was a better way.

[+Karl G]

There's no reason I can think of that a repetition restrainer bit shouldn't work just as well for collisions as it does for button presses, etc. Maybe you can post some sample code that's not working?

 

Now that I think of it, though, it may be failing in the case of flicker - one frame it may be colliding, and you set your bit. The next frame that sprite is flickered off, so the collision doesn't register, so you clear the restrainer bit. The following frame that sprite is flickered back on, so it registers as a new collision.

 

One solution would be to switch to some kind of software collision detection instead of hardware. Another would be a variable like you say to require a certain number of frames with no collision before you count a new collision again.

[KevKelley]

43 minutes ago, Karl G said:

There's no reason I can think of that a repetition restrainer bit shouldn't work just as well for collisions as it does for button presses, etc. Maybe you can post some sample code that's not working?

 

Now that I think of it, though, it may be failing in the case of flicker - one frame it may be colliding, and you set your bit. The next frame that sprite is flickered off, so the collision doesn't register, so you clear the restrainer bit. The following frame that sprite is flickered back on, so it registers as a new collision.

 

One solution would be to switch to some kind of software collision detection instead of hardware. Another would be a variable like you say to require a certain number of frames with no collision before you count a new collision again.

I had tried boundary boxes on all mixed with collision statements when I was playing around with NUSIZ copies but can't recall if those performed better. I wound up getting rid of some in an attempt to clean things up. I was playing around with different options. 

 

I'm still not that experienced using bits so I was hoping to understand better hoping my attempts were something I overlooked. I'll try to post some relevant code later if I don't come up with a workable solution.

 

 

[+Random Terrain]

See if this helps at all. Move the sprite on top of the other sprite to increase the score by one. Move completely off and back on to do it again.

 

 

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

temp_ex_sprite_col_bit_2020y_02m_03d_1246t.bin

 

Here's the bB code:

temp_ex_sprite_col_bit_2020y_02m_03d_1246t.bas

[KevKelley]

I feel like an idiot.  I was staring at my screen for hours last night combing through the code, going through line by line and trying different ways around...

 

Turns out that i had accidentally labeled the sprites in a collision statement elsewhere which is why it kept on adding!  The example you had provided worked!  I am sure the other lines that I was playing around with would do well too.  I guess it is good to call it quits some nights and take a break! 

 

At least I got familiar with the process so there is that I guess...