R0J0hound's Recent Forum Activity

  • Decimal numbers are seldom perfectly precise on computers. For example 0.2 can’t be precisely represented in floating point numbers so it will be a bit off which adds up with calculations. It’s not really that far off actually if you look at it.

    Anyways this is seldom an issue unless you’re displaying the numbers, because by default too many decimal places are displayed.

    A solution is to round the number before displaying it.

    Set var to round(var*10)/10

    Or maybe after every time you do a calculation, or before you want to compare a number to be an exact decimal number.

  • Clamp limits the range of a number.

    It’s clamp(number, low, high)

    So if the number is lower than low, it will use low.

    And if the number is higher than high, it will use high.

    Otherwise the number will be used as is.

  • 1. Calculate the average x,y of all the player positions.

    2. Set your camera position using the average position as the second parameter of the lerp.

    Then to limit the player positions to the screen you could clamp the player positions.

    So maybe something like this.

    Global number camx=320

    Global number camy=240

    Every tick

    — set camx to lerp(camx, (player1.x + player2.x)/2, 0.03)

    — set camy to lerp(camy, (player1.y + player2.y)/2, 0.03)

    —scroll to (camx, camy)

    — player1: set x to clamp(self.x, camx-320, camx+320)

    — player1: set y to clamp(self.y, camy-240, camy+240)

    — ...do the same for player2

    Notes:

    320, 240 are half the viewport size 640,480. Change as needed.

    The above does the average of two players. For three it would look like this:

    (Player1.x+player2.x+player3.x)/3

  • Not really worth the effort.

    If it’s for free and you think it would be fun to try then that’s one thing. Construct features/limits are heavily dependent on browser apis and JavaScript features.

    Feature parity would be a tall order.

    If it’s something to sell you could just do paid porting, and implement features as needed on a game by game basis. That’s what the next Penelope did, and chowden is basically just a porting service as well.

  • It only accepts a paticular Json form for it to load.

    You can see the format by setting a text box to array.asJSON.

    If you need to read any json value the use one of the plugins made for json or use some js from the browser object

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • There have been a few before. I think they help automate create the ace’s.

    It’s not really useful though. It’s simple to add more of those. The bulk of a plugin is interacting with some JavaScript library or the guts of construct’s runtime.

    I haven’t touched the c3 plugin sdk though. I know that it’s a bit more repetitive, maybe a tool could be made to help with that.

    I wouldn’t use construct to make such a tool though.

  • how about use touch.x instead of touch.absoluteX. The later is typically not what you want to use. I've almost never wanted to use it.

  • Web browsers only see one mouse. That alone makes it not doable.

    On mobile there is no mice, but you can have multiple touch. It can’t tell one finger from another so typically you’d have one player on one half of the screen and the 2nd on the other.

    Outside of the browser there are ways to get each mouse input independently. Typically you’d hide the operating system cursor and draw your own.

    Apparently you can add more features to nwjs exports to make it possible for windows exports. But I think it would be more worthwhile and easier to just remake your game from scratch in something else.

    So shorter answer, not possible in html5/JavaScript and in turn not possible in construct.

  • Here's a capx:

    dropbox.com/s/8q7n27kfdc5n431/ball_3Dish.capx

    I did it slightly different than my description and I got carried away with some tangents, but it hopefully will give some ideas.

    Edit:

    What happened? I made a post, then posted again and it ate my previous post. This forum... oh well, it probably needs more bug testing.

    Anyways to answer your question sin and cos will work with any angle whatsoever.

  • Hello,

    1. You can use any angle with sin and cos and it will work.

    2. You can make the ball slow by setting the vx and vy to self.vx*0.5 and self.vy*0.5 in the bounce event.

    I’ll post a capx shortly. Ended up eating dinner so that delayed me.

  • Two ideas come to mind.

    One is to think back to grade school and just use two numbers, the numerator and denominator, for each number. Then you’d never actually do a divide, just multiply the denominator.

    You’ll probably need to simplify the fractions, before displaying them. But algorithms for that are easily found. It’s GCD (greatest common denominator) as I recall.

    The other idea is to find an algorithm to find the closest matching fraction to a decimal number. I used one before.

    Google is your friend here. Both ideas would be the same in most programming languages.

  • You can covert an x, y to an index and back again. Since your goal seems to be sending only one number.

    Index = x + 10*y

    X = index%10

    Y = int(index/10)

    Where 10 is the number of horizontal tiles. Change as needed.

    You could also alternatively send multiple values in some text with commas in between, and use tokenat to separate them later.