Bug Report Thread

[+batari]

Two more bugs I discovered a few days ago:

 

"pfscroll right" doesn't work at all. It was caused by me commenting out a line of code that I shouldn't have.

 

I also discovered another bug with || if both conditions are true.

 

for example:

 

if a=1 || b=1 then s=s+1

 

If either a or b are 1 (or neither are) the statement works properly.

 

But if both a and b are 1, then s=s+1 will execute twice! I'll fix this sooner or later.

Edited October 2, 2005 by batari

[djmips]

In the function

 

Assign44to88:

 

there is a stx just before the rts that should be a ldx

 

 

(nice job on the sign extension)

[Luigi301]

pfread is backwards. My pixel is on and pfread doesn't do anything. !pfread performs the proper action.

[+batari]

pfread is backwards. My pixel is on and pfread doesn't do anything. !pfread performs the proper action.

974589[/snapback]

I just tried this out and have confirmed this. It's been added to the todo list for the next release, which I hope to get started on soon.

[+Random Terrain]

How are we doing on the pf stuff? Do you think we'll have the bugs fixed soon? I should have a little time to work on some kind of game soon and it would be nice if the pf problems were fixed first.

[+batari]

How are we doing on the pf stuff? Do you think we'll have the bugs fixed soon? I should have a little time to work on some kind of game soon and it would be nice if the pf problems were fixed first.

981680[/snapback]

Well, I think the pfvline and pfread problems can be fixed right now by using a modified pf_drawing.asm file. When the next version of bB is released, these fixes will be in place so your pf code should work all the same. For now, just overwrite your existing pf_drawing.asm file with this one.

pf_drawing.zip

[+Random Terrain]

How are we doing on the pf stuff? Do you think we'll have the bugs fixed soon? I should have a little time to work on some kind of game soon and it would be nice if the pf problems were fixed first.

981680[/snapback]

Well, I think the pfvline and pfread problems can be fixed right now by using a modified pf_drawing.asm file. When the next version of bB is released, these fixes will be in place so your pf code should work all the same. For now, just overwrite your existing pf_drawing.asm file with this one.

982082[/snapback]

Thanks! I hope to make at least one fun game before I die.

[+Atarius Maximus]

I'm using the latest build (99b) with the multisprite kernel...and I can't seem to use collision detection with the player 2-5 sprites. If I try to use a collision statement with anthing other than player 0 or 1 I get a compile error. In other words:

 

this works:

if collision(player0,player1) then .... code ....

 

this doesn't work:

if collision(player0,player5) then ..... code .....

 

Is this a problem with the multisprite kernel, or am I doing something wrong?

 

Steve

[+batari]

I'm using the latest build (99b) with the multisprite kernel...and I can't seem to use collision detection with the player 2-5 sprites. If I try to use a collision statement with anthing other than player 0 or 1 I get a compile error. In other words:

 

this works:

if collision(player0,player1) then .... code ....

 

this doesn't work:

if collision(player0,player5) then ..... code .....

 

Is this a problem with the multisprite kernel, or am I doing something wrong?

 

Steve

I posted an answer in another thread, but I'll follow up here too. You aren't doing anything wrong - the commands for 2-5 sprites do not exist. The 2600 actually only supports 2 sprites, and has just enough collision registers for these two players.

 

Sprites 1-5 are "virtual" sprites, in that the player1 sprite is repositioned mid-screen several times. So collision(player0,player1) will detect a collision between player0 and any one of player1-5 sprites. To figure out which one you actually hit, you will have to check your y-position of player 0 vs. that of the other sprites.

 

This will all be explained in the documentation, that is, when I get around to writing it...

[+Atarius Maximus]

I'm using the latest build (99b) with the multisprite kernel...and I can't seem to use collision detection with the player 2-5 sprites. If I try to use a collision statement with anthing other than player 0 or 1 I get a compile error. In other words:

 

this works:

if collision(player0,player1) then .... code ....

 

this doesn't work:

if collision(player0,player5) then ..... code .....

 

Is this a problem with the multisprite kernel, or am I doing something wrong?

 

Steve

I posted an answer in another thread, but I'll follow up here too. You aren't doing anything wrong - the commands for 2-5 sprites do not exist. The 2600 actually only supports 2 sprites, and has just enough collision registers for these two players.

 

Sprites 1-5 are "virtual" sprites, in that the player1 sprite is repositioned mid-screen several times. So collision(player0,player1) will detect a collision between player0 and any one of player1-5 sprites. To figure out which one you actually hit, you will have to check your y-position of player 0 vs. that of the other sprites.

 

