Wall/Object Collision and Multiple Screen Help

[Arcade]

Okay, so here is my game so far. The game will be a 2-player game to where one controls a turkey, the other a pilgrim. The object is to shoot at each other and score the most points. I do have a silly story behind the game as well (but I won't get in to that right now). You can hide behind some "plymouth rocks" on screen (which I only have one right now). I don't have coding yet for "bullets/missiles" or a 2-player scoring mechanism. After doing a lot of research I came upon some code that allowed collision detection between the sprites. I'm going to read the explanation as to why the code does what it does as I didn't quite understand it. Now as for my questions (so far):

 

1) How do I cut down on the code, and save room?

2) How can I reverse sprites without the way I have it?

3) The collision is poor. The characters can get stuck on each other. Also, it seems the turkey can be blocked by the rock for some reason, but the pilgrim can not unless the turkey is positioned a certain way. How do I overcome being stuck to each other and allowing both to be blocked by the rock?

 

Thanks for the advice and help. By the way, when answering questions about the code, could you also explain as to "why" so I can better understand what you're saying. I've read some stuff on this site and others but to be honest I still don't understand. Dumb it down if you will for me please. This is my first time coding with batari and I def want to understand why things happen the way they do with the code.

Test.bas

Edited May 8, 2013 by Arcade

[+Random Terrain]

You can use REFP0 and REFP1 to flip sprites with the standard kernel. The Multisprite Kernel section says "although the multisprite kernel doesn't have special variables for REFPx, you can set the reflection bit for each individual sprite by using bit 3 of _NUSIZ1 or NUSIZ2-NUSIZ5, as this bit is unused by the TIA register NUSIZx."

 

If you are new to programming in general, be sure to check out these sections:

 

Basic Questions

 

Glossary of Terms

 

New to BASIC and Game Making?

 

 

I don't use the multisprite kernel, so I don't know what can and can't be done, but you still might want to check out this collision detection example for the standard kernel in case it might be helpful:

 

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

[iesposta]

1) How do I cut down on the code, and save room?

 

You are alreading saving space by putting variable declarations that are the same on one line separated by colons. As in "b = 0: c = 0: d = 0" If you have others with the same value, it doesnt have to be 0, put them on the same line. This creates smaller code because it compiles to "load a number and put it in b, c, and d," instead of "load 0 put it in b, load zero put it in c, load 0 put it in d." That is the best I can explain it.

 

Use "return thisbank" instead of just "return." I don't know if that will save space here because you are only using one bank.

 

Space saving tips are in this thread: http://atariage.com/forums/topic/186611-squeezing-the-bbytes/

[+Random Terrain]

Space saving tips are in this thread:

 

I think you are missing a link.

[iesposta]

Yep, had to search it out.

I often make multiple edits (which sucks if you read them in mail).

[Arcade]

Thanks so much to both of you! I did the REFP0 and REFP1 deleting the old flipped pixel code. I also cut back and put a-d in the same line. Def added some memory back (not like I'm going to use up a lot but every little bit helps and will be noted for any future games I might work on!) Now I'm noticing two problems with the code and want to ask if you can help solve it...

 

1) If you notice in the code I have Player 1 (NOT 0) set at a brownish color...yet he is black if you test the code.

2) My Player 0 can turn around now with the REFP0 yet Player 1 can't...I'm guessing there is some kind of flaw with him, perhaps it also relates to the above question as well? I set REFP1 to 0 and 8 just to test...neither will flip him.

 

Here's the updated code by the way. Also IESPOSTA, could you show me code wise what you mean as far as putting all the declarations as 0 instead of loading each letter as 0? Thanks!

Test.bas

Edited May 6, 2013 by Arcade

[iesposta]

You could:

 

player0y=50: player1y=50

I never used the multisprite kernel, but I think you have to use:

_NUSIZ1{3}=1

That sets virtual sprite 1's bit 3 to on, which should flip player1.

[Arcade]

Here's what I got:

 

a=0: b=0: c=0: d=0

if joy0right then a=1

if joy0left then a=255: REFP0=8

if joy0up then b=1

if joy0down then b=255

player0x=player0x+a

player0y=player0y+b

 

if joy1right then c=1: _NUSIZ1{3}=1

if joy1left then c=255: _NUSIZ1{3}=0

if joy1up then

 

