Ashley's Recent Forum Activity

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,440,688 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x63
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs