Ashley's Forum Posts

  • Yeah, 0.99.3 is an unstable testing build so you can expect things like this to go wrong, but I think it's fixed in the next build. If you're trying to get stuff done, rather than find bugs to report, use the last stable build (0.98.9).

  • It's unecessary to try and work out how to store a "reference" to an object in events. The usual way is just to use the object-picking conditions to run the logic. For example, given the situation:

    • each 'unit' has the private variables is_selected, can_build
    • 'build' button should be invisible unless a selected object (is_selected = 1) can build (can_build = 1)

    Then you can just take advantage of the top-to-bottom execution of events:

    + Always

    -> Build button: Make invisible

    + Unit: 'is_selected' equals 1 (...picks all selected units)

    + Unit: 'can_build' equals 1 (...picks all selected units that can build)

    -> Build button: Make visible (...this only runs if at least one object met the above conditions)

  • > What's wrong with using subevents under a for-each loop? It works fine...

    > ou are right, they do. I think the words in the guide will agree. It just points out to be careful and not get complicated with for each + sub-event.

    They're not necessarily complicated or dangerous at all. They work perfectly logically like you'd expect. I'm all in favour of people writing their own hints and tips, but it should

    • be correct and properly checked - for example random("n") is misleading because it does not take a string, it takes a number!
    • be written by someone well experienced who knows if something really is difficult/complicated, because in the case of subevents in for each loops, there really is nothing wrong with them and that kind of advice might mislead beginners.

  • The Mouse & Keyboard object has expressions to get the absolute mouse position.

  • No, there's several places you need to add code to support private variables. Search the Sprite object source for 'private'.

  • The runtime already supports changing to any resolution via events, and you can position things for any resolution using DisplayWidth and DisplayHeight expressions. What's wrong with that?

  • What's wrong with using subevents under a for-each loop? It works fine...

  • Construct converts everything you import to lossless 32-bit PNG files, which doesn't affect the quality. When you run the game, DirectX loads the PNG files effectively as uncompressed BMP files, because textures cannot be compressed in VRAM. So the source file format affects neither the .cap file size nor the runtime speed or VRAM usage.

    How many sprites are you talking about? 100? 10,000? You could also check out the optimisation tips article.

  • Multipass effects arent supported in Construct - I couldn't get them working with the D3DX library. Also, Construct does use mipmaps, but not for rendertargets (like canvas objects or layer effects).

  • No,that would be silly! It caches it depending on the cache setting. I've actually written up XAudio2 fully for the wiki, so check it out.

  • i have a technique for making motion blur that uses very little power and is simple to implement. the blur is generated using the "broken" subtract 0.0 shader. that shader seems to capture frames and slowly fade them away, so when u move an object under it, it captures all of its movement, and adjusting the opacity of the filter

    That effect is called frame-feedback (previous frames fade out). You can do it properly with a canvas with grab layout and less than 100% opacity - using a "broken" shader relies on undefined graphics card behavior and might look borked for other people. Personally I find it quite an irritating effect, and it's definitely not a true motion blur, more of a stepped trail effect, like spawning fading-out sprites behind a moving object.

  • It works OK for me, but if something you're trying isn't working, check it isn't reported on the tracker already, then submit a bug report.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Use autoplay instead?

  • Currently all the data is just embedded to the EXE. Using external data files would not make the total amount of data you need to send out smaller, it wouldn't be faster, either, and I doubt it would save memory. So I don't see much reason to do this I'm afraid

  • > I'd advise against going over 1024x1024 since the runtime requires temporary textures the size of the window and some video cards will create a 2048x2048 surface for anything bigger.

    >

    really? so it'll kill the speed at 1920x1200?

    It'll just use a lot more VRAM, that alone won't slow it down. But I imagine rendering a lot of objects at that high a resolution could be slow anyway, since you're simply pushing so many pixels to the screen.