Ashley's Forum Posts

  • I'm not sure why this happens. I guess it would be useful to narrow it down to a single setting.

    I can't see how Construct could cause more than two or three frames latency given double buffering, which should appear almost instant. It might be something to do with graphics cards settings, VSync, mouse settings, or a combination. I don't know of anything I could do to rectify this at all; as far as my code does, it gets the mouse position and draws it, all in the same frame, so I can't see where such a large delay would come from!

  • The mouse behavior does not use timedelta. It's almost identical to using an always - set position to mousex, mousey event.

  • Since the website upgrade the chat has stopped working. (Thanks Aeal for noticing)

    I think we may as well get rid of it and use an IRC channel, since the old phpBB chat seemed to burn a lot of server bandwidth and was slow and kept saying 'Error: connection status 0'.

    Is anyone already running an IRC chat? I can put links to an "official" channel in the chat window.

  • 'Every X milliseconds' cannot trigger faster than the framerate, so at 75 fps, 'Every 1 ms' will trigger every 13.3 ms instead (ie. every tick).

    The correct way is to use TimeDelta.

  • I think it's a known issue; try just kicking off the music loop again in an 'On loaded' event (it's a system condition that triggers after loading the app state).

  • Please report bugs through the tracker, thanks... also, it's very important to have them reproducable so they can be fixed.

  • Sorry, I've updated the original post text to say it is now the new stable build.

  • Have you tried the Ghost Shooter tutorial? It covers some of this.

    For lives you want:

    "Lives: " & global('Life')

    There's also a condition in the system object to compare a global variable.

  • Click the question mark icon in the top right. It's true 0.99.62 came out about two weeks ago, I only decided to set up the auto-updater now, since I'm fairly sure it's stable(r).

  • Wow, sorry about the downtime on the forum, but after a truly monumental effort it's now working, is upgraded to 3.0.6, and is relocated to scirra.com/forum.

    Hopefully everything works now.

    Hopefully.

    Let me know if there are still any quirks...

  • Hmm, is anyone having trouble creating new threads? I may have accidentally broked the phpBB install...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Oops, thanks for spotting the wrong date. Fixed it now, 0.99.62 was released on 22nd November.

  • You might find the Optimisation tips wiki page interesting.

    if you have a graphic of 512 x 512 and you resize it to 32x32, what is the final output, will it take more resources to work with the texture , than an original 32x32 graphic

    "Resources" is a fairly vague term - it could mean memory usage, or processing time. Usually processing time is most important, as long as you can fit everything in to memory.

    The important things here are:

    • The source texture - in this case your 512x512 image
    • The destination rendering size - in this case scaled down to 32x32
    • Whether any pixel shader 1.1 or 2.0 effects are applied

    Generally, with no effects applied and a good graphics card, it's very hard to measure any performance differences between various combinations of scaling up small textures or scaling down large textures. Graphics cards are precisely designed for that kind of thing so as far as I can remember from my own tests, they render about the same speed as not scaling it at all!

    However, the source texture is always in video memory (VRAM) so a larger source image will occupy more VRAM than a small source texture. As above though, this does not seem to affect the framerate much.

    [quote:1l4kb5ro]an to the same, if you have a 512x512texture and make it 1024x1024 will it work faster then an original 1024

    As above it probably runs just as fast, but in this case you're using less video memory, since the source texture is smaller.

    [quote:1l4kb5ro]if you have like a line spread out between points, it will take the square space that is needed to draw the line, will this affect renderingspeed much, if its very big, like 2000px, or

    will it not take much as its just a line?

    Do you mean like a long, thin sprite rotated at 45 degrees? In this case its bounding rectangle (its outline) is very large, but the actual drawn area is small in comparison.

    If you don't have any PS 1.1 or above effects applied, it only draws the line area, which is fast.

    If you have got PS 1.1+ effects applied, it renders the full bounding box area, which can be slow! However, graphics cards won't bother drawing anything offscreen, so it's never going to process a 2000x2000 area - just what you see on-screen.

    So if you use effects, try to keep the objects small, and if you don't, the next best thing is to use fewer (but sprites without effects are very fast to render).

    [quote:1l4kb5ro]whatever is set invisible has no influence in render speed? or does it take cpu to calculate , lets say a texture of 512x512 invisible will take less cpu then 1024x1024 invisible to translate,

    is invisible the same as opacity 0 ?

    Invisible objects still run events (so take some CPU time), but skip rendering completely.

    Objects with 0 opacity are still rendered so have the same performance impact. So you're always better off using 'make invisible' than setting to 0 opacity. It's intentional that they are still drawn with 0 opacity, because if you used an effect which changes opacity (eg. inverts it), then the object would become visible.

    [quote:1l4kb5ro]is it better to cram everything together in the same for each "object" action or dont worry about it an split it up as much as you want for better overview

    I doubt you'll ever measure a difference (try it and see if you can see a change in fps) so I would advise you do whatever makes your events easiest to read.

    [quote:1l4kb5ro]if you have an area of 10000 by 10000, and there is some activity in places, is there something you can do to make it less cpu intensive or will the extra eventchecking make it more intensive

    I'm not sure what you mean. The fact that the layout is big doesn't have any performance impact itself. Only things on-screen affect rendering speed, and objects run events even if they are offscreen.

    [quote:1l4kb5ro]if you zoom out, very far, more objects are rendered would it be a good thing to exchange the sprite with something smaller or less detailed, set the sprite to frame 2 for example

    , or hide things that arent showing anyway, like particles

    As I said above swapping for smaller textures probably won't affect anything - it's more the number of things on-screen will be very large.

    Making things like particles invisible is a good idea. If you couldn't see them anyway, you can save the graphics card from even attempting to render them. This could speed things up a lot if you have a lot of particle effects.

  • You can always hide the Windows mouse cursor so you can't see the difference between that and the sprite cursor.

  • Construct uses a double-buffered, V-synced display for optimal rendering quality - and this inevitably causes some lag. How bad is it, though? Usually it's fairly small.