Ashley's Forum Posts

  • if you're overloading the computer, it has to slow down or skip stuff, those are really the only options.

    This is absolutely true. How can this be fixed other than making your application use less CPU?

  • MMF is fundamentally designed to be framerate dependent. You pick your framerate (eg. 50fps) and 'machine independent speed' skips drawing if it can't hit that rate. Since you need to get the logic running at a fixed rate to make a framerate dependent game keep running at the same speed, if your computer still can't hit that framerate, the whole game slows down anyway, kind of defeating the point of the option. As far as I know, you can't V-sync and have machine independent speed on in MMF (or if you can, your game will change speed depending on the framerate, I guess).

    If you turn on V-sync in Construct, it won't skip drawing the screen, but instead the value of timedelta increases since it's taking longer to process frames. This can result in objects 'tunnelling' through each other, or physics going a bit funky, at very low framerates. The solution is to use the minimum framerate option. It does make the game run in slow-motion if your CPU can't keep up, but so would 'machine independent speed' if it were in Construct, and hey, you can't do an infinite amount of processing and keep the same framerate.

    Physics is processed on the CPU so the CPU will be the cause of the slowdown. In this case drawing the screen takes a comparitively little amount of time, so skipping drawing the screen won't solve this problem. You need to use less CPU!

  • The VRAM expression can tell you how much VRAM is being used. The next build will introduce features that allow you to choose which parts of the application are loaded in to VRAM and when, which will help reduce your usage a lot.

    As mentioned, images are fully decompressed (to alpha-red-green-blue format, 4 bytes per pixel) and placed on a texture a size of a power-of-two, eg. 512x512 for a 300x300 image.

    Large animations with lots of frames are an extremely inefficient way to use VRAM. You can end up using tens of megabytes from one object. A much faster and more conservative way is to use static images and move them about to create an animation. The end result is actually smoother than you can achieve with frame-by-frame animations, too. If you play with the bone movement, you should see the effects you can get with six unanimated sprites, which would use hardly any VRAM at all. The same goes for explosions and so on: importing a really high resolution explosion animation with loads of frames is a huge waste of memory. With a few fading, moving sprites, a couple of particle effects (which use basically nothing, if you use say a 32x32 particle texture), you can actually create a much more interesting explosion, and it'll use hardly any VRAM at all.

    If you're worried about VRAM, change your technique to one which doesn't revolve around basically loading entire video files on the GPU.

  • Don't ask, just do it! I review all changes made by everyone else anyway, so if you're worried you make a mistake, I'll check over it later.

  • Please do.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you select a single frame in the animator bar, you can change its relative time. So 1.0 is normal time, 2.0 spends twice as long on that frame, 0.5 spends half as long on that frame, for the given animation speed.

    Is that what you wanted or are you talking about a more complicated system?

  • We don't have a plugin for this yet. Maybe someone will come up with one in future.

  • Looks cool I'm sure some people would still benefit from a .cap.

  • Can you post .caps which produce these?

  • 0 opacity: object still renders itself to the screen processing any effects, taking the GPU's time, but most likely results in nothing being changed on-screen. However, if you had an effect which did something like invert the opacity, it would still be seen.

    Invisible: object skips drawing at all so will never be seen under any circumstances. Therefore GPU spends no time at all trying to draw the object.

    In short, use 'invisible' instead of 0 opacity to hide objects, it's faster.

  • Looks like a bug, better submit it to the tracker.

  • You can use the system information object to get the current screen resolution width and height, but we'll try to add detection of all supported resolutions in future.

  • Can you upload a .cap that shows the difference?

  • active

    Sprite.

    Construct tells them apart by using conditions to filter only the instances that met the event.

    [quote:1ol6augh]Is it just like TGF's rather poor method of using Spread Values

    You rarely, if ever, need to use spread values in Construct - have a look at the 'For Each Object' condition.

    [quote:1ol6augh]collide with another object semi-automatic way that you must design your whole code around

    I don't understand this, what's the specific problem you are talking about? Hazarding a guess, you might be interested in the advanced collision system condition, which allows you to choose which objects involved in the collision get picked in the event.

    [quote:1ol6augh]I remember reading something somewhere saying that Construct has an unlimited amount of actives available and without any slow-down, is this true?

    It's true that Construct supports an unlimited number of sprites, and you don't need to specify any limit. However, if you're drawing them all on the screen, there will of course be a slowdown. Construct isn't magic, if you have twice as many objects, it'll probably take twice as long to draw them all! We've worked hard to try and make it as fast as possible, though.

    [quote:1ol6augh]if I wanted to, I could just code the whole game according to each seperate active object, using as many as I need to, correct?

    I don't really understand... you want to code each instance separately? I wouldn't advise that. The best way to go is to use ordinary objects, use Families to group together the related ones (like Friendly and Enemy), and code your events around the families. You can use event sheet includes to have your family events affect the entire game, and it saves you repeating events.

  • I was just saying setting the time scale for an individual layer would be difficult to implement in Construct. Are you sure you're not talking about layouts, by the way? Have you read about pausing in the FAQ?