Ashley's Recent Forum Activity

  • There's already another group!

  • Hehe, there will surely be more in future though!

  • Because PNG files are compressed, and textures are decompressed in VRAM (they'd be roughly the same size as uncompressed .bmp files). A compressed image cannot be drawn unless it's decompressed first, which is why they are decompressed in VRAM.

  • Aw, I didn't mean to make you delete it. Sorry if I came off harsh. You're right I'm seeing this mainly from a technical standpoint (I'm keen to make sure all the technical stuff is accurate), but I'm still not convinced it's wise to tell everyone to always use power-of-two textures. If you do, wouldn't people come back with questions like:

    1) Why can I resize an image to a non power of two size then?

    2) None of my art is power of two size. Can I not use it in Construct then? (or, do I have to laboriously resize every single image?)

    Yes, for tiled background the advice is pretty much sound: always use a power-of-two texture if you can. For everything else though, a better lesson is just to know VRAM is separate to memory and usually much more limited - so large textures and long animations don't come for free.

  • Not sure I agree with the basic premise of this article.

    your game will run much slower and behave far more erratically.

    [citation needed] - what do you mean by "erratically"? Isn't the issue you followed up with purely to do with Tiled Background?

    Power-of-two images are pretty much a necessity for tiled backgrounds, because that's the only way you can get perfect seam-free display, and it's faster too. Outside of Tiled Background, the only issue with using a non-power-of-two texture is it uses slightly more VRAM (ie. rounds up to a power of two size as you say). For sprites and other objects, Construct never stretches the textures, just places transparent gutters around the edges, so there's no difference in visual quality whatsoever, the performance will probably be identical if the same number of pixels are drawn, and there should be nothing "erratic" about it. The conclusion should be "be aware you might be using more VRAM for non-power-of-two textures - and remember Tiled Background is a special case", but your conclusion of "always use power of two textures" is over the top. Also, I think GPUs from the past five years or so can all safely handle 1024x1024 textures, since 512x512 is still pretty limiting. Remember Construct often creates window-sized textures for effects and such, so even for a 640x480 game, a window sized texture is rounded up to 1024x1024.

    Edit: don't mean to totally trash your article though it's a fairly important engine point that's worth knowing.

  • I think David's looking in to fixing a related bug in the Xbox 360 controller behavior for the next build.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 'Call function after delay' only checks if the delay has expired at the end of the event list. So if you're running at 100fps, it'll only check to see if the delay has expired every ~10ms, so timings less than that don't make much sense. It's perfectly safe to use smaller values, they'll just still be executed after about 10ms. Generally all timing things in Construct are synchronised to the framerate so your resolution will be about (1000ms / framerate) milliseconds.

  • Construct still uses the August 2008 version of DirectX, so as long as they've finished that, it'll work.

  • Good point Mr. Wolf, to properly calculate VRAM, the number of bytes is w x h x 4. So 512 x 512 x 4 is 1048576, or 1mb.

  • I edited my post to include an answer about VRAM.

  • Oh right, it shows black bars when the layout is smaller than the window. Those black bars are drawn as well, and each weighs up to about the same performance impact as the tiled background (a four vertex quad). In such an intensive test, they're bound to show up as making a difference. Always keep the layout bigger than the window if you want to keep it a fair test.

    Edit:

    [quote:7mikr2h8]Edit: Also just noticed that it suddenly starts to need 4 Megs of VRAM in the second sample - why is that? Sort-of drawing the application "background" and the layout as different things or something like that?

    When the layout is smaller than the window, it draws to an offscreen surface first, to ensure nothing is drawn outside the viewable area. It's this offscreen surface you're seeing VRAM usage for. It's also going to further reduce performance copying this offscreen surface to the main window, which also explains the FPS dip.

    In short, these performance/VRAM usages probably won't make much sense unless you know how the engine works.

  • I can't reproduce any performance difference by changing the layout size. The layout size is pretty much just used to enforce scrolling limits - it doesn't have much to do with rendering, so I'm not sure why you'd see a difference there.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 10 Mar, 2025

Twitter
Ashley has 1,450,588 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
  • x64
    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