Ashley's Forum Posts

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

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • EddyDingDongs - you can already do that using 'Request fullscreen' in the Browser object with the node-webkit export.

  • I'm pretty against this. It seems a backward justification: if your intent is to prevent degrading the user experience, then implementing a framerate cap will degrade the user experience on high-end devices that are perfectly capable of 60 FPS. Give it a couple of years and then everyone's got more powerful devices which are capable of 60 FPS, and you're unnecessarily degrading the experience for everybody. So I don't really buy that this improves the user experience.

    With delta-time variable framerates should still continue gameplay at a steady rate. Perhaps you could provide an in-game option to reduce the number of sprites/effects to a "lo-fi" version to help it run faster if the player doesn't like the variable framerate. Also I think most casual players are far less sensitive to framerate issues than we are - I remember a few years ago crappy software-rendered Flash games staggering along with a horrible framerate still going viral all over the web... and once I saw someone on a plane playing a Bejeweled clone at 4 FPS... completely rubbish, but they didn't seem to care!

  • I told Ludei to maintain the C2 CocoonJS plugin themselves. There shouldn't be any ambiguity here. They kept making breaking changes to their API, and when I asked, they couldn't even tell me what they'd changed. It didn't seem reasonable for me to try and maintain it under those circumstances - it was a nightmare for me, whereas they know their own API, presumably - and then they asked me to add more features... so I told them to do it themselves!

  • Construct 2 does not modify any of the CSS on the list box, only the position and optionally font-size. Are you sure you are using the correct CSS? This seems to be a browser issue and not a Construct 2 bug, so closing.

  • OK, should be fixed in next build, thanks.

  • It doesn't seam in Chrome, IE or Firefox here, either in preview or in export. Looks fine.

    However there's no point cutting it in to 512x512 tiles - you may as well have one big image. It's just up to the maximum widely supported texture size of 2048x2048.

  • It's not a glitch or bug, it's a normal result in computer graphics. Use a transparent background with transparent spaces between each character, or letterbox integer scale, and it should be fine.

  • Closing, please don't double-post.