Playfield boundaries?

[endrien]

Alright, so the snippet says:

   if collision(player0,playfield) then gosub knock_player_back

  goto main

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

 

Now that's perfectly fine except my code uses a different movement code:

  if joy0up then b=b-1
  if joy0down then b=b+1
  if joy0left then a=a-1
  if joy0right then a=a+1

 

So that playfield boundaries code won't work.

 

Can anyone help me adapt the code to work properly with my games code?

mainc.bas

[SeaGtGruff]

Alright, so the snippet says:

   if collision(player0,playfield) then gosub knock_player_back

  goto main

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

 

Now that's perfectly fine except my code uses a different movement code:

  if joy0up then b=b-1
  if joy0down then b=b+1
  if joy0left then a=a-1
  if joy0right then a=a+1

 

So that playfield boundaries code won't work.

 

Can anyone help me adapt the code to work properly with my games code?

Just change the knock_player_back code to use a instead of p0_x, and b instead of p0_y.

 

Michael

[endrien]

Alright, so the snippet says:

   if collision(player0,playfield) then gosub knock_player_back

  goto main

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

 

Now that's perfectly fine except my code uses a different movement code:

  if joy0up then b=b-1
  if joy0down then b=b+1
  if joy0left then a=a-1
  if joy0right then a=a+1

 

So that playfield boundaries code won't work.

 

Can anyone help me adapt the code to work properly with my games code?

Just change the knock_player_back code to use a instead of p0_x, and b instead of p0_y.

 

Michael

 

 

If I do that then my character won't appear on screen. I tried placing the code in different areas, I did get it to recognize that my character was hitting the playfield but it only made the character flicker a bit. I then tried testing the code and put the knockback values to just put my character at 50xy and it worked but it did not stop my character, it just flickered my sprite at 50xy and the character kept moving outside the playfield.

I have since put the code right after drawscreen like in the example and it makes the character not visible.

My code is attached.

mainc.bas

Edited August 30, 2010 by endrien

[SeaGtGruff]

My code is attached.

Okay, I should have looked at your code before posting my previous reply.

 

There are a few problems with the code. The biggest problem is that the overall structure needs to be modified a bit. Here's a simplified description of how it's laid out:

 

  some code ("section 1")

titlescreen

  some code ("section 2")

  drawscreen

  if joy0fire then goto start

  goto titlescreen

start

  some code ("section 3")

  drawscreen

  if collision(player1,playfield) then gosub knock_player_back

  goto start

knock_player_back

  some code ("section 4")

  return

  some code ("section 5")

  if !joy0up && !joy0down && !joy0left && !joy0right then y=30 : goto still

stillreturn

  some code ("section 6")

  if !joy0left && !joy0right then skipref

  some code ("section 7")

skipref

  goto start

still

  some code ("section 8")

  goto stillreturn

Most of the structure is okay. However, there's no way for the program to get to the code in what I've labeled "section 5" (immediately after the knock_player_back routine). And since the code after that is called only from the bottom sections (after the knock_player_back routine), none of that code will ever be performed.

 

You can correct this either by moving that code up into your main loop, and/or by changing it to subroutines and putting a gosub in your main loop to call it.

 

Another problem with the structure isn't an error per se, but prevents it from running as efficiently as it could. Namely, you're putting some things inside of your loops that don't need to be there. For example, you don't need to define the pfcolors and the playfield inside the loops, because once you define them, they'll stay that way until you redefine them. If you leave them inside the loops, they'll eat up your cycles, and you might not have time to do everything you want to do.

 

As for the player movement code-- including the routine to knock the player back if he runs into the playfield-- you've got some problems with the way you're handling the variables. If you're going to use a and b for the player's x and y motion, then you don't want to set player0x and player0y to a and b. Instead, you can just initialize player0x and player0y to where you want the player to start, then add a and b to them to make the player move. Also, you don't need to dim p0_x and p0_y, since you aren't using them in your code-- but even if you were, you've dimmed them to variables that are being used for other things.

 

I've made some modifications to your code to get it to run as I think you intended it to. I tried to keep things the way you had them as much as possible, but I added some lines, changed some lines, deleted some lines, and moved some lines. See if you can compare the new version to your original code to see where all the changes are.

 

There are some other changes you could make. For example, you're using a bunch of if statements to set each bit in variable c. Since you're setting all 8 bits in each if, you could just set c to the desired binary value with a single statement, such as c = %10000000 if you want to clear bits c{0} through c{6} and set bit c{7} to 1. The way you're doing it might be easier for you to understand, but it takes a lot more time than just setting c to the desired binary value with a single statement.

 

Michael

mainc_1.bas

[endrien]

My code is attached.

Okay, I should have looked at your code before posting my previous reply.

 

There are a few problems with the code. The biggest problem is that the overall structure needs to be modified a bit. Here's a simplified description of how it's laid out:

 

  some code ("section 1")

titlescreen

  some code ("section 2")

  drawscreen

  if joy0fire then goto start

  goto titlescreen

start

  some code ("section 3")

  drawscreen

  if collision(player1,playfield) then gosub knock_player_back

  goto start

knock_player_back

  some code ("section 4")

  return

  some code ("section 5")

  if !joy0up && !joy0down && !joy0left && !joy0right then y=30 : goto still

stillreturn

  some code ("section 6")

  if !joy0left && !joy0right then skipref

  some code ("section 7")

skipref

  goto start

still

  some code ("section 8")

  goto stillreturn

Most of the structure is okay. However, there's no way for the program to get to the code in what I've labeled "section 5" (immediately after the knock_player_back routine). And since the code after that is called only from the bottom sections (after the knock_player_back routine), none of that code will ever be performed.

 

