moving player1 overreacting?

[pacgreg]

I'm trying to make player1 respond to a hit caused by pressing the fire button on joy0 but whenever it connects and reads the line p1x = p1x - 2, it teleports all the way to the side of the screen, as it does with any movement I put there. I need another perspective of this because I can't find any reason that this keeps happening. The problem is likely hiding in the sections marked FIRE or HitManagement. Player1 moves fine using a similar move command to line himself up with the punch.

Thanks

Superman.bas

Edited January 6, 2015 by pacgreg

[+Random Terrain]

One thing I see is that you need to remember the difference between things like bank3 without a space and bank 3 with a space:

 

atariage.com/forums/topic/120530-bankswitching/#entry1456132

 

Bank 3 and any of the banks need to be indented.

 

 

Also, you need to check out the AND/OR/NOT Chart on the right side of this page to see what you can and can't use with NOT:

 

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

 

 

I don't know if if-then has been upgraded, but using math in an if-then didn't use to work.

 

Instead of this:

 

if p0x + 6 > p1x then p1x = p1x + 0.5

 

I use this:

 

_My_Temp01 = p0x + 6

if _My_Temp01 > p1x then p1x = p1x + 0.5

 

 

_My_Temp01 or whatever you want to use would need to be DIMed. (I don't trust the usual temp variables when using DPC+.)

 

 

 

Errors in my programs have caused an if-then line of code with no problems to act up. After you fix up your program, the problem you posted might go away.

[bogax]

I'm trying to make player1 respond to a hit caused by pressing the fire button on joy0 but whenever it connects and reads the line p1x = p1x - 2, it teleports all the way to the side of the screen, as it does with any movement I put there. I need another perspective of this because I can't find any reason that this keeps happening. The problem is likely hiding in the sections marked FIRE or HitManagement. Player1 moves fine using a similar move command to line himself up with the punch.

Thanks

 

 

It appears that Bb is bugged.

 

It fails to load p1x before it subtracts 2

0 is what's in the accumulator at that time so it effectively sets player1x to -2

 

I think this is one for Reveng

 

as a work around you could try

 

player1x = p1x - 2

 

or

 

p1x = p1x - 2.0

[RevEng]

Hmmm... admittedly this involves a section of batari's code that I find the most difficult to trace through. The assignment parser uses RPN with 6502 opcodes instead of traditional operands and operators, which is incredibly neat, but it also has some magic numbers that I haven't fully grokked yet.

 

The code that's causing a problem is commented "// this needs work - 44+8+44 and probably others are screwy"

 

It does the right thing if the assignment is done on its own line, but not if it's anywhere in an if...then. It's also limited to fixed point numbers. I'll dig deeper later and hopefully fix it, but definitely use player1x=p1x-2 as a workaround in the meantime.

[iesposta]

Artie, my beloved, said, "(I don't trust the usual temp variables when using DPC+.)"

What is it with you and variables??? Relax!

 

In DK Arcade 2600 we use every temp hundreds of times, reuse variables for different things in different sections, and even have 2 that aren't used: y and var8

[iesposta]

On topic, we are using the temp1=math , if temp1 > whatever then ...

But if that temp value is only used once, in my optimizing I have been removing the temp and putting the math in the if/then statement. I have to do this on a one by one basis because sometime it will break compiling and sometimes it compiles but messes up the game.

[iesposta]

Also, later, if you have a lot of same code, like this is at least 5 times: CTRLPF = $11 : ballheight = 2 : ballx = p0x + 4 : bally = p0y + 3

  gosub makealabelname

makelabelname
   CTRLPF = $11 : ballheight = 2 : ballx = p0x + 4 : bally = p0y + 3
   return thisbank

Just put the above outside of any game loop.

[RevEng]

On topic, we are using the temp1=math , if temp1 > whatever then ...

But if that temp value is only used once, in my optimizing I have been removing the temp and putting the math in the if/then statement. I have to do this on a one by one basis because sometime it will break compiling and sometimes it compiles but messes up the game.

In "bB.1.1d.reveng32", batari fixed an issue with complex math in if...then conditions. They were very broken prior, but after the fix I haven't personally run into any issues with them.

 

If I'm going to do one last fix release, we may as well make it a good one. If you can reproduce any bugs with simple code, send 'em my way.

[+Random Terrain]

Artie, my beloved, said, "(I don't trust the usual temp variables when using DPC+.)"

What is it with you and variables??? Relax!

 

In DK Arcade 2600 we use every temp hundreds of times, reuse variables for different things in different sections, and even have 2 that aren't used: y and var8

 

Related posts:

 

atariage.com/forums/topic/203631-drawing-playfields-from-data-statements/?p=2612081

pfpixel and similar functions obliterate temp1, temp2, and temp3, which is probably why you're having trouble with the looping and getting ARM exceptions.

 

 

atariage.com/forums/topic/209496-getting-started-with-the-dpc-kernel/?p=2707040

Using 'set kernel_options collision(player1,playfield)' will return the y-coordinate where the first such collision occurs, so you can later figure out what sprite it was. Value is returned in temp4 after a drawscreen. The 1.1d version of the DPCplus_kernel has a timing error if you don't use this option, always include it for now.

 

 

atariage.com/forums/topic/209496-getting-started-with-the-dpc-kernel/?p=2810231

temp1 ds 1 ; used in sprite flickering

temp2 ds 1 ;are obliterated when drawscreen is called.

temp3 ds 1

temp4 ds 1

temp5 ds 1

temp6 ds 1

temp7 = topP1x ; This is used to aid in bankswitching

 

 

atariage.com/forums/topic/202997-questions-about-playfield-collision-detection-in-dpc-kernel/?p=2605066

My comment about the temp variables being used in other routines besides drawscreen was mainly in response to what theloon said about them being "unreliable." In my own experience they're safe to use as long as you don't expect them to keep their values after calling drawscreen, but it also depends a great deal on what other things are going on in your program. For example, the mul8 routine uses temp1 and temp2, so if you store something in temp1 and temp2, then do some multiplication that requires calling the mul8 routine, your temp1 and temp2 values will be toast afterward.

 

 

atariage.com/forums/topic/212784-platforming-project-oh-my/?p=2762908

the only problem with the temp variables is that bB uses them.

If you don't ask bB to do anything that uses them you're safe

 

drawscreen uses them

pfread uses temp1 and temp2

 

it's not always obvious that you're asking bB to do something

that will use them.

 

a multiplication or division by something other than a constant

that is a power of 2 uses temp1 and temp2

 

multiplication and division are only things I can think of

just off hand that aren't obvious or might slip by (me

at least)

 

 

 

