bogax

I only used temp1 because you can't use an expression as an index. Rand is a function. In the case of rand it's like a variable whos value changes every time you read it. each time you read it, it calls a subroutine that calculates a new value. That takes time (the inlinerand optimization puts a copy of the code that does the calculation wherever you use rand, that's faster but takes more space) So whenever you do f = rand & 7 you get a new f If f is only used for the one thing eg the player1 color you may as well make f the color and not the index so you don't have to keep looking in the table. if the player color is one that you have to set after each drawscreen you'd do this. f = rand & 7 f = color_table_0[f] when you want a new color then where ever you set COLUP1 COLUP1 = f if you don't need to update COLUP1 untill you change the color you'd do this temp1 = rand & 7 COLUP1 = color_table_0[temp1] and not waste a variable (again, this is assumming you're not using f for anything else)

I think he means something like this rem rand & 3 takes rand mod 4 temp1 = rand & 3 player_color = color_table[temp1] data color_table color0, color1, color2, color3 end Here, since the number of possible values rand returns is a multiple of 4, you can reduce the range to 4 values by taking rand mod 4 whithout producing bias towards any color(s) (it's trickyer if you want say one of 5 colors without bias) Since 4 is a power of 2 you can do the mod operation by masking for the lower 2 bits by anding with 3

Not sure how useful this is likely to be. I modified SeaGtGruff's move_around_rooms code to use tables to choose a new room from more than 256 possibilities based on a couple of indexes using a bit of asm. In bB a table index can only go up to 256 (I don't know what the limit on entries in the actual table is but it can be more than 256) So you need to use more than one table to index more than 256 entries. You can do that by using different routines for different tables (as is done in SeaGtGruff's code) This needs more code and a lot of jumping around Here I've put (the pointer to) the tables in tables then select a table with one index then point into the selected table with another index. Unfortunately this is (relatively) complicated and needs a bit of asm. First you have to create a table of pointers to tables. Since you need two bytes to specify a table and bB tables have one byte entries the table of pointers is split into tables of hi and lo bytes. Since the target table is changing and not hard coded in rom you need a couple (consecutive) bytes of ram to point to it. I used temp1 and temp2. You need to create the tables of pointers to tables data pointers_hi >table0_name, >table1_name, >table2_name end data pointers_lo <table0_name, <table1_name, <table2_name end bB adds a "." to the beginning of labels but not for table names so you don't need the a "." So you look up the table pointers and put the lo part of the pointer in temp1 and the hi part of the pointer in temp2. Then a bit of asm looks into the pointed to table and puts the result in a variable. This is packaged in a macro called lookup rem parameter 1 is the destination variable rem parameter 2 is a variable containing rem the index into the tables of rem pointers to tables rem parameter 3 is a variable used to index rem into the selected table macro lookup temp1 = pointers_lo[{2}] : temp2 = pointers_hi[{2}] asm ldy {3} lda (temp1),y sta {1} end end here I've molested SeaGtGruff's code tables_of_tables.bas if lookup is a function you can pass constants (but it's slower and uses another level of stack) rem first parameter is the index into rem the table of pointers table rem second parameter is the index into rem the selected table function lookup asm tax lda pointers_lo,x sta temp1 lda pointers_hi,x sta temp2 lda (temp1),y end return tables_of_tables_w_function.bas

