Cross_'s Forum Posts

  • I would like to have the background layer scaled, so there is no letterboxing on different aspect ratios.

    However, the UI layer (which in my case consists of a progress bar and button at the bottom) should always be visible and stay anchored to the bottom of the browser window.

    Reading examples and tutorials I thought that adding an Anchor to the progress bar should suffice but unfortunately it does not. For portrait orientation the progress bar is anchored at the bottom and visible, but for landscape it disappears.

    https://www.dropbox.com/s/8s5ccrpd06txr ... .capx?dl=0

    Could anyone tell me which steps to take in the above Capx to achieve the desired outcome?

  • I was curious to see what it would take to port a classic game to C2.

    Game:

    https://dl.dropboxusercontent.com/u/57216006/index.html

    Capx:

    https://dl.dropboxusercontent.com/u/57216006/gberetBak.capx

  • "The WebGL renderer more or less already does that, but with fewer vertices since it can turn repeating areas in to a single quad."

    Right. But if I have repeating areas I might as well use a Tiled Background object. I would expect tilemaps to show variety instead of identical tiles next to each other. At that point the current implementation performs no better than rendering individual sprites, right ?

    "when editing the tilemap at runtime it now needs to involve the GPU - either a full or partial mesh rebuild and associated GPU upload."

    The same issue exists with your current implementation too I would assume. You need to recalculate the larger quads and upload those.

    "Also it means it has to switch between buffers"

    You mean switching between vertex buffers for sprites & tilemaps? Currently for every tile in a (non-trivial) tilemap you switch textures, which means OpenGL will do its notoriously slow texture state validation. That is worse than VB switching I'd think.

    "improvement does not carry over to the canvas2d renderer"

    True. I am mostly concerned about how construct2 runs on current mobile devices, and seeing warnings pop up for every single tile in the iPad OpenGL profiler is not a great sign.

  • Size of the final tilemap object does not matter. Size of the individual tiles in the tile sheet does matter. E.g. on iPad the tile sheet must not exceed 2048 or 4096 pixels.

  • There's no "feature request" forum so I will just leave this here..

    Looking at the blog post about C2 tilemaps I was wondering how the rendering of tilemaps is actually performed. Turns out that the implementation is not as optimized as it could be. If your tilemap looks like a checkerboard then each individual tile is rendered like an individual sprite. If there are rectangular regions of identical tiles those will get optimized and only be rendered as a larger block. Of course having large identical regions defeats the purpose of a tilemap and you could be using a tiled background object instead.

    Suggested change for the C2 developers: upload the entire tilemap texture sheet as a single texture instead of as individual tile textures. For the tilemap create a single mesh (tristrip with degenerate triangles, and duplicated vertices) and modify the UV coordinates so that the relevant subimage from the tilemap texture is addressed.

    In my retro gamer I have a 30x20 tilemap on screen. C2 currently creates around 300 individual draw calls for those tiles. With the above changes that number would go down to 1. Of course the GPU now has to do extra work but if your CPU utilization is reduced by two orders of magnitude that should be a worthwhile trade-off.

  • My bad. There was another event sheet and the project was set to using the "Default" layout at startup.

  • My game (which relies on tilemaps) runs fine on Chrome. It also runs fine when launched on iPad2's Safari. However, when I try to run it with Ejecta 1.5 all I see is a blue screen.

    I followed the ejecta tutorials: https://www.scirra.com/tutorials/926/ej ... ow-for-ios

    The ejecta app builds and looking at the XCode debugger I can see that the images are being loaded, and the canvas initialized. However all that appears on screen after the Ejecta splash screen is a blue canvas- nothing else. The debugging console shows no other error or warning- it just ends with canvas created.

    Has anyone encountered similar problems? Are there additional restrictions on canvas or tilemap sizes to get it to work ?

  • Nice.

    One thing to keep in mind: the duration of "Every tick" can change. You should not add 1 every tick, instead you need to multiply it with dt so the object moves smoothly on slow & fast computers: "Add 100*dt to Startangle"

  • What do you need it for ?

    Typically you would use System.Compare Variable with >0 or <0 instead.

  • Instead of saying "Don't jump when you are in the air" think of it as "Only jump when you are on the ground". So you could create an event with two conditions: Is overlapping (ground) & Keyboard (Jump) pressed. Only when both are true would you apply an impulse to make the player jump.

    Another option: when you jump off the ground set a variable to prevent the player from pressing the jump button again until the next time they collide with the ground.

  • Is the game running inside Ejecta or Webkit ?

    For ejecta you would have to first bridge Obj-C with Javascript: http://impactjs.com/ejecta/extending-ejecta

    Then you need a bridge from Javascript to C2 objects. One solution would be creating a custom plugin:

    https://www.scirra.com/manual/15/sdk

  • Is the game running inside Ejecta or Webkit ?

    For ejecta you would have to first bridge Obj-C with Javascript: http://impactjs.com/ejecta/extending-ejecta

    Then you need a bridge from Javascript to C2 objects. One solution would be creating a custom plugin:

    https://www.scirra.com/manual/15/sdk

  • Those are two excellent answers.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Construct's coordinate system is a bit unusual, but you are on the right track with sin/cos.

    You can use cos(angle) to get the horizontal offset and sin(angle) for the vertical offset. Put them together and you have an x,y coordinate for your sprite. Construct uses clockwise angles in degrees, so your A point is actually at 90 degrees and the B point at 180 degrees. If you set your sprite to cos(90),sin(90) it will be at the A point. Set it to cos(180), sin(180) and it will be at the B point. Note that sin/cos return values between +1 and -1. By multiplying the values you can make the circle larger or smaller: cos(90)*50, sin(90)*50 will be on a circle with radius of 50 pixels for example.

    To get some movement you need to animate between those two angles over time. I.e. calculate the position for angle=90..91..92..93 and so on until you reach 180. Construct has an anglelerp function to help you with that. You would stick that inside your equation like this and update your sprite position every tick: cos(anglelerp(STARTANGLE,ENDANGLE,CURRTIME))*RADIUS, sin(anglelerp(STARTANGLE,ENDANGLE,CURRTIME))*RADIUS

    The remaining task is to update the CURRTIME variable so it goes from 0 to 1 over the course of time. You can just declare a variable in the event sheet that starts out at 0 and then every tick increase it by "dt * SPEED". With SPEED=1 it would take 1 second to move from A to B. With SPEED=1/4 (that's 0.25) it would take 4 seconds to travel that distance.

  • Thank you, Zathan. I am looking at Magicam. My question though was more about using built-in functionality.

    siks I think this would run into the same bug/limitation that I am talking about. Let's say you want to have the camera 40 pixels in front of the player. If you add an event "every tick: camera.x = player.x" this will exhibit stutter for integer views.

    If the camera and player are linked via a Pin it works, however.

    EDITED: Never mind. I must have had a stray event somewhere. I recreated the event sheet and now it's behaving as expected.