Collision Prevention With Adjustable Sprite Height and Width

[+Random Terrain]

I wanted to create an example program where the user can have collision prevention with different sprite heights and widths. I've been working on this for about 8 days and it finally seems to be done.

 

I tried it with different superchip resolutions, but smaller row heights use up too many cycles. It should work with the DPC+ kernel using 11 rows, but I haven't tried it yet. I'll make a DPC+ version in a day or two.

 

I still see little problems here and there when testing. If anybody has ideas that could improve the program, please post your version of the code. I'd like to get this working correctly before putting it on the batari Basic page.

 

ex_cp_with_adjustable_h_and_w_2015y_06m_09d_0744t.bin

 

ex_cp_with_adjustable_h_and_w_2015y_06m_09d_0744t.bas

 

 

Instructions

 

Hold down the fire button and press the joystick up or down to change the height of the sprite. Hold down the fire button and move the joystick left or right to change the width of the sprite.

 

To move the sprite, release the fire button and press the joystick in any direction.

 

This program uses a combination of collision prevention and collision detection to get rid of the sticky wall problem that a lot of games have. The sprite smoothly glides along the playfield pixels instead of sticking to them or repeatedly bouncing off them.

 

The left side of the score shows the sprite height. The right side of the score shows the y position of the sprite.

[STGraves]

Incredible, very nice work, very nice RT.

[STGraves]

I ran into a problem while adding it to my game, the playfield only sometimes scrolls left or right but not up or down, and when I use the fire button it randomly flickers and changes the sprite size and resets to whatever loop it wants, I got lost with no idea on what am I doing.

[STGraves]

I solved the sprite changing size randomly, but still flickers a lot, and also sometimes the sprite gets stuck in walls and also the pfscroll is not working at times and on specific locations.

[+Random Terrain]

Make sure that you're not blindly copying and pasting things without using your brain. For example, if you copy over dims that use the same variables as other dims in your game, you'll need to change the variables to ones that aren't already used in your program. And the whole fire button subsection from my example program should not be copied. It's only for the example program. You wouldn't want to have it in an actual game.

[STGraves]

Yes I know, the fire button section was completely ignored as I figured it's unnecessary, and yes I'm aware about the variables, since I didn't have enough available I decided to use one or two of the ones that can have multiple values (in my game of course) like the Y

[+Random Terrain]

Yes I know, the fire button section was completely ignored as I figured it's unnecessary, and yes I'm aware about the variables, since I didn't have enough available I decided to use one or two of the ones that can have multiple values (in my game of course) like the Y

 

Then how was the sprite size changing when you pressed the fire button?

 

If y is the one that is used for various bits, it can't be used as a full variable for another purpose.

[STGraves]

Ohh I didn't know, I did it because I don't have enough free variables.

[STGraves]

Is there a way to do so without the use of Nybbles or switching to the superchip ram?

[STGraves]

If anyone can, will you help me out checking what am I doing wrong? Or try to help me to find a fix to the variables problem? Thanks, I attach here my code.

etsrev3.bas

[+Random Terrain]

If anyone can, will you help me out checking what am I doing wrong? Or try to help me to find a fix to the variables problem? Thanks, I attach here my code.

If you always use dim and put the dims in alphabetical order, it will be easy for anybody to tell how many variables you have left. I'm not going to go through your code on a variable hunt.

 

Example:

 

dim _Fart_Jelly = a

 

dim _Apple_Nuts = b

 

dim _Tasty_Toenails = p

 

dim _Crystal_Crab = r

[STGraves]

Ok, let me do it.

[STGraves]

Here it is, all of the variables are ordered, and almost all are completely different, except for two which I had to put under the "i" variable, which are _Sprite_Height and _Spritex_Width, I don't know what else I'm doing wrong.

etsrevstg.bas

[+Random Terrain]

Here it is, all of the variables are ordered, and almost all are completely different, except for two which I had to put under the "i" variable, which are _Sprite_Height and _Spritex_Width, I don't know what else I'm doing wrong.

 

Have you read these section yet?

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#bit

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dim_descriptive_names

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#bitop_remember

 

 

You need to understand the difference between a full variable and a bit or you will keep screwing up your program over and over and over and over and over and over and over again.

 

A variable is made up of 8 bits. You can use those 8 bits separately like tiny variables that can only be on or off. If you are using the bits of a variable to do certain jobs, you can't start using the whole variable for other jobs or you will screw up the bits you are already using.

 

_Spritex_Width and _Sprite_Height require their own variables, so trying to make them share a variable that is already being used for bits will only screw things up. If your sprite never changes width, you don't need _Spritex_Width. And if you know how tall your sprite is, you don't need _Sprite_Height. I'll make a version of my example program that doesn't use adjustable width and height and see if that helps any.

[STGraves]

Thanks RT, I really appreciate it, I'm sure it's gonna be quite helpful.

[+Random Terrain]

Try this:

 

ex_cp_with_adjustable_w_removed_2015y_06m_12d_0023t.bin

 

ex_cp_with_adjustable_w_removed_2015y_06m_12d_0023t.bas

 

There's a good chance that it won't work with scrolling anyway, so this might be a waste of time.

[STGraves]

Ok Thanks a lot RT, I'll check it tomorrow, here in MX is quite late and I gotta sleep, thanks again.

[STGraves]

You were right RT, it didn't work, but you gave an idea on how to change the game to something different and cool without using pfscroll at all.

[STGraves]

Of course I'm gonna use your code to improve the playability of my game I hope you don't mind. Thanks

[STGraves]

How can I use the collision with both players at the same time? I mean both player1 (main character) and player0 (ET). Because ET passes through the PF and kills you very easily, I attach the newest code here.

plyr1.bas

Edited October 5, 2015 by STGraves