Just for the hell of it I rewrote SeaGtGruff's code with more tables. This saved about 200 bytes, but it's probably slower. It's certainly not as easy to understand. Most of the savings is just replacing the string of if statments with on goto. For the rest, it's probably not the new tables but rearranging the old ones so that seperate routines are not needed. Mostly I was interested in how one might replace long strings of arbitrary if statements with looping through tables. In this case it saves nothing and no doubt takes longer. (but this wasn't a long string of if statements) move_around_rooms_with_more_tables.bas

The loons code has directions 1-4 he does an on goto based on the room you're currently in which takes you to an on goto for that room that selects a new room based on the direction you're going. The one I called lookup_room is simlar except I took out the on gotos and put the target rooms in a table. There's a row for each room and the four columns are the four directions. Since the rows/rooms are every fourth direction the current room is multiplied by four to get the row and then the direction is added to get the column for the index into the table. Then on gosub to select the drawing code for that room. The one I called compute_room assumes the rooms are in a 3 x 3 grid. if you want to go right you add one to the column address of the room and if you want to go down you add one to the row address. Simliar for left or up except you subtract. row / column numbers have to wrap so that eg 0 is after 2, that's built into the table. So you just look up the result of adding or subtracting in the appropriate table. Similar to forming the table address for lookup_room, since there's 3 columns of rooms the row number is multiplied by 3 and the column number is added to get the room number then on gosub is used to go to the room drawing code for that room. The direct_lookup code has a table for each direction and an entry in each table for each room. You just look up the new room for a particular dirction based on the room you're in now. Then on gosub to draw that room. SeaGtGruff's move_around_rooms is similar except he goes to a subroutine for each direction that does the table look up for that direction then uses the room to look up a room shape (and a room color) then uses a bunch of if statements instead of on goto (and why in the world.. ;P ) to select the correct room shape drawing code for the room. (so different rooms can have same shapes with different colors)

I guess this merits some comment. Contrary to SeaGtGruff's comment, I think the third bit "direct_lookup" is closer to his. I debated whether to do it that way to begin with but I was trying to shoehorn a table into your code with minimum changes. eg you don't use direction for anything there, other than choosing the room, but you might want to. After thinking about it a bit I decided it was silly to advocate lookup tables and not demonstrate building the calculations into the table. so I added the direct_lookup bit. I debated whether to call the tables by the directions but opted for add and sub(tract) to emphasize that that was built into the table. I arranged the tables 3 x 3 because that's how you had the rooms arranged and I was trying to make the correspondence easy to see. But the tables make it easy to do arbitraty connections between rooms. Going right from a to b need not mean that going left from b will take you to a The rooms don't have to be in a two dimensional grid they could be three or four or what ever dimensions. Or nothing like a grid.

Look up tables are easy and fun look up your room: check_boundaries if player0x = 0 then player0x = 152 : direction = _left : goto change_room if player0x = 153 then player0x = 1 : direction = _right : goto change_room if player0y = 17 then player0y = 87 : direction = _up : goto change_room if player0y = 88 then player0y = 18 : direction = _down : goto change_room after_check_boundaries if counter{4} then REFP0 = 8 drawscreen goto main change_room current_room = current_room * 4 + direction - 1 current_room = room_data[current_room] on current_room gosub drw_rm0 drw_rm1 drw_rm2 drw_rm3 drw_rm4 drw_rm5 drw_rm6 drw_rm7 drw_rm8 goto after_check_boundaries rem rows are rooms columns are directions data room_data 2, 1, 6, 3 0, 2, 7, 4 1, 0, 8, 5 5, 4, 0, 6 3, 5, 1, 7 4, 3, 2, 8 8, 7, 3, 0 6, 8, 4, 1 7, 6, 5, 2 end compute room: check_boundaries if player0x = 0 then player0x = 152 : room_col = sub[room_col] : goto change_room if player0x = 153 then player0x = 1 : room_col = add[room_col] : goto change_room if player0y = 17 then player0y = 87 : room_row = sub[room_row] : goto change_room if player0y = 88 then player0y = 18 : room_row = add[room_row] : goto change_room after_check_boundaries if counter{4} then REFP0 = 8 drawscreen goto main change_room current_room = room_row * 2 + room_row + room_col on current_room gosub drw_rm0 drw_rm1 drw_rm2 drw_rm3 drw_rm4 drw_rm5 drw_rm6 drw_rm7 drw_rm8 goto after_check_boundaries data sub 2, 0, 1 end data add 1, 2, 0 end lookup_room.bas compute_room.bas edit: the returns should have been return thisbank (now fixed) another edit: another option check_boundaries if player0x = 0 then player0x = 152 : current_room = subc[current_room] : goto change_room if player0x = 153 then player0x = 1 : current_room = addc[current_room] : goto change_room if player0y = 17 then player0y = 87 : current_room = subr[current_room] : goto change_room if player0y = 88 then player0y = 18 : current_room = addr[current_room] : goto change_room after_check_boundaries if counter{4} then REFP0 = 8 drawscreen goto main data subc 2, 0, 1 5, 3, 4 8, 6, 7 end data addc 1, 2, 0 4, 5, 3 7, 8, 6 end data subr 6, 7, 8 0, 1, 2 3, 4, 5 end data addr 3, 4, 5 6, 7, 8 0, 1, 2 end change_room on current_room gosub drw_rm0 drw_rm1 drw_rm2 drw_rm3 drw_rm4 drw_rm5 drw_rm6 drw_rm7 drw_rm8 goto after_check_boundaries direct_lookup.bas

call stack (Wikipedia) In the 2600 the variables are at the bottom of memory and the stack is at the top and grows downward. You're liable to run over something important or have something important run over you if you let the stack grow too big. edit: In case it's not clear from that article, on the 2600, gosub saves two bytes to the stack and return removes them, if you don't execute a return for every gosub you execute or pop the return address from the stack, the stack (on the 2600) can/will grow untill it overwrites other stuff (or is overwritten by other stuff).

If you're leaving junk on the stack, yes. This is particularly true with bB where the stack is only 3 or (something) deep.

Your code looks kind of convoluted. I didn't try too hard to follow it. here alien_noises if g>8 then g=8 : goto intro_main_2_setup if f<3 then c{3}=1 if c{3} then f=f+1 else f=f-1 if f>30 then c{3}=0 : g=g+1 AUDV1=g : AUDC1=6 : AUDF1=f return you branch out of a subroutine without popping the stack, do you ever return? (doesn't look like it to me, but I can't be sure) I assume you're meant to bounce off the orange, you don't always.

oops, yup. good idea, I should have moved them inside the main loop

again, I'm no expert I don't think you have to keep setting the players and playfield inside of main. you could move the main label to after the player2 statement. I think the turkey doesn't remember which way it's going after a drawscreen so you need to remember for it and tell it before each drawscreen (the if statements only tell it if it's actually moving) You can code negative one as -1 instead of 255 (personaly, I prefer 255) player2: %11111111 %11011111 %11011111 %11000011 %11011011 %11000011 %01111110 %00111100 end dim rp0 = p main a=0: b=0: c=0: d=0 if joy0right then a=1 : rp0 = 0 if joy0left then a=-1: rp0 = 8 if joy0up then b=1 if joy0down then b=-1 REFP0 = rp0 player0x=player0x+a player0y=player0y+b That's just a snippet so you can see what I'm suggesting. You wouldn't need to dim a variable and when I do I put all the dim statements at the beginning of code.

Again, I'm no expert The yellow highlighting I assume is some Visual bB thing. I know nothing of Visual bB. I suppose there's likely something in the multisprite.inc that you might want. I'm not sure how necessary it is. Things work fine for me without it.

I'm no expert While some strange things happen, I didn't have any trouble getting it to compile. Maybe this is a silly question but you did tell bB that you want the mutisprite kernel right? As I understand it, the mutisprite kernel recycles player1 and player0 has a higher priority, ie player0 will always be in front of all the other player sprites. Also the virtual sprites will flicker if more than one of them occupys the same horizontal space, they don't go behind each other.

It's still not perfect. If you get a high enough score on there so that it's recognizeable as the hiscore and then just keep firing so that you don't linger on the title screen sometimes it doesn't show the high score. sometimes it continues to show the last score and sometimes (it seems) to show 0 I can't see how that happens. look at your stop_shooting routine (in the original) then hang your head.. (I know, it's your first game, I forgive you ) edit : I think I got it moved where score gets set to hiscore and scorecolor gets set to the hiscore color to before goto MusicSetup dpooper_messed_with.bas

bah! this a game sucks (my hi score is 1700, I was trying not to score ) I didn't have any trouble with the hiscore but every fourth game the score is gone from the title screen and it's back to 0, can't figure out how that happens. (and with your original it just doesn't do anything, it sticks at the titlescreen with out the (hi)score) edit: I messed with it some. don't know how much I may have messed it up. but then, it was already pretty messed up http://pastebin.com/bxi3KVqq