This will all be explained in the documentation, that is, when I get around to writing it...

 

Sorry for posting this question twice. I thought this would be the most appropriate place for the question, but it also seemed relevant in the jumpman demo post. Thanks for clearing it up for me, it makes perfect sense now.

 

Steve

[+Atarius Maximus]

I've come across a few more possible bugs in the multisprite kernel that I'd like to share.

 

1. Collision Detection doesn't seem to work properly. I pasted in some code below to use as an example. It the sample program, when a collision occurs between the player and any other sprite on the screen, it should send your player sprite to the upper left hand corner of the screen, which should mean there is no longer a collision taking place and you should be able to move. However, it seems that once a collision of any kind is made, the compiled code thinks that it is always taking place. Once you hit another sprite, your player is immovable at the top left of the screen.

 

2. It seems that all 6 sprites must be defined, or none will appear. If you use the sample program below and remove the sprite graphic definition for player5, as well as the 'player5x=o:player5y=p' line, none of the sprites will appear. This may be by design, I'm not sure.

 

3. I know this was already mentioned, but I noticed a little detail that might be helpful. The background color does change properly until you call a drawscreen, which then forces it to grey.

 

Steve

 

init 
 set kernel multisprite

 a=130 : rem X Position of Player0
 b=24  : rem Y Position of Player0
 c=36  : rem X Position of Player1
 d=34  : rem Y Position of Player1
 i=130 : rem X Position of Player2
 j=44  : rem Y Position of Player2
 k=36  : rem X Position of Player3
 l=54  : rem Y Position of Player3
 m=60  : rem X Position of Player4
 n=64  : rem Y Position of Player4
 o=80  : rem X Position of Player5
 p=74  : rem Y Position of Player5

main

 COLUPF=144
 COLUBK=208
 COLUP0=46
 COLUP1=30
 COLUP2=55
 COLUP3=95
 COLUP4=138
 COLUP5=238
 scorecolor=64

 player0:
 %00000000
 %00111100
 %01000010
 %10011001
 %10100101
 %10000001
 %10101001
 %01000010
 %00111100
 %00000000
end

 player1: 
 %00000000
 %00000000
 %11111100
 %11111100
 %11111100
 %10000100 
 %10000100
 %01001000
 %00110000
 %00000000
end

 player2: 
 %00000000
 %10111010
 %11111110
 %10111010
 %00111000
 %10111010 
 %11111110
 %10111010
 %00111000
 %00000000
end

 player3: 
 %00000000
 %10000100
 %11001100
 %11111100
 %11111100
 %11111100 
 %11001100
 %11001100
 %10000100
 %00000000
end

 player4: 
 %00000000
 %00000000
 %00000000
 %11111100
 %10000100
 %11111100 
 %00000000
 %00000000
 %00000000
 %00000000
end

 player5: 
 %00000000
 %00000000
 %00110000
 %01111000
 %11111100
 %01111000 
 %00110000
 %00000000
 %00000000
 %00000000
end

 player0x=a : player0y=b 
 player1x=c : player1y=d 
 player2x=i : player2y=j 
 player3x=k : player3y=l 
 player4x=m : player4y=n 
 player5x=o : player5y=p

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

 drawscreen

 if collision(player0,player1) then a=28 : b=83

 goto main

[+batari]

I've come across a few more possible bugs in the multisprite kernel that I'd like to share.

 

1. Collision Detection doesn't seem to work properly. I pasted in some code below to use as an example. It the sample program, when a collision occurs between the player and any other sprite on the screen, it should send your player sprite to the upper left hand corner of the screen, which should mean there is no longer a collision taking place and you should be able to move. However, it seems that once a collision of any kind is made, the compiled code thinks that it is always taking place. Once you hit another sprite, your player is immovable at the top left of the screen.

Oops... I think I forgot to hit CXCLR in the kernel. If you place CXCLR=0 just before every drawscreen, this should patch the problem. When I fix the kernel this won't be necessary.

2. It seems that all 6 sprites must be defined, or none will appear. If you use the sample program below and remove the sprite graphic definition for player5, as well as the 'player5x=o:player5y=p' line, none of the sprites will appear. This may be by design, I'm not sure.

Not by design - it's a bug. Added to todo list.

 

If you find any others, please let me know.

[Jess Ragan]