Thanks to this P0 can flip, as well as P1. P1, however, can STAY flipped whereas P0 goes back to his "default". I don't like when they go back to default. Any suggestions? By the way I got my P1 color fixed...I put the _ in front of his color and he is all dandy now! So that's another question solved!

[+Random Terrain]

The sprite flipping stuff has to be used before every drawscreen for it to work properly. If you know how to use Bit Operations, you can turn a bit on and off for each sprite to let the program know which way each sprite should be facing. Here's an example from a maze example program:

 

  REFP0 = 0

  if _Bit6_Flip_P0{6} then REFP0 = 8

[Arcade]

I'm still not understanding. I was looking over your maze code and thought I might have had an idea, but after some experimentation, I still can't get my turkey sprite to stay turned left until the joystick is pressed right again.

 

I would either get him to stay left completely, look left and only turn right (so it was vice versa the original code). I'll post my code that I have again so far. If you have any suggestions on how to change up my sprite movement/collision code that would be great. Perhaps the change will allow for me to then have BOTH sprites continue to face the direction they were told to walk to UNTIL a new direction is commanded.

Test.bas

[bogax]

again, I'm no expert

 

I don't think you have to keep

setting the players and playfield

inside of main. you could move

the main label to after the player2

statement.

 

I think the turkey doesn't remember

which way it's going after a drawscreen

so you need to remember for it and tell

it before each drawscreen

(the if statements only tell it if it's

actually moving)

 

You can code negative one as -1 instead

of 255 (personaly, I prefer 255)

 

player2:
%11111111
%11011111
%11011111
%11000011
%11011011
%11000011
%01111110
%00111100
end

dim rp0 = p

main

a=0: b=0: c=0: d=0
if joy0right then a=1 : rp0 = 0
if joy0left then a=-1: rp0 = 8
if joy0up then b=1
if joy0down then b=-1
REFP0 = rp0 
player0x=player0x+a
player0y=player0y+b

 

That's just a snippet so you can see what

I'm suggesting.

You wouldn't need to dim a variable and

when I do I put all the dim statements at

the beginning of code.

[Arcade]

Thanks so much bogax! That def fixed my problem! And thanks to you too, RT...I know this is what you were telling me, but I didn't understand you at the time because I misread something in your post.

 

I kept the player colors inside the main...if I took them out, the player colors stayed the same except Player0...the sprites defaulted to black. Don't quite understand as to why, so I will just keep it in the main so they will stay their coded colors.

 

The collision is still glitchy with the P0 sprite, but I tested and found if pressing up and I wiggle back and forth, he will squeeze out of whatever he's stuck in (usually the rock). If, however, the turkey gets stuck in the rock, P1 can NOT move.. Thinking about it, I do understand that this is a glitch. However, could this actually be a useful glitch during the game so as P1 can't take advantage of P0 being stuck? Sounds good to me so far...now I just need to get collision detection down for P1 with the rock. P0 detects collision with P1 and P2 (aka the rock). P1 only detects with P0 so I'm going to look in to that and hope that I can figure this one out.

[bogax]

 

I kept the player colors inside the main...if I took them out, the player colors stayed the same except Player0...the sprites defaulted to black. Don't quite understand as to why, so I will just keep it in the main so they will stay their coded colors.

 

oops, yup. good idea, I should have moved them inside the main loop

[Arcade]

Got a few new questions, figured I'd edit the topic instead of making a new one...In wanting to learn more about Batari, I switched to a new program to test out collision detection.

 

I can get the detection down within close border. However, I wanted to test going from Room 1 to Room 2. I tried the old collision detection and of course I couldn't go past a certain point, even with there being a "hole in the wall". I'm guessing this is because it's not looking at there being a hole, it's looking at the code stating "don't go beyond this point".

 

I've read over some of RT's code numerous times with collision detection (sprite and collision detection) but I'll admit I didn't understand it. With the help I received in my previous thread I'm starting to understand why certain things have to be coded like they are (not all of it but I do understand more of it now).

 

So here are some questions...

 

1) How can I check for collision detection ONLY if there is actually something in the way? (This also does NOT have to relate to just walls, i.e. if I decide to throw a few "blocks" in the middle, how could I detect them as well?).

 

2) How can I go from room to room after having pixel collision detection? I want my character to be stopped by any wall or brick if you will, but go through the open door I have for them.

 

