bogax

none of this is tested get rid of the redundant stuff if x<18 && _monster=1 then x=18 if x>135 && _monster=1 then x=135 if x<18 && _monster=2 then x=18 if x>135 && _monster=2 then x=135 if x<18 && _monster=3 then x=18 if x>135 && _monster=3 then x=135 if x<18 && _monster=4 then x=18 if x>135 && _monster=4 then x=135 if x<18 && _monster=5 then x=18 if x>135 && _monster=5 then x=135 could be rewritten as if monster < 1 || monster > 5 then skip if x < 18 then x = 18 if x > 135 then x = 135 skip here you'd average ~4 if statements if monster is random and you jumped out when you found your monster but somtimes you'll run one if statement sometimes eight if statements (as it is you always run all eight) __mongen _monster=(rand&7) rem *_monster=4 missile1height=10:COLUM1=rand missile1x=200:missile1y=200 if _monster=0 then _monster=10 if _monster=7 then _monster=10 if _monster=6 then _monster=10 if _monster=5 then player8x=80:player8y=80 if _monster=4 then player7y=140 if _monster=3 then player6y=1 else player6y=200 if _monster=2 then player5x=1 if _monster=1 then player2y=(rand&7)+20:player2x=(rand&7)+50 return on goto and on gosub take about as much time as four if statements but they use less code and they take a consistent amount of time __mongen _monster=(rand&7) rem *_monster=4 missile1height = 10 : COLUM1 = rand missile1x = 200 : missile1y = 200 : player6y = 200 on _monster goto m0 m1 m2 m3 m4 m5 m6 m7 m0 m7 m6 _monster = 10 : return thisbank m5 player8x = 80 : player8y = 80 : return thisbank m4 player7y = 140 : return thisbank m3 player6y = 1 : return thisbank m2 player5x = 1 : return thisbank m1 player2y = (rand & 7) + 20 : player2x = (rand & 7) + 50 : return thisbank think about what you're doing here you'll sometimes be wasting time needlessly setting pfscore2 several times before it gets to what you want if r=0 then pfscore2 = %11111111 if r>30 then pfscore2 = %01111111 if r>60 then pfscore2 = %00111111 if r>90 then pfscore2 = %00011111 if r>120 then pfscore2 = %00001111 if r>150 then pfscore2 = %00000111 if r>180 then pfscore2 = %00000011 if r>210 then pfscore2 = %00000001 if r>240 then pfscore2 = %00000000 if r>242 then goto __gizdead bank4 at the least you should reorder the code and then jump out when you get where you want if r > 240 then pfscore2 = %00000000 : goto skip if r > 210 then pfscore2 = %00000001 : goto skip_the_rest if r > 180 then pfscore2 = %00000011 : goto skip_the_rest if r > 150 then pfscore2 = %00000111 : goto skip_the_rest if r > 120 then pfscore2 = %00001111 : goto skip_the_rest if r > 90 then pfscore2 = %00011111 : goto skip_the_rest if r > 60 then pfscore2 = %00111111 : goto skip_the_rest if r > 30 then pfscore2 = %01111111 : goto skip_the_rest if r = 0 then pfscore2 = %11111111 goto skip_the_rest skip if r > 242 then goto __gizdead bank4 skip_the_rest personally I'd do something more like this again uses less code takes about the same amount of time and the timing is more consistent if r > 0 && r < 31 then skip rem temp1 = r / 30 temp1 = r / 2 : temp1 = ((temp1 / 16) + 1 + temp1) / 16 pfscore2 = tbl[temp1] data tbl %11111111, %01111111, %00111111, %00011111, %00001111, %00000011, %00000001, %00000000 end if r > 242 then goto __gizdead bank4 skip

