Stupid question I probably shouldn't be asking...

[Dragnerok X]

Done.

 

Here's what I have now.

 

Combat_DX.bas

 

Combat_DX.bas.bin

 

These should now be 100% version 1.0 compatible.

 

I've set up a generic "fortress" map, but plan on relocating my maps to their own bank for additional carnage (and set some sort of selection scheme up, say that ten times fast).

 

As you can see, the missiles' interaction with the playfield works perfectly, I just haven't found a reasonable way to do the player's collision yet (any ideas ).

 

Still, I think this game is evolving quite nicely.

[Dragnerok X]

Maybe I didn't word this right.

 

As you can see, the missiles' interaction with the playfield works perfectly, I just haven't found a reasonable way to do the player's collision yet (any ideas ).

 

With my current set-up, what is the best way to handle collisions between the player and the playfield?

[SeaGtGruff]

Maybe I didn't word this right.

 

As you can see, the missiles' interaction with the playfield works perfectly, I just haven't found a reasonable way to do the player's collision yet (any ideas ).

 

With my current set-up, what is the best way to handle collisions between the player and the playfield?

 

How do you want it to behave? For example, do you want the tanks to get bumped back if they start to run into a wall? That's easy to do, and there are a few examples for posted somewhere in these forums.

 

Or do you want to keep the tanks from being able to overlap the walls by even 1 pixel (i.e., to prevent the tank from ever colliding with a wall in the first place)? That's trickier to do, because it requires that you convert the tanks' player-pixel coordinates into their equivalent playfield-pixel coordinates, and then use the pfread function to "look ahead" at the next adjacent playfield pixel to determine whether or not the tank can move into that spot.

 

Michael

[Dragnerok X]

Maybe I didn't word this right.

 

As you can see, the missiles' interaction with the playfield works perfectly, I just haven't found a reasonable way to do the player's collision yet (any ideas ).

 

With my current set-up, what is the best way to handle collisions between the player and the playfield?

 

How do you want it to behave? For example, do you want the tanks to get bumped back if they start to run into a wall? That's easy to do, and there are a few examples for posted somewhere in these forums.

 

Or do you want to keep the tanks from being able to overlap the walls by even 1 pixel (i.e., to prevent the tank from ever colliding with a wall in the first place)? That's trickier to do, because it requires that you convert the tanks' player-pixel coordinates into their equivalent playfield-pixel coordinates, and then use the pfread function to "look ahead" at the next adjacent playfield pixel to determine whether or not the tank can move into that spot.

 

Michael

 

I guess just bumped back, what the missiles are doing.

[SeaGtGruff]

How do you want it to behave? For example, do you want the tanks to get bumped back if they start to run into a wall? That's easy to do, and there are a few examples for posted somewhere in these forums.

 

Or do you want to keep the tanks from being able to overlap the walls by even 1 pixel (i.e., to prevent the tank from ever colliding with a wall in the first place)? That's trickier to do, because it requires that you convert the tanks' player-pixel coordinates into their equivalent playfield-pixel coordinates, and then use the pfread function to "look ahead" at the next adjacent playfield pixel to determine whether or not the tank can move into that spot.

 

Michael

 

I guess just bumped back, what the missiles are doing.

 

Here are a few threads that may help:

 

http://www.atariage.com/forums/index.php?s...t&p=1056561

http://www.atariage.com/forums/index.php?s...t&p=1162438

 

These show examples of bumping the player back when it runs into a wall. In particular, you might want to look at the "move_around_rooms" program in the second thread, because I tried to keep the code very easy-to-follow (at least, once you get past all the data statements at the beginning ).

 

Here's another thread in which converting between player coordinates and playfield coordinates was discussed, although the horizontal player coordinates will be a bit different for bB version 1.0:

 

http://www.atariage.com/forums/index.php?s...st&p=900612

 

Note that if you want to run any of the programs in these threads, it would probably be best to download and run the BIN files, rather than recompiling the BAS files with bB 1.0-- although you should of course look at the BAS code to see what's being done!

 

