Resetting game causes whole screen to move up (including scores)

[Fort Apocalypse]

Ok this is really wierd. If you move a car over the finish line enough to win (it is not that hard to do after you get the hang of it) you will win, and if you hit reset, the screen (including player scores) moves up by almost one playfield row.

 

If you do it again, it resets back to the way it was. Wierd!

 

Also playerscores for some reason can't have color set on them in the title loop as it doesn't appear to take for some reason. Not sure why.

 

And of course there is the issue I said before about one player always thinking it is colliding with the playfield when it isn't and another player never recognizing it hit the playfield, even though the other two players detect collisions with playfield fine and there is really no difference in the code. It must be some strange timing issue I guess?

 

At least I have an "interesting" title screen now...

 

ultindy500_0.3b.basultindy500_0.3b.bas.bin

ultindy500_0.3b.bas.asm.txt

Edited October 3, 2007 by Fort Apocalypse

[MausGames]

That would be your use of:

 

pfscroll upup : pfscroll up up

[Fort Apocalypse]

That would be your use of:

 

pfscroll upup : pfscroll up up

 

That is correct. When I remove that code the problem doesn't happen anymore, but since it is a hack to reduce the vertical resolution of the playfield, I also can't use as much of the playfield as I could before. I reduced the playfield by one block after removing that pfscroll business and it works. Thanks!

Edited October 4, 2007 by Fort Apocalypse

[Fort Apocalypse]

(double posted)

Edited October 4, 2007 by Fort Apocalypse

[Fort Apocalypse]

Still having problems with scorecolors and collision detection though.

[MausGames]

You don't need to remove the pfscrolls, just do something like:

 

if s = 0 then pfscroll upup : pfscroll upup : s = 1

 

 

So that it's only done once.

 

The other two issues I'd need more time than I have to fix.

 

EDIT:

 

This is called a "flag", and the more efficient way of doing it is to use the bits of a variable, since each bit can be either Off (zero), or On (one). If you set aside a variable for this use, it can be used as six different flags by setting each bit. So it would be:

 

if s[0] = 0 then pfscroll upup : pfscroll upup : s[0] = 1

 

The way the score bounces around when vertical scrolling is used is a bug introduced in bB 1.0, no fix yet as far as I know...

Edited October 4, 2007 by MausGames

[Fort Apocalypse]

You don't need to remove the pfscrolls, just do something like:

 

if s = 0 then pfscroll upup : pfscroll upup : s = 1

 

 

So that it's only done once.

 

The other two issues I'd need more time than I have to fix.

 

EDIT:

 

This is called a "flag", and the more efficient way of doing it is to use the bits of a variable, since each bit can be either Off (zero), or On (one). If you set aside a variable for this use, it can be used as six different flags by setting each bit. So it would be:

 

if s[0] = 0 then pfscroll upup : pfscroll upup : s[0] = 1

 

The way the score bounces around when vertical scrolling is used is a bug introduced in bB 1.0, no fix yet as far as I know...

 

Good idea! I think I'll do that. I was thinking at first maybe pfscroll upup had to do with the other playfield collision detection bugs but it didn't.

[Dragnerok X]

You don't need to remove the pfscrolls, just do something like:

 

if s = 0 then pfscroll upup : pfscroll upup : s = 1

 

 

So that it's only done once.

 

The other two issues I'd need more time than I have to fix.

 

EDIT:

 

This is called a "flag", and the more efficient way of doing it is to use the bits of a variable, since each bit can be either Off (zero), or On (one). If you set aside a variable for this use, it can be used as six different flags by setting each bit. So it would be:

 

if s[0] = 0 then pfscroll upup : pfscroll upup : s[0] = 1

 

The way the score bounces around when vertical scrolling is used is a bug introduced in bB 1.0, no fix yet as far as I know...

 

Just a slight correction. For bit operations, you would use s{0} = 1 instead of s[0] = 1.

More information on this can be found here.