Ashley's Forum Posts

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

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

  • Great job. I'll credit you in the changelog.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't know, isn't that a question for the Wine developers?

  • Nice tool

  • Your 16x16 .cap actually uses a 16x18 texture That's not power of two, so power of two rendering is disabled! If you resize the texture to actually be 16x16, the framerate goes up.

    Just to clarify some of the comments here, in practice the framerate for tiling power-of-two textures (16x16, 128x128...) should be roughly the same. Power-of-two textures can be drawn more efficiently - there's basically a single command which is "tile texture N times". That doesn't work for non-power-of-two textures though, so instead for each and every tile Construct has to issue a separate "draw this texture once here" command. That introduces a very large overhead of command data going to the GPU which is the main cause of slowdown when many tiles are visible on-screen.

  • Outline should work properly if you turn off text antialiasing... but then all text will appear kind of jaggy.

  • Nice find, thank you very much! Not sure how that code ended up there since everywhere else I've been pretty careful about use of SSE2 instructions! That would explain everything since that code was introduced with the new renderer (0.99).

    I've simply changed it to call the non-SSE2 version since I'm not sure the SSE2 version actually ever ran faster anyway.