This will work of course, but its hiding an issue, not fixing it.

Overlapping means one object is on top of another. For some reason, when 2 objects are perfectly side by side (such as in a grid), the overlapping condition is true.

I am using the default calculated bounding box for a 32 x 32 sprite, which contains 0's and 32's in the coordinates. I don't expect a 32 x 32 sprite at 0,0 to be overlapping a 32 x 32 sprite at 32,0

I tried the awesomium export today, nice to see it working. I have to say, I laughed when I saw that the scripts were moved to the bottom of the page for faster loading (somewhat of a micro-optimisation) but then the whole of jQuery is included just to resize a few things... Perhaps you guys want to consider dropping the jQuery dependency.

Have you tried anything else without success? Doesn't chromium embedded do this? I thought it had WebGL support also. I'm asking because it would be nice to have a wrapper that is only limited to the license conditions of the LGPL. And it works on mac and linux.

ou wouldn't use crop mode for that - you'd either turn the browser fullscreen option off entirely (so the canvas is just centered in the page), or use a scale mode, possibly with letterbox.

Yes, if that's all you were doing then I agree with you, but I think you missed the point. I am suggesting that the crop mode with frame clipping works in all environments, from the small scale up to the large.

enerally you should not use crop mode on mobile. Consider the iPad 2 and iPad 3, both which have the same size physical screen but one is double the resolution of the other. Using crop mode all your sprites will appear half as big on the iPad 3, and show twice as much of the layout, which is probably unwanted.

I'd have to disagree. Common practice in the mobile dev world is to not upscale images but to hand-produce various versions of the images at different resolutions. Upscaling the level so that its an integer multiple is good but its not the same thing as producing multiple versions and cropping the window to fit. This multiple versions approach obviously yields a maximum and minimum resolution. While its probably safe to assume that the lower limit is sensible, I don't think that its right to assume an upper limit. Given that this is a no-scale option, you would just want the frame to center itself in the window. Clipping around the frame provides a one size fits all solution.

The point about wrapping, that is a fair point I guess, but isn't it just that? It's wrapping the frame. Its rendering contents that are inside the frame, you have just wrapped it around. That doesn't mean you are rendering contents outside the frame, you are rendering contents inside a virtual frame.

I can see the point in wanting to be able to control the entire canvas. I don't understand why you have chosen to call it "crop" mode.

Is this not reason enough to expect an update on it?

Why should crop mode limit the view to the size of the layout?

Well ok I should probably make myself more clear. No view mode should render outside the layout in my opinion. Give me a good example of where anybody would want to render outside the frame, and I might reconsider asking for an option to turn it on/off.

You know we have to support a whole ton of screen sizes, but what

happens when I want to render say, a max 640 x 480 area on 1920 x 1080

screen. I start to see everything that lives outside the frame, which

is not desired in any case. So first of all, crop mode is not fit for

purpose in this case. However, when I play on a 320 x 480 mobile

device, the crop behaviour works perfectly.

If you can't understand why I don't just upscale, you clearly never worked with a pixel artist.

All I am saying is that expanding beyond the limit of the frame isn't

useful to anyone and it makes sense to clip to the frame size, because

displays can be larger than the frame.

Moreover, assuming it were useful to render outside the frame, the behaviour of objects outside the frame area is inconsistent with objects in side the frame area. Suppose I have a single sprite that is scrolling to the right. If I move the sprite down too far outside the frame it stops scrolling. Its still rendered. I'm rendering inactive objects.

I just don't expect anything to render outside the frame ever. This area is where visually bad stuff can happen. That's the whole point of the frame is it not? You can also be more efficient with rendering by doing this (assuming construct applies any sort of basic spatial querying).

The notion of "crop mode" is still valid if you don't render contents outside the frame.

Who wants to rely on a screen size being smaller than some arbitrary

size? I'd rather not rely on the screen size being smaller than the

frame, but I want the crop behaviour on screens which are smaller than

the frame size. I can't imagine anybody wanting the current behaviour.

So I can dynamically resize the window based on the browser width/height? Yeah sure I can do that, but it's not really the point though. I don't have a logical explanation for the expansion beyond the frame size. Who would possibly want this? That's the question.

Or rather I should say, sure keep the canvas at full screen in the browser (which makes sense), just don't render outside the bounds of the current frame. Align vertical/horizontal centre when the frame is smaller than the size of the canvas.

Well, the difference is that the view expands but not beyond the frame boundaries. Why would I want it to expand beyond the frame boundaries? If I turn off full screen there is no expansion at all.

I've just read through the manual to understand what the different fullscreen modes do. I am just a little bemused at the behaviour of "On (crop mode)". I get that it increases the view of game instead of scaling. What I don't get is why it expands beyond the bounds of the layout. I see no reason to even bother with a layout size in this instance where I can render objects outside the layout. My expectation was that it would clip around the layout based on the specified size (so things outside the level aren't visible). Is this a bug?

Need I reply to that? -_- the shame.

I guess while I'm at it, can I set the image point using typed in numbers?

I've tried construct for the first time. Took a little while to familiarise myself with it. Came up with this

http://dl.dropbox.com/u/17781372/imagepoint.capx

I noticed that the bullets are spawning randomly at either image point 1 or the image hotspot. I tested in r91 beta with the same issue. I'm running the 64bit version in windows 7

Please correct me if I've done something stupid. My intention was for the bullets to spawn at point 1.