Jump to content

Photo

Bug Report Thread


244 replies to this topic

#151 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,487 posts
  • begin 644 contest

Posted Fri Jul 10, 2009 3:25 PM

I cannot replicate that behavior. I get this, which is the "correct" behavior:

lda #ENEMY_MAX_Y
   sta player1y
Can you post your source or PM it to me?


Search for ENEMY_MAX_Y in the source for an example.



Thanks

I can't repeat your issue with your source, either. What version of bB are you using?

#152 Robert M OFFLINE  

Robert M

    Stargunner

  • 1,486 posts
  • Rootbeer!
  • Location:Western NY state

Posted Fri Jul 10, 2009 6:52 PM

I cannot replicate that behavior. I get this, which is the "correct" behavior:

lda #ENEMY_MAX_Y
   sta player1y
Can you post your source or PM it to me?


Search for ENEMY_MAX_Y in the source for an example.



Thanks

I can't repeat your issue with your source, either. What version of bB are you using?


Mac OS-X version dated 2/14/07 12:59. It is the same one as on the bBasic homepage.

#153 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,487 posts
  • begin 644 contest

Posted Fri Jul 10, 2009 7:56 PM

I cannot replicate that behavior. I get this, which is the "correct" behavior:

lda #ENEMY_MAX_Y
   sta player1y
Can you post your source or PM it to me?


Search for ENEMY_MAX_Y in the source for an example.



Thanks

I can't repeat your issue with your source, either. What version of bB are you using?


Mac OS-X version dated 2/14/07 12:59. It is the same one as on the bBasic homepage.

Here is the latest OSX build that should fix that issue (and will also give you the features of the 10-25-08 DOS/Windows build.)

Attached Files



#154 Robert M OFFLINE  

Robert M

    Stargunner

  • 1,486 posts
  • Rootbeer!
  • Location:Western NY state

Posted Fri Jul 10, 2009 9:12 PM

Here is the latest OSX build that should fix that issue (and will also give you the features of the 10-25-08 DOS/Windows build.)



Yes, that fixed the problem. Thanks. Will you be updating the download link on the bBasic homepage to link to these newer binaries for OS-X?

#155 yuppicide OFFLINE  

yuppicide

    I am the Black Knight. Give me your money!

  • 6,933 posts
  • Location:New Jersey

Posted Fri Jul 10, 2009 9:23 PM

I was going to say I tested it fine, but you guys already beat me to it.

BTW, nice looking game. Could it be made in to Satan's Hollow? That game is awesome!

I cannot replicate that behavior. I get this, which is the "correct" behavior:

lda #ENEMY_MAX_Y
   sta player1y
Can you post your source or PM it to me?


Search for ENEMY_MAX_Y in the source for an example.



Thanks



#156 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,487 posts
  • begin 644 contest

Posted Sun Oct 25, 2009 2:02 PM

I found a bug in startup.asm. This will only affect games using a custom pfrowheight (which means very few.) The bug will only manifest itself on real hardware, and not all hardware will exploit it.

The fixed file is attached.

Attached Files



#157 devwebcl OFFLINE  

devwebcl

    Dragonstomper

  • 896 posts
  • Location:Chile

Posted Mon Mar 8, 2010 7:17 PM

Although is was asked before, I didn't get the solution.

Using ImgtoCode I got the following when I was trying to compile:

