The engine is ready for you to start that amazing mirrored movement game. I expect no less than a screenshot as soon as it is worth taking one

I extended it a lot. Auto Zoom Engine should be flexible enough to go with the design ideas of you and your friend. Ever thought about a level, where not only one sprite mirrors the movement of the other, but one sprite only mirroring horizontal and one sprite only vertical movement of a third sprite? Well, if so, AZE will be with you

Try the demo and start doing your own cameras. Good luck and much fun

Just follow this link for downloading

AZE is a engine that provides automatic zooming and tracing of any number of spots. It is following the concept of cameras similar to the one used by the Advanced Camera object. Any one camera always assures to enclose all spots passed to it by zooming and positioning while never going beyond the layout's borders when completely zoomed out, as long as the aspect ratios of the display and the layout match. If they don't match and completely zoomed out, AZE compensates by aligning three sides to the display and only the left or the top side goes beyond the border. At least one spot is needed per cam.

Features:

• Unlimited number of cameras may be created/destroyed at any one time
• Unlimited number of spots may be passed to a camera
• spots may represent everything, a single point or a dozen of physics objects. Everything that can be represented by the four parameters X, Y, Width and Height
• spots may be of any size, even or uneven aspect ratio
• limit the maximum zoom to any number
• offset to focus not exactly centered between any number of spots

The two files differ. Auto Zoom Engine.cap is a cleaned and differently organized cap, while Auto Zoom Engine debug.cap is a documented demo. Both are fully documented on the engine itself.

[EDIT] Damn, I knew this would happen... Two things:

First, I forgot to mention anywhere in the documentation, that you have to set the layout AZE is working with to unbounded scrolling. (Layout Properties, tick "Unbounded scrolling"). This is done in the caps, but if you add new layouts you have to think of that.

Second, I was playing around with local AZE sprites when I created the two caps and didn't set it back to global. It is neccessary to set the sprite "AZE" to global (Sprite Properties, Common, tick Global) Please do so before adding new layouts or AZE refuses to work.

IWell, the breakthrough isn't the fact that its points instead of polys, its the fact that there isn't a limit to the detail. That hasn't ever been done with voxels. From what I understand voxels are slower than polys

Of course that has been done before. That's what CT scans, x-rays etc. do every day

The earlier voxel engines (like the first voxel space from 1997) were indeed slow. But that is more to the fact, that there weren't any hardware solutions. With the newer approach from id software a demo was presented running with stable 60 fps.

The trick is to use something called a sparse voxel octree. Every voxel is assinged 8 subvoxels, every of them again 8 subvoxels etc. That way you limit the process of searching for points to be displayed within a huge point cloud.

The real problem is the amout of raw data. Serious developers like id software don't ignore that. In fact, it is needed a technique to outsource that data to RAM and even to disc, because we are talking of an amount no PC in the next few years will have enough RAM for. That's not a problem if I only present a limited demo of a 20m forest without any characters (like unlimited detail did). But imagine a fps level with a few km, 20 detailed characters moving around, vehicles, etc...

Hmm, I don't see nothing new here, and much less a breakthrough. That technique is well known, the points of a point cloud are called voxels (short for: volumetric pixel), and the first game engine working with that concept was voxel space by NovaLogic starting in the late 90's. There are a few games out there working with voxel space, the best known probably Delta Force.

Today id software is thinking about doing a half voxel based engine following the very same principles for their next engine 6. Their trick is to just calculate static objects with the voxel technique while using conventional polygons for dynamic objects.

In medical science voxels are a standard since the early 70's.

Lighting is an issue, all voxel based engines need to use some form of baked lighting, although dynamic lighting adds so much to the gaming experience.

I saw a few videos from unlimited detail. Every other phrase is "Well, we haven't done that yet, but we know it's possible." Of course they know, people have already done it.

And

for those who followed me to the end (

)

Could someone please check it? I can't reach the wiki (error message: "group not found for name: construct")

The problem is the "crossfading" between the two cameras, while one is moving and the other is static but zoomed. This leads to different lerpings, I think. You can test this by creating a static cam at the last "main" position when switching to "zoomed" and later switch ti the newly created one instead of "main" this transition works perfectly. So maybe you should consider creating a intermediate static cam and fade from "zoomed" to "intermediate" to "main"? But there still might be a problem with transitioning from static to moving. But the zoom problem should be eliminated this way.