Then we have this from the bB page:

 

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

I haven't memorized all of the bB routines—and the source code for bB's routines are always subject to future change—but I *think* bB uses the temp variables in the order they're needed. That is, bB will use temp1 first, and will not use temp2 unless it's already using temp1 for something and needs to use another temp variable. So that means, generally speaking, that the temp variables are safest to use in reverse order—in other words, temp6 is safer than temp5, and temp5 is safer than temp4, etc. The exception is temp7, which—as I mentioned—is reserved for bankswitching, so you shouldn't use temp7 in a bankswitched game or you could screw up the bankswitching big time.

 

 

According to that info, temp1, temp2, temp3, temp4, and temp7 cannot be freely used because they may be used at any time by bB. The only two that might be safe at all times are temp6 and temp5, but there are no guarantees.

[+Random Terrain]

I'm trying to make player1 respond to a hit caused by pressing the fire button on joy0 but whenever it connects and reads the line p1x = p1x - 2, it teleports all the way to the side of the screen, as it does with any movement I put there. I need another perspective of this because I can't find any reason that this keeps happening. The problem is likely hiding in the sections marked FIRE or HitManagement. Player1 moves fine using a similar move command to line himself up with the punch.

Thanks

I just remembered that I had a similar problem one time. Instead of using p1x = p1x - 2, use this:

 

p1x = p1x - 2.0

 

I just tried it. It works. It makes sense since p1x is a fixed point variable.

 

But if you want the bad guy to bounce back, wouldn't you want to use something like p1x = p1x + 5.0 in the other direction? Here's an example:

 

superman_2015y_01m_06d_0738t.bin

 

superman_2015y_01m_06d_0738t.bas

 

[i also fixed the bank stuff that I mentioned in my other post.]

[iesposta]

Related posts:

 

According to that info, temp1, temp2, temp3, temp4, and temp7 cannot be freely used because they may be used at any time by bB. The only two that might be safe at all times are temp6 and temp5, but there are no guarantees.

I appreciate you collection of all the information, and I could not program bB without your website as a reference (that's why you're credited in FLAPPY ), but I just haven't run into any problems in bB DPC+.

 

Either we know what we're doing (doubtful), are very, very lucky (doubtful), or ???

As long as you don't expect them to hold on to a value, and temporarily use them right away (that's why they are called temp) here is what I know.

DK Arcade 2600 uses:

temp1 = 93 times

temp2 = 70 times

temp3 = 24 times

temp4 = 28 times

temp5 = 21 times

temp6 = 17 times

temp7 = 0 times

[+Random Terrain]

I appreciate you collection of all the information, and I could not program bB without your website as a reference (that's why you're credited in FLAPPY ), but I just haven't run into any problems in bB DPC+.

 

Either we know what we're doing (doubtful), are very, very lucky (doubtful), or ???

As long as you don't expect them to hold on to a value, and temporarily use them right away (that's why they are called temp) here is what I know.

DK Arcade 2600 uses:

temp1 = 93 times

temp2 = 70 times

temp3 = 24 times

temp4 = 28 times

temp5 = 21 times

temp6 = 17 times

temp7 = 0 times

 

If you are avoiding the various things that use the temp variables, that's great, but we can't tell bB users that the temp variables are completely safe to use because they'll pop up with various hair-pulling problems and ask us why we didn't warn them about all of the things that can go wrong when using temp variables. Just because you got lucky doesn't mean they will.

 

You can put one bullet into an empty revolver, spin the cylinder, hold it up to your head and pull the trigger a few times without splattering the contents of your head all over the furniture, but you can't hand the gun to someone else and expect that they will have the same experience just because you got lucky.