In my opinion, you should take advantage of layer zooms. Build your game around a certain resolution and aspect, and then zoom your layouts using that as a base.

In pseudo code:

OriginalX == 640
OriginalY == 480
CurrentX == ?
CurrentY == ?
Set X Zoom factor to:
   (CurrentX * 100) / OriginalX
Set Y Zoom factor to:
   (CurrentY * 100) / OriginalY[/code:179ejxv1]

This is a simple ratio thing I learned in high school.  It produces a percentage of scale (with OriginalXY being 100%) that will always correctly scale your layers to any resolution in the same aspect ratio.

EDIT:  I should point out if you plan on letting your game scale to high resolutions, you should create all your graphics at as high a resolution as possible and scale them down in Construct.  Thus, when you zoom your layers you do not encounter blurry sprites and backgrounds.

Are you talking generic screen shots with Print Screen, or a frame buffer type application within your project?

I've had several unsuccessful attempts at doing this with the Canvas Object. Perhaps someone could fill us in?

Well, what you're doing is fine, but it comes off wrong. Instead of making a challenge to the community (which IS here to offer solutions and workarounds), make an request directly for a change or addition. I can't speak for the others, but to me the way you've been making points about construct comes off as more combative than constructive (forgive the pun).

If you can do this, not only will we all get along better but we might get things done more efficiently. Got a bug report? Supply a small .cap to display it. Have a feature request? Keep it to a couple of clean paragraphs and encourage further discussion. These things help you help us help Rich and Ashley.

I'll start by apologizing for my bit of snideness earlier. I should have stuck to trying to help out instead of complaining.

Please review the end of this thread:

That may help get you started. If after that you have any further questions, please ask.

I believe I see better what you mean now. But I ask you, what is it that you have accomplished that Construct does not already do through layouts? If anything, you are adding an extra couple of steps to achieve what is, in your mind, a better means of organization.

Which is fine, don't get me wrong.

Now if we were to remove your starting "flow" checks (a global variable dictating what code to use), we're back to square one. Expanding your flow events out reveals that you are doing no different than the rest of us as far as picking objects via their criteria. In this I will admit you have not limited the scope of the program - if you will also admit you have added nothing but an organizational element to your event sheet.

It's 0400 my time, and I am about to pass out. I will give your .cap a more in-depth look in the morning to see if I can help you with the mouse and behavior stuff. In the mean time I suggest you play around with the Ball Behavior's "Set Activated" function.

To be continued...

You know, I more than figured this was j0h posting again.. But just in case we had a new person trying to learn construct, here I went taking the post seriously and actually trying to help. Shows what happens when I try to be a good little forum-goer.

TheInstance

I get an error opening your file.

Please forgive me if I've misunderstood, but let me make an attempt to explain this.

In accordance with the example provided, it appears as though you want Construct to decide which actions are appropriate in a given situation. You have a setup where two values are used to determine which action is to be taken, provided one or the other is true at the time. If VALUE_1 is true, you want to make the Sprite move 10 pixels left or right when the appropriate arrow is pressed. If VALUE_2 is true, you want those controls reversed (left arrow moves right, and vice-versa).

The problem you're claiming to be Construct's design flaw is in reality much simpler. As soon as you set both values true, which you indeed do at application start, you've created your own paradox. Now, one press of the arrow moves your sprite 10 pixels in that direction, and 10 pixels in the opposite direction, with a net gain of zero. The Sprite does not appear to move because this all happens in one frame.

This is not so much a factor of learning curve so much as it is just realizing for the first time you have to be mindful of how you set up your events. In this case, if you're using two separate variables to determine which method of control to use, you have to make sure that the two cannot both be true. You need to have a system of telling Construct which event should be true at what time. Construct itself, nor any other programming platform, can ever determine how to handle this situation without further input from you or the user.

--

To address your first issue... "Sprite" is no more than a default name for that object. It is suggested at the creation of every object that you name it yourself. This can be done by clicking on the new object and going to the Common Properties panel (by default on the left of your screen), and changing the object's name at the top. This change is in fact reflected in the Event Editor, even retroactively (meaning you do not have to also rewrite events when you change an object name).

[ASHLEY: Perhaps a "Please name this object" dialog box at the creation of certain objects is a good idea?]

About starting events with what you call "flow events." In short time you will realize how limiting that will be. Please consider playing with one of the tutorials available on the site to get a feel of how eventing works. In general, it works like this:

IF (this),
AND IF (this),
Then do something.[/code:2lame8jn]

The reason you cannot limit starting events with "flow events" is something you've already pointed out.  It [i]does[/i] limit what can be done with the program.  Allow me to explain.

We have the same road you wish to drive on.  We have cars on the road and some stop lights.  We must tell the drivers of those cars what to do when they encounter a stop light.  The easy thing to do would be:

[code:2lame8jn]IF Car is near Stop Light,
AND IF Stop Light is "Red,"
Then stop Car.[/code:2lame8jn]

However, we only have system events to help us here.  Unfortunately for us, this method of picking objects does not classify in your definition as a flow event.  The System Object, one of the flow objects you describe, can give us true or false comparisons between two variables to potentially work around this.  However that method is clunky, and our situation is better resolved by using "pick object events."

Does this mean you have to be careful about making a conflict to this Stop Light event?  Yes.  That's just part of the puzzle you have to overcome.

Regarding loops, I do not believe you're ready for them yet.  You correctly point out that they can be mirrored by standard events, but that is not the point.  Loops are designed to run in between ticks to perform actions that must be computed in advance.  I or any of the other people here can help you with those when you need to use one for the first time.

--

I hope this has helped you understand the process a little better.  Just keep practicing with the event sheets, and be mindful that Construct cannot read your mind to know what it needs to do and when.  You just have to take that extra step or two to let it know what you are thinking.

<img src="http://www.strouperman.com/Special/screen/Worldlike_DX9_runtime-05.09.2008-02.11.39AM.jpg">

It's a rough sketch, but I wanted to see what it'd look like with a sphere graphic applied as a lens.

Ashley

You're right, and I'm a terribly picky audiophile myself. My complaint had nothing to do with their product, but more of their straw-that-broke-the-camel's-back actions against one of their community leaders who had been modding back in features Creative was purposefully removing from its driver sets for lower-end cards or cards not made for Vista. I thought that was a terrible shot in the foot, and I'll consider alternatives when purchasing audio boards.

Great. Now I've gone from saving the topic to derailing it again.

Oh of course the math would work better/faster than defining the collision by the sprite. It would also allow you to vary the amount of damage based on distance, among other things.

The circle object itself would be 90% a visual thing. Consider a selection window, or the actual animation for an explosion - which my way allows for. It CAN be used as the collision box for an action, but like you correctly observe it doesn't have to be.

I know how you feel, man, and it's hard to not become jaded when you're faced with the worst of it day in and out. Just remember feelings are just feelings, and you should set them aside on occasion to give to new things a worthy try lest ye be relegated to the abyss of outdatedness and longing.

But Creative Labs is my exception to that rule. Call me hypocritical, but there's a difference between making terrible software and actually SCUTTLING it post-sale.