Hard to know what you don't follow & is a bitwise AND 1 AND 1 = 1 1 AND 0 = 0 0 AND 0 = 0 so if you AND x with 1 you get x if you AND x with 0 you get 0 & ANDs corresponding bits in two bytes putting the result bit in the corresponding bit of the result byte %11000000 & %10111111 = %10000000 the playfield is 32 (pixel) columns x 12 (pixel) rows each byte is 8 bits a playfield row is 4 bytes (ie 4 (bytes) x 8 (bits)) each bit is a playfield pixel the whole playfield is 48 consecutive bytes var0 is the name of the location of the first byte of the playfield which is pfpixels 0..7 in the upper left corner the fourth byte of the playfield is var4 (the first byte of the second playfield row) but you can also refer to it as var0[4] (var0[0] is just var0) the data statements work in a similar fashion in this case the first byte of each row is %11000000 the 1s are the firewall so you look up the location of the playfield byte you want according to whatever f is in the top and bot tables and put it in temp1 temp1 = top[f] you need to do that because you can't use indexing to index something ie you can't do var0[top[f]] so you use temp1 to refer to the desired playfield byte var0[temp1] which you & with an approprate byte chosen from a table using f mask[f] &ing the appropriate bit with 0 turns off that pixel then put the result back in the same byte of the playfield var0[temp1] = var0[temp1] & mask[f]

with the kernel you're using it's possible to manipulate the screen directly without using pfpixel the screen is 4 bytes per row the first column (of bytes, 8 screen pixels) is bytes 0, 4, 8 .. etc. the corresponding screen variables (names) are var0, var4 etc here I've rewritten the fw routine to look up an index for the screen byte (indexed relative to var0) then apply a mask to mask out the appropriate screen pixel fw temp1 = top[f] : var0[temp1] = var0[temp1] & mask[f] temp1 = bot[f] : var0[temp1] = var0[temp1] & mask[f] f = f + 1 return data mask %10111111, %10111111, %10111111, %10111111, %10111111 %01111111, %01111111, %01111111, %01111111, %01111111 end data top 4, 8, 12, 16, 20, 4, 8, 12, 16, 20 end data bot 40, 36, 32, 28, 24, 40, 36, 32, 28, 24 end

not sure I follow your code but it looks to me like your else clauses turn on pixels that should already be on your line of if statements keeps running through statements that turn off pixels that you've already turned off so most of your calls to pfpixel are completely redundant and you should only need to mess with the pixels when f changes not sure this will work or if I got it right but try replacing the f = f + 1 statements and if statement tests of f with calls to this subroutine (sorry, can't test it, don't have all that newfangled bB stuff) (I may have slipped the tables by one) edit: damn, I must have been groggy last night see if this works better fw temp1 = col[f] : temp2 = trow[f] : pfpixel temp1 temp2 off temp1 = col[f] : temp2 = brow[f] : pfpixel temp1 temp2 off f = f + 1 return data col 1, 1, 1, 1, 1, 0, 0, 0, 0, 0 end data trow 1, 2, 3, 4, 5, 1, 2, 3, 4, 5 end data brow 10, 9, 8, 7, 6, 10, 9, 8, 7, 6 end Dragon Defense mod.bas

It probably just takes too long to run. You might be able to break it up and do some stuff this drawscreen and other stuff next drawscreen The processor creates the screen periodically in real time it needs to do this at a fixed time. after it draws the screen there's a little time left while it waits for the next time it needs to draw the screen That's when your program runs If your program takes too much time between drawscreens it'll miss it's schedule. There's probably speed optimizations you could make it would help if you posted your source

Me to And it's worse than that. At least for some stuff if you use a keyword as the beggining of a variable name bB will get confused. But that's not the fix I'd choose. That statement was not meant as criticism only to note that I do these things differently. (if it were serious criticism I wouldn't have stuck my tongue out ) This is an ages old debate. And it's not just people with bad memories and learning disabilities that prefer your "style" (style in quotes because I think, as in your case, it's something more than just style) I find it very wearying and distracting if a variable name is a sentence I have to parse. That should be !_Bit0_Reset_Restrainer{0} Since I goofed something else and edited I may have inadverntently fixed that too.

