bogax

some how I've gotten different versions and modifications of the MonkeyKing source the score_graphics and playerscores.asm all jumbled up I've been looking at the stack a little. I haven't seen it go deeper than 4 you can flatten your code a little. if you always gosub sprite_color and drawscreen you can instead jmp drawscreen from sprite_color in which case I haven't seen a stack depth more than 3 the branch clearing routines don't need to be subroutines looks like there are several places you could manipulate the screen directly and save subroutine calls to pfvline or pfread (might take more code but it would probably be faster) I'm not exactly sure how the game is supposed to behave I haven't seen score graphics glitches or going over on lines with MonkeyKing_NTSC.bas you could sacrifice one of your variables to the player scores routine and get an extra spot on the stack I think

what do you expect player0score = $a to display? if you're shooting for 10 it should be $10

This applies to the plain vanilla standard kernel, things will be different with some of the kernel options the playfield is 32 pfpixels x 12 pfpixels each pfpixel is 4 pixels x 8 scanlines the pfpixels are represented in memory by 32 x 12 bits the pf pixels go row x column starting at the top left the top left corner is pfpixel 0 0 (x y) the bottom right is 11 31 with 8 bits per byte that's 48 bytes 4 x 12 those are named var0..var47 in bB the bytes are consecutive in memory and every 4 bytes is a playfield row var0 is pfpixels 0..7 in row 0, var4 is pfpixels 0..7 in row 1 (the second row of pixels) the odd number bytes are reversed we number the the bits in a byte 7 6 5 4 3 2 1 0 var0 = %10000000 (128 decimal) will result in pfpixel 0 0 on and pf pixels 1..7 0 off (ie x = 1 to 7 with y = 0) var1 = %00000011 (3 decimal) will result in pfpixels 8..9 0 on and pfpixels 10..15 0 off the trunk of the player0 tree is at pfpixel 8 0..11 so to clear the branches on the right var1 = 1 the second column of 8 pfpixels are reversed so the bits in var1 numbered as 7 6 5 4 3 2 1 0 appear as playfield pixels 8 9 10 11 12 13 14 15 corresponding to var1 bits 0 1 2 3 4 5 6 7 to create a player0 tree right branch on row 0, var1 = %00011111 (31 decimal) (and it just occured to me that you've got the right side branch creation under the __left label and I used the value15 so the right side branches are only 3 pfpixels wide in my code) the branch clearing just sets every fourth playfield variable to the correct value and the way bB works it's faster if you put all the assignments on the same line (because they're all the same value) if you put the assignments on different lines it'd be something like this (in bB)(acc is a processor register, the accumulator) acc = 1 var1 = acc acc = 1 var5 = acc acc = 1 var9 = acc etc. since they're all assigning the same value and if they're all consecutively on the same line it's more like this acc = 1 var1 = acc var5 = acc var9 = acc etc. (of course it's in machine code not bB) if playfieldpos is 1 when pfscroll down returns you know pfscroll down just spent a lot of time moving the playfield otherwise it just increments playfieldpos you could move the playfield in bB it might save you 200+ cycles but it would take 200 bytes or so you'd basically do your own version of pfscroll down in bB

not sure what you mean by larger playfield this has more rows at the cost of some variables

Here I've meddled with your code some. Aside from thowing in a few goto's in empty goto spots (necessary to even get it to compile) and other minor rearrangements mainly I poked the screen variables directly in some places, clearing the branches in particular moved the new row/branch generation to after the scroll down and added a drawscreen so that's all you do in the rest of that frame having bumped the playfield up in the scroll routine (which takes time) moved the drawscreen into the sprite_color routine since they go together Unfortunately I've added a bug which I haven't figured out yet (you'll probably notice it ) edit: fixed (so you wont notice it ) I haven't seen it go over on the line count (neither this, or your original code) What makes you think bB doesn't like more than two &&'s ? MonkeyKing_NTSC_2_mod.bas

looks like you've got extra characters in the score graphics

Not really a bug I am frequently frustrated by having constant macro parameters treated as immediate values. Not really sure how to deal with that. How hard would it be to perhaps escape a constant to suppress emission of the "#" ? (best I could think of)

I know nothing of what you're doing don't you want to be testing temp2?