DASM V2.20.07, Macro Assembler (C)1988-2003
--- Unresolved Symbol List
game                     0000 ????         (R )
bs_mask                  0000 ????         (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.

and the snippet header of the batari code is:

set romsize 32kSC
 set tv ntsc
 set kernel_options no_blank_lines
 set smartbranching on
 COLUBK = $00
 COLUPF = $0E
 const noscore = 1
 const pfres=86
 playfield:


#158 jwierer OFFLINE  

jwierer

    Dragonstomper

  • 890 posts
  • Location:Seattle,WA

Posted Mon Mar 8, 2010 7:48 PM

Although is was asked before, I didn't get the solution.

Using ImgtoCode I got the following when I was trying to compile:

DASM V2.20.07, Macro Assembler (C)1988-2003
--- Unresolved Symbol List
game 0000 ???? (R )
bs_mask 0000 ???? (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.

and the snippet header of the batari code is:

set romsize 32kSC
 set tv ntsc
 set kernel_options no_blank_lines
 set smartbranching on
 COLUBK = $00
 COLUPF = $0E
 const noscore = 1
 const pfres=86
 playfield:

Are you using the Windows 64-bit compiler found in this thread? I've encountered a couple different situations where code would not compile with that version. I just use a 32-bit machine and the older compiler until it's resolved.

-Jeff

#159 devwebcl OFFLINE  

devwebcl

    Dragonstomper

  • 896 posts
  • Location:Chile

Posted Tue Mar 9, 2010 5:51 AM

Are you using the Windows 64-bit compiler found in this thread? I've encountered a couple different situations where code would not compile with that version. I just use a 32-bit machine and the older compiler until it's resolved.

-Jeff


Well, I just had updated from the RanomTerrain update, but I tried out with the original batari 1.0 and still is not working.

I just upload the bas source code I'm trying to compile if someone else can do it, so there I can see I have something with my configuraton.

thanks in advance.

Devwebcl

Attached Files



#160 jwierer OFFLINE  

jwierer

    Dragonstomper

  • 890 posts
  • Location:Seattle,WA

Posted Tue Mar 9, 2010 9:38 AM

Are you using the Windows 64-bit compiler found in this thread? I've encountered a couple different situations where code would not compile with that version. I just use a 32-bit machine and the older compiler until it's resolved.

-Jeff


Well, I just had updated from the RanomTerrain update, but I tried out with the original batari 1.0 and still is not working.

I just upload the bas source code I'm trying to compile if someone else can do it, so there I can see I have something with my configuraton.

thanks in advance.

Devwebcl

Thanks for posting the source. The good news is your compiler is working normally because the problem is that the playfield is too large for a normal bB playfield. If you want a larger than supported playfield you'll need to generate the assembly option in imgToCode and use the bitmap kernel.

-Jeff

#161 Cliff Friedel OFFLINE  

Cliff Friedel

    Dragonstomper

  • 592 posts

Posted Tue Aug 17, 2010 9:08 PM

Reporting this as a bug. I have come across a problem using the background kernel option where the screen will display differently based on whether the no_blank_lines option is present or not. When no_blank_lines is used, the screen appears to render normally:

AztecChampion1.PNG

When I take out no_blank_lines though, the screen distorts:

AztecChampion2.PNG

Here is the code I used to produce the issue.

Attached File  default.bas   1.43KB   139 downloads

I am hoping this is just an example of poor programming instead of an actual bug, but I figured I would post it to make sure.

#162 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 24,896 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Aug 20, 2010 3:19 AM

I am hoping this is just an example of poor programming instead of an actual bug, but I figured I would post it to make sure.

I played with your code and can't figure out what is making that odd stair step between the colors, but I do know if you put the following in your main loop, the top row will turn blue again:

COLUBK = $80


#163 Cliff Friedel OFFLINE  

Cliff Friedel

    Dragonstomper

  • 592 posts

Posted Fri Aug 20, 2010 7:29 AM

I am hoping this is just an example of poor programming instead of an actual bug, but I figured I would post it to make sure.

I played with your code and can't figure out what is making that odd stair step between the colors, but I do know if you put the following in your main loop, the top row will turn blue again:

COLUBK = $80


It really doesn't make sense. The code appears ok. Can you think of any reason that no_blank_lines would fix it? Also, I don't want to change the background color as I am using that to make the sand (so I can build the pylons with COLUPF = 00). If I can't figure it out, I may just shelve the project for now and work on the other game I am making.

Cliff

#164 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 24,896 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Aug 20, 2010 2:31 PM

It really doesn't make sense. The code appears ok. Can you think of any reason that no_blank_lines would fix it? Also, I don't want to change the background color as I am using that to make the sand (so I can build the pylons with COLUPF = 00). If I can't figure it out, I may just shelve the project for now and work on the other game I am making.

Maybe batari will see this and he'll be able to explain.

#165 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,487 posts
  • begin 644 contest

Posted Wed Aug 25, 2010 3:09 AM

The bankground color code simply exchanges the playfield color store with the background color store. Due to timing issues, when no_blank_lines is off, the color change occurs in the middle of the scanline, and you don't notice since the playfield is normally off here. Of course the background can't be turned off so you see the stairstep. I remember encountering this bug years ago and not being able to fix it.

When you use no_blank_lines, a missile is not displayed and the color changing code is used in its place. The missile code occurs before the visible scanline so you don't see any glitches.

I looked again and I still don't think I can fix this bug. I recall being able to move the stairstep to the left a bit, and it looks like this is the best I can do:default.bas.bin.png

Edited by batari, Wed Aug 25, 2010 3:15 AM.


#166 Cliff Friedel OFFLINE  

Cliff Friedel

    Dragonstomper

  • 592 posts

Posted Wed Aug 25, 2010 7:50 PM

Ok, thanks. I will have to try and think of something else to get that sky effect. I think I have an idea. If I set the background to the sand color, I could draw the sky as a negative of the upcoming pyramid and the ground would be background. To draw the pylons, I could just set the lines to black and put them up. That will let me get rid of the background altogether and I can use or not use the no_blank_lines as needed. Thanks for the info. I appreciate it. Definitely appreciate bB too!

Cliff

#167 Philsan OFFLINE  

Philsan

    River Patroller

  • 2,761 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Mon Sep 20, 2010 1:38 PM

Hi Fred.
According to RevEng (who helped me very much with title screen and other things), there's a bug in bB that causes jumps between 311 and 312 scanlines in PAL50 version of my L.E.M. game (NTSC and PAL60 version are OK).
I attach a test version without title screen.

Attached Files



#168 RevEng ONLINE  

RevEng

    River Patroller

  • 3,348 posts
  • bit player
  • Location:Canada

Posted Mon Sep 20, 2010 4:28 PM

Here's a minimal program that triggers the "less than 312 scanlines" problem...

 set tv pal
 set kernel_options player1colors

 dim frame=a
 scorecolor=$0f

gameloop
 frame=frame+1
 frame=frame&31
 rem ** burn a variable amount of time
 for t=0 to frame
  z=z
 next
 drawscreen
 goto gameloop
...the player1colors kernel option is key. Without it, the scanlines are stable.

Edited by RevEng, Mon Sep 20, 2010 4:53 PM.


#169 atari2600land ONLINE  

atari2600land

    Game Gear>Game Boy

  • 8,096 posts
  • Location:Salem, Oregon

Posted Sun Sep 26, 2010 7:15 PM

I don't know whether this is a bug or if bB was programmed this way. I can't do this:
p=(rand/t)*4
Instead, I have to do this:
if t=1 then p=rand/64
it t=2 then p=rand/32
Any thoughts?

#170 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Sun Sep 26, 2010 9:12 PM

I don't know whether this is a bug or if bB was programmed this way. I can't do this:

p=(rand/t)*4
Instead, I have to do this:
if t=1 then p=rand/64
it t=2 then p=rand/32
Any thoughts?

I don't understand what you're trying to do, because the lines of code aren't equivalent. Assuming that t will equal either 1 or 2, the first line of code gives you

p=(rand/t)*4
=([a number between 1 and 255]/t)*4

if t=1:
p=([a number between 1 and 255]/1)*4
=[a number between 1 and 255]*4
=[a multiple of 4 between 4 and 252]

if t=2:
p=([a number between 1 and 255]/2)*4
=[a number between 0 and 127]*4
=[a multiple of 4 between 0 and 252]

If the second two lines of code show what you're trying to do, then the first line of code should have been as follows:

p=rand/(64/t)

What exactly are you trying to do? P is supposed to be a random number, but what kind of random number is it supposed to be?

Michael

#171 RevEng ONLINE  

RevEng

    River Patroller

  • 3,348 posts
  • bit player
  • Location:Canada

Posted Mon Sep 27, 2010 11:36 AM

It looks like bB version 1.01 has something different going on with multiplication by powers of two. I'm not entirely sure if this was intentional or not.

The following program...
include div_mul.asm

 a=b*1
 a=b*2
 a=b*4
 a=b*8
 a=b*16
 a=b*32
 a=b*64
 a=b*128

compiles as...
.L01 ;  a = b * 1

	LDA b
	STA a
.L02 ;  a = b * 2

	LDA b
	asl
	STA a
.L03 ;  a = b * 4

	LDA b
	asl
	asl
	STA a
.L04 ;  a = b * 8

	LDA b
	asl
	asl
	asl
	STA a
.L05 ;  a = b * 16

	LDA b
	LDY #16
 jsr mul8
	STA a
.L06 ;  a = b * 32

	LDA b
	LDY #32
 jsr mul8
	STA a
.L07 ;  a = b * 64

	LDA b
	LDY #64
 jsr mul8
	STA a
.L08 ;  a = b * 128

	LDA b
	LDY #128
 jsr mul8

In summary, multiplication by powers of two greater than 8 are using the multiplication subroutines, instead of cycle-cheap ASLs.

The situation is even worse for bankswitched binaries, as you get bankswitch penalties on top of it all.

#172 diogoandrei OFFLINE  

diogoandrei

    Chopper Commander

  • 210 posts
  • Location:Brazil

Posted Wed Jan 19, 2011 2:06 PM

Hello,

there's seems to be a bug related to the constant *_length for data arrays. It looks like it returns weird values. RevEng was helping me out and he suggested that this might be a bug (here).

So, an action like this:

 a = pixelData_length

...for an array like this:

 data pixelData
 1,1,2,2,3,3,4,4,5,5,6,6
end

...won't return the value of 12.

Anyone else experienced that? Thanks & cheers

#173 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,487 posts
  • begin 644 contest

Posted Thu Jan 20, 2011 4:20 PM

Hello,

there's seems to be a bug related to the constant *_length for data arrays. It looks like it returns weird values. RevEng was helping me out and he suggested that this might be a bug (here).

So, an action like this:

 a = pixelData_length

...for an array like this:

 data pixelData
 1,1,2,2,3,3,4,4,5,5,6,6
end

...won't return the value of 12.

Anyone else experienced that? Thanks & cheers

It won't return a value of 12 if you reference pixelData_length before you define the data statement. Any time bB parses a statement, it has to decide if a value is a variable or a constant, and since it doesn't yet know about your data statement, it treats it as a variable.

As for a permanent fix, that might be tough. If I treat everything ending in "_length" as a constant, it might break existing games. What I will do is issue a warning if it finds "_length" treated as a variable.

A few fixes that will work are (obviously) to put the data statement first, or do a forward declaration of sorts - one way to do that is use "const pixelData_length=pixelData_length" at the beginning of your code.

Edited by batari, Fri Jan 21, 2011 1:51 PM.


#174 diogoandrei OFFLINE  

diogoandrei

    Chopper Commander

  • 210 posts
  • Location:Brazil

Posted Fri Jan 21, 2011 3:25 AM

It won't return a value of 12 if you reference pixelData_length before you define the data statement. Any time bB parses a statement, it has to decide if a value is a variable or a constant, and since it doesn't yet know about your data statement, it treats it as a variable.

As for a permanent fix, that might be tough. If I treat everything ending in "_length" as a constant, it might break existing games. What I will do is issue a warning if it finds "_length" treated as a variable.

A few fixes that will work are (obviously) to put the data statement first, or do a forward declaration of sorts - one way to do that is use "const pixelData_length=pixelData_length" at the beginning of your code.


Makes sense, thanks! :)

Edited by batari, Fri Jan 21, 2011 1:51 PM.


#175 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,487 posts
  • begin 644 contest

Posted Fri Jan 21, 2011 2:01 PM

Made tiny edits to the above two posts to correct something. Also, I changed bB source to issue a warning for anything ending in "_length" treated as a variable.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users