I'm still no fan of the wait object, if it is used just to be able to place a dozen of actions in one event. It makes the event sheet very unflexible.

But hey, it works.

The result is a fully functional editor that helps making seamless tiles. I like it.

One proposal: Why not letting the user decide where to save the generated png? Just using the CommonDialog to get a valid path shouldn't be hard to implement.

But, again, nice work! I like it.

The cap below shows just one way of doing it.

And never use 1 huge texture to form your game world. Compose it out of several tb, sprites, etc.

For example, in a real game, I wouldn't use just one tb for the map's surface, but use several sprites for the houses, streets, trees, whatever and apply the same technique as shown in this example.

But before you go on, make sure you are familiar with all the basics of CC. Use a tutorial that comes close to your game idea, consult the wiki, try some behaviors.

Good luck :)

mediafire.com/file/42yo52x2d14tzt1/scrolltiledbackground.cap

Alright, but just so we're clear on the effect I want to get, "I like to be sure". Objects outside of light will not just be darker, but a whole different color. Silhouette. The reason this is so important, is because a creture in the dark could have a darker body, but white eyes that show clearly. I probably should have mentioned that earlier. :P

Either way thanks for being so helpful.

That is exactly what Color Fusion (Masked) was made for. You select whatever color/darkness you like for the parts that are not lit. The lighting is realized with objects on a layer that are used to cut holes in the non-lit color, giving the impression of lighting that area. For the wolves example you would create a seperate object with just the shape of his eyes and place them on the mask layer and move them together with the wolf. His eyes would show as you created them (or even mix-colored with the eyes on the mask layer), but the rest of the body tinted with the non-lit color.

There might be other methods to achieve this, Color Fusion (Masked) just makes it easier to achieve. So wait for others to show other ways, maybe there is one that serves your purposes better.

And start small, then experiment and learn by doing :)

If you just have one light source, have a look at the ghostshooter tutorial, that explains how to do such an effect without using too much gpu load.

If you will have several light sources with different behaviours, movements, rotations, animations, colors and the like, then Color Fusion (Masked) fits perfect.

Nice idea.

Hope you develop it to a point where direct saving of the new tile is supported. Maybe even importing own textures, resizing, applying image operations and the like.

(Dreams of bumpmapping baked into the generated tile, and a library function to manage the tiles)

<img src="smileys/smiley4.gif" border="0" align="middle" />

HiYouNamedMatt :D

depending on what exactly it has to do, Color Fusion (Masked) could be of help. It is an effect, have a look at the description and download link here:

http://www.scirra.com/forum/effect-color-fusion-masked_topic41460.html

EDIT: Strange, the link gives me an error although correct. Try copying this:

scirra.com/forum/effect-color-fusion-masked_topic41460.html

Using different files per group will also help increasing stability. With some efford when trying to read in the data you can manage for your engine to be able to work even if 1 or more of the files are corrupted.

With only one file all is gone if the file is corrupted.

I want them to be able to edit the file. My goal is to make an engine that can be fully edited by the end user even if they don't have Construct or any desire to learn it, so as far as I can tell using .ini's seems to be the path of least resistance to that goal.his is also a statement for multi-file-management. I think the users of your engine will have more fun editing if they don't have to look through one huge file and saving the content of it, everytime they just work on one tiny change.

Just look again at my example. In the case of a sprite, you always know the distance, it simply is the width of the sprite. You often know the distance without knowing the coordinate ;)

With a more concrete example to the issue, I could give a more concrete answer.

In general, any y can be calculated from the distance between the anchor point to the new point and the angle between them.

If in the example image above red is the anchor point and green the one to be calculated, then

green.y = sin(anglebetweenredandgreen) * distancebetweenredandgreen

If we talk about a rotated sprite whose width is shrinking and whose pivot point is red, then

green.y = sin(sprite.angle) * sprite.width

Unless I misunderstood, it simply is

distance(red.X, red.Y, green.X, green.Y)

I really would think about making your own camera system, if it isn't too much you want to integrate (following the player even delayed, shaking a bit, rotating, that is done in minutes; it would be grid scrolling or following more than one player sprite, and the finer details of magicam that would cause headache)

But, if you need to use magicam, I would only come up with this idea:

Place all events related to fullscreen/perfect pixel zooming/black bars/etc into a function and call that function delayed (at least by one tick; just calculate time from fps).

It's just an idea, don't know if it would work, would have to test it also.

You mean something like that?

http://www.mediafire.com/file/1lmfgk4sfqpuhj7/rotatingsprites.cap

(Was too lazy to do ccw and omitted the array, which is a simple task to add now)