Board Thread:Questions and Answers/@comment-24454571-20140517053531/@comment-5334617-20140523202956

Azihayya wrote: I'm not quite understanding that last part; first, it seems to me like the pixel is 6x6 because of the +5's,

It's really important to use words correctly, not only for expressing yourself to others, but to keep the concepts straight in your own head. The pixel is not 6*6 (at least, not unless you're using units of one-sixth of a pixel, and there's no reason to do that). The pixels are the smallest 'boxes' it is possible for SmileBasic to draw - and the box drawn by the program above is not the smallest box possible. The +5s in the GFILL command mean that the box that is drawn on the screen is 6*6 pixels. (The +5s in the IF statements are because the logic, and mathematics, should match what is drawn on the screen. Characters are 8*8 pixels, that's just part of the design of SmileBasic.)

and damn, I really don't get what's going on with those four IF statements. I see that it's checking the player location within the indices of the MAP Array, but I'm not relating to how those values are relating to the ... 'characters'?

The MAP array is related to the characters by the lines:

After the MAP array is filled with READs, every position in the array is checked: if the MAP is not zero for that location, then BGPUT puts a character on the screen at that location. If the MAP is zero for that location, then nothing happens, and that part of the screen is left blank. So, after this loop, there is a relationship between what is in MAP and what is on screen.

That relationship is not actively maintained; if another assignment were made to MAP without a corresponding BGPUT, there would be an inconsistency, and it might appear that there's a wall you can drive through, or an invisible wall; if another BGPUT were executed without updating MAP, that would also cause an inconsistency. But, for the rest of the program, MAP is not updated and no more BGPUTs are executed, so the relationship holds.

So, taking the PLX & PLY starting locations and rounding them, 48/8 =  6, 32/8 = 4; (48+5)/8 = 6.625, 32/8 = 4; 48/8 =  6, (32+5)/8 = 4.625; (48+5)/8 = 6.625, (32+5)/8 = 4.625, I'm not seeing the significance of these values.

The significance of those numbers are they are the X and Y values for the character locations of the four corners of the square. The top-left corner of the square (initially) is pixel location 48,32, which is in character location 6,4; because of the BGPUT loop I showed above, you can tell whether that character location is empty, or contains a wall, by checking MAP with those indices - because the value of MAP with those indices determines whether or not a wall ever got put there.

It says IF MAP(those values) THEN [update Player location].

More correct to say, IF MAP(coordinates) THEN [revert player location to old values]. Remember the explanation above; when the buttons are pressed, it is assumed that the square can move to the new location, and this assumption is reversed later on if it turns out the new location causes a crash into a wall. The IF statements are not about moving the square, they are about preventing the square being moved where it shouldn't.

Another way to put it, in the context of your explanation, is that I don't get how any of those equations will return a 0 or a 1.

The expression MAP(INDEX1,INDEX2) will only ever give the value 0 or 1, because the only values ever written to MAP(INDEX1,INDEX2) are 0 and 1. If I say ALICE=5:BOB=6:CHARLIE=5:DAVE=6 then any of the variables ALICE, BOB, CHARLIE, and DAVE will only have the values 5 or 6.

The modulo operator (%) is not used in this code.