239 replies to this topic

[batari]

Robert M, on Fri Jul 10, 2009 4:13 PM, said:

batari, on Fri Jul 10, 2009 3:09 PM, said:

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?

[Robert M]

batari, on Fri Jul 10, 2009 4:25 PM, said:

Robert M, on Fri Jul 10, 2009 4:13 PM, said:

batari, on Fri Jul 10, 2009 3:09 PM, said:

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.

[batari]

Robert M, on Fri Jul 10, 2009 7:52 PM, said:

batari, on Fri Jul 10, 2009 4:25 PM, said:

Robert M, on Fri Jul 10, 2009 4:13 PM, said:

batari, on Fri Jul 10, 2009 3:09 PM, said:

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

•  OSX_1.01.zip   52.6K   164 downloads

[Robert M]

batari, on Fri Jul 10, 2009 9:56 PM, said:

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?

[yuppicide]

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!

Robert M, on Fri Jul 10, 2009 4:13 PM, said:

batari, on Fri Jul 10, 2009 3:09 PM, said:

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

[batari]

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

•  startup_fix.zip   571bytes   186 downloads

[devwebcl]

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:

[jwierer]

devwebcl, on Mon Mar 8, 2010 7:17 PM, said:

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

[devwebcl]

jwierer, on Mon Mar 8, 2010 7:48 PM, said:

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

•  imagen.bas   8.52K   254 downloads

[jwierer]

devwebcl, on Tue Mar 9, 2010 5:51 AM, said:

jwierer, on Mon Mar 8, 2010 7:48 PM, said:

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

[Cliff Friedel]

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:



When I take out no_blank_lines though, the screen distorts:



Here is the code I used to produce the issue.

 default.bas   1.43K   110 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.

[Random Terrain]

Cliff Friedel, on Tue Aug 17, 2010 9:08 PM, said:

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

[Cliff Friedel]

Random Terrain, on Fri Aug 20, 2010 3:19 AM, said:

Cliff Friedel, on Tue Aug 17, 2010 9:08 PM, said:

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

[Random Terrain]

Cliff Friedel, on Fri Aug 20, 2010 7:29 AM, said:

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.

[batari]

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:

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

[Cliff Friedel]

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

[Philsan]

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

•  LEM-bug-PAL50.bas.bin   16K   122 downloads

[RevEng]

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.

[atari2600land]

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?

[SeaGtGruff]

atari2600land, on Sun Sep 26, 2010 7:15 PM, said:

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

[RevEng]

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.

[diogoandrei]

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

[batari]

diogoandrei, on Wed Jan 19, 2011 2:06 PM, said:

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.

[diogoandrei]

batari, on Thu Jan 20, 2011 4:20 PM, said:

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.

[batari]

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.