Ashley's Forum Posts

  • Use a family. If the balls are in a family, you can use conditions in the family to pick a different set of objects.

    For example:

    + MyFamily 'selected' = 1

    + Ball overlaps MyFamily

    -> Do action on ball

    In the actions, "Ball" relates to the objects overlapping the selected instance, and "MyFamily" relates to the object with selected = 1.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Enter + left click selects the object underneath. Does that help?

  • Crashes are always bugs, so please report them!

  • I don't think streaming is possible in DirectX. Both the CPU and GPU wait until the texture upload completes, and that is almost certainly a noticable pause.

  • Can you post a .cap?

  • There is no such thing as drawing from a compressed texture. If it's on the video card, it's uncompressed.

  • You could load JPEGs from external files.

  • It's not possible to control VRAM how you describe. The runtime has no idea which textures you're going to need shortly. It can only guess, and when it gets it wrong, the game will become noticably choppy as it transfers textures to the GPU (it's a slow process). And if there are X megabytes of textures to show on-screen, you need X megabytes of VRAM, regardless of whatever limit you want.

    I haven't fully designed how the system will work yet, I'm still working on it, since it's important to get something which is useful and will work well before I start coding. But it'll probably take the form of:

    • Layout settings (load and free the layout's textures on an application or layout lifetime)
    • System actions (dump all VRAM, dump currently unused VRAM. or cache certain objects for customisation)
    • Object settings (load and free object textures in the layout or object lifetime) although this is not as effective a way to do it

    If you have any other suggestions how it could be configured I'm listening (now's the time to get your ideas in), however, in short, the user will have to decide how to load and unload VRAM. The runtime can't second guess what your game is going to do, nor can it magically lower the minimum requirements to less than what they really are.

  • Construct doesn't care what format you import your graphics as. It saves them as 32 bit PNG with alpha channel. You won't get a smaller filesize by compressing beforehand unless you make it more compressable by PNG (for example, by reducing colour depth).

    JPEG has no alpha channels so is not a particularly useful format for most games.

    40 frames of 480x480 textures will use about 41mb of VRAM. Due to other overheads, this might be too high even for 64mb cards. So now due to one single explosion sprite your game requires a graphics card with 128mb VRAM. That's not the way to do it: DirectX games are rarely based around imported video, even 3D commercial titles are more economical with memory than this. Compose your explosions out of a number of smaller, single frame sprites, dynamically stretch and resize them, and throw in a few particle effects. The system requirements will drop massively, it will look smoother, will look better with timescaling, and hey, it might even look better!

  • I think this counts as a bug, submit it to the tracker.

  • You'd actually get much better performance with an array object even if it used a lot of memory, because it's immediately available to the CPU.

  • It's doable, but it would be extremely slow. The textures holding the colour and opacity data are on the graphics card. The event engine, which runs expressions and events, runs on the CPU. In order to retrieve a pixel, you'd have to stall the GPU rendering (because it works in parallel), and transfer a pixel from the GPU to CPU over a high latency bridge already bottlenecked with rendering commands. Basically, although it's possible, the system is not at all designed for it. I think there are much better ways to achieve it than relying on pixel data on textures. The expression you want would totally strangle performance and I bet we'd get lots of people complaining that it's slow.

  • XAPOFX1_1.dll is an XAudio2 DLL. It's installed by the latest DirectX update which he should have been prompted to do when running your game. Did he not see that message? Why did they not update DirectX instead of you sending them DLL files?

    The 8 direction movement thing might be a configuration thing, I'll have a look.

  • LOL!

  • I prefer the pronunciation "goblins".