Halfgeek's Forum Posts

  • For mobiles?

    It should run fine, you just have to optimize and test during development.

  • > I think that only occurs in the context of C2, on iOS8+ WKVWebview, right?

    >

    I'm pretty sure all modern web browsers do jit. Chrone, Firefox and Safari each are continually making js faster, and jit is always utilized in some way.

    Okay, but Apple's implementation is so much faster. It's worlds apart to compare WKVWebview Safari vs Android Chrome for example.

  • > If we had control over loading into vram, we can specify which sprites to load on start of layout or between transitions, and when they are called, there's no stutter.

    >

    Placing an object in the layout view is how you tell the engine to load it in to VRAM on startup. If you don't need it on startup, just destroy it on start of layout - it still gets its textures loaded and can be created without stutter. So I think you already have the control you need?

    Yes, it's what I've learnt to do for some assets which can be loaded and set invisible or destroyed on startup. But others cannot as its tied to game logic and AI. I notice those micro-stutter, the first time weapons fire or explosions go off awhile ago and hack it on start of layout to avoid it. Ultimately I'm sure its possible to add all the sprites one needs on the layout (off the margins so they aren't view-able) and destroy those instances on start-up (or add destroy on outside layout behavior)...

    But more explicit control would be very useful. Just an event to "Load Sprite X into memory" would be much more easier to use avoiding all the workarounds.

  • No you can't, but you can limit logic to update at 30 fps intervals, or every 0.032 seconds instead of the default every tic which is 0.016 seconds.

    Just place all your game logic under a Every X seconds lead. Less frequent logic updates = less CPU usage for mobiles, which matter a lot.

  • You want random spawn?

    Can do it easily with a global variable, call it EntryPoint = 0

    The default is 0.

    Then on your layout, you have a check at Start of Layout.

    EntryPoint = 0 => Spawn somewhere

    EntryPoint = 1 => Spawn somewhere

    and repeat for as many spawn points as you need.

    So when you move to return to a prior layout, set the EntryPoint what you need. If you want it to be random, then set it to int(random(0,10)) or however many points you have.

  • Try the setting down-sampling set to low. The blurry images are due to texture mip-maps. Odd I know but setting to low gives the best results.

  • megatronx

    Hehe, you live and you learn, that's how it goes!

    I keep trying and testing to get features to work exactly as I want, even if its unorthodox or "hackish".. I only care about the end result.

  • Also, there is plenty of other weird quirks. Right now I have object that uses rotate plugin, and it is suppose to shoot every x seconds and when is in between angles. It does shoot, however the projectile with bullet behavior only moves at 180 degrees instead, even thought of having the angle of motion set to spawning objects angle. What to do? Sorry to say, but this is irrational.

    Use set angle on your projectile rather than set angle of motion. There's a few things like that which once you figure it out, it's understandable why.

    Let me take a screen from my own example, I hope it makes sense:

    https://halfgeekstudios.files.wordpress ... /09/00.jpg

    It's a shotgun, 8 round blast in a cone from the gun.

  • > JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine

    >

    Most modern Javascript engines use just-in-time (JIT) compilation to machine code. They use a flow something like script -> bytecode -> profiling -> machine code generation. This means well-written Javascript gets "truly" compiled and can reach pretty impressive levels of performance.

    I think that only occurs in the context of C2, on iOS8+ WKVWebview, right?

    Nitro-JIT engine.

    I notice it performs very close to Chrome on PC, ie, similar cpu usage for my test games, which is rather insane when you think about how powerful an Intel i5 or i7 is compared to what's on an iPad Mini 2.

  • Why do you think its higher quality if you add a bigger image but then downscale it in-game?

    An sprite of 128 x 128 looks good with an image that's 128 x 128, as good as an image that's 256 x 256. It may even look better due to down-sampling losing some details (blurry).

  • > I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

    >

    The engine already does this automatically on a layout-by-layout basis. The problem with adding more control over this is you create the opportunity for mistakes in memory handling to actually make things worse and use even more memory, or you rely too much on mid-gameplay texture loading which can cause serious jank, which is something everyone wants to avoid.

    [quote:3rdo5u6u]The biggest limitation I see currently is single-thread logic.

    See Why do events only run on one core? The blog post goes on to detail many features which modern browsers (and our own engine) run multithreaded.

    I know the engine already does this per layout, but the option to do it manually for a sprite that we want when we want it is what allows more flexibility. Sure, people can mess up if they don't know how to use it, but that's a poor excuse to not have that level of control at all.

    I'll give you a basic example of the jank that people notice in C2 games. When a layout is changed, everything prior is flushed to gc, a new layout is started, sprites are spawned etc, but they are spawned fresh when called in the first time in that layout, so creating a big sprite or one with many frames cause a visible stutter. Why? Because it has to be loaded from HDD and as its not present in vram.

    If we had control over loading into vram, we can specify which sprites to load on start of layout or between transitions, and when they are called, there's no stutter.

    Multi-thread is difficult to get it to work well, big engines have it and little engines don't.

    It's up to you guys for C3 if you want to be part of the big boys or not, its bluntly put but that's reality, I see it all the time when devs talk about game engines and compare them on forums and reddit. I regularly defend C2 on r/gamedev! Single-threaded on JS which incurs extra overhead is a limiting factor. Most C2 users wont ever hit that ceiling but it's lower than other engines and much lower than big engines that support multi-core CPUs well. So it's a question of how grand do you want your engine to be capable of?

  • You can do the bar to any variable, global or instance.

    If instance, you have 2 instance variables for your player sprite.

    1. Health

    2. HealthMax

    Set the bar width to ((Player.Health / Player.HealthMax) * 100)

  • If you use C2 for mobiles, its vital to start testing performance on mobiles from the start. Use the cpuutilisation to check on your target device, this way you know when you add some new features and it drops performance (cpu usage jumps up), you know that's to be avoided.

    Some behavior or effects hurt performance a lot on mobiles. I posted awhile ago with a short list of things to avoid.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The logic and collision still functions for invisible objects.

    It's how I often do AoE explosion damage, by spawning an invisible sprite to test for collision.

  • For mobiles or PC?

    If for PC you don't need to worry about those things in general until you have a very massive game. Ashley is keen to tell people not to waste time optimizing, its true for most cases.

    For mobiles, always test it and see which runs faster. Debug, profile view, look at CPU usage and compare for yourself.