thehen, nice link. I find that amusing however. That looks like the creator is psema4. He is currently working on getting HTMl5/JS game running on the Ouya. By using the Chormium webkit as the wrapper.

This strikes me that psema4, has keen interest on working with html5/js and open game consoles. :P

forums.ouya.tv/discussion/comment/8897

If it's linux, can't you do export for nodewebkit? I know what the Pi is, but I don't know a lot of details.

C2 as of this time has no robust networking api. There is also no C2 server technology yet... however there is promising hope down the road....... sometime down the road. However we currently do have

Websocket

Socket.io

these paths will require you to program a server backend. As they are only client communications

Velotjet has(http://www.scirra.com/forum/behavior-multiplayer-online-demo_topic61563_page1.html)

Photon Cloud Behaviour

Multiplayer plugin

These are more robust and include more room options and you can create a game using this providing you know there isn't going to be server side logic. I'm prone to detail errors on this

I think I know what your asking. If I'm wrong. Sorry, but your 3rd paragraph is throwing me.

search = int(tokenat(List.SelectedText,0,",") )

xIndex = Array.indexof(search)

xpos = Array.At(xIndex, 0)

ypos = Array.At(xIndex, 1)

you will have to validate both values. but I think this is the direction your looking at.

uumm

"if (condition A and condition B and condition C) or (condition D)"

Compare two Value

condition:   (a=b & b=c & c=d) | a=d

comparative: =

vale:        1

something like that, I personally wouldn't want to type that out in C2 small box, but that would be it or along those lines.

Hello, here with another problem with my tile game. After testing the game on an ipad I came to the horror. The game was just playable. However, this left 7" and lower in the lurch. So I thought why not use zoom.

And that's where it went all kinds of wacky. Zoom doesn't zoom where pressed, the tiles move right over each other causing wacky behaviour. I'm trying the CanvasToLayer, but that doesn't seem to be working :(

I would appreciate it if some one can take a look and spot the problem :)

docs.google.com/file/d/0B0V2EvCXNzYUTUQwUGg5Umt6Vzg/edit

How it is suppose to work

* Touching/clicking on the play area starts to zoom in at the point of pressed

* Release zooms out

* tiles should remain on there X or Y axis rather than floating anywhere on the board.

edit: removed easetween behaviour

I think the game is pretty good puzzle kind of game

however, maybe adding a move where Do makes quick Dash, with a Rainbow trailing behind? could help with some of the tougher puzzles :)

also the game had a very long load time.

• Set TiledBg width: clamp(TiledBg.width + 1, minWidth , maxWidth)

and for the lower

• Set TiledBg width: clamp(TiledBg.width - 1, minWidth , maxWidth)

clamp(x, lower, upper) is by the far the easiest way to handle return of lower and upper limitations.

however, i'm surprised your buttons to change your slider. I always found it to be more intuitive to use a drag model.

for simple sample this assumes that all your objects center points are on the left side rather than the center. also the sample uses touch, but you can use mouse. However, I find touch to be a lovely action for when the mouse is being pressed anyways :)

give the dragborder/box the variable touchid and set default to -1

dragborder.touchid = -1

when the touch or mouse is on the meter frame

onTouch dragborder

-- dragborder = touch.touchid

while the right touch id is touching the screen

isTouching

dragborder.touchid = touch.touchid

-- meterbar.width = clamp(touch.x, dragborder.x, dragborder.x + dragborder.width)

--meterbar.value = (meterbar.width / dragborder.width) * 100

when the touch event is released

on any touch end

dragborder.touchid = touch.touchid

-- dragborder.touchid = -1

-- meterbar.value = meterbar.value = (meterbar.width / dragborder.width) * 100

i like them. thanks for sharing :)

sqiddster, I thought it might create a more fluid deceleration that was dt based rather than tick based. If the deceleration was per tick then slower hardware would end up having a deceleration slower compared to the dt already implemented... however I forgot to add the dt modifier.

i'm just trying brainstorm an idea. If it helps get you on the right path the suggestion successful :)

hmmm

var constant dec = 0.2 // fiddle to speed

var constant pwr = 10

var speed = gamepad.x * pwr

if (speed < sprite.currentspeed)

{

sprite.currentspeed = lerp(sprite.currentspeed, speed, dec)

}

else if (speed > sprite.currentspeed)

{

sprite.currentspeed = speed

}

ummmm. will that work based on what your looking for; or at least maybe some inspiration to solve your problem. It's not fined tuned too work 100%. I'm just brainstorming.

There is a difference between an image of a Sprite and the Instance of Sprite. Your lumping the sprite as individual images even if they are the same image. That`s not the case.

* A sprite is world object that renders an image based on world position. The sprite usually only consists of a few values such as XY, frame.....

* An image is a memory allocation that holds the colours that creates the visual looks.

A sprite is location where the image is to be drawn to on the canvas. That way you can have many sprite information XYs, but not use up more memory. The sprite is not the image.

ImageMountain, size 200kb

Sprite1, x0,y0, image=ImageMountain.(size is 100bytes)

Sprite2, x0,y100, image=ImageMountain.(size is 100bytes)

Sprite3, x0,y200, image=ImageMountain.(size is 100bytes)

Sprite4, x0,y300, image=ImageMountain.(size is 100bytes)

Sprite5, x0,y400, image=ImageMountain.(size is 100bytes)

this is just rudimentary principle. There is only one singular image for each sprite. That image is the largest chunk of ram. Each sprite even though there are 5 of them all use a tiny fraction.

When the computer is then told to draw the sprites. The computer will draw the same image for the same sprite.

Sprite is not the image... sprite is the location and condition to draw the image :)

(note: the term sprite seems to shift depending on the tools being used)