Ashley's Forum Posts

  • It sounds exactly like a graphics card driver bug, which is more likely to occur when updating the OS.

  • Aren't you worried about people with expensive, high-end phones getting an unnecessarily degraded experience?

  • Can't reproduce on Windows 8 with Chrome. Check your graphics card drivers are up to date.

  • It's not currently supported but is on the todo list. The only workaround is to either play lots of sounds with one tag, or add the effect to multiple tags (but be aware if you add the effect to N tags it will use N times as much CPU time to process).

  • Have you tried using a folder-based project and directly pasting over the animation frame image files? If you have Construct 2 closed when you do this, then re-open the project in C2 after replacing the files, all the objects should still be in the same position/angle.

  • Just thinking I could experiment with a non-adaptive half-vsync rate mode that's only supported with high-resolution timers in the next beta. Perhaps it could be split in to off / mobile only / all devices, so you can leave it uncapped on desktop... but IMO it'd still be annoying to have a really powerful phone like the Nexus 5 (which can outperform some of the desktop machines in our office!) and have the game capped at 30 FPS to ensure a better experience on weaker devices... if I had a phone like that I'd want it to be on 60 FPS!

  • Why not just minimise it so it's gone completely?

  • I didn't say we would never support it. IMO It's a trickier subject than most people are giving it credit for.

    Issues with dt at low framerates are a different problem. If the framerate is low enough to cause problems with gameplay, usually it is much lower than 30 FPS, so a framerate cap does not fix that. It's a separate problem.

    Adjusting the framerate cap at runtime is a pretty difficult problem and hard to get reliably right. You'd want to figure that out on startup, but Javascript optimisation and garbage collection tends to make things a bit choppy on startup, so any measurements would be unreliable. Even so later on there might just be a single momentary blip below 60 FPS, and you probably don't want that to trip it down to 30 FPS. So then you have to draw a line somewhere, and wherever you draw the line, sometimes you'll choose 60 FPS when it should have been 30 and 30 FPS when it would have been better to choose 60. I'm not at all confident the engine would be able to choose correctly most of the time.

    Other game creation tools might provide a framerate setting, but I don't think that makes it a good idea!

    A screen with a refresh rate like 72 Hz doesn't play the game at 60 FPS - it plays it at 72 FPS (if the system is fast enough). A framerate independent game adapts to this seamlessly, ensuring best quality display. To be more correct, instead of talking about 60 FPS and 30 FPS we should say "vsync rate" and "half vsync rate". The engine could support a "half vsync rate" mode, but then you can't easily tell the display refresh rate in Javascript, so you have to go off some adaptive system again, which is unreliable and might pick wrong, and then you have a choppy framerate again. Also that kind of thing needs reliable high-precision timers, which aren't available everywhere.

    Consoles are a different case: the hardware is known in detail in advance, so you may be able to say confidently that a game you have absolutely cannot run at vsync rate. However C2 games run everywhere from powerful desktops to weak phones. IMO a game running at half-vsync on a powerful desktop PC is both annoying and an inferior experience to a vsync-rate game. I didn't spend all that money on a ridiculous graphics card for 30 FPS :)

    In short my opinion is that if a system can run a game at vsync rate, we should let it. Since there's probably not a really reliable way to detect the need for half-vsync rate and then accurately hit that, the best way to try and let it is to leave the framerate uncapped.

  • The spritesheet you pasted earlier has a black background and the characters go right up to the edge of the cell.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Another problem is not all devices use a 60 Hz display. It's common, but it's by no means required. 30 FPS will have an uneven framerate if it doesn't divide nicely in to the refresh rate of a different frequency display, e.g. on a 75 Hz monitor.

  • Perhaps, but the biggest drain on battery on modern devices is the screen. If the screen is on the same amount of time, then whether the game ran at 30 FPS or 60 FPS probably won't make a bigger difference than the fact the screen was still on that whole time. Meanwhile you want your game to look good on high-end devices compared to other games, right?

  • Can you provide any error messages that were in the browser error console or link us to the uploaded game that is not working? Most of the time, a black screen after export is either due to server misconfiguration, or you just forgot to upload all the files.

    Also, the .capx file is corrupt - it's missing a bunch of project files. That might explain it.

  • It was scaled down, and I still didn't see any seams.

    Seams can be tricky to avoid especially with floating point position/scale. You might use more memory but making a single texture will definitely not seam. Phones ship with 2 GB of memory these days, and a single 2048x2048 image will take up about 16mb of memory. As long as you don't have lots of them and aren't targetting really low-end devices, that's OK. If you still want to cut it up, square tiles isn't the best way to do it - a smarter way would be to cut out each item on the image (e.g. text, each building image, etc.). The background is a low-contrast gradient, which you can reproduce with linear sampling and scaling up a small sprite. That would probably use even less memory than the square tiles approach, it wouldn't seam, and you can then re-use the individual pieces of art throughout the project.

  • You should post a .capx so we can see ourselves. It ought to work just fine with the settings you have shown.

  • Families should be a good workaround for this. There are two reasons why there isn't a generic system action for picking by UID which does not specify an object type:

    1) suppose it exists, and you use the condition. Which object do you put the action under? You don't actually have a way to use the object you just picked.

    2) there are some pretty complicated optimisations in the event engine to ensure picking happens fast when it comes to subevents. One of the things it needs to know in order to optimise this well is which objects might have their picked objects changed. A condition which could pick from *any* object type therefore means no optimisation can happen. Due to how the engine works, running that event would take O(n) time, where n is the number of object types in the project. So the bigger your project gets, the slower that condition would get. It is more important to make bigger projects fast than smaller ones, so that's not acceptable.