forgot, bB prepends a "." to labels here's RT's/your code slightly modified and your/RT's code stuffed in to a macro just supply the first byte of high score as a parameter ;``````````````````````````````````````````````````````````````` ; Remembers the high score until the game is turned off. ; dim _High_Score1 = v dim _High_Score2 = w dim _High_Score3 = x ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ;``````````````````````````````````````````````````````````````` ; Converts 6 digit score to 3 sets of two digits. ; ; The 100 thousands and 10 thousands digits are held by _sc1. ; The thousands and hundreds digits are held by _sc2. ; The tens and ones digits are held by _sc3. ; dim _sc1 = score dim _sc2 = score+1 dim _sc3 = score+2 mk0 asm sed lda _High_Score3 cmp _sc3 lda _High_Score2 sbc _sc2 lda _High_Score1 sbc _sc1 cld ; Carry will be clear if score > _High_Score ; need to prepend a . to the label as bB does bcs .No_High_Score ; Branch if Carry Set (goto ___No_High_Score label if carry is set) end ; New High Score code - this is skipped if we goto ___No_High_Score _High_Score1 = _sc1 _High_Score2 = _sc2 _High_Score3 = _sc3 No_High_Score ; (more bB code) mk1 def do_hiscore = callmacro _nh macro _nh asm sed lda {1} + 2 cmp score + 2 lda {1} + 1 sbc score + 1 lda {1} sbc score cld ; Carry will be clear if score > _High_Score bcs *+12 ; Branch if Carry Set (goto ___No_High_Score label if carry is set) lda score sta {1} lda score + 1 sta {1} + 1 lda score + 2 sta {1} + 2 end end do_hiscore _High_Score1 edit now I left out the sed (now fixed)

you need decimal mode

for what it's It works the the same for me with bB.1.1d.reveng41 (which I just downloaded, had been using 37) on Windows 8.1 Get the same warnings but the .bin works (I haven't actually looked at the code produced) I don't use VBB

I think this should work, but I don't think you can do it in less than 16 bytes dim scr0 = score dim scr1 = score + 1 dim scr2 = score + 2 dim hi0 = a dim hi1 = b dim hi2 = c if scr0 <= hi0 && scr1 <= hi1 && scr2 <= hi2 then skip_new_high_score hi0 = scr0 : hi1 = scr1 : hi2 = scr2 skip_new_high_score

Oops Yes, I should have mentioned that. Does it actually not compile? Or does it compile and give you that warning? I never really doped that out. It seems to produce the correct code. You get that if you assign 'minikernel' to the value of a label I'm guessing that inserting a JSR to the minikernel (ie to the label) shifts the label and that that gets fixed on a subsequent pass.

I'm trying to think how to put this without sounding like I'm telling you how you should be doing it, 'cause I'm not. You show some bB and then some equivalent assembly. My off the top of my head, gut reaction is that that's a good way to do it. The bB gives you something familiar to hang it (eg the assembly) on. I was just pointing out that you could take that farther. Now if it was me, I think I'd start with the bB show the how and why of the assembly it produces, then how it could be improved and how you might do things in assembly that aren't practical in bB (I'm thinking specifically the bit of code that does the MOD 15 and timing in a loop as a good example). But I'm not sure that that's better than just saying 'here, learn some assembly it's not that hard'.

You can do a minikernel (mostly) in bB. I don't know if thats helpful or just trying to dodge things that should be confronted head on. ie you don't really need to know much assembly but you still need to know nuts and bolts (and you need enough assembly to understand what you get from bB anyway) x6_1_5.bas

Oops I goofed the loop It will miss the player0y > 54 test So I guess it should be something like this if player0y < 54 then skip temp1 = 4 loop if player0x = p0xUpdat[temp1] then gosub __Up bank6 : goto p0yGt54test temp1 = temp1 - 1 ; if temp1 then loop if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank p0yGt54test if player0y > 54 then return otherbank skip const p0xUpdat = dat1 - 1 data dat1 19, 40, 112, 133 end

Get rid of the redundancy 166 bytes if player0x = 19 && player0y >=54 then gosub __Up bank6 if player0x = 40 && player0y >=54 then gosub __Up bank6 if player0x = 112 && player0y >=54 then gosub __Up bank6 if player0x = 133 && player0y >=54 then gosub __Up bank6 if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank if player0y > 54 then return otherbank 148 bytes if player0y < 54 then skip if player0x = 19 then gosub __Up bank6 if player0x = 40 then gosub __Up bank6 if player0x = 112 then gosub __Up bank6 if player0x = 133 then gosub __Up bank6 if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank if player0y > 54 then return otherbank skip 82 bytes if player0y < 54 then skip if player0x = 19 then gosub gsUp if player0x = 40 then gosub gsUp if player0x = 112 then gosub gsUp if player0x = 133 then gosub gsUp if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank if player0y > 54 then return otherbank skip gsUp goto __Up bank6 77 bytes if player0y < 54 then skip temp1 = 4 loop if player0x = p0xUpdat[temp1] then gosub __Up bank6 : goto skip temp1 = temp1 - 1 ; if temp1 then loop if player0y = 66 then _Bit0_P0_Floor = 2 : return otherbank if player0y > 54 then return otherbank skip const p0xUpdat = dat1 - 1 data dat1 19, 40, 112, 133 end

