Ashley's Forum Posts

  • Ah, grouping was meant to be removed a few builds ago because it was broken. It'll be gone from the right click menu next build.

  • I'm interested in synthesis and had a go at writing a synthesiser in C++ recently. It's based on 2,400 triangle-wave oscillators which move randomly between notes in various chords. It sounds pretty creepy. I might be able to use it in some kind of weird game soundtrack

    http://www.gullen.pwp.blueyonder.co.uk/weirdsynth.mp3

  • Yes, I need these kinds of features myself as well, so rest assured I'm planning something

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It shouldn't really matter which way round it is... could you send me an example of the order being important?

  • I can't create something like 'Enemy collides with Sword > Subtract 10 HP', since all the enemies in the family will lose 10 HP, unless I'm doing it wrong.

    You must be doing it wrong. Families obey ordinary object picking rules. In that event, only the objects that meet the event will be affected.

    [quote:18ri3ogn]Also doing something like 'Always > Enemy: Add LOS obstacle 'Barrier' seems to crash the program

    Crashes are always bugs, please submit them to the tracker so we can make Construct more stable!!

    See the attached file. It's a quick example proving events involving families work only on the right instances. It's also got a quick and dirty health bar implementation. The health bars are not in a container with the objects, they just 'naturally' pair up one to an instance if there's the same number of objects of each. This works with ordinary types as well and can be very useful. Hopefully it will help you see the real use of families. They can save a LOT of repeated events. I don't know how I'd manage without them!

  • Maybe post an example .cap so people can find a way to fix it.

  • Are you using the Compare Values system condition? It doesn't do ordinary object picking. It should work fine if you use the conditions within the sprite object itself to compare. Alternatively you could put a "For Each Enemy" condition above the comparison.

  • Yeah, it needs to be changed and it will. It makes the requirements higher than they need to be, because all your menu textures will be in VRAM while you're in the main game, etc. However, it does almost completely eliminate loading times. Scaling never affects it because only the source original texture is stored in VRAM.

    A 30 frame animation of 256x256 frames is still going to use about 8 mb VRAM, so after a handful of objects you could be knocking out all cards with less than 128mb VRAM from playing your game. Even if Construct was clever enough to load animation frames only when they're displayed, it would perform very poorly, because transferring textures from the CPU to GPU is slow, and they're stored as PNG files which need to be decompressed first. To be honest, you're going to have difficulties designing your game like this. Try scaling everything down to 128x128 or smaller.

  • The Event wizard does not allow for a way to access this variable, either to compare it for conditions, or to set it.

    That means it can't yet be set at runtime. An option for that can be added.

  • What current problem with hitboxes would this solve?

    It's generally expensive to try and retrieve the colour of a pixel somewhere on a texture and send it back to the CPU, so I think another solution would be best.

  • Umm... did you try this? It's already built in, and documented here. It's a little buggy, but I think it works with brackets round each operand, ie. (a = b) ? (c) : (d)

  • Well, if you're using something like 640x480 on a widescreen monitor, it's either got to stretch it or add bands to the sides. You could detect the user's desktop aspect ratio on startup using the System Information object, and use the Change Display Resolution action to go to the best resolution in that aspect ratio. Then you can go fullscreen and it keeps the user's aspect ratio. However, the runtime will stretch the display to fill the extra room unless you set the resize mode in application properties to "show more content".

  • Well before you go ahead do some calculations and figure out if when the game is done, will one layout's complete textures even fit in system memory? Will the system requirements be too high to be useful to anyone?

    You should come up with satisfactory answers to these questions before you make your game. There's no point launching in to creating a game which is impossible to run.

  • It will still take up VRAM.

    [quote:2x55o1z8]Currently Construct loads all textures from all objects in to VRAM on startup. This should be improved to be configurable layout-by-layout in future, but that still won't help.

  • If something is locked you can't select it, so what use is an "unlock selected" option?