Ashley's Forum Posts

  • For instance, I know that MMF extensions had unique identifiers so that the main program could verify that you had the correct extensions required to view the project file, and I figure Construct has something similar, but I haven't found it yet.

    The plugin SDK has no such identifier; Construct uses the plugin filename as the identifier.

  • Uploading .caps is a great idea, I'll get that done as soon as my ISP can provide a semblance of service. Also you're right, the lightning one is corrupt, will fix as well.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • ISP decided to cut off internet access shortly after installing it. They move in mysterious ways! Back soon.

  • Oops, fixed that, thanks!

  • Try them out, let me know if any problems or issues. If you have any more suggestions for demos, post them here - it would be cool if we had some small, simple, fully playable games as demos as well, so if anyone's up for making one, I would happily put it up.

  • We need everyone's help, but we need to configure the wiki to add a new permissions level. We should have it done soon, sorry.

  • Mipmapped images are pre-rendered with high quality, not just linearly interpolated. I guess you don't want that for point sampling though.

  • The current status on Python is that it seems to be broken in the latest builds - I think that if you install yourself a version of Python different to the one the IDE has implemented, Python can't find the right files, or something like that. We'll be looking in to it and fixing it before 1.0.

  • Bah, I prefer the runtime motion blur! To me that looks nothing like motion blur, because the main object graphic is still perfectly crisp. It's just a smudgy trail behind it.

  • Also feel free to ask any questions about the SDK in the plugins forum, or in the codebase forum!

  • I'm not aware of a hardware-accelerated implementation of any of the pixel-art rescaling algorithms, as it may not be possible to implement via shaders. I did look in to one pixel art algorithm a while ago and it relied heavily on lookup tables, and I'm not sure how good pixel shader processors are at that. Still, as David said, why rely on a special algorithm to give your games detail when you can draw in the detail? Or why not use a different rendering application to scale all your graphics before you put them in?

  • > If I remember my Physics correctly, all you need to do is calculate the centre of gravity, and make everything fall towards that.

    >

    Soo, do you stay indoors during the day, so you can stand on the ceiling instead of falling into the sun?

    No, because you have to take in to account the Earth's centre of gravity and the Earth's mass! (My example does not take in to account mass, which I noted). In reality, the centre of gravity you fall towards will be ever so slightly towards you from the centre of the Earth's gravity due to your own mass, but the effect is vanishingly small.

  • One more thing, are pick by comparison events as processor consuming as for each object loops?

    No, it's an ordinary filtering condition and doesn't run repeats. Nesting them doesn't cause further exponential processing - just further filtering of the handful of objects that are picked in that event. It is the repetitions run by the looping conditions like Repeat, For, For-each and so on that cause exponential processing when nested.

  • If I remember my Physics correctly, all you need to do is calculate the centre of gravity, and make everything fall towards that. This example shows that, but I don't think it's quite perfect (it doesn't take in to account that objects with a bigger mass have a greater effect on the centre of gravity). It shows the right idea though.

  • Well, .cap files even from 0.8 in theory are still compatible, and we have a very good compatibility code that allows us to add, remove, or completely change sections of the file format as necessary, while still being able to load the old format. So we'll never change the format in a way that breaks all existing files.

    Being beta sometimes we need to make changes in order to fix bugs which might affect - but not completely invalidate - older files. The physics bug deadeye was referring to actually only affected .cap files that were started with a couple of the more recent builds. The default world scales were incorrect, but the value was ignored. So I corrected the default value and fixed the bug that made it ignore the value - but this meant old files were now making use of the incorrect default value. The change was very simple (change two properties to 3.3% and it worked exactly like it did before). This was, like any other similar situation that has arisen or will arise, detailed in the changelog. If you keep up-to-date with the changelog, it's a trivial change. Very old applications in the newest version might suffer a few of these minor changes, and it becomes more difficult to track down all the tweaks after more builds get released.

    The official line is that you shouldn't start any really serious projects in Construct until 1.0. This is true, but it becomes less of an issue the closer we get to 1.0, and large-scale applications are very good for testing Construct. You should back it up regularly however, including to separate media (this is just generally good practice with any software). Construct includes anti-corruption code - every time it saves or autosaves it verifies the data it generated is valid and can be successfully loaded. In theory, this means your .cap file is never corrupted (overwritten with data that cannot be loaded). However, there might be some other obscure as-yet unknown situation that causes an invalid file to be saved (even mature commercial applications sometimes do this). With regular backups, I'm fairly confident your work would be safe, but take precautions in case it is not.