This Works if x <> c - 2 && x <> c + 2 then skip a = 26 skip This Works better if c - 2 <> x && c + 2 <> x then skip a = 26 skip

this compiles dim Level_Section = z dim Extra_Bits = g dim abcdefg = g def Enemy_Direction = Extra_Bits{0} def Ball_Direction = Extra_Bits{1} def Missile_Direction = Extra_Bits{2} def Section_Exit = Extra_Bits{3} def Section_Order = Extra_Bits{4} def !SectionOrder = !Extra_Bits{4} def am = a{4} if !Level_Section && !Section_Order then Level_Section=6:goto LS2 if !SectionOrder && !Level_Section then Level_Section=6:goto LS2 LS2

Here's one way Here's an explanation of rand & 76 something similar applies to your code. Here's the javascript for generating bB code ranged_rand_generator.html

or ; rand & 3 will be a random number 0..3 if collision(player0, missile1) then d = rand & 3 : player0x = P0xrnd[d] : player0y = P0yrnd[d] data P0xrnd 80, 140, 85, 10 end data P0yrnd 10, 50, 90, 50 end

The example code sets the player0x and player0y increments (P0_x, P0_y) according joy0 then applies that movement (adds them to player0x, player0y) does a drawscreen (which is when a collision is detected) then, if there's a collision, reverses the movement (it subtracts P0_x, P0_y from player0x, player0y) I substituted player1x, player1y for player0x, player0y (in the example code) and/or x and y (in your code) I couldn't see any reason not to use player1x, player1y directly instead of x and y (doesn't mean you don't have one) then substituted your x and y for P0_x and P0_y in the example code that is to say x and y have the same roll as P0_x and P0_y which seemed to be what you were trying to do. I also zeroed x and y after the collision check. 'till then you (might) need them, after that you either want them to be 0 or what ever joy0 indicates

It'd be something more like this rem Generated 4/12/2018 5:43:58 PM by Visual bB Version 1.0.0.548 rem ********************************** rem *<filename> * rem *<description> * rem *<author> * rem *<contact info> * rem *<license> * rem ********************************** set tv ntsc set kernel_options player1colors no_blank_lines set kernel_options pfheights set romsize 32kSC set optimization speed set smartbranching on set optimization noinlinedata set optimization inlinerand pfheights: 8 8 8 5 5 6 6 8 8 8 8 end playfield: XXXXXXXXXXXXXX....XXXXXXXXXXXXXXX X...................X..........X X...................X..........X X..............................X X...................XXXXXXXXXXXX X..............................X X..............................X X..............................X X..............................X X..............................X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end COLUBK = 0 COLUPF = 144 f = 0 player1x = 75 : player1y = 75 main if f = 2 then player1: %00000000 %00011000 %00011000 %01111110 %01111110 %00011000 %00011000 %00000000 end if f = 4 then player1: %00000000 %00110000 %00110110 %00011110 %01111000 %01101100 %00001100 %00000000 end if f = 6 then player1: %00000000 %01100110 %01100110 %00011000 %00011000 %01100110 %01100110 %00000000 end if f = 8 then f = 0 if f = 0 then player1: %00000000 %00001100 %01101100 %01111000 %00011110 %00110110 %00110000 %00000000 end player1color: $40 $42 $44 $46 $48 $4A $4C $4E end drawscreen if collision(player1,playfield) then gosub knock_player_back x = 0 : y = 0 if joy0right then x = 1 if joy0left then x = -1 if joy0up then y = -1 if joy0down then y = 1 player1x = player1x + x : player1y = player1y + y if SWCHA < 240 then f = f + 1 : goto animationinc animationinc goto main knock_player_back player1x = player1x - x player1y = player1y - y return PF_boundaries.bas PF_boundaries.bas.bin

That should be if SWCHA<240 then f=f+1

have a look at this