bogax

I'm not going to fight with that god cursed forum editor. new_explanation.txt

Do you want a better explaination or do you not care?

rand & 12 isn't what you want to do ANDing with something is a simple way to take a number mod some other number but it only works if the other number is a power of two. Then I can AND with that power of two minus one. in decimal say I have a four digit number and I want to take that number mod 100 I just throw away the every thing except the least significant two digits wxyz becomes 00yz it doesn't work if I just keep, say, the y so I get 00y0 But that's sort of what you are doing when you do rand & 12 binary %hgfedcba & %00001100 = 0000dc00 (%00001100 is 12 in binary) I would scale the random number to 13. In this case it would be 13/256 = 13/256 = (1/2 + 1/4 + 1/64)/16 g = rand/2 : g = ((g/4 + g)/2 + g)/16 That could probably be improved by adding some rounding in (by adding a 1 or 4 or something before dividing by 16 maybe) but that's probably good enough. if !collision(player0,missile1) then skip g = rand/2 : g = ((g/4 + g)/2 + g)/16 score = score + 10 : n = 10 if !g then skip missile1y = m1y_tbl[g] rem see if missile1x is the same rem if it is change g if missile1x = m1x_tbl[g] then g = g + 5 if g > 12 then g = g - 12 missile1x = m1x_tbl[g] skip data m1x_tbl 0, 40, 56, 72, 88, 104, 120, 40, 56, 72, 88, 104, 120 end data m1y_tbl 0, 59, 59, 59, 59, 59, 59, 26, 26, 26, 26, 26, 26 end That will probably skew things because it only checks missile1x and missile1x can be the same for different positions so it will choose a different position for missile1 when it doesn't need to. That can be fixed but it's probably not worth it edit incorrect wording re ANDing to mod by powers of two

heh once per frame is definitely not true though it may be only noobs (me too) that read the buttons multiple times. It's not at all uncommon to see long strings of if statments reading the same buttons. I generally don't worry about it I'm going to be using Stella. But it's sloppy. I'm pretty sure I've seen the subject discussed here on the forums before but it doesn't come up much so I guess it's not much of a problem. I'm not sure you could count on that. My recollection is that 20ms is the usual prescription (time to wait for the bouncing to stop) and that's supposed to be plenty so 16ms is probably enough. But I know I've seen switches (relays actually) that bounced for a lot longer than that. I have no idea what an Atari controller would do and I have no idea what piece of air they pulled the 20ms figure from. Sure. I wasn't even objecting to calling it debounce (although, like I said, it drives me nuts) It's just that there's a possibility of confusion when some noob comes across actual debounce and it turns out to be something different from what they're expecting.