Michael

[supercat]

I guess just bumped back, what the missiles are doing.

 

If you want non-quirky behavior, you should keep track of each player's state before each move, and reset the player to the previous state whenever a wall is encountered. Bumping the player backward when a wall is encountered may generally work, but it may result in weird teleporting effects (as in Combat).

[SeaGtGruff]

I guess just bumped back, what the missiles are doing.

 

If you want non-quirky behavior, you should keep track of each player's state before each move, and reset the player to the previous state whenever a wall is encountered. Bumping the player backward when a wall is encountered may generally work, but it may result in weird teleporting effects (as in Combat).

 

The way I do it is to use two variables for the x and y *directions*, in addition to the two variables for the x nad y *positions*:

 

  dim p0_x = b
  dim p0_y = c
  player0x = 92
  player0y = 47

loop
  p0_x = 0
  if joy0left then p0_x = 255
  if joy0right then p0_x = 1
  player0x = player0x + p0_x

  p0_y = 0
  if joy0up then p0_y = 255
  if joy0down then p0_y = 1
  player0y = player0y + p0_y

  drawscreen
  if collision(player0,playfield) then gosub knock_player_back
  goto loop

knock_player_back
  player0x = player0x - p0_x
  player0y = player0y - p0_y
  return

 

Thus, if the player is *not* moving horizontally, the x direction will be 0, otherwise it will be 255 (-1) when moving left, or 1 when moving right. Likewise, the y direction will be 0 if the player is *not* moving vertically, or 255 (-1) if moving up, or 1 if moving down.

 

This assumes that the x coordinate increases from left to right, and the y coordinate increases from top to bottom. If the y coordinate runs in the other direction (increasing from bottom to top, or decreasing from top to bottom), then use a y direction of 255 to move down, and a y direction of 1 to move up.

 

Also, you could move 2 or more positions at a time, such as 254 (-2) to move left 2 positions, and 2 to move right 2 positions.

 

Michael

[Dragnerok X]

Thanks for the info. Supercat, Mike. I'll get started right away.

[Dragnerok X]

O.k. I'm trying to free a byte of memory for use in a routine similar to Mike's. I figured that the easiest way to do this would be to use bit operations. So I took the variables e and h, and turned them into e{0} and e{1}, freeing up h. The problem is, it's just not compiling for some reason.

 

Ideas?

 

Combat_DX.bas

[SeaGtGruff]

O.k. I'm trying to free a byte of memory for use in a routine similar to Mike's. I figured that the easiest way to do this would be to use bit operations. So I took the variables e and h, and turned them into e{0} and e{1}, freeing up h. The problem is, it's just not compiling for some reason.

 

Ideas?

 

Combat_DX.bas

It's the way you used e{0} and e{1} in the if statements. You can use "e{0} = 0" or "e{0} = 1" to *set* a given bit, but if you want to *test* the bit in an if statement, then you have to use "e{0}" by itself to test if e{0} is true (set to 1), or "!e{0}" to test if e{0} is false (set to 0).

 

I used search and replace to find and correct all of those problems, and it compiles now.

 

Michael

combat_DX.bas

[Dragnerok X]

O.k. I'm trying to free a byte of memory for use in a routine similar to Mike's. I figured that the easiest way to do this would be to use bit operations. So I took the variables e and h, and turned them into e{0} and e{1}, freeing up h. The problem is, it's just not compiling for some reason.

 

Ideas?

 

Combat_DX.bas

It's the way you used e{0} and e{1} in the if statements. You can use "e{0} = 0" or "e{0} = 1" to *set* a given bit, but if you want to *test* the bit in an if statement, then you have to use "e{0}" by itself to test if e{0} is true (set to 1), or "!e{0}" to test if e{0} is false (set to 0).

 

I used search and replace to find and correct all of those problems, and it compiles now.

 

Michael

 

Thanks for the help, Mike!

 

Time to implement this beast...

[Dragnerok X]