Just how advanced is Batari BASIC now? What features have been added to the programming environment since I last used it?

 

JR

[+Atarius Maximus]

If you place CXCLR=0 just before every drawscreen, this should patch the problem.

Yep, placing the following code just before the drawscreen worked great. Thanks.

 

. asm
. stx CXCLR
end

I've noticed that If I position the player4 and player5 sprites too closely together vertically, it will make sprites 1-3 (positioned above 4 & 5) disappear from the screen. They don't have to overlap the same horizontal scan line, it happens if they are close. This may happen when positioning other sprites too closely as well, it's just all I've tested.

 

The P4/P5 sprites represent the ladder sprites on the screen from my demo game. Positioning them like this this will cause players 1-3 to disappear:

 

1.........................
2...P4....................
3...P4....................
4...............P5........
5...............P5........
6.........................
7.........................

 

Positioning them like this will work:

1.........................
2...P4....................
3...P4....................
4.........................
5...............P5........
6...............P5........
7.........................

 

I also noticed that the score doesn't appear at the bottom of the screen after setting 'scorecolor'.

 

Steve

Edited April 12, 2006 by Atarius Maximus

[+Atarius Maximus]

Just how advanced is Batari BASIC now? What features have been added to the programming environment since I last used it?

 

JR

My favorite new feature of the multisprite kernel is the ability to display higher resolution graphics. This alone will make it easier to create much more professional looking games.

demo1.txt.bin

[Jess Ragan]

Dayum. That IS an improvement!

 

JR

[+batari]

Just how advanced is Batari BASIC now? What features have been added to the programming environment since I last used it?

 

JR

I believe you used 0.2 last. For 0.30 and 0.35 changes, look at the following link (scroll down to the 0.30 and 0.35 revision history)

http://www.alienbill.com/2600/basic/downlo...0.35/README.txt

 

For the two bleeding-edge builds, look at these two blog entries:

http://www.atariage.com/forums/index.php?a...&showentry=1064

http://www.atariage.com/forums/index.php?a...&showentry=1280

 

I haven't written the documentation yet

My favorite new feature of the multisprite kernel is the ability to display higher resolution graphics. This alone will make it easier to create much more professional looking games. icon_smile.gif

Yeah, this was easy to add, since the playfield had to be moved to ROM. I think the one you are showing there uses pfheight=1. I think that you can specify pfheight=0 as well, which will double the vertical resolution you have there, but it has some funky glitches when you display sprites on top of it. May be useful for title screens or for sprites with fixed vertical positions.

[+batari]

If you place CXCLR=0 just before every drawscreen, this should patch the problem.

Yep, placing the following code just before the drawscreen worked great. Thanks.

 

. asm
. stx CXCLR
end

I've noticed that If I position the player4 and player5 sprites too closely together vertically, it will make sprites 1-3 (positioned above 4 & 5) disappear from the screen. They don't have to overlap the same horizontal scan line, it happens if they are close. This may happen when positioning other sprites too closely as well, it's just all I've tested.

Yep - the sprites need a line or two of blank space so the kernel has time to reposition them. The disappearing thing is a limitation of the intelligent flicker engine. I hope to fix this in the future, so overlapping sprites too close will simply result in flicker instead of turning them off.

I also noticed that the score doesn't appear at the bottom of the screen after setting 'scorecolor'.

 

Steve

Oops, my bad. I forgot to put in the routine to display the score

 

Well, now that someone's using the new kernel, I'll bump it up near the top of the priority list.

[+Atarius Maximus]

Oops, my bad. I forgot to put in the routine to display the score

I'm glad it's an easy fix.

 

Well, now that someone's using the new kernel, I'll bump it up near the top of the priority list.

Thanks! I'm sure everyone will start using this kernel over the standard one once they see what it can do.

 

Not by design - it's a bug. Added to todo list. If you find any others, please let me know.

Ok.

 

I found one more possible bug this morning as i was trying to implement velocity in my demo. If you insert 4.4 or 8.8 variables, the program will not compile.

 

Inserting either of these code snippets will cause a few hundred "label mismatch" errors:

. include fixed_point_math.asm
. c=0
. dim test=c.c
. test=test+0.1

 

. include fixed_point_math.asm
. c=0
. d=0
. dim test=c.d
. test=test+0.1

 

Error message:

C:\bB\dasm jd4.txt.asm -f3 -ojd4.txt.bin
DASM V2.20.10, Macro Assembler (C)1988-2004
$f5f2
  bytes of ROM space left