You can put the labels into a table in bB You need to add a period to the beginning of the label(s) because that's what bB does The label, "label" is actually ".label" in the asm bB produces So (with a minimum of asm trickery ) you can do (something like) this rem on i goto temp1 = lbls_lo[i] : temp2 = lbls_hi[i] asm jmp (temp1) end data lbls_lo <.lbl_00, <.lbl_01, <.lbl_02, <.lbl_03 end data lbls_hi >.lbl_00, >.lbl_01, >.lbl_02, >.lbl_03 end This uses 2 more cycles and eight more bytes than Cybearg's (and two temp variables) Cybearg's label tables in bB rem on room goto asm LDX room LDA lbls_hi,x PHA LDA lbls_lo,x PHA RTS end data lbls_hi <(.lbl_00-1), <(.lbl_01-1), <(.lbl_02-1), <(.lbl_03-1) end data lbls_hi >(.lbl_00-1), >(.lbl_01-1), >(.lbl_02-1), >(.lbl_03-1) end

That's cheating (I don't think RT is doing assembly)

If you're going to need more than one if statement to break things up, on goto will be faster and shorter and constant time rem on i goto j = i / 8 : k = i & 7 on j goto slice0 slice1 slice2 slice3 slice0 on k goto lbl_00 lbl_01 lbl_02 lbl_03 lbl_04 lbl_05 lbl_06 lbl_07 slice1 on k goto lbl_08 lbl_09 lbl_10 lbl_11 lbl_12 lbl_13 lbl_14 lbl_15 slice2 on k goto lbl_16 lbl_17 lbl_18 lbl_19 lbl_20 lbl_21 lbl_22 lbl_23 slice3 on k goto lbl_24 lbl_25 lbl_26 lbl_27 lbl_28 lbl_29 lbl_30 lbl_31 for on gosub just gosub to the on goto(s) ( the lbl_xx will be the subroutines ) (which will require moving the on gotos out of the way) rem on i gosub gosub select . . select j = i / 8 : k = i & 7 on j goto slice0 slice1 slice2 slice3 slice0 on k goto lbl_00 lbl_01 lbl_02 lbl_03 lbl_04 lbl_05 lbl_06 lbl_07 slice1 on k goto lbl_08 lbl_09 lbl_10 lbl_11 lbl_12 lbl_13 lbl_14 lbl_15 slice2 on k goto lbl_16 lbl_17 lbl_18 lbl_19 lbl_20 lbl_21 lbl_22 lbl_23 slice3 on k goto lbl_24 lbl_25 lbl_26 lbl_27 lbl_28 lbl_29 lbl_30 lbl_31

