Yep, useful info is that too.

The link at the bottom of the page on the main site (and possibly other pages) directs to http://www.scirra.com/forums/ but it should be http://www.scirra.com/forum/

Just thought I'd mention it.

While it looks like there is a bug, I have not seen it on my game and I have tested it a lot wiht the Xbox 360 controller.

I did have problems when I used a clone Xbox 360 controller under WinXP. It was very flaky and would not work at all on one of the WinXP machines, until I switched to an Official Xbox 360 controller. It now is rock solid and plays perfectly.

So whether I just had a bad clone controller or MS made sure theirs works better I can't say. But the problem only occurred while testing it on 2 WinXP machines. Vista and WIn 7 were fine.

The XBox controller for Windows has had a history of not being so great. The unofficial one some guy did (I forget it's name but so many use it, it's easy to google for) worked awesomely. Alas it still wouldn't work for 64bit versions of Vista, last I checked.

But on the plus side, the newest official controller works fine from what I can tell.

Quazi's idea appears to be best, with LoS toggled to give the opposite (what it can't see).

Ok, since half the users say save/load is bugged, and the other half say it's fine to use except with certain third party plugins that are bugged. Why not a compromise?

Setup an event that saves a version of the undamaged level, in this case where none of the bricks have been destroyed, using the save to ONLY save the undamaged bricks (and other things you want to persist like that, depends on what else you have in mind but we'll stick with just bricks for this example). Then when the player starts the game, upon entering that level, he/she automatically loads that saved file. Because it's only loading certain things and not expected to load everything, then badly behaved plugins shouldn't have an issue with it.

When the player leaves the level as per your example. Those bricks are once again saved in their new state, to the same file. So when the player returns, bingo, the level is how they left it, and previously destroyed bricks, remain destroyed.

Then use a value inside an ini file or registry key (you'll need an installer such as Inno or Nullsoft to create the registry key, but then construct can edit it afterwards) to tell it if it's supposed to be a new game or not, or alternatively, a profile type setup. In which case a new undamaged version of a save file is saved prior to the player getting their grubby hands on the level (like during a "loading level 1" message, so they don't notice it's saving/loading anything). Then in the case of a new game, all the bricks will be untouched, ready to be destroyed again.

That make sense?

lol, awesome!

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.

Construct stretches textures over 1024 but below 2048 when you load them in (unless you fixed that, but it was the case a couple of versions back when I last noticed it).

It's simply bad practice not to use pow2. Pow2 images are very clean and easy to organize. Your own animation frame splitter requires each frame to be the same size. It's easier explaining that with pow2 than going into details with it. (Yes, I know, they just have to be the same size, and don't have to be pow2, but that's besides the point).

The erratic comment is directed at using none pow2 in general. Might be ok with construct but it sure isn't with other apps out there, and once people get into a bad habit, it's pretty difficult to break.

It's far less of a headache to think in power of two for everything.

Also don't forget, you're a programmer, I'm an artist. We know these things. But Joe off the street who comes along cause construct looks like an easy way to make games is going to get confused really quickly as to why pow2 is required in some cases but not always, and why his many resolution animation sequence isn't behaving correctly. Or why he can't have dozens of 1024x1024 animations wizzing around the screen, or why the game he made for his gran doesn't even work on her computer. It'll be less hassle for Joe if he learns the basics, sticks to pow2 UNTIL he's learned enough to know when and how certain rules can be broken, which he'll learn at his own pace in his own time. But until then he'll be doing things right and have fewer problems to start with.

A perfect example of not bringing these things up, are the many users who create all horrors of art related assets, that would have been avoided entirely if they'd -thought- they had to stick with pow2. For example "Why should I use tiling?" Try explaining until they understand why tiling is better, when they can use any old image instead and don't see the point to it because "well it works for me". Or the guy on that site, who claimed his event laden parallax scrolling effect worked better and faster than layers and that construct was laggy and slow. You gotta remember, construct, by its very nature of simplicity is not aimed at professionals. So even the most basic things will be confusing and difficult to grasp. So if a new user comes along and thinks they have to do everything in pow2. At least he'll be doing it right.

I just think it's a good idea that new users with no previous knowledge (and there's been a few, and there will be more to come, I'd put money on that), learn these old basics early on, and how to optimize their games by doing so, rather than realizing too early that there are no real limitations and simply slapping any old stuff together without any thought, then complaining on other forums how "construct is broken and crap" just because it didn't work out for them for whatever reason.

You could compare it to a game of Sim City. Two players, one who cheats from the start and can use any buildings he likes, with no cost. The other, who plays through normally from the beginning, and slowly builds up knowledge of how things work together. Bet the latter has a more successful city after a week than the guy placing lots of huge fancy buildings all over his city from the start.

And yes I'm aware comparing construct to Sim City is probably the weirdest comparison ever, lol.

But anyway, no real point keeping this up then. You might as well delete this one, and the VRAM one.

Inaccurate information. Thread to be deleted.

Thank you! I was concerned with my game having 14 megs of VRAM in one layout which was only half complete, but it looks like I shouldn't worry about it too much anymore.

By testing a game on a lower-end system, how low end do you recommend going? My laptop with integrated graphics can only run it at an average of 15 fps, while my sister's computer which has a Geforce MX4000 (or something like that) get's 60 fps. Should I just ignore the laptop's performance?

Depends on the sort of game you're making, and the type of player you're aiming for. Then anyone with specs below the ones you list as the minimum requirements, aren't supported.

Generally the fancy big sprites and graphics will have a higher minimum spec than the retro style ones using a tiny screen that's zoomed in. Also the lower the minimum specs, the more people will be able to play it. If your game is still playable on your laptop, you could use that as your minimum requirement if you wanted to. It's entirely up to you. So long as you know it works fine on the minimum (even if you've got a lot of effects and such turned off).

The lower the better though, since folk expect 2D games to just work.

Just use the line of sight behavior, that has the field of vision (angle range) that you're wanting, and distance it can see.

Quicksave/load just saves and loads to memory temporarily. Use the regular save/load which saves to a file instead if you want to keep things. Consider the quicksave/load as more of a checkpoint type thing rather than a full save.

So, do I just click on it and I can use the rectange tool to draw a collision mask?

Yep, though you can use any tools to draw or erase your mask, doesn't have to be a rectangle if you don't want it to be.