Ashley's Forum Posts

  • Construct automatically takes in to account the device pixel ratio (which I presume that setting is changing). So it should work. It's hard to say more without more information.

  • I realised the runtime can actually calculate this for you, so I've added a read-only Z scale property to 3D camera, and a new ZScale expression on 3D camera, for the next beta.

  • There's rarely any need to use base64 these days, and it's more efficient if you don't use base64. You can instead use 'Save image' in Canvas, use AJAX to fetch the image directly in to Binary Data, and then use Local Storage to save the Binary Data to storage. Then you can later load the Binary Data from storage again, load an image from the Binary Data URL, and paste that in to the canvas. This keeps everything binary and never converts to base64.

  • I don't speak Spanish but Google Translate says "capas" is "layers" in English. So I think that message is in fact telling you that the free edition layers limit is exceeded, not the events limit.

  • So when we first added Z elevation the Z axis was originally normalised such that at 100% zoom the camera is at a Z position of 100, looking down at the Z=0 plane (i.e. 100 units away). This kind of made sense for Z elevation to make it simple to use no matter the view size. However with the added 3D features I think it's actually become a bit of a complication. We might need to add a setting that lets you change this to something that uses equal units on all axes for 3D.

    To work out the math you just need to think about the camera on a side-view, and use trigonometry:

    If you split the view in half, notice the top triangle has an angle of fov / 2, and the opposite side of the triangle has length viewH / 2. Currently Construct calculates z to be 100 and scales the view to fit that, using a fixed FOV of 45 degrees. But instead you can calculate what z ought to be given the angle and opposite length. With trigonometry we know tan(a) = opposite / adjacent, which in this case is tan(fov/2) = (viewH / 2) / z. Rearranging to solve for z, we get z = (viewH / 2) / tan(fov/2). If I open the 3D shape example and use the view height there of 480, this gives z = 240 / tan(22.5) = 579.4 (approx). Since we know Construct calculated z to be 100, this gives a Z scale factor of ~5.8 to match Z units to X/Y pixels. So one of the 3D boxes is 100x100; to make it a cube its Z height should be 100 / 5.8 = 17.2 (approx).

    So if I set the cube to a Z height of 17.2 and set up a 3D camera looking at it, bingo, it looks like a cube with the same size on every axis:

    The default of 14 was just a guess from eyeballing it, but is a bit too short. Your guess of about 5:1 was close, it's 5.8 in this case, but as you can see it depends on the viewport height of the project.

    With a new camera setting to match all the axes, you'd be able to just set the 3D shape to 100x100 with a Z height of 100, and it'd look cube. Although I'd add the details of these calculations may change in future, such as if we add a configurable FOV.

  • You need to make sure at least one layer is set to use 3D mode, and you must also initialise the camera with 'Look at position', otherwise the camera is not initialised and so cannot be rendered. (For example, unless you provide an up vector, the engine doesn't know which way you want to be up.)

  • No, I meant with us. We can probably work around it if something's changed. As ever filing issues is the way to report problems, things only mentioned on the forum are easily lost or forgotten.

  • Maybe something changed in a Chrome update. If you can reliably reproduce it please file an issue.

  • You can only set a light radius when the light height is 0.

  • Can't you just put the JS code from the other thread in a script in Construct? That post is from the old C2 forum, but C3's JavaScript coding feature is ideal for snippets like that.

  • I just tried it in Chrome in the latest stable and beta and it seems to be working fine.

    Do you have any browser extensions installed? They can interfere in various ways.

  • If there's a problem with iOS itself, you'll need to report it to Apple.

  • The project filename is already displayed in the Project Bar if you open two projects with the same name. So I'm not sure where any ambiguity would come from. Either you have one project open and presumably you know which you opened; or you have two projects open with different names so you can tell them apart; or you have two projects open with the same names but then Construct adds the filenames in the project bar so you can tell them apart.

    It makes sense to show the filename in the editor in a few more places anyway just to make things clearer, so I've added it to the tab tooltips and also as a tooltip to the project name in the project bar.

    As for the project name vs. filename, the project name is used in all sorts of places for things like the app name or the document title for web exports. Quite apart from the problem of "what's the filename of a project you haven't saved yet?", I'm sure not everyone will want that to match the filename - for example whether you use "My game (variant 1).c3p" or "My game v1.5.c3p", you may well want the app name/document title to just be "My game", i.e. different to the filename. If we made it use the filename, I can imagine someone writing an equally impassioned plea that we add a separate project name so they can control it separately to the filename. Not everyone uses software the same way, and we have to design Construct to work for a wide range of customers and usage styles. It's probably easy to critique software design and say it should work exactly how you want it, but it's not always the case that all the thousands of people who use Construct all want that as well. As with most things, there are subtleties and trade-offs to consider.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • We'd need browser APIs to access any device-specific features. As pointed out hopefully all the existing APIs such as Gamepad cover it. If not then it's probably not much use us talking to Valve, they'd need to talk to browser vendors.

  • Yeah, that's what Remote Preview for NW.js is for.