Hard to know exactly without seeing your code. The colors are taken from a table in rom, which you are filling with a constant y which I think may be $EE a sort of greenish beige. (the variable y is at location $EE in ram) I think you need seperate pfcolor statements for each color

Another possibility Or the playfield bytes together and check the result. something like temp = ((((((((((var0 | var1) | var2) | var3) | var4) | var5) | var6) | var7) | var8) | var9) | var10) | var11 if temp then pf_not_clear Of course there's more than 12 variables to the playfield. You could do them a few at a time or all at once. You need the parentheses or bB gets goofy with the stack There's no limit on the height of a sprite is there? Perhaps you could cover the play field with big sprites and check for collisions.

I messed with your (game-16.txt) code some I changed it in four spots I guess you'll have to decide if it's any improvement I changed where the score get's set to the room should work as long as room < 16 score = 0 score = score + room ======= I think your jump/collision code is a mess ;P . I think you should clean it up. I tryed, not sure I got it right. edit: I tryed to remove the redundancies I didn't try to clean it up it's still a mess ======= I put the arrange sprite code in bank 2 and put the paramters in a table. Saves gosubs to other banks which take a (relative) lot of time and code. Even if you going to call it from another bank, you ought to make just one call and one return. I added some stuff to fill the table which I hope is not harmfull room 0 sets ballx,y to 180 room 15 sets player8x,y to 180 then there's exceptions for stuff that didn't/couldn't go in the table which gets called with on room gosub Since arranging the sprites in bB results in a lot of redundant loading of the index (room) (which irks me ) I also did a version in asm ======= I changed the draw_room code to on-goto and got rid of the string of if-thens game-16_mod.bas game-16_mod_w_asm.bas

I think the limit is the line length. bB doesn't seem to like lines over about 190 characters. (I can get it to compile for 44 labels) edit: I can't get it to do more than 45 labels even with a shorter line I believe when I asked about parameters I was told 46 was the limit, don't know if that's related

Something odd. The number of bytes left that's reported changes depending on where you break the line, even though the code produced is exactly the same.

I don't know if it's the length of the lines or the number of colon seperated statements on the lines, but if you break those long if-then statements up (and fix the stuff iesposta mentioned) it will compile.