Hey guys, this might be a pretty trivial problem, but I've been puzzling over it for a while. It goes something like this - let's say you have a perfectly rectangular block of something light that you place perfectly flat at the bottom of an equally flat container, then fill it up with water. Since there's no water under the block, there shouldn't be anything to push back up on it, so it should just stay there.

It seems pretty counterintuitive, and I can't really imagine it happening. But I've also been thinking that the normal force at the bottom of the container should negate that downward fluid force, and make it rise again. But what if you have a container exactly equal to the dimensions of the block except for the height, you put the block at the bottom, and you fill the top with water such that only one side is touching the water. Are these two situations equivalent?

Of course, there could be other reasons why the block would stay there (negative pressure, hydrogen bonds, etc.), but negating all that, what should happen?

Yo, we don't condone the distribution of copyrighted works around here. There's other places you can advertise, so try not to do it over here too much.

If you're using interrupts, then there's very little difference. If your program isn't fast enough in the slightest, though, the difference becomes obvious.

For(F,L6+12,L6+767       //loop through all of the screen pixels except the last 12
{F} and {rand^8+Str1}->{F-12}   //take the byte, use AND to erase a single bit from it, and then store it into the byte directly *above* it
End                     //this makes it so that as the byte rises, each frame a pixel is erased from it

Thie first line loops through all the bytes in L6 (except for the last row, which is the last 12 bytes. We save those so that there's something to "feed" the flames). Since L6 has 768 bytes, we loop from 12 to 767.

If you look at the Str1 sprite, it's essentially diagonal pixels filling up the sprite, and each row/column has exactly one pixel. By using rand^8, we select one row at random, and erase that pixel from the screen. We then shift the entire screen up a row. By adding more pixels or taking them away from the sprite, you can do all sorts of things with the flames - bias them to one direction, make them last much shorter times, etc.

haha, they included a decades-old game

Yeah, but I think what he's trying to get at is loading a value into X, then using that value in HL as the first argument for the Line() command, which should make sense. It's easier to modify values outside of the command block.

Quote from: Xeda112358 on December 07, 2012, 07:41:00 am

I like how the twitter one is titled "Portal's physics engine rebuilt in 50KB—on a graphing calculator" and then right below it: "Portal's physics engine rebuilt in 25KB—on a graphing calculator" and in reality it is under 16KB

Lol wow

Actually IIRC there's the app, which is 16k, then there's the appvar, which hovers around 9k

You need to use free RAM and not program variables. (i.e. use the bytes in L1 and don't store new values to your original map, say GDB0 or whatever)