PixelRebirth's Forum Posts

  • You mean you want your regular HTML5 game to be locked to landscape view on mobile devices? I don't think it's possible to force this in browsers.

    However there is a setting "Orientations" in the project properties. You can set it there, but it does also say "if this can be enforced". Best give it a try.

    What you can definitely do is check for the orientation with the browser object and display a warning message if it's in the wrong one.

  • You can use a single global variable (default value 1) which you store via webstorage. When the player completed a level, it will unlock the next one. Meaning that 1 will be added to the variable.

    Now in the level selection screen, you only allow to go to levels which are lower or equal to that variable's value. How this is actually achieved depends on the style of your level selection. If you had clickable tiles representing a level you could add an instance variable called "level" which would represent the level number obviously. Now you could compare this easily to the unlock variable.

    Remember to store the variable in local storage with the webstorage object to keep the progress saved.

  • Give your levers and doors an instance variable called "id".

    Match the variables for the levers and doors that are connected, meaning a lever with the id 4 will open any door with a matching id.

    Of course in order to achieve this you need to add a condition checking for the door id to be equal to the lever id.

  • How bout just using overlap at offset, and getting rid of the array?

    Your suggestion is valid, but my issue was not with finding a different approach, of which there are certainly many. I was just not getting why this exact approach didn't work the way I believed it should.

    But yeah, for anyone looking to do something bomberman-like there is certainly no need for an array.

  • Now that I'm wide awake and not on my phone I did some tests. I'm pretty sure you'd have to use round() in CC as well. And as far as being just integer values cos(270) is not exactly 0 in either C2 or CC.

    If you set some text to cos(270) you'll get 0, but that's because C2 does some rounding to give you prettier numbers for display. If you set the text to str(cos(270)) you'll bypass the pretty rounding and get -1.8369701987210297e-16.

    In the meantime I did actually recreate the same example with CC and ran into the exact same issue, haha. So I guess I should just shut up and accept my defeat at math. And use round <img src="smileys/smiley36.gif" border="0" align="middle" />

  • Sin, and cos will have some issues when it comes to rounding angles, plus the only time you might want to use it is when those rounding issues would pop up ie diagonals. Catch 22 I guess.

    Right, but this is calculating the following three things for the north direction:

    cos(3*90)*1

    cos(3*90)*2

    cos(3*90)*3

    And all of these should equal 0. Yet I have to put round in front of it for some reason. Is this really something to be expected? I don't recall having had such an issue at any point in my ~5 years with C2 and Classic before that. And cos and sin were being used frequently.

    Also I'd highly suggest snapping your mouse xy with int(mouse.x/cell)*cell +cell/2 for tile games.

    That may be so, but I don't see the relevance here.

  • after quite some testing, I found the problem. Seems to be some sort of computational error

    use

    Function.Param(0)+round(cos(loopindex("boomSides")*90))*loopindex("boomRange")

    and

    Function.Param(1)+round(sin(loopindex("boomSides")*90))*loopindex("boomRange")

    when comparing the value in the array

    Thank you very much for taking a look and nailing the error!

    A computational error indeed, I don't actually think this should need the round expression at all. I mean we aren't even dealing with floats here, all the variables used in the event have simple integer values.

    I found that you only need to apply the round for the X value in the condition, the second one isn't actually needed. I guess this makes some sense since the error only occurs on the left side, meaning at a certain range of X coordinates.

    The X calculation for the 270? angle needs to be always 0 though, which even my calculator agrees on. Yet Construct somehow needs round to make it work?!?

    So yeah, this leads me to believe this might be an actual bug in Construct 2. It could be an accuracy issue with the math expression cos or simply a general issue with that array condition and using math in it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Okay, I wanted to quickly create a little example of a bomb mechanic that works similar to Bomberman.

    I'm doing it using an array storing the obstacles that block the blast (value of 1)and a function that uses a nested loop which creates the blast in the four directions around it(using cos and sin) and only continues the line of explosion if there isn't an obstacle.

    I thought of this implementation as rather elegant. <img src="smileys/smiley9.gif" border="0" align="middle">

    Unfortunately it isn't quite working. In the example you click to create an explosion at that cell position. Now the blast that goes out north (270�) doesn't actually get blocked by obstacles when creating explosions on the left side of the screen. Or it gets blocked where there are no obstacles at all. On the right side it however works fine and all other blast directions also work according to plan (everywhere).

    The values in the array also look fine judging from the debugger view.

    This should be simple, but instead it's driving me mad. I've looked over it a million times and can't figure out why it's behaving so strangely.

    <img src="smileys/smiley19.gif" border="0" align="middle">

    Oh yeah, here is the capx: https://dl.dropboxusercontent.com/u/2306601/bomb_1c.capx

    Maybe it just needs a fresh set of eyes.

  • Seems like Clickteam dropped the tired term "multimedia" and added .5 to the version number, but this still looks exactly like old MMF2:

    http://store.steampowered.com/app/248170

    That event editor still gives me a headache. The only thing it got going for it are the exporters I guess. I also wonder how their HTML5 exported stuff compares to Construct 2, anyone with experience there?

  • Let's say your game got a native width of 640 and height of 480 pixels.

    Now make an event that sets the layout scale to Browser.ExecJS("window.innerWidth")/640. In a subevent you should check if LayoutScale*480 is greater than Browser.ExecJS("window.innerHeight") and set the scale to Browser.ExecJS("window.innerHeight")/480 instead.

    This measure prevents parts of the layout from being cut off because there isn't enough vertical space available.

    Now you need to set the canvas size to 640*LayoutScale in width and 480*LayoutScale in height.

    The result should be basically the same as if you had letterbox fullscreen enabled. In preview it will add the border for non fullscreen projects that will mess it up a little.

    Of course now you can make an event that sets it to half that size easily or control it in any other way. This can also be useful if you licensed a game and you are asked to add dynamic resizing to your game as part of the API implementation.

  • If you want to resize your canvas at runtime it's better (in my experience of course)to not use any fullscreen mode, but turn it off and use your own events instead.

    Use some simple math to find the layout scale (window.innerWidth / native width and then check if the height still fits with that scale, if not base it on the height), set it, and then also set the canvas size accordingly right after that.

    Since Browser.ScreenWidth/Height returns the user's desktop resolution, I use Browser.ExecJS("window.innerWidth") and "window.innerHeight" instead, which gives the correct results.

  • Try to lower the deceleration of the platform behavior when the player is being hit and possibly also disable player input for the duration of the "fallback".

  • The browser object has the actions "Go to URL" and "Open URL in new window".

  • Why don't you simply push the UIDs of the objects you want to group to an array? You could then iterate through them and call the necessary actions.

  • Revisiting this thread again, because I seem to have fixed my issues with the Chrome Web Store.

    What worked for me: remove the div element in which the canvas is enclosed in the index.html file. I know it says "The canvas must be inside a div called c2canvasdiv" in the file, but that doesn't appear to hold ground.

    Then change the canvas tag to look like the following:

    <canvas id="c2canvas" style="display: block; margin: 0px auto;">

    Projects that are exported with fullscreen off have some unnecessary space at the bottom of the canvas. This change gets rid of it.

    It also makes the canvas always be centered even if you resize it at runtime btw.

    I didn't test these changes exhaustively, but it does indeed work for my project. But do this at your own risk of course, keep backups.

    Another chrome web store related hint: if you make use of a plugin like Clay.io, which will communicate with an external server, you need to add an additional line to your manifest.

    "content_security_policy":"script-src 'self' 'unsafe-eval' clay.io https://clay.io:846; object-src 'self'",

    Of course the specified URLs are for the Clay.io plugin. Switch them with the ones you need.