$f5f2
jd4.txt.asm (1687): error: Label mismatch...
--> 0.L045 f7cd
jd4.txt.asm (1692): error: Label mismatch...
--> 0.main f7cd
jd4.txt.asm (1698): error: Label mismatch...
--> 0.L046 f7cd
.
.
.
lots more of the same....

[+batari]

\Error message:

C:\bB\dasm jd4.txt.asm -f3 -ojd4.txt.bin
DASM V2.20.10, Macro Assembler (C)1988-2004
$f5f2
  bytes of ROM space left
$f5f2
jd4.txt.asm (1687): error: Label mismatch...
--> 0.L045 f7cd
jd4.txt.asm (1692): error: Label mismatch...
--> 0.main f7cd
jd4.txt.asm (1698): error: Label mismatch...
--> 0.L046 f7cd
.
.
.
lots more of the same....

I've found that the label mismatches are usually bogus. The Dasm assembler makes several passes, and during some early passes it mispredicts the size of the locations pointed to by the labels and when it's found to be wrong in later passes, it thinks that it's an error. However, usually it corrects itself in the last pass but not before barfing out several hundred lines of junk. I'd check to see if the program compiled anyway.

 

There seems to be no way to stop Dasm from showing all of these bogus errors. I'm tempted to modify Dasm myself to supress label mismatches until the last pass, but for now, don't worry about them if the program actually compiles correctly.

[+Atarius Maximus]

I've found that the label mismatches are usually bogus. The Dasm assembler makes several passes, and during some early passes it mispredicts the size of the locations pointed to by the labels and when it's found to be wrong in later passes, it thinks that it's an error. However, usually it corrects itself in the last pass but not before barfing out several hundred lines of junk. I'd check to see if the program compiled anyway.

 

There seems to be no way to stop Dasm from showing all of these bogus errors. I'm tempted to modify Dasm myself to supress label mismatches until the last pass, but for now, don't worry about them if the program actually compiles correctly.

I just tried to compile it again several times using variations of 4.4 and 8.8 variables, and each time the compiled code doesn't seem to run. I just get a blank black screen in Stella.

 

Steve

[+batari]

I've found that the label mismatches are usually bogus. The Dasm assembler makes several passes, and during some early passes it mispredicts the size of the locations pointed to by the labels and when it's found to be wrong in later passes, it thinks that it's an error. However, usually it corrects itself in the last pass but not before barfing out several hundred lines of junk. I'd check to see if the program compiled anyway.

 

There seems to be no way to stop Dasm from showing all of these bogus errors. I'm tempted to modify Dasm myself to supress label mismatches until the last pass, but for now, don't worry about them if the program actually compiles correctly.

I just tried to compile it again several times using variations of 4.4 and 8.8 variables, and each time the compiled code doesn't seem to run. I just get a blank black screen in Stella.

 

Steve

I'm not sure what's wrong. If you PM me the source, I'll take a look at it and post my findings.

[+Atarius Maximus]

I'm not sure what's wrong. If you PM me the source, I'll take a look at it and post my findings.

PM Sent. Thanks, batari.

[jjsonique]

I may have messed something up, but it appears the numbering of the y-axis is reversed when you move from 99b standard to 99b w/multisprite kernel. Ie, assuming you're using y for player0's y postition, in 99b standard, y = y + 1 moves player0 down 1 pixel, but in 99b multisprite y = y + 1 moves player0 UP 1 pixel. Although, my changes to player0's y position were tied to joystick movement, so maybe the joy0up/down reads are somehow reversed? I didn't test by just changing player0's initial position, which I should have (and will do tonight).

 

UPDATE: Tested again, and it IS the y numbering of that's reversed. A player0 with y directly set to 20 will appear at the top of the screen in 99b standard, and near the bottom in 99b multisprite.

 

Also, I was having trouble getting the extra sprites to show, but I now think that was due to not having them all defined at once (as Atarius Maximus notes above). I will try that out tonight and see if that solves that problem.

 

UPDATE pt 2: Got it to work! At first I was still having problems after defining all the sprites, but I discovered if any sprite is positioned offscreen, it can cause all all the extra sprites to disappear. Keeping them w/n screen bounds, it works fine.

Edited April 21, 2006 by jjsonique

[Luigi301]

the // division seems to freeze the compiler. I've added div_mul and div_mul16 to the includes file and it's simply refusing to compile if I don't rem out

 

b = brickx // 2