Sorry, I guess I wasn't clear. It's not the use of goto's that I object to Nor do I object to reversing the condition and skipping forward It's jumping forward when you should jump back especially jumping forward and then immediately jumping back and extra especially when you're jumping forward instead of looping back only because you jumped forward just so you could jump back. I only put the extra if-then-to-set-the-debounce_flag in because I thought it made it clearer what was going on I'd use a gosub to get the junk out of the way because I think it makes the code easier to read If there was a reason not to use a gosub I'd put the code at the beginning of the loop and, if there's reason to, jump into the middle of the loop to enter the loop. As for that bit of code, hard to know how I'd rewrite it without context but something like this probably if !switchreset then _Bit0_Reset_Restrainer{0} = 0 : goto __Skip_Main_Reset if !_Bit0_Reset_Restrainer{0} then : _Bit2_Game_Over{2} = 0 : goto __Start_Restart __Skip_Main_Reset except I might reverse the sense of _Bit0_Reset_Restrainer{0} instead of using the ! and I wouldn't use those verbose names or leading underscores edit: oops missed a line

This bit is why dingbats think goto's are so dangerous It's needlessly complicated. __Title_Screen_Loop drawscreen if !switchreset && !joy0fire then _Bit0_Debounce_Reset{0} = 0 : goto __Skip_Title_Reset_Fire if _Bit0_Debounce_Reset{0} then goto __Skip_Title_Reset_Fire goto ____Main_Loop_Setup bank2 __Skip_Title_Reset_Fire goto __Title_Screen_Loop rem we're going to loop in the title screen untill rem the first time switchreset or joy0fire is pressed rem we will keep a flag that indicates if switchreset or rem joyfire was pressed last time throught the loop rem so we can decide if this is the first time switchreset rem or joy0fire has been pressed rem the flag will be true if either switchreset or joy0fire rem was pressed last time through the loop rem if the flag is true we loop back, set the flag and rem draw the title screen rem if the flag is not true we test if either of switchreset rem or joy0fire is pressed this time. rem if switchreset and joy0fire are both not pressed we loop rem back, otherwise we fall through and get on with it __Title_Screen_Loop if switchreset || joy0fire then debounce_flag{0} = 1 else debounce_flag{0} = 0 drawscreen if debounce_flag{0} then __Title_Screen_Loop if !switchreset && !joy0fire then __Title_Screen_Loop __Main_Loop_Setup

what else does the timer have to do? do you really want 45 or do you want 0..44? count = count + 1 if count = 68 then count = 0 if count & 7 = 5 then count = count + 3 will go through a cycle with a length of 45 but it doesn't count 0..44 bits 0..2 count 0..4 and bits 3..6 (ie count/8) count 0..8