Wow, that was a pain!

 

I've gotten the collision to work, yet it seems a bit jittery for some reason, and at that in un-expectable places (the edge of the map, for example) It probably has to do with something I've implemented wrong. (scroll down)

 

Oh well.

 

The good news is during this time, I was able to free up an extra 7 variables (originally joystick control latches) using bit-operations.

 

Here's what I have now.

 

Combat_DX.bas

 

Combat_DX.bas.bin

 

Any help towards fixing the collision problem (that means you, Mike ) would be appreciated.

Edited March 31, 2007 by Dragnerok X

[Dragnerok X]

I've gotten the collision to work, yet it seems a bit jittery for some reason, and at that in un-expectable places (the edge of the map, for example) It probably has to do with something I've implemented wrong.

 

Well... as it turns out, my complicated problem was fixed with a simple line of code.

 

  if c <> 6 && collision(player0,playfield) then goto skip_clear
  k = 0 : l = 0 : m = 0 : n = 0
skip_clear

 

You see, the routine wasn't syncing up with my tanks slow-down ticker, so I added "if c <> 6 then goto skip_clear", but that made the tank move too fast. I finally thought...

 

...oooOOO(Hey! Why not just speed it up only when it touches the playfield?)

 

...and that's what lead to what you see now. I hope you like it.

 

Combat_DX.bas

 

Combat_DX.bas.bin

 

My next peril is trying to tweak the random generator so it doesn't land you on the playfield.

 

Ideas? Possibilites?

Edited March 31, 2007 by Dragnerok X

[SeaGtGruff]

I'm glad you got your collision problem worked out. I was away from my keyboard-- work of course, followed by my usual Friday night after-work movie-- this week it was "Meet the Robinsons." (One of my favorite lines in the movie was "Let's see... Take responsibility for my own life, or blame you?... Blame you wins hands down!")

 

My next peril is trying to tweak the random generator so it doesn't land you on the playfield.

 

Ideas? Possibilites?

 

As I see it, there are at least three possibilities:

 