debounce would be something like this (not that this is the way I'd code it) if debounce then key_is_pressed if !joy0fire then j0f = 0 : skip j0f = j0f + 1 if j0f > 2 then debounce = 1 : j0f = 0 goto skip key_is_pressed if joy0fire then j0f = 0 : skip j0f = j0f + 1 if j0f > 2 then debounce = 0 : j0f = 0 skip edit oops, forgot to reset the j0f counter when debounce changes

I'm not following you then. The problem is when and how you set or reset that bit not the bit itself.

so what is player01 ?

If you're trying to get one of six randomly selected values for player0x you could do like this temp1 = rand/2 : temp1 = (temp1/2 + temp1)/32 player0y = 60 : player0x = tbl[temp1] data tbl 36, 53, 69, 85, 101, 117 end scale rand, which ranges up to 255, down to 5 (6 values, 0 - 5) 1/2 + 1/2 / 2 = 1/2 + 1/4 = 3/4 3/4 / 32 = 3/128 3/128 * 255 = 5.9765625

You can put them where ever you want I generally put them right after the jump back to the main loop. bB automatically inserts a jump around the table so that you don't run in to it. something like goto skip_table_1 data table1 0, 1, 2, 3 end skip_table_1 although you can't see the goto If you use the noinlinedata optimization it leaves out the goto part So you could put tables after a goto or a return or put in your own goto (maybe to jump around a group of tables instead of having bB put in a jump for each table)

u = 1 player0y = 60 : player0x = dat_tbl[u] data dat_tbl 0, 0, 36, 53, 69, 85, 101, 117 end it's lookup table, a read only array dat_tbl equals 0 for u = 0 dat_tbl equals 53 for u = 3 dat_tbl equals 117 for u = 7 like that

Don't know what you're doing (where's the random go?) u = 1 player0y = 60 : player0x = dat_tbl[u] data dat_tbl 0, 0, 36, 53, 69, 85, 101, 117 end

What bit are you talking about?

I fyou're doing it on an emulator it's because the keyboard is already debounced. If it's on a real 2600 then most of the bouncing might be hidden by the delay due to drawscreen but you couldn't count on that. Either way it's still not debounce

I'm not sure how to explain any better. maybe I didn't make it clear that what I read 0001010010110110011101110111111 edge detection 0001010010100100010001000100000 debounce 0000000000000000000111111111111 is meant to represent one key press. Your code would increment score 8 times in that example for that single keypress. Thats not debounce

COLUP1 = $1A if !joy0right && !joy0left && !joy0up && !joy0down then __Skip_Animation f = f + 1 if joy0right then _P0_L_R = _P0_L_R + 0.30 if joy0left then _P0_L_R = _P0_L_R - 0.30 if joy0up then _P0_U_D = _P0_U_D - 0.30 if joy0down then _P0_U_D = _P0_U_D + 0.30 if f = 10 then player0: doesn't need an extra variable

I'd call it edge detection. Not sure it matters. My impression is that, when talking about writing games debounce is more often used to mean edge detection than actual debounce (but not always) You might note that it's not actually debounce but that that is the term that's used and leave it at that. And/or you might add a bit on actual debouncing since that's generaly considered a good idea even though I don't see it done here much. (probably more likely to see it when talking asm)

I probably shouldn't confuse you, but that's not actually debounce. It's more edge detection though The term debounce seems to be (mis)used for it a lot. (drives me nuts, heh ) Probably someday you're going to run into someone talking about actual debounce and wonder what they're talking about. For various reasons (one being bouncy contacts in a switch, hence debounce) when going from, say, 0 to 1 a switch might jump back and forth between 0 and 1 before it stays 1. Debounce is getting past that cleanly. Now suppose I decide I wont believe its really a 1 until I've seen three 1s in a row. then it might look something like this (each 0 or 1 is what I read when I read the switch one time): what I read 0001010010110110011101110111111 edge detection 0001010010100100010001000100000 debounce 0000000000000000000111111111111

dim current = temp1 dim previous = d scorecolor = $1A main rem keep a copy of joy0fire in previous rem joy0fire is true when bit 7 is 0 rem current is what we read this time rem previous is what we read last time rem invert current and AND it with previous rem then mask for the joy0bit rem true only if fire was not pressed rem last time and is pressed this time current = INPT4 temp2 = ((current ^ %10000000) & previous) & %10000000 previous = current if temp2 then score = score + 1 drawscreen goto main

Heh, I don't suppose anybody cares but.. I added a collision indication. The player color changes. I added a few different player shapes which you can step through using left and right when the player is yellow. Step through the functions using fire. The functions are: move the playfield block, move the player, change the player shape. Scorecolor follows function. scr_positions.bas

You skip the clean ! playfield statement when c = 5

You can if you want If you have questions, ask It's really just to show pfpixel positions versus player positions. The reason I said the player-playfield collision code is probably not what you want is because in it there's only one pfpixel it can be and it doesn't care which direction you're going. That simplifies things greatly But I expect most of the time you'd need to figure out which of several/many pfpixels your player is colliding with you have to do that by position. And it could be that this corner of the player is colliding with that pfpixel and that corner of the player is colliding with this pfpixel. hmm maybe I should rig it to show when an actual collision is detected. It's only when an actual player pixel overlaps a playfield pixel that you get a collision. I used a box for the player so if it overlaps at all you'd get a collision but if the player was say a single pixel you could have player pixels that you defined as off overlapping pfpixels without a collision and that complicates figuring by position which is colliding with what.

here's some code that will show you sprite and pfpixel positions fire switches between them sprite_v_pf.bas

I'll add that I've been using gosubs for things you might not normally use a gosub for, just to get player defintions and the like out of the way, to make it easier to see what the code is doing. you'd (probably) normally use a gosub where you want to reuse a piece of code but don't want to take up space with another copy of the code. but gosubs use extra time and code/memory compared to say, a goto especially if you're jumping around in diferent banks.

I rearranged your code I doubt this is what you want. r_pixel.bas

True I keep forgeting you guys are using VbB (I'm not)