The crash might be a bug that needs fixing, but your (1-Global('g') is wrong.

+Player collides with sprite
   -Set g to (0 minus g)
   -Set force of gravity to g
[/code:1c9dxf6b]

This will toggle back and forth between 20 and -20.

<img src="http://i38.tinypic.com/311s65k.png">

~ OR ~

<img src="http://i36.tinypic.com/23hpurt.png">

You can zoom a layer's x and y separately by a percentage.

I just tested it out on one of my projects and it works just fine. I also have a widescreen monitor, but the stretching is usually very minimal and not really noticeable in most games. The game I'm making though has a ball as the player object, so you can see that it's slightly oblong in fullscreen. Changing just the X zoom ratio to 80ish percent fixed it.

[quote:11v3ogku]My only suggestion is that maybe you should make the window 800x600, A LOT of people use their desktop resolution at 1024x768, so that would make the game more accessible in that sense.

Did you see that, Sol? I didn't even have to pay Kr!s to say that

(@Kr!s... I've been telling him this forever)

Some of these things are issues that are being dealt with, some are bugs, and some are things that will probably never be implemented in the default behavior so you'll just have to code your own method.

Ashley has mentioned the possibility of changing the push-up routine of the platform object so that it pushes out of solids in the direction it went in instead of always defaulting to up.

As for the window dragging, it's a bug. I believe I reported it a while back, but that might have been for the sound object messing up when dragging the window.

I've never had much success with vertical moving platforms. I've always had the jittering effect you described. But... the last time I tried making a vertical platform was before the introduction of adjustable gravity settings at runtime and the ability to set the velocity of the platforming character manually.

The method I've been thinking of (but haven't actually gotten around to trying yet) goes like this:

1. Measure the distance from your platform sprite's hotspot to the bottom edge of the sprite in pixels.

2. For your vertical platforms, make an image point exactly that number of pixels above the top edge of the platform.

3. Make a foot detector for your platforming sprite.

4. When the foot detector is overlapping the vertical platform (and the character isn't jumping) do the following:

• Turn gravity off for the platform object.
• Turn Ignoring Input on for the platform object.
• Set the platform object's xy to (self.x, (platform.ImagePointY(1))
• Manually intercept the controls for Left, Right, and Jump
• If Left or Right is pressed, manually set the horizontal speed accordingly

5. If Jump is pressed, or if the detector is no longer in contact with the platform, turn gravity back on and Ignoring Input to off.

It might need a little tweaking, but I think it could work. Possibly. Theoretically with no gravity to fight against the jitter will be eliminated.

As for intersecting the sides of horizontal moving platforms, you'll have to code your own push-out routine to avoid being popped to the top automatically by the platform behavior. At least, until the new push-out method is done.

Finally, as for your question about whether or not Construct can be used in a production type scenario for a platform game. I'm assuming you mean "can you currently make and release a bug-free game of commercial quality." Well, probably not. Construct is still in beta. Either you can wait for v1.0 or you can help out with bug testing and wait for v1.0.

It is however quite capable of making playable games, if not perfect ones. You just need to be aware that things will probably be a little buggy for a while.

lol damn im stupid. Fine be that way Deadeye

I was just playing with you man, it's all good

WTF O.o

Bwaahahahaa!

Anyway, yeah that guy really is a jackass.

An excellent review, Sol. You make some really good points. I didn't realize that the game held such deep meaning for you as an independent game developer, but I can really see where you're coming from.

deadeye

Yeah lol, nobody drinks that crap here. IRONY! Fosters wins at it.

Heads up: Nobody drinks that crap anywhere.

We do, however, wash our hair with

)

Am I right in saying that this only happens on the boundary between Tiled Background and Sprites (or other objects)? It doesn't look like the tiled background is breaking up inside of itself, just the borders. I will try and fix this ASAP.

Not just at the boundary between sprites and bg tiles, no... the edges of the bg tile objects themselves are just where the problem is most visible. If you have a bg tile all on it's own you might notice that it's sort of shifting around inside it's bounding box by about 1px. At least, I have.

In the .caps I posted with the bug report (the ones that no longer work), the tiles were much smaller and you could see the entire tile shifting up and down (or left and right) much easier. It's like it can't render sub-pixel increments the same way as sprites or something so it's moving the contents to the next whole pixel. I think. I'm not super techy but that's what it appears to be doing to me.

Edit:

Hehe, conflicting reports itt... We've just teamed up to confuse the hell out of you Ash

Im semi-dee-dee-dee

Aw geez, did you just quote Carlos Mencia? That's it, I'm never helping you again

Heh, jk

What, no Fosters? But it's Australian for beer

Fosters, what a joke