Ashley's Forum Posts

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

  • Haha, you did, a little But I've posted an announcement anyway.

    There's lots more information on Construct now as well - the old site was rather brief about it. There's also some forum integration, so you can login/logout via front page, be recognised when you visit it if you're logged in, and of course the latest posts box.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Our new website is now live: http://www.scirra.com

    If there are any broken links or issues, let me know! Thanks to Mary Jane for contributing artwork. Hope you like the update

  • Yep, was just ensuring everything works then was going to post. Any broken links or something not working let me know!

    Thanks also to Mary Jane for the Construct image on the front page!

  • Not sure how I missed this one, I've moved it in to help & tech support.

  • The simplest solution is probably for someone to write an online plugin

  • LOL! Well, it's a fair bit more involved. It's kind of an obvious idea for a game.

  • Well, RTS (with the A* algorithm) is more of a brute force solution - it checks all possible solutions to the problem, then picks the shortest path.

    Not quite - A* is a bit more clever than that. There are infinite unique journeys to travel between any points - just think of all the times you could go half way, go in a circle, then carry on, then the same with two loops round the circle, then the same with three loops round the circle...

    So it's actually impossible to generate all possible solutions then pick the best. It's a surprisingly efficient algorithm, but as a tradeoff it is not perfect in all situations. But I think it picks the optimal path in 99.9% of situations or so. Worth it to get an answer before the end of the universe!

    - the RTS behavior generates a complete path in the 'Move to' action, stores it, then just starts moving the object along the already calculated path. So it's not actually running any pathfinding logic as the mouse moves around, so you'll see negligable CPU usage. The biggest problem with that system is if the path is really big and complicated, or you're moving hundreds of objects in one go, it could hang for a second or two while it calculates all the paths.

  • Interesting idea for a challenge I'm not sure about how useful it is to prove whether or not Construct can do anything - difficult logic problems are difficult logic problems, no matter what tool you use - unless the tool solves that specific problem for you, which general-purpose tools usually do not. By "Construct can do anything 2D", I think we mean limitations in Construct shouldn't get in your way and prevent you from making the game you want.

    In this case, though, Construct does effectively solve the problem for you

    <img src="http://www.scirra.com/images/mouseevent.png">

    If that's not a perfect example of events being a quick and readable way to do something, then I don't know what is

    I've attached a copy where I just added the RTS behavior to the mouse, carefully adjusted the settings, and added an event to move the mouse to the cheese. The RTS movement has a very decent A* pathfinding algorithm built in to it which will basically immediately work out the optimal path to the destination, then move the object along that path. The A* bit is great, but it seems the RTS behavior's code to move the object along the path is a bit ropey. It wasn't designed for small, enclosed layouts like a maze - it's aimed at wide open spaces with occasional obstacles. So I had to tweak the settings a lot, but now the mouse basically walks directly through the maze to the cheese.

    It's pretty surprising to see how bad the RTS behavior fared with the default settings, it gets stuck pretty quickly. I guess it needs a redesign if I ever get round to it. The mouse also has to be very small and use the smallest cell size available in the RTS behavior, since the walls of the maze mark entire cells as solid, and the entire map would be marked solid with a large cell size.

  • Well, remember you can do everything the app runtime does in the DirectX runtime, you just need DirectX installed. That wouldn't make sense for public tools, but if it's your own little thing, I guess it's fine.

  • Importing events from text sounds suspiciously like a scripting language, which is not the purpose of events. It is kind of crazy how events exported as text are formatted, that could use some work, since it would be useful to post events to forums and such.

  • Actually, I don't think you could make much with the application runtime, at least not without a bunch of more useful plugins aimed at the app runtime.

    I think it's one of those features which didn't work out quite as we planned - I don't think many people use it, and it hasn't had much development time, it was kind of rushed. So maybe in the next version it'll either be dropped, or expanded on to make it more useful.