here I've set a (lives) right at the beginning then choose the deadscreen or the title based on that (you still need to set it when you begin again after you've run out of lives (sorry I was messing with your code so I don't know what I might have messed up) it would be nice if you used the code tags and/or attach your code rem Generated 1/4/2010 1:48:01 PM by Visual bB Version 1.0.0.548 rem ********************************** rem *<Tinkernut World> * rem *<Shoot the squirrel before he * rem *eats you.> * rem *<[email protected]> * rem *<www.tinkernut.com> * rem ********************************** rem Create a variable to keep up with lives a = 5 deadscreen if a then opening rem Create the dead screen playfield: .............XX................. ............XXXX................ .............XX................. .........XXXXXXXXXX............. ........XX........XX............ ........XXXXX.X..XXX............ ........XX.X..X..XXX............ ........XX.X...XX.XX............ ........XX........XX............ ........XX........XX............ ........XX........XX............ end rem added a delay so deadscreen shows rem if your still firing a = 60 delay drawscreen a = a - 1 if a then delay goto title rem Create the title screen opening playfield: .XX.XXX.XX..XXX...XX..X.X.XXX.XX X....X.X....X..X.X..X.X.X.X..X.. .X...X.X.XX.XXX..XXXX.X.X.XX..X. ..X..X.X..X.X.X..X..X.X.X.X....X XX...X..XX..X..X.X..X..X..XXX.XX ................................ ....X...X.XXXX.XXX..X...XXX..... ....X...X.X..X.X..X.X...X..X.... ....X...X.X..X.XX...X...X..X.... ....X.X.X.X..X.X.X..X...X..X.... ....XX.XX.XXXX.X..X.XXX.XXX..... end COLUBK = $00 COLUPF = $0E rem Loop the screen until the spacebar is pressed title drawscreen if !joy0fire && !joy1fire then title rem This function displays after the title is skipped skiptitle rem Colors COLUPF = $40 COLUBK = $60 COLUP0 = 222 rem Player location player0x = 50 : player0y = 50 player1x = 20 : player1y = 20 rem Score setting and color score = 0 : scorecolor = $F8 rem Missle size and location missile1height=6:missile1y=255 NUSIZ0 = 25 rem Create a variable to keep up with lives a = 5 rem Create the playfield playfield: ..XX..XX..XX..XX..XX..XX..XX..XX XX..XX..XX..XX..XX..XX..XX..XX.. ..XX..XX..XX..XX..XX..XX..XX..XX XX..XX..XX..XX..XX..XX..XX..XX.. ..XX..XX..XX..XX..XX..XX..XX..XX XX..XX..XX..XX..XX..XX..XX..XX.. ..XX..XX..XX..XX..XX..XX..XX..XX XX..XX..XX..XX..XX..XX..XX..XX.. ..XX..XX..XX..XX..XX..XX..XX..XX XX..XX..XX..XX..XX..XX..XX..XX.. ..XX..XX..XX..XX.XXX..XXX.XX..XX end rem Create acorn sprite player0: %01111110 %01000010 %01011010 %11000010 %01100111 %11111110 %01010101 %10010010 end rem This main function is what loops constantly main rem This is the animation function animate rem This frame variable slows down the animation v = v + 1 rem This code animates the sprites if v > 7 then on w gosub ax bx cx dx : v = 0 : w = w + 1 : if w > 3 then w = 0 nextstep rem check to see if a missile has already been fired checkfire if missile1y > 100 then goto skip missile1y = missile1y - 2 : goto draw rem if a missile hasn't been fired, then fire missile skip if joy0fire then missile1y = player0y - 2 : missile1x = player0x + 4 rem Draw output to screen draw drawscreen rem Fix player wraparound bug if player0x < 8 then player0x = 8 if player0x > 150 then player0x = 150 if player0y < 8 then player0y = 8 if player0y > 84 then player0y = 84 rem Have player 1 chase player 2 if player1y < player0y then player1y = player1y + 1 if player1y > player0y then player1y = player1y - 1 if player1x < player0x then player1x = player1x + 1 if player1x > player0x then player1x = player1x - 1 player1x = player1x : player1y = player1y rem Detect missile collision with squirrel if collision(missile1,player1) then score = score + 1 : player1x = rand / 2 : player1y = 0 : missile1y = 255 : goto pointsound rem Detect squirrel collision with the acorn if collision(player0,player1) then score = score - 1 : player1x = rand / 2 : player1y = 0 : missile1y = 255 : a = a - 1 : goto deadsound rem joystick movements if joy0up then player0y = player0y - 1 if joy0down then player0y = player0y + 1 if joy0left then player0x = player0x - 1 if joy0right then player0x = player0x + 1 rem refresh the screen skipmove goto main rem These four sprites are different stages of the animation ax player1: %00011000 %01111110 %01111110 %01111110 %00100100 %11000011 %01000010 %11000011 end return bx player1: %00011000 %01111110 %01111110 %01111110 %00100100 %11000011 %01000010 %11000011 end return cx player1: %00011000 %01111110 %01011010 %01111110 %00100100 %11000011 %01000010 %11000011 end return dx player1: %00011000 %01111110 %01011010 %01111110 %00100100 %11000011 %01000010 %11000011 end return rem Play point sound pointsound AUDV0 = 5 : AUDC0 = 8 : AUDF0 = 10 p = p + 1 drawscreen if p < 2 then pointsound p = 0 AUDV0 = 0 : AUDC0 = 0 : AUDF0 = 0 goto main rem Play dead sound deadsound AUDV1 = 8 AUDC1 = 6 AUDF1 = 12 p = p + 1 drawscreen if p < 5 then deadsound p = 0 AUDV1 = 0 : AUDC1 = 0 : AUDF1 = 0 if a = 0 then goto deadscreen goto main edit: added a delay so that the deadscreen shows if you're still firing

caveat: I'm not really familiar with the use of this kernel First I think you maybe need to clean up your code a little, it wouldn't compile for me (I'm guessing it thinks the first pfcolors statement is 11 lines, I don't know but it compiles with 12) The pfcolors are in tables in ROM so the simplest thing would be to just define a bunch of tables and select among them if that gives you enough variety Of course that will take a lot of space. the pfcolor statements as they are now are rather redundant (there's basically three color schemes repeated among nine tables so you could save some space there (but maybe those are just place holders not the intended final colors) You could probably combine tables into one or several bigger tables and manipulate the pointers (basically, write your own version of the pfcolors statement in bB so you'ld have one instance of your pfcolors routine that deals with the tables your way instead of a bunch of different instances of the standard pfcolors statement) Since the first and last colors in the tables are the same you could overlap tables and save some space. If tables in ROM won't do, you might be able to put the table in RAM and manipulate it there but you'ld have to give over [about] half your variables to the color table.

ranged rand (sorry, freehosting with ads)

In the x direction, correct player0: %00001111 %00001111 %00001111 %00001111 %00001111 %00001111 %00001111 %00001111 end player1: %00001111 %00001111 %00001111 %00001111 %00001111 %00001111 %00001111 %00001111 end player0x = 60 player1x = 100 player0y = 40 player1y = 40 scorecolor = $1A loop if !joy0fire then skip if p then p = 0 else p = 1 skip if p then P1 f = (l ^ $F0) | SWCHA : l = SWCHA if !f{4} then player0y = player0y - 1 if player0y < 1 then player0y = 80 if !f{5} then player0y = player0y + 1 if player0y > 80 then player0y = 1 if !f{6} then player0x = player0x - 1 if player0x < 16 then player0x = 150 if !f{7} then player0x = player0x + 1 if player0x > 150 then player0x = 16 goto draw P1 if joy0up then player1y = player1y - 1 if player1y < 1 then player1y = 80 if joy0down then player1y = player1y + 1 if player1y > 80 then player1y = 1 if joy0left then player1x = player1x - 1 if player1x < 16 then player1x = 150 if joy0right then player1x = player1x + 1 if player1x > 150 then player1x = 16 draw temp1 = player0x + 8 - player1x temp2 = player0y + 12 - player1y if temp1 < 17 && temp2 < 25 then COLUP0 = $42 : COLUP1 = $74 else COLUP0 = $36 : COLUP1 = $B2 drawscreen goto loop proximity_example.bin

Suppose playerx and playery are both 8 x 8 pixel boxes and the player position is the upper right corner of the box. The left edge of player0 is at the player0x position the right edge of a player0 is at player0x + 7 If the player1x position is less than player0x + 7 + 5 the left edge of player1 will be within 5 pixels of the right edge of player0 Likewise, if player1x is greater than player0x - 7 - 5 then the player1 right edge wiil be within 5 pixels of the left edge of player0 (-5 is the 5 pixel gap to the left of the player0x position, -7 is where the player1x position would be relative to player1's right edge) So if player1x is greater than player0x - 12 or less than player0x + 12 then player1x is within 5 pixels of player0 If we take the player1 position to be 0 then player0 must be greater than 24 or less than 0 In 8 bit binary, "less than 0" is greater than 24 as long as it's not 256 - 24 = 232 less than 0 (256 is 0) ie 0 - 232 = 24 So if (player1 - player0 - 12) < 24 then player1 is within 5 pixels of player0 That's just an example. The details will depend on your sprites and how the kernel you're using works. Here's some example code. player0: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 end player1: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 end player0x = 60 player1x = 100 player0y = 40 player1y = 40 scorecolor = $1A loop if !joy0fire then skip if p then p = 0 else p = 1 skip if p then P1 f = (l ^ $F0) | SWCHA : l = SWCHA if !f{4} then player0y = player0y - 1 if player0y < 1 then player0y = 80 if !f{5} then player0y = player0y + 1 if player0y > 80 then player0y = 1 if !f{6} then player0x = player0x - 1 if player0x < 16 then player0x = 150 if !f{7} then player0x = player0x + 1 if player0x > 150 then player0x = 16 goto draw P1 if joy0up then player1y = player1y - 1 if player1y < 1 then player1y = 80 if joy0down then player1y = player1y + 1 if player1y > 80 then player1y = 1 if joy0left then player1x = player1x - 1 if player1x < 16 then player1x = 150 if joy0right then player1x = player1x + 1 if player1x > 150 then player1x = 16 draw temp1 = player0x + 12 - player1x temp2 = player0y + 12 - player1y if temp1 < 25 && temp2 < 25 then COLUP0 = $42 : COLUP1 = $74 else COLUP0 = $36 : COLUP1 = $B2 drawscreen goto loop

m{0} just references bit zero in byte m you can replace m{1}=0 :rem Turned on if the last location of the joystick was UP m{2}=0 :rem Turned on if the last location of the joystick was DOWN m{3}=0 :rem Turned on if the last location of the joystick was LEFT m{4}=1 :rem Turned on if the last location of the joystick was RIGHT m{5}=0 :rem Turned on if the last location of the joystick was UP+LEFT m{6}=0 :rem Turned on if the last location of the joystick was UP+RIGHT m{7}=0 :rem Turned on if the last location of the joystick was DOWN+LEFT m{0}=0 :rem Turned on if the last location of the joystick was DOWN+RIGHT with m = %0001000 and if joy0up then m{1}=1:m{2}=0:m{3}=0:m{4}=0:m{5}=0:m{6}=0:m{7}=0:m{0}=0 if joy0down then m{1}=0:m{2}=1:m{3}=0:m{4}=0:m{5}=0:m{6}=0:m{7}=0:m{0}=0 if joy0left then m{1}=0:m{2}=0:m{3}=1:m{4}=0:m{5}=0:m{6}=0:m{7}=0:m{0}=0 if joy0right then m{1}=0:m{2}=0:m{3}=0:m{4}=1:m{5}=0:m{6}=0:m{7}=0:m{0}=0 if joy0up && joy0left then m{1}=0:m{2}=0:m{3}=0:m{4}=0:m{5}=1:m{6}=0:m{7}=0:m{0}=0 if joy0up && joy0right then m{1}=0:m{2}=0:m{3}=0:m{4}=0:m{5}=0:m{6}=1:m{7}=0:m{0}=0 if joy0down && joy0left then m{1}=0:m{2}=0:m{3}=0:m{4}=0:m{5}=0:m{6}=0:m{7}=1:m{0}=0 if joy0down && joy0right then m{1}=0:m{2}=0:m{3}=0:m{4}=0:m{5}=0:m{6}=0:m{7}=0:m{0}=1 with if joy0up then m = %00000010 if joy0down then m = %00000100 if joy0left then m = %00001000 if joy0right then m = %00010000 if joy0up && joy0left then m = %00100000 if joy0up && joy0right then m = %01000000 if joy0down && joy0left then m = %10000000 if joy0down && joy0right then m = %00000001 In the latter case you can go further The if statements reference bits in SWCHA The SWCHA (joy0) bits are RLUDxxxx (here x is 'we don't care' but they're joy1) a 0 is true ie if SWCHA reads %1101xxxx then joy0 is up if joy0up then is like if !SWCHA{5} then The SWCHA (joy0) bits are RLUDxxxx (here x is 'we don't care' but they're joy1) a 0 is true ie if SWCHA reads %1101xxxx then joy0 is up if SWCHA reads %1001xxxx then joy0 is up and left note you are not going to see %1100xxxx because that's joy0 up and down at the same time SWCHA / 16 will give you (joy0) %0000RLUD You can invert the lower 4 bits by xoring with %00001111 (so that a closed switch reads 1 instead of 0) and in that case the maximum value you would get is 10d or %00001010 (joy0 R & U) so your code would be something like rem %00000000 0d (decimal) no switch pressed rem %00000001 1d down rem %00000010 2d up rem %00000011 3d up & down, can't happen rem %00000100 4d left rem %00000101 5d left & down rem %00000110 6d left & up rem %00000111 7d left & up & down, can't happen rem %00001000 8d right rem %00001001 9d right & down rem %00001010 10d right & up rem 11..15 are either down & up or right & left (or both) temp1 = (SWCHA / 16) ^ %00001111 m = joy0_flag_table[temp1] data joy0_flag_table %00000000, %00000100, %00000010, %00000000, %00001000 %10000000, %00100000, %00000000, %00010000, %00000001 %01000000 end hopefully I got that all right but I guarentee nothing edit: fixed some goofs

Actually, regular data statements can be larger than 256 bytes but you can't reach more than the first 256 bytes in the normal way.

It appears that Bb is bugged. It fails to load p1x before it subtracts 2 0 is what's in the accumulator at that time so it effectively sets player1x to -2 I think this is one for Reveng as a work around you could try player1x = p1x - 2 or p1x = p1x - 2.0

Here I've moved data statements to the end and added the noinlinedata optimization put galactopus in a data statement removed some redundant if clauses this frees 92 bytes but the galactopus data statement can't cross a page boundary and there's only 57 bytes between the end of galactopus and the next page boundary (and part of that is because I also moved some subroutines past the galactopus data statement) no idea how badly this will mess any thing up Galactopus20141105_2.bas

I hesitate to comment since I'm a complete novice but I think you're stuck with symmetry unless you're willing to put up with flicker. I don't think there's time to reposition the sprites even if there's some way to (otherwise) do it. But flicker suggests some interesting possibilities. hmm, I think I feel another minikernel comming on..

You have a number of opportunities to optimize for space. If you do assignments to like values consecutively on one line it will save space So for example if you're zeroing a bunch of variables put the assignments to 0 consecutively on one line and bB wont keep reloading 0 it'll load it once per string of zero assignments. I did some of that. It saves about 50 bytes You have redundant code you could get rid of. One big instance of redundancy is with the animation of Galactopus Here I've moved that to a subroutine. I also rearranged it a bit so that b gets incremented before Galactopus and made the Galactopus sprite selection on temp1 so c is not needed. I don't know if that messes anything up. I didn't test this to see if it actually works You could probably save some bytes by putting Galactopus into data statements or one sprite definition but that's more complicated (but only slightly) Galactopus20141011_opt.bas

rand is different every time you use it (and it takes time to calculate each time) edit: Wrong! an if statement just uses the current value of rand without calling the rand routine your code should be fine but.. Do this instead p1_orientation = rand/2 : (p1_orientation/2 + p1_orientation)/16 + 1 Rand goes from 0..255 That takes rand and multiplies it by .75/16 and adds 1 (rand * .75)/16 gives you a number 0..11) edit perhaps I should point out that that always sets p1_orientation to a number between 1..12 yours would skip it if rand > 240

Yes it uses the score, the scorepointers the aux varables the temp variables and some of the stack variables. It doesn't use temp7 so hopefully bank switching would stiil work. It doesn't use aux1 so maybe playfield heights would still work I've only tried it with the plain vanilla kernel

yes This diplays 6 sprites The sprites are selected with six pointers mkptr0..5 The pointers point into two tables splistlo, and splisthi The tables contain the locations of the sprite data. The sprites have to be upside down The constant mklines specifies the number of lines to use (the number of lines in a sprite) The first bit of the fourth sprite is repeated in the first bit position of the sixth sprite and the first bit of the sixth sprite never shows edit: fixed a bug unrelated to the minikernel that kept one from coming up sprites_minikernel.bin sprites_minikernel.bas

Here's another messages_minikernel.bas messages_minikernel.bin

Yes and I think that's true for all of them (fire, up, down etc) I was in no way refering to your post (you were posting while I was composing)