Ashley's Forum Posts

  • So in my case the graphics are the bottle neck.

    Then have options to allow the user to turn off effects if their computer can't handle them. It's a well known issue physics doesn't work well with large timedeltas.

  • I tried the .cap and had a quick look at the events, I'm not sure what's causing it. The way to find out what causes a slowdown is to back up your .cap and delete things until the framerate jumps back up.

    My best guess is you use hundreds of sprites instead of a tiled background for the floor. You really really really really should use the tiled background objects instead of tiling hundreds of instances of sprite! With hundreds of sprites, every tick anything requesting a collision check (like the platform movement, which requires several every tick) has to iterate collision tests over hundreds of objects. With a tiled background, it makes one collision check, and then it's done the whole tiled background area.

    If it's not that, though, then you should try the removal approach.

  • We could make it recycle textures, but unless you manually specified the same ones, it'd have to work out on export time which ones match... which could take a long time...

  • 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.

  • 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?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.