+batari Posted July 10, 2009 Share Posted July 10, 2009 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. main052.txt Thanks I can't repeat your issue with your source, either. What version of bB are you using? Quote Link to comment Share on other sites More sharing options...
Robert M Posted July 11, 2009 Share Posted July 11, 2009 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. main052.txt 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 11, 2009 Share Posted July 11, 2009 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. main052.txt 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.) OSX_1.01.zip Quote Link to comment Share on other sites More sharing options...
Robert M Posted July 11, 2009 Share Posted July 11, 2009 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? Quote Link to comment Share on other sites More sharing options...
yuppicide Posted July 11, 2009 Share Posted July 11, 2009 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. main052.txt Thanks Quote Link to comment Share on other sites More sharing options...
+batari Posted October 25, 2009 Share Posted October 25, 2009 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. startup_fix.zip Quote Link to comment Share on other sites More sharing options...
devwebcl Posted March 9, 2010 Share Posted March 9, 2010 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: Quote Link to comment Share on other sites More sharing options...
jwierer Posted March 9, 2010 Share Posted March 9, 2010 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 Quote Link to comment Share on other sites More sharing options...
devwebcl Posted March 9, 2010 Share Posted March 9, 2010 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 imagen.bas Quote Link to comment Share on other sites More sharing options...
jwierer Posted March 9, 2010 Share Posted March 9, 2010 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 Quote Link to comment Share on other sites More sharing options...
Cliff Friedel Posted August 18, 2010 Share Posted August 18, 2010 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 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 20, 2010 Share Posted August 20, 2010 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 Quote Link to comment Share on other sites More sharing options...
Cliff Friedel Posted August 20, 2010 Share Posted August 20, 2010 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 20, 2010 Share Posted August 20, 2010 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 25, 2010 Share Posted August 25, 2010 (edited) 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 August 25, 2010 by batari Quote Link to comment Share on other sites More sharing options...
Cliff Friedel Posted August 26, 2010 Share Posted August 26, 2010 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 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted September 20, 2010 Share Posted September 20, 2010 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. LEM-bug-PAL50.bas.bin Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 20, 2010 Share Posted September 20, 2010 (edited) 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 September 20, 2010 by RevEng Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted September 27, 2010 Share Posted September 27, 2010 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? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 27, 2010 Share Posted September 27, 2010 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 27, 2010 Share Posted September 27, 2010 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. Quote Link to comment Share on other sites More sharing options...
diogoandrei Posted January 19, 2011 Share Posted January 19, 2011 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 Quote Link to comment Share on other sites More sharing options...
+batari Posted January 20, 2011 Share Posted January 20, 2011 (edited) 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 January 21, 2011 by batari Quote Link to comment Share on other sites More sharing options...
diogoandrei Posted January 21, 2011 Share Posted January 21, 2011 (edited) 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 January 21, 2011 by batari Quote Link to comment Share on other sites More sharing options...
+batari Posted January 21, 2011 Share Posted January 21, 2011 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.