I will post the code. As you can see I put the second Playfield in there only to show where I'm getting at. I know with the way it's coded the character is actually starting in Room 2 instead of Room 1. That's fine for now, as I'm sure with the help I get I can code it to how it should be. I've also left it simple as some of the things I've tried while reading over some examples didn't compile or confused the heck out of me, so I'm at the simplest code until I can get some help/dumbed down examples to help show/explain things to me.

 

Thanks again for all the help! Sorry for all the questions and needing of things dumbed down for me!

default.bas

[+Random Terrain]

When I work on a program, I just try stuff until it works and ask for help when I can't figure it out. I can barely get a useful program working, so I don't know how to explain it in a dumbed down way because I don't really understand it enough to explain it.

 

I adapted your program with code from one of my programs to make a very simple two room example with collision detection/prevention.

 

**********************************************************************************

Update

 

I made a mistake when adapting the code to work with no_blank_lines. The code below should be fixed now, but please let me know if it messes up so I can make more adjustments.

 

**********************************************************************************

 

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

 

collision_test_2013y_05m_09d_0206t.bin

 

 

Here's the bB code:

 

collision_test_2013y_05m_09d_0206t.bas

 

 

I increased the size of your sprite to 8 x 8 so I wouldn't have to spend 10 years changing the numbers in my code. If you change the size of the sprite, you'll probably have to change some of the numbers in the collision detection/prevention code to make it work correctly.

[+Gemintronic]

Please don't take this the wrong way R.T. I can't read the collision example. Meaning, I look at it and see gobbildy-gook.

 

Maybe we could come up with a dead simple, smaller set of collision examples. Maybe one mini example for each collision technique:

 

* Playfield collision using xprevious and yprevious variables.

* Playfield collision using reversing direction to avoid collision (i.e. if collision and direction is left move right a bit)

* Playfield collision using pfread

[+Random Terrain]

* Playfield collision using xprevious and yprevious variables.

* Playfield collision using reversing direction to avoid collision (i.e. if collision and direction is left move right a bit)

 

I think those sticky collision examples already exist in the example program thread.

 

 

* Playfield collision using pfread

 

That works for Pac-Man style games, but when moving around freely, you have to add in normal collision detection for those times when the sprite overlaps the playfield pixels.

[+Gemintronic]

I think an example using the concept of xprevious and yprevious would look like this:

 

 set smartbranching on
set romsize 4k

dim xprevious = a
dim yprevious = b

player0:
%00111100
%01111110
%11100111
%11000011
%11111111
%11011011
%01111110
%00111100
end

playfield:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

player0x = 33 : player0y = 33
COLUBK = $04
COLUPF = $4A

main
xprevious = player0x
yprevious = player0y

if switchreset then reboot
if joy0left then player0x = player0x - 1
if joy0right then player0x = player0x + 1
if joy0up then player0y = player0y - 1
if joy0down then player0y = player0y + 1

COLUP0 = $1A
drawscreen

if collision(player0, playfield) then player0x = xprevious : player0y = yprevious

goto main

[+Random Terrain]

Yeah, that's sticky collision.

[+atari2600land]

I found a glitch:

[SeaGtGruff]

I kept the player colors inside the main...if I took them out, the player colors stayed the same except Player0...the sprites defaulted to black. Don't quite understand as to why, so I will just keep it in the main so they will stay their coded colors.

It's because the score is drawn using player0 and player1. If you aren't setting the colors for player0 and player1 in the loop, they get stuck on the score's color, which defaults to black.

[+Random Terrain]

I found a glitch:

 

Thanks. I must have forgotten to move an important bit of code or I need to change a number.

[+Random Terrain]

I found a glitch:

 

I think I found the problem. Looks like I changed the wrong number when adjusting for no_blank_lines. I put the latest version in my post:

 

atariage.com/forums/topic/211997-wallobject-collision-and-multiple-screen-help/#entry2749720

 

Check that out when you get a chance and see if you can make it screw up. Once this is fixed, I can put a no_blank_lines version on the bB page.

 

 

Thanks.

[+atari2600land]

It looks okay to me.

[+Random Terrain]

It looks okay to me.

 

If you can't find any screw ups and nobody else does, I'll put a version of this on the bB page tonight or some time tomorrow.

 

Thanks.