TiAm's Forum Posts

  • Might be something else going on. Your device is way more powerful than mine, but I'd estimate I was getting around 30-40fps in space blaster myself.

    My guess is that it's your device resolution. 2560x1440 is a crazy number of pixels to push around, even on a desktop, much less a mobile. If you are using high quality scaling, you are wasting a ton of GPU rendering pixels you'd need a microscope to see. Try:

    Fullscreen in browser: Letterbox scaling

    Scaling Quality: Low Quality

    Game Resolution: Leave at 960x720. If you want it sharper, try 1280x960, but IMHO it would be a waste.

    Sick phone, BTW.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Am I the only one who finds Firefox unusable due to random, severe lagging/janking? I'm not talking about a little here and there, I'm talking about terrible stop/starting and dt varience, even with relatively simple projects.

    I see the input lag in Canary. At first I wasn't, even with my 'torture test', a bullet hell shooter with > 2000 objects onscreen and a couple webGL shaders. No lag, 60fps, on my lowly HD4000.

    However...my project resolution is low. Like, 800x600. Scaled it up by 2x, and lo and behold, there is the input lag. Plus, janking and jerking...things look terrible even at 40-50fps.

    Tried in IE11. Surprisingly...it still looked pretty bad below 60fps. However, there was no input lag. Scaling the window down, everything is smooth again.

  • Umm...yeah, something is certainly wrong.

    FYI, the text object is pretty demanding (I know that sounds bizarre, but it's true). If you are updating it every tick, use a spritefont instead. From the man himself (search for 'text'):

    https://www.scirra.com/manual/134/performance-tips

    What about trying a real game with an exporter? Have you tried a test export of space blaster? Throw an fps/cpu meter on it (remember, use a spritefont) and export it. You could also print out the renderer; if it says canvas2D, then something is amiss.

    For comparison, I have a much lower-end device -- LG Ultimate 2, Snap 205 1.2ghz, Adreno 305 -- and get very playable framerates in space blaster, even at it's most intense. My current project is using a couple webGL shaders and up to 50 onscreen objects, and hits 60fps consistently.

    Also, I'm not seeing a great deal of difference between CocoonJS and crosswalk, but that may just be my projects.

    Chrome could be causing a problem too...I haven't tested Chrome mobile extensively, but on desktop v38 had poor rendering performance that led to unstable framerates and 'janking'. This may have affected mobile as well.

  • Right, so google play apps are still fine.

    Just save the games progress into webstorage, clear it if the player dies, resume if the player quits and comes back. Which part of this is giving you trouble?

  • Shouldn't be, the limit is 500mb iirc.

  • So it can be run on the web? Nowadays, you have to have a premium account to do that with dropbox. There are alternatives though. I'm using altervista right now.

    https://en.altervista.org/

    You can export as an html5 project, zip the project, and use their archive uploader to upload the zip. It'll automatically unpack. Then you just link to the index.html file.

    Others have suggested alternative sites. One I've been meaning to look into is:

    itch.io

    They let you host your files for free, and link out to them. I haven't used them for that yet though. Just a really awesome site in general; a lot of thoughtful, offbeat indie content on there.

  • Honestly, the few games I've tried on my new phone haven't run much different w/ cocoonJS vs crosswalk. CocoonJS might be 10-20% faster at most, but a couple examples have run faster in crosswalk. That being said, the APK size does matter...right now, that's the biggest drawback with crosswalk, and one that is unlikely to change any time soon.

  • My remake of the arcade classic Death Race, from 1976. It's for a friend -- and fan -- of the game who was bummed to hear that a cabinet would cost a mint, and that it couldn't be emulated. He used to play it when he was a kid, back when it first came out.

    Incidentally, I'm loving shaders right now.

  • The easiest way to do this is to move the center point of the orbiting object outside of its bounding box, then set it's position to the object you want it to orbit. Pin the orbiter, and rotate it.

    The problem is if you want to change the orbit distance, you have to take a different approach.

  • Elliott

    Wow, was not expecting that. I've never seen a poly that complex. It looks like it's comparable to the 'many box' approach though, so I'd stick with it, given that it's less objects + easier to understand and tweak.

    Aurel

    I think you're under-estimating yourself there...

  • Aurel might have some insight. I doubt 'complex' polys would make much difference, as long as they were < 8 points. Having more objects (building with many boxes) would probably be a bigger hit on performance. But hey, I could be wrong...

  • Yes, it is.

  • When you test a condition in construct -- did foo collide with dragon? -- any actions you take within that event only affect the instances that fulfill that condition -- the dragon that was hit.

    However, when you call a function, the function itself doesn't know anything about the condition that led to it being called.

    Now, you can tell the function, but that requires passing it some data that allows it find the instance again. This is called the uid. You feed this to the function by passing it as a parameter, and you select the object by 'picking' it, using the condition pick by uid within the function.

    An easier way of going about this, in most cases, is to use families to test for collision events, allowing you to minimize redundant events, while still having multiple object types.

  • Or dropbox👇

  • Search for collision and overlap in your events. Check for behaviors you might have forgotten about (the most likely candidate).