(1) Let the tank appear at some random location, but then (after the screen's been drawn) check for a collision between the tank and the playfield, and if one is detected, loop back to where you position the tank at a random location, and keep doing that until there's no collision. Drawback: Since you can't detect a collision until after the screen's been drawn, this method can result in the tank popping up at several locations until an acceptable spot has been found, which could make it look like the program has some kind of glitch.

 

(2) As soon as you get a new random location for the tank, use pfread to check if its new position is overlapping a playfield pixel-- i.e., before you actually draw the screen. Then keep looping back to get another random location (still before displaying the screen) until pfread indicates that the tank won't be overlapping any playfield pixels.

 

(3) For a particular playfield formation (or maze), predetermine what the acceptable locations could be for that maze-- i.e., you would have a table of safe locations for each maze-- and then randomly choose one of the safe locations. This would work best if you divide the playing area into a certain number of equal-sized zones, so the list of safe locations for a given maze wouldn't be too long.

 

Michael

[+atari2600land]

Or you could do this:

222 a = rand 
223 if a>140 || a<35 then goto 221 
224 b = rand
225 if b>80 || b<10 then goto 223
226
if collision(playfield,player1) then a=a+5

Where a is playerx and b is playery. Since a playfield pixel is 4 pixels wide, this option moves the player sprite (in this case, a tank) 5 notches to the right before it shows up on the screen. You might have to fiddle with the 5 in line 226 to get a number that works. That's my 2 cents.

 

EDIT:

I tried this in a demo and it didn't work. Just go with SeaGtGruff, I always do.

Edited March 31, 2007 by atari2600land

[Dragnerok X]

I'm glad you got your collision problem worked out. I was away from my keyboard-- work of course, followed by my usual Friday night after-work movie-- this week it was "Meet the Robinsons." (One of my favorite lines in the movie was "Let's see... Take responsibility for my own life, or blame you?... Blame you wins hands down!")

 

Actually, I'm kind of surprised you (nor me) hadn't noticed half of the bugs my routine set up, which made last night a very busy night for me, but still, half of them only occur in situations you would never hope to get into. Here's a short(ened) list.

 

Green = Fixed Red = Not Fixed

 

-----------------------------------------------------------------------------------

 

Apply player 0's jitter-control to player 1.

 

Apply jitter-control to the sides of the map.

 

Re-adjust boundries due to jitter-control.

 

Keep either player from pushing each other through walls upon collision.

 

Either player had the ability to touch a wall, then speed the other player up.

 

When colliding with an object/wall, the tank moves, but the ball stays in place.

 

Keep players from getting "stuck" on the corners of walls.

 

Fix random number generator due to walls.

 

-----------------------------------------------------------------------------------

 

As you can see, I was busy last night.

 

No movies for me, to say the least.

 

My next peril is trying to tweak the random generator so it doesn't land you on the playfield.

 

Ideas? Possibilites?

 

As I see it, there are at least three possibilities:

 

(1) Let the tank appear at some random location, but then (after the screen's been drawn) check for a collision between the tank and the playfield, and if one is detected, loop back to where you position the tank at a random location, and keep doing that until there's no collision. Drawback: Since you can't detect a collision until after the screen's been drawn, this method can result in the tank popping up at several locations until an acceptable spot has been found, which could make it look like the program has some kind of glitch.

 

(2) As soon as you get a new random location for the tank, use pfread to check if its new position is overlapping a playfield pixel-- i.e., before you actually draw the screen. Then keep looping back to get another random location (still before displaying the screen) until pfread indicates that the tank won't be overlapping any playfield pixels.

 

(3) For a particular playfield formation (or maze), predetermine what the acceptable locations could be for that maze-- i.e., you would have a table of safe locations for each maze-- and then randomly choose one of the safe locations. This would work best if you divide the playing area into a certain number of equal-sized zones, so the list of safe locations for a given maze wouldn't be too long.

 

Michael

 

I myself like idea #1. It seems the easiest to implement. A (possible) work-around to keep the generator from looking like a bug would be to set the background and all objects to black, or in binary, %00000000. Just an idea.

 

EDIT:

I tried this in a demo and it didn't work. Just go with SeaGtGruff, I always do.

 

Will do, though your routine probably would work if you placed that last line after your drawscreen.

 

Oh, and before I forget. Here's the current build.

 

Combat_DX.bas

 

Combat_DX.bas.bin

[SeaGtGruff]

Or you could do this:

222 a = rand 
223 if a>140 || a<35 then goto 221 
224 b = rand
225 if b>80 || b<10 then goto 223
226
if collision(playfield,player1) then a=a+5

Where a is playerx and b is playery. Since a playfield pixel is 4 pixels wide, this option moves the player sprite (in this case, a tank) 5 notches to the right before it shows up on the screen. You might have to fiddle with the 5 in line 226 to get a number that works. That's my 2 cents.

 

EDIT:

I tried this in a demo and it didn't work. Just go with SeaGtGruff, I always do.

The reason it doesn't work is because when you change an object's position, you can't detect any collisions for the new location until *after* you've drawn the screen using the object's new location-- at least, not using the collision latches. Any detections that you might appear to be detecting will be from the object's *old* location, the position it had when the screen was last drawn. Of course, you can still use the collision detection (*after* redrawing the screen), as long as you don't mind if the objects flickers about at different spots on the screen until it finally lands in a spot where it doesn't collide with the playfield.

 

That's why I suggested pfread as an alternative, because you can check the playfield position(s) that correspond to the object's new location, to see if any of them are turned on-- i.e., you're trying to predict whether a collision will occur *before* you redrawn the screen and a collision actually occurs.

 

Michael

[SeaGtGruff]

(1) Let the tank appear at some random location, but then (after the screen's been drawn) check for a collision between the tank and the playfield, and if one is detected, loop back to where you position the tank at a random location, and keep doing that until there's no collision. Drawback: Since you can't detect a collision until after the screen's been drawn, this method can result in the tank popping up at several locations until an acceptable spot has been found, which could make it look like the program has some kind of glitch.

 

(2) As soon as you get a new random location for the tank, use pfread to check if its new position is overlapping a playfield pixel-- i.e., before you actually draw the screen. Then keep looping back to get another random location (still before displaying the screen) until pfread indicates that the tank won't be overlapping any playfield pixels.

 

(3) For a particular playfield formation (or maze), predetermine what the acceptable locations could be for that maze-- i.e., you would have a table of safe locations for each maze-- and then randomly choose one of the safe locations. This would work best if you divide the playing area into a certain number of equal-sized zones, so the list of safe locations for a given maze wouldn't be too long.

 

Michael

 

I myself like idea #1. It seems the easiest to implement. A (possible) work-around to keep the generator from looking like a bug would be to set the background and all objects to black, or in binary, %00000000. Just an idea.

The only problem with that would be that the screen might be blank for a bit, which would also look like a glitch.

 

Idea #3 shouldn't be difficult to implement, although the lists of "safe locations" for each maze would use up some ROM.

 

Idea #2 also shouldn't be too difficult to implement, especially if you combine it with part of what I said in idea #3-- divide the playing area into a number of equal-sized zones, such that any random position the tank might be given will correspond to no more than 2 playfield pixels. In other words, you would be finding a random x value between 0 and 30 (the number of playfield pixels across the screen, minus 1), then multiplying it by 4 (because a playfield pixel is 4 times as wide as a player pixel), and then adding a fixed offset value to end up with the player's new x value. You would do something similar for the y position-- find a random value between 0 and 11 (the number of playfield rows), multiply 8 (because playfield pixels are 8 times as tall as player pixels), and add a fixed offset to get the player's new y value. In fact, if you do it this way, then it should be easier to check for a possible collision, because after you generate the random x and y values, you can immediately use them with pfread to check the playfield pixels.

 

Michael

[Dragnerok X]

The only problem with that would be that the screen might be blank for a bit, which would also look like a glitch.

 

O.k. then, other possibilites. How about doing this except having the screen color the same as the victor? As in Red wins = Red, Blue wins = Blue, Tie = White. You could even use the score to add in a message to the player(s) while waiting (with a bit of hacking).

 

Idea #3 shouldn't be difficult to implement, although the lists of "safe locations" for each maze would use up some ROM.

 

...and I want as much room for mazes/code as possible, so that's out.

 

Idea #2 also shouldn't be too difficult to implement, especially if you combine it with part of what I said in idea #3-- divide the playing area into a number of equal-sized zones, such that any random position the tank might be given will correspond to no more than 2 playfield pixels. In other words, you would be finding a random x value between 0 and 30 (the number of playfield pixels across the screen, minus 1), then multiplying it by 4 (because a playfield pixel is 4 times as wide as a player pixel), and then adding a fixed offset value to end up with the player's new x value. You would do something similar for the y position-- find a random value between 0 and 11 (the number of playfield rows), multiply 8 (because playfield pixels are 8 times as tall as player pixels), and add a fixed offset to get the player's new y value. In fact, if you do it this way, then it should be easier to check for a possible collision, because after you generate the random x and y values, you can immediately use them with pfread to check the playfield pixels.

 

This sounds a bit more promising then the last one. If you can provide some example code to get me started, I'll seriously consider it. Otherwise, I'm sticking with idea #1.

[SeaGtGruff]

I added a routine to get a "safe" random tank position, and I also added the "get_rand" function that I'd posted in another thread. To see the changes, check the very beginning of the program to see the four new variables (tank_x, tank_y, x_y, and tank_direction), then search the code for those variable names.

 

Michael

Combat_DX.bas

Combat_DX.bas.bin

Edited April 2, 2007 by SeaGtGruff

[Dragnerok X]

I added a routine to get a "safe" random tank position, and I also added the "get_rand" function that I'd posted in another thread. To see the changes, check the very beginning of the program to see the four new variables (tank_x, tank_y, x_y, and tank_direction), then search the code for those variable names.

 

Michael

 

Wow!

 

You've gone above and beyond my expectations and have even implemented this for me. I, unfortunatly, had to work on my game some since last, so a little bit of copy/paste is in order. No matter, that was still very nice of you and all I can say is many thanks and I'll post a newer (though still not complete) binary later tonight.

 

Again, I can not say thank you enough!

 

[Dragnerok X]

Here's the updated source/binary I was talking about earlier.

 

New Features:

 

*Upped size of binary to 16k to make room for new maps.

 

*Set up a level selection system using the select switch. Uses

the score to display the current level.

 

*Added "template levels" for now, get ready for a (possible)

level design contest coming soon.

 

*Added Mike's new random position generator.

 

Bugs Fixed:

 

*Tanks are no longer stuck to walls, this was fixed with a rotation

collision detection system.

 

*The ball stays with the tank even when colliding with walls.

(but not firing, of course )

 

*Tanks no longer spawn inside the walls.

 

New/Unfixed Bugs:

 

*The players movement seems kind of rigid to me, especially when

going through tight tunnels. What about you?

 

*The random position generator sometimes (about 1/10 times) spawns a player

just past the bottom of the screen and locks up the other player's controls.

 

...and here it is.

 

Combat_DX.bas

 

Combat_DX.bas.bin

[SeaGtGruff]

New/Unfixed Bugs:

 

*The players movement seems kind of rigid to me, especially when

going through tight tunnels. What about you?

 

*The random position generator sometimes (about 1/10 times) spawns a player

just past the bottom of the screen and locks up the other player's controls.

I guess if you can speed up the players' motion a bit, that would be good.

 

The second problem is my fault. bB's standard playfield has 12 playfield rows, numbered 0 to 11, but the last one is (usually) covered up by the score bar. I used get_rand(0,11) in the randomize_tank routine, but it should have been get_rand(0,10), since you don't want the tank to appear anywhere below the last visible playfield row.

 

Michael

Combat_DX.bas

Combat_DX.bas.bin

[Dragnerok X]

New/Unfixed Bugs:

 

*The players movement seems kind of rigid to me, especially when

going through tight tunnels. What about you?

 

*The random position generator sometimes (about 1/10 times) spawns a player

just past the bottom of the screen and locks up the other player's controls.

I guess if you can speed up the players' motion a bit, that would be good.

 

The second problem is my fault. bB's standard playfield has 12 playfield rows, numbered 0 to 11, but the last one is (usually) covered up by the score bar. I used get_rand(0,11) in the randomize_tank routine, but it should have been get_rand(0,10), since you don't want the tank to appear anywhere below the last visible playfield row.

 

Michael

 

Thanks for clearing that problem up. I swear I must have been searching through that code 15 times last night looking for a typo, but apparently, a single number on a single line can make a heck of a difference these days!

 

As for your motion suggestion, I would, but I would be straying a bit too far away from the original games physics (like I haven't already ), but moreover, would have to change ~20 of my "C" timer references in the process.

 

I have, however, simplifeid my rotation collision detection a bit, making it easier to use and freeing up 100 or so bytes of rom-space. Here are the latest binary and source files.

 

Combat_DX.bas

 

Combat_DX.bas.bin

 

Now that this is pretty much as far as I can get before adding any more levels, like I said before, I propose a level design contest is in order, probably somewhat like Gosub's. Suggestions?

[+atari2600land]

How about this:

 playfield:
....................X...........
....................X...........
....XXX....XXXXXXXXXX....XXX....
....X......X...............X....
....X......X...............X....
...............XX...............
...............XX...............
....X...............X......X....
....X...............X......X....
....XXX....XXXXXXXXXX....XXX....
...........X....................
...........X....................
end

 

 

I'll be making some more levels soon. BTW, what does the game select button do?

Edited April 4, 2007 by atari2600land