Ashley's Forum Posts

  • I'm aware of the several flaws in Construct at the moment, but our best shot to correct those problems are in Construct 2.

  • Davo, how come the runtime csx has increased to 450kb just for that change?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You should be aware if you're only using a well-known one-way hash algorithm anyone sufficiently determined will still be able to crack it (curious people like me open cabs, dlls, sys files etc with suspiciously small file sizes). If you really want a good solution, use something like blowfish encryption.

  • The channel is released when it finishes so other sounds can play on it - if it didn't need reloading and kept the same sound in, eventually an autoplay might overwrite the channel, then you're playing a different sound unintentionally. Depending on the cache settings it also gives the opportunity to free the memory straight away. Loading is basically free with the cache enabled though, so it shouldn't be a big deal (and autoplay is designed to take care of the loading for you anyway).

  • Time scale affects animation speed too, so the animations slow down if the time scale slows down.

  • Post a .cap to show what you mean, it usually helps. Hazarding a wild guess from your post, I'd try enabling Unbounded Scrolling in the layout.

  • It means your game had no data attached to it for some reason, it shouldn't happen! If it happens every time, submit a bug with the .cap.

  • You might be interested in positioned sounds in XAudio2, instead of 3D sounds (would that make sense in a 2D world?)

  • This has been requested a lot but is difficult in Construct 1, I'll try and put it in Construct 2!

    In the mean time you can work around it by speeding up your player by dividing by the timescale (eg. speed = normal speed / timescale).

  • What exactly are the events? The actions to move objects with the RTS behavior runs a potentially CPU intensive search. They are only designed to be called in triggers or one-off events - if you are calling them every tick unecessarily, you will waste CPU for no extra pathfinding benefit.

  • I don't think users are interested in doing the debugging, it requires a high level of technical expertese. Those who are interested can always download the source code and build debug builds themselves, using the full Visual Studio debugger, which is very good.

  • Crash dumps don't provide information on why the program went wrong, it's just a big dump of the state of the memory and system when the problem happened. It's probably useful to ******** assembly programmers who deal with the machine-level instructions, but Construct is written in much higher level C++, so finding anything useful in a thousand pages of binary that actually related to the problem at all is definitely finding the needle in the haystack.

    Fixing problems is 1000x easier if the developer can reproduce the problem and debug the entire execution of the program, to watch the steps that happen and lead up to causing the problem. A dump of the system state doesn't really help with that.

  • It's expected behavior: every time you visit a layout, it is created in its original state in the layout editor. This is so that if you blow up some walls or something then restart the game, you don't have the same "ruined" layout.

    Having said that, though, perhaps a "persist state" option for layouts would be good for Construct 2: if you enable it it saves the layout state so you can return to a layout as you left it, or use an action to explicitly reset the state to the initial state.

  • If the cache is enabled loading is effectively free (as in takes no extra CPU/disk activity), or you can rewind a sound back to the beginning to replay it.

  • Crash dumps are completely useless to Construct users though, so an improved debugger would be good for Construct 2.