Well his game got featured there

Lol. Don't worry about it, yours is a great size considering grayscale and all that.

Wow. Thanks! That's meaningful, considering yours is one of the first AND most famous. Still have a feeling it could be smaller than it is, though.

Anyways, if there's  anything else anyone wants, say the word.

Hayleia helped me optimize mine and I haven't updated it yet 

Grrrr...

It's no use, mine has too much eyecandy...

Will somebody please help?

I only suggest that you make it into more!

We should really change this into a "favorite routine" thread!


Mine is a Day of Week calculator (Month, day, and year are M, D, and Y, respectively):
:Y-(M<3
:round(7fPart((int(23M/9)+D+4+Y+int(Ans/4)-int(Ans/ᴇ2)+int(Ans/400)-2(M≥3))/7

Dino, I too think that Goto does have its place (heck, I preferred it over a While loop in my Shutdown game, and then there was this big argument...you had to be there, I guess). It still is kinda inefficient, though; you could use loops instead on most occasions.

And I also think that a useful command is Ans. Ans helps for optimizations in both size and speed...it's all-around good.

Finally, I want to expand on Dino's idea of "subroutines". I actually know of code for that (use any label other than S for the subroutine, and any variable you want in the loop instead of S, just make sure the subroutine doesn't modify it!):
:ClrHome
:Disp "MAIN PROGRAM
:For(S,-1,0
:If S
:Goto S
:End
:Disp "MAIN AGAIN
:For(S,-1,0
:If S
:Goto S
:End
:Disp "BACK IN MAIN
:Return
:Lbl S
:Disp "SUBROUTINE
:EndThis should display MAIN PROGRAM,SUBROUTINE,MAIN AGAIN,SUBROUTINE,BACK IN MAIN on the homescreen in 5 lines.

I have never come across a situation where I'd use this in my programs, but I would if I ever did. I recommend that to other BASIC programmers...it helps.

The curved surface is moving at a static speed, right? If you treat the collision like a static collision, but apply the curved surface's velocity as an offset to the ball's velocity, then subtract that offset from the result, you get the correct result.

Left and right, it will be constant. I'll make the curved object bounce on command, though.

Okay so I've never done that before, but I gave it a quick think and that's what I thought of.

Let's say you have a curved surface sprite that is 16 pixels wide. Let's make it look like this :



Now you have to build a 16-entries normal angles table. By that I mean a table that will hold 16 values, one for each X coordinate on the sprite, and which will represent the normal angle of the pixel on that coordinate. I don't think you have to calculate them, just guess them based on what you see. Of course, they had to be in the range 0-255 and not 0-359.



Using these angles requires all of your velocities to use polar coordinates. That means that your ball will not have X, Y, VX and VY coordinates (VX and VY being velocity amount for X and Y coordinates), but X, Y, VR and VT coordinates. X and Y will be your ball's coordinates on the screen, like you always used them, but VR and VT will be the polar coordinate for your velocity vector - respectively the length and the angle.

When you hit a pixel - I'll let collisions to you - just grab the X coordinate of the pixel relative to the start of the sprite, get the corresponding angle in the normal angles table and apply symmetry with the velocity angle - I think you'd do velocityAngle += (pixelNormal - velocityAngle) * 2. Then that should be good.

Of course you will have to write the code to handle polar velocity. You might want to apply trig on the angle and multiply the result by the length, to add both results (X and Y) to the ball's coordinates.

...I'm assuming this works with falling with proper accel, right?