Should work in 7, don't know why it wouldn't. There are problems with this method however, such as certain full-screen layer effects displaying incorrectly, camera scrolling doesn't work properly, and mouse-based movements sometimes behave weirdly.

If you can find a better solution to the problem of scaling, I'd say go for it; this method works, but only for static frames and it can be temperamental for reasons I can't fathom.

Ah yes, 'trigger once while true', the OTHER bane of an animators life. The number of times I've forgotten to put that in, panicked mildly as my animation failed dramatically, only to have the sudden realisation...yup, once again, 'Trigger Once' is required.

Glad you got it sorted anyway.

There are...a lot of events there. I couldn't actually find the event that changed him to the damage animation. However, just a hunch, do you have a 'play animation' event after the 'set animation' one? If not, try it.

Somthing like:

'Megaman' on collision with 'Baddie': Set animation to 'Ouch!', Play Animation.

Whenever I have trouble with animation like that, it's usually because I havn't put a 'play animation' event in. It's worth putting one in any time you need an animation to start afresh; otherwise, for some reason, the animation might start halfway though or something. Usually happens after the animation has already played, but only partially; Construct seems to remember which frame it got to, and starts it from there next time.

Try adding 'play animation' and see if that helps.

Well each background is one layout, basically, at 1280x720 resolution. There's no scrolling or anything (well actually there is, but only in special scenes and I'll load the textures for these manually thus avoiding the problem). I can load each layout fine, it's just loading LOTS of layouts at once that makes the VRAM huge. Without loading multiple layouts in one go, there is a huge pause as you transition between layouts and the program loads the texture.

I've tried making it load the textures for the next layout while the player is still on a previous one, but loading the textures at any point causes a pause; there no way to slowly or 'subtly' load in layout textures in the background.

By cutting up brackgrounds and minimising wasted forground space, I should be able to load each screen in at around 10mb of VRAM. This means I should safely be able to load up to six layouts at a time, and have them transition smoothly, without overstepping the ~60mb VRAM usage required for working with rubbish graphics cards. I'll design the game's environment around this limit; I'll add doors or some such that the player has to move through, then slyly load/dump the neccessary textures as the screen changes, eliminating the noticable pause for loading.

I havn't tested this fully yet; I need to try loading 6 full backgrounds and layout object in one go and see if the VRAM stays at a reasonable level. If not, I'll have to drop the load to 5, and so on 'til it work. It's a pain, and a compromise, but I think I can make it work.

OK, could I, in order to transition between layouts smoothly without having to load textures each time, load the textures for the NEXT layout while the player is playing the first layout? So technically, the textures for two layouts would always be loaded at any time. Would loading the textures for the next layout while one layout is running cause a performance hit?

I'm going to test this out sometime soon, could be a promising method of doing things.

It's certainly an interesting conundrum. Is this maybe one reason why we see so few high-res 2D games on modern hardware? I always thought this was down to 2D simply being out of fashion, but it seems as though video hardware has a natural dislike for large 2D images, as opposed to complex 3D models, which they seem to handle fairly easily.

I've been playing around, and loading the textures, one for forground and one for background, straight in as one object takes up 16mb VRAM. Chopping these up into 512x512 tiles and tiling them drops the count to 12mb. Cutting them up further into 256x256 tiles and minimising empty space drops it to 11.25mb, but the difference seems negligable at this point.

For this project I've always intended to allow different graphics settings so most people can at least play the game, however, this VRAM issue is quite a large one. I intended for low graphics settings to disable certain visual effects to improve performance; however, Construct seems to be able to render plenty of effect with little performance drain. Disabling these effects will compensate for cards with old pixel shader versions, but won't affect VRAM usage much at all.

With 3D games, as you say, they can just whack the resolution and texture-quality right down to allow them to run on older machines. However, they aren't designed with this setting in mind; the games are designed in high-resolution, then simply scaled down if needed. They are effectively designed with mid-high range graphics in mind. I can't do this with a 2D game; artwork is artwork, it'll take up the same space regardless of how crappy it looks, and scaling it down to fit lower resolutions won't work. Thus, I have to design the game with low-range graphics in mind, and then scale it UP if someone has a decent rig.

Taking into account low-range cards at around 64mb, what's the largest amount of VRAM I can afford to use? About 32mb? Does VRAM refresh for individual layouts? If so, with backgrounds using ~12mb per screen, I could get away with using high-res textures providing I use individual layouts for every screen of the game. Doing so would be a logisitcal pain in the ass, but should keep the VRAM of each layout down to a usable amount.

Ok, thanks folks, it would seem that with my current backgrounds my best bet would be to chop em up into 1024 x 1024 to save time and VRAM. I understand that tiling a backdrop and adding objects to it would be the most efficient way of doing things, but that wouldn't really work with the art style we're using - we're using high-definition, hand-drawn backdrops and sprites.

I'd already pretty much ruled out this running on really low-end hardware (~64mb cards), but would like it to perform comfortably on mid-range cards. I'd prefer it if people didn't require Crysis-eating rigs to run our game. What I could do is chop the foreground up into individual objects - saves memory rendering empty space - and then chop the background up into the most efficient power-of-two segments possible.

I'm going to try out a few different methods with my current backgrounds and see what the most efficient method it. I'll also have a word with our artist about making the actual background a tileable power-of-two texture wherever possible. Am I right in thinking that tiling a 1024 x 1024 image is considerably more efficient that cutting up a larger image into 1024 x 1024 pieces? I'll try a few techniques out, anyway, and try to avoid rectangular textures wherever possible.

Hi folks, I'm wondering what the most time/memory efficient way of loading a big high-res image into Construct is. My game runs at 1280x720 resolution, so the backgrounds are that size per screen. However, loading giant 1280x720 textures into a backdrop object is clearly inneficient, and ends up slowing Construct down a fair bit.

I know that Construct prefers to work with power of two squared textures; would I be better off cutting up each backdrop into a sequence of power-of-two tiles, say 256x256, and importing them as seperate objects? Or, would I be better exporting the background image as one oversized power-of-two image (in this case, 1296x1296)?

Also, is any particular object best suited to loading backdrops like this? Backdrop, Tiled Backdrop, Sprite, do these add different strains on processing? Currently I've been using Tiled Backdrop for all my static backgrounds. Any help or ideas would be appreciated,

Cheers, Tom

I thought that might be the case, ah well, I'll just have to hold off on sexy bloom effects 'til it's fixed then. Cheers anyway.

I'm using the canvas object to create a psuedo-bloom lighting effect in my game, but I'm having trouble when it comes to scaling the game to full-screen. The scaling system I'm using should automatically zoom all layers to fit the screen size, but this doesnt seem to effect the canvas object, which stays at it's default size. If I try to resize the canvas object seperately to the layers, then it scales up incorrectly.

Here's an example of what I'm talking about: http://www.mediafire.com/file/z2rzlmktl ... caling.cap

If you deactivate the 'Scaling' group, you can see the effect working properly in window form. And with Scaling on, you can see the issue I'm having here. Any ideas as to how I can make the canvas object scale up and still capture the layout correcty?

Cheers, Tom

(Oh, and the background image in the example isn't mine. I think it's from Avatar: The Videogame. I just needed something to apply bloom to )

OK, I'll hold off on bug reports 'til I've tested it in a newer build then. Not sure if the animation issue is down to the same bug, but I'll keep you posted.

• Tom

Yes, I get this also, however, as well as duplication objects, saving then loading the game also screws up my animation system somehow. Interestingly, if you use the debug to try to check the properties of objects duplicated by this bug, Construct crashes. I'll post an example to the bug reporter shortly.

• Tom