Monopolies mean the product cannot be superior as there is nothing to compare against.

Also, they're usually to blame when the product quality decreases, as there is no incentive to improve, but there is to reduce manufacturing cost.

So anyways, what I mean is that physics APIs can be implemented in OpenCL, not that you'd have to roll your own physics in OpenCL. And if Physx gets implemented in OpenCL, we'll have choice again. Which would be cool.

with picking.

When a condition matches an object, the actions will apply only to the objects that fulfilled the condition.

For example, if you have

+on collision door with car

• set value 'door_opening' to 1

+compare global('door_opening') to 1

• set door position to 0,0

there is no relationship between the sprite that triggered the event to the action. But if instead you do something like

+on collision door with car

• set door position to 0,0

only the door that collided with the car will be set to 0,0

I'd like to be able to retrieve music position, as one can do with normal channels.

the window kind of spazzes out if I set it to MouseX, MouseY

I'd imagine, since on moving the window the relative coordinates of the mouse change.

Use absolute mouse position instead

EDIT: http://www.udec.cl/~jfuente_alba/dragwindow.cap yup, it works. Can't get the window edge sizes though, so it jumps a bit on grab. Guess that could be fixed too somehow.

EDIT2: removed window frame thus no jump. Any key to get rid of the flashing annoyance.

zip password support would be nice

at least for decompression

Man.

I can't draw. I look at your stuff and I realize I can't draw at all.

the idea is after a while one would get the *feel* for where one's gonna land, and this feel is harder to get the farther you are teleporting (since distance increases geometrically).

I got this idea after watching the movie Jumper and then playing the game and lamenting how horrible it was

Another quick gameplay mechanic experiment

http://www.udec.cl/~jfuente_alba/teleport.exe

Hold shift to teleport. Distance grows exponentially, be careful not to dissappear from the layout!

You'll teleport in the direction you are facing RIGHT BEFORE YOU LET GO. This is so you can decide first to teleport and then where to land also allows a teleport feign.

Edit: I know teleporting speed needs tweaking right now it picks up too slow, it's time squared. I'll adjust a proper curve when I use this in a game.

I made a similar example once but instead of repeating a high number of times it just consumes a time pool.

The time pool was refilled on each frame, so you could have fixed frame rate logic (good for exact collisions) with dynamic frame rate graphics. It's somewhat similar but not exactly the same and only useful if the graphics rate stays way over the fixed logic rate.

It just doesn't fit...

Metroid was a sidescrolling platformer before it got the FPS treatment.

yup that's the motion blur, two perpendicular passes.

yup, it's variable.

Haha, I love it. I'm sure there are some awesome gameplay ideas that could come from this one.

thx, I had some in my head but I can't spare the time to do any games these days. Thought I'd share and let others at it

oh and there's probably a better way to set/unset collision for a whole layer, but I couldn't think of any.