Ashley's Forum Posts

  • You definitely can't guarantee seamless rendering with "letterbox fullscreen". Since it can use any scale, even floating point scales like 1.317, you can't guarantee that layout pixels will line up perfectly with screen pixels. Enabling letterbox integer scale preserves this guarantee, by ensuring the zoom level is an integer.

    There are tricks you can employ to get seamless rendering with letterbox scale. Things like ensuring all your tiles overlap each other by 1 pixel generally ensures seams are covered up (a seam is usually the background showing through at a low opacity), or just choosing a background color close to the tile colors can help. Sometimes there are even graphics card driver bugs that can cause seams, so updating your drivers might help.

    However the easiest way to guarantee seamless rendering is to use those settings.

    Tokinsom - I've not heard of any bug like that. Has it been reported?

  • I'd suggest contacting Ludei about the issue.

  • Closing, please provide a minimal .capx reproducing the problem. A 100mb file of a built game is not really useful at all for the purposes of investigating a bug.

    Note lots of people report bugs with rendering seams which are a consequence of their own project settings. To guarantee seamless rendering, you must use pixel rounding, point sampling and letterbox integer fullscreen (or no fullscreen mode). Otherwise you are choosing settings that may cause seams, which is not a bug. When seams occur can vary from platform to platform, even between Chrome and node-webkit (which is based on Chromium), because the details of the rendering system are different.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Physics won't work in CocoonJS until Ludei release the next launcher update.

  • Closing, I'm afraid we can't do anything about this unless you provide the steps to follow to make this happen in the first place. Since the files are already missing, we don't know how they went missing, so we don't know how to fix it.

  • Is this relating to Chrome for Android? It's useful to always use the full bug report template so you include details like this up-front. We have a bug fix for touch events not working correctly in Chrome for Android in the next build, so I think this might be fixed already.

  • maesbn - it's a property on the Touch object.

  • You need "" inside a string to indicate a single ". I wouldn't bother doing it that way, just import project files and AJAX request them, and then you never need to bother with these horribly messy expressions.

  • Node-Webkit is as good as the Chrome browser (it's almost the same thing), which is great because Chrome has generally been the best and fastest browser for HTML5 games. (Firefox has done well to catch up lately though!) Our HTML5 renderer in Chrome is on par with CC's DirectX9 native engine performance-wise.

    The node-webkit plugin should allow all the file access you need. The Dictionary object is the new name for hash table. Don't use INI, it's an ancient format from Windows 3.1; the Dictionary object is a better choice anyway.

    WebGL shaders are probably as good as or better than DX9 PS2 shaders. DX9 PS2 level was specified in 2004; the WebGL spec was started in 2011. They also work on mobile and Mac and Linux desktop.

    We recently added line-of-sight, and I don't know if you've checked out C2's Audio object lately, but it includes positioned sounds and advanced audio effects which should make it on par with XAudio2 - but again, cross platform.

    Performance shouldn't be a problem, except for desktop systems with out of date graphics card drivers (which can sometimes fall back to software rendering). Usually a driver update resolves any problems.

    I would seriously strongly recommend you go with C2 instead. I do think its desktop exporting via node-webkit is comparable to Classic's, with the added bonus it runs on Mac and Linux, in browsers, on mobile...

  • 1. It's a one time payment.

    2. You always need an Apple Developer Account to publish to iOS. We've written a guide on how to sign up here: https://www.scirra.com/tutorials/72/how-to-become-an-ios-developer

  • Write your text in some text files, then import them as .txt files to the project. See Using project files in Construct 2

  • Regex features are on the todo list.

  • Did you encode .m4a versions of all your sounds?

  • Every single expression in Construct 2 should have at least a brief description in the manual. There are definitely should not be hundreds which are missing. Could you list any you find that are missing so we can review them?

    The Audio object is probably a little different in that it assumes some knowledge of digital audio. It's not really the manual's place to teach you how FFTs work, what frequency bins are, what the trade-off between FFT size and frequency resolution is, etc. It's a big and complex subject and there are many places to learn about that, so the manual entry simply skips it. You're right that those specific expressions were a little too brief, so I've edited the manual entry to try and make it clearer. Again if you find any other parts of the documentation you think ought to be clearer, let us know and we can try to improve it.

    With the Audio object, you play sounds with a tag, e.g. "gunfire" or "music". You can add effects to a tag, so the effect only changes the sounds with that tag. You can add multiple effects to a tag, so each tag has a list of effects. And then the analyser returns a frequency domain analysis of the audio, which is a list of "frequency bins" (a standard audio term) with values representing the magnitude of energy over that frequency range. Therefore the "Tag" is the tag of the audio you added the analyser to, the "Index" is the index of the effect in the list, and "Bin" is the number of the frequency bin to retrieve from.

  • The problem is that the platform behavior is not designed to be teleported in to solids. I think this is a pretty reasonable limitation. I could change the details of how the platform behavior teleports itself to a free space when it's teleported inside a solid, but I don't believe this would fix it - it would just change the circumstances of when it teleports badly, especially when dealing with slopes, moving platforms, etc. So then it's still a bad idea to rely on it, except it's even more insidious, because at first it will look like it works but actually it will just bite you further down the line when you're even more invested in your game and it's even harder to change.

    Basically if the platform behavior suddenly finds itself wedged inside a solid, it has to guess where to move itself out to. It could guess smarter, but it will never get it right every time. So I think it's better to leave it obviously guessing wrong, so people never rely on it guessing correctly.

    I don't see any reason you can't just use a fixed collision object and change the animation on top of that. That looks exactly like what California's example is doing. And it will always work.