You can correct this either by moving that code up into your main loop, and/or by changing it to subroutines and putting a gosub in your main loop to call it.

 

Another problem with the structure isn't an error per se, but prevents it from running as efficiently as it could. Namely, you're putting some things inside of your loops that don't need to be there. For example, you don't need to define the pfcolors and the playfield inside the loops, because once you define them, they'll stay that way until you redefine them. If you leave them inside the loops, they'll eat up your cycles, and you might not have time to do everything you want to do.

 

As for the player movement code-- including the routine to knock the player back if he runs into the playfield-- you've got some problems with the way you're handling the variables. If you're going to use a and b for the player's x and y motion, then you don't want to set player0x and player0y to a and b. Instead, you can just initialize player0x and player0y to where you want the player to start, then add a and b to them to make the player move. Also, you don't need to dim p0_x and p0_y, since you aren't using them in your code-- but even if you were, you've dimmed them to variables that are being used for other things.

 

I've made some modifications to your code to get it to run as I think you intended it to. I tried to keep things the way you had them as much as possible, but I added some lines, changed some lines, deleted some lines, and moved some lines. See if you can compare the new version to your original code to see where all the changes are.

 

There are some other changes you could make. For example, you're using a bunch of if statements to set each bit in variable c. Since you're setting all 8 bits in each if, you could just set c to the desired binary value with a single statement, such as c = %10000000 if you want to clear bits c{0} through c{6} and set bit c{7} to 1. The way you're doing it might be easier for you to understand, but it takes a lot more time than just setting c to the desired binary value with a single statement.

 

 

Michael

Thanks a ton, I'll take a look at what you changed, though it works just as I had wanted to.

A lot of the structure came from the snippets in the sticky, I don't really see any way of learning besides them?

[SeaGtGruff]

Thanks a ton, I'll take a look at what you changed, though it works just as I had wanted to.

I know it does, but you need to understand the changes and why they were made, otherwise you won't learn from it!

 

A lot of the structure came from the snippets in the sticky, I don't really see any way of learning besides them?

There's nothing at all wrong with using examples or snippets that other people wrote, as long as you understand how they work. For example, you don't need to use the same variable names as the examples and snippets, and you can adapt their techniques to fit your particular needs.

 

One very important way that you learn is by making mistakes-- and then trying to figure out what you did wrong. You don't learn as much if someone else fixes your mistakes for you, unless you study what they did different to get it to work.

 

Beware of copying example code verbatim. To illustrate, a month or so back I decided to start writing a program in Visual Basic. Now, I understand BASIC, and I had dabbled a little bit with Visual Basic many years ago, but the newer versions have quite a few changes from the earlier ones. Anyway, I decided to start very simple-- just an empty window, with a simple menu at the top-- all it had was a File menu with one option-- Exit. Click on the File | Exit menu selection, and the window would close. Very simple, right? Wrong! It took me two hours of pulling out my hair before I got it to work. I used sample code that I got from books, from the help documentation, and from online programming forums. Guess what? The sample code didn't do squat! After two hours of going around in circles and screaming in disbelief that something so simple could be so frigging difficult, I finally figured out what else I needed to do to make it work-- and nobody explained it anywhere in all of those examples where they said "The following line of code will close the window." In my experience, examples are only useful if they contain *all* the code you need to make the example work-- not just one statement shown out of context-- and if they explain why you need to do A and B to make C work.

 

Michael

[endrien]

Thanks a ton, I'll take a look at what you changed, though it works just as I had wanted to.

I know it does, but you need to understand the changes and why they were made, otherwise you won't learn from it!

 

A lot of the structure came from the snippets in the sticky, I don't really see any way of learning besides them?

There's nothing at all wrong with using examples or snippets that other people wrote, as long as you understand how they work. For example, you don't need to use the same variable names as the examples and snippets, and you can adapt their techniques to fit your particular needs.

 

One very important way that you learn is by making mistakes-- and then trying to figure out what you did wrong. You don't learn as much if someone else fixes your mistakes for you, unless you study what they did different to get it to work.

 

Beware of copying example code verbatim. To illustrate, a month or so back I decided to start writing a program in Visual Basic. Now, I understand BASIC, and I had dabbled a little bit with Visual Basic many years ago, but the newer versions have quite a few changes from the earlier ones. Anyway, I decided to start very simple-- just an empty window, with a simple menu at the top-- all it had was a File menu with one option-- Exit. Click on the File | Exit menu selection, and the window would close. Very simple, right? Wrong! It took me two hours of pulling out my hair before I got it to work. I used sample code that I got from books, from the help documentation, and from online programming forums. Guess what? The sample code didn't do squat! After two hours of going around in circles and screaming in disbelief that something so simple could be so frigging difficult, I finally figured out what else I needed to do to make it work-- and nobody explained it anywhere in all of those examples where they said "The following line of code will close the window." In my experience, examples are only useful if they contain *all* the code you need to make the example work-- not just one statement shown out of context-- and if they explain why you need to do A and B to make C work.

 

Michael

 

 

Well mostly what I see you did is added a sub so that the code is actually able to be accessed, did you change anything else?

[SeaGtGruff]

Well mostly what I see you did is added a sub so that the code is actually able to be accessed, did you change anything else?

Yeah, that was probably the most important change. I also changed the still code to a subroutine, and I changed where the two loops go back to (so they don't keep repeating any code they don't need to). There were probably a few other little changes-- like adding a COLUPF statement in the two loops to make the top playfield row be the right color-- but I don't remember everything I did. Oh, I also moved and changed the code that actually set the player's position, and initialized a and b to 0 just before the joystick code that sets them to 1 or -1 if the stick is pushed left, right, up, or down.

 

Michael

[endrien]

Thanks, it's better to know what you did so I don't have to ask the next time I have to do it .