It seems to be an issue with setting the position of an object with the physics behavior. But it also seems to affect only the first object that has physics.

The solution is to create a dummy object with the physics behavior and make it the first object at edittime by sending it to the back.

Do this:

Create another sprite to be a dummy object. Give it the physics behavior. Set the physics collision mask to none, so legitimate physics objects won't collide with it. Right click on the object and send it to back.

Now that's important what you found out! It should be on the wiki, because almost everyone playing around with physics stumbled upon this one without a solution (at least I couldn't read on the forums other than "there are issues")...and it is so simple to solve. Great work ROJOhound!

I'm not very familiar with the Function object... so I tried my best to replace all of the global variables (except the 'lenPlayerArea' variable) with Function objects. Here is my result. Please scrutinize and correct me.

The function object is designed to hold more than one function call. You don't need more than one function object. I'll go over it, just give me a day or two. I'm currently thinking of extending it for you to have more control and flexibility. But no promises

Also, it's not really going to be co-op, I don't think. (My friend is the main designer.) The player will control both characters, but the controls will be mirrored for the character on the opposite side of the map.

Wow, that sounds even more interesting. Could serve for mind-breaking puzzles

That's crazy. There is nothing wrong with the cap. All events should work just fine, if the version of 's' is accurate (older versions don't work). I just loaded the cap again with Construct .62 and .84 and the newest version of 's', and it works like a charm.

Did you install manually? If so, maybe you replaced s in \plugins\ but not the runtime version under \plugins\runtime\ ?

...and it's like the angels crying

Download: raindemo.rar

Yes it is quite large, sounds are included for full experience. The archive contains not only the cap and the sounds but the executable also, to make sure you see and hear what I intended. I'm not sure how filepaths are handled, but I guess you need to re-import the sounds to the cap.

...and various s plug-in downloads from your plug-in thread, but no joy with getting the level editor work. ...

Did you try the most actual one?

http://dl.dropbox.com/u/1013446/s/sdebug/s.rar

from this post:

http://www.scirra.com/forum/viewtopic.php?f=2&t=4791&hilit=lucid%27s+plugin&start=77

Well, let's start with the good news:

Here is a cap working the way you want.

The bad news:

It's much more complicated. Of course the cap isn't optimized, but even then it needs a lot of expressions, because there is a lot you have to keep an eye on.

I try to explain from the beginning, but feel free to ask if I'm not clear enough.

(1)

Most important is understanding, that you will see parts outside of the layout's boundaries when completely zoomed out, if the aspect ratios of the layout and the display don't match.

Your layout is 1800x1200, that's an aspect ratio of 1.5 (or 3:2), but the display was 640x480, which is 1.333... (or 4:3). I can prevent seeing beyond the bounds when the cam displays less than the layout's height, but not if the cam displays the complete layout's width.

In short: If you use my solution and set the display to an aspect ratio of 1.5 (e.g. 720x480), you will indeed never see anything outside the layout's boundaries.

(2)

To get this working you need to take care of the horizontal and vertical aspects, but this needs to be splitted. That's why you will find so many globals like "lenPlayerW", "lenPlayerH", "zoomW", "zoomH", "lenCamW", "lenCamH" etc. This could be solved much more elegantly by using functions, but I was a bit too lazy

Basically, the expressions calculate a horizontal zoom and a vertical zoom and apply the one with the lowest value to the camera.

The position of the cam is set manually to be able to clamp the camera display to the layout's boundaries. This is very straight forward.

Both the zoom and the position of the camera are set using the lerp versions "Smooth Zoom" and "Move To Position". This is only in case you might want to have some lag in either of them. If so, just raise the milliseconds value of them both to your needs.

A cooperative game with one display? I'm curious about it. That could be very interesting. Hope to see some screens soon

EDIT: Forgot to say that you don't need the AdvancedCamera object for this solution. You might as well just use "System: Set zoom" and "System: Set scroll to x" resp. "System: Set scroll to y"