Okay, this one's a bit unusual.

Long story short, .werkkzeug3 TE is a free procedural texture editor. There's no use in it being procedural, since you'll need to export the images to .BMP and such (the library that allows loading of it's internal format costs 16000 euros, I think...), but still, it's free, it has unusual interface some people might like, and it comes with a bunch of very impressive presets to get you started.

Basically, it's a texture-oriented fragment of a full .werkkzeug3, that is sadly not available to the public. .werkkzeug3 was used to create the famous .kkrieger

You'll need to fill a form to download .werkkzeug3 TE, but there's no validation involved (not even a confirmation email, IIRC), so you can enter some rubbish if you don't want to give them your personal information for some reason.

Almost every game needs graphics, and not everyone can afford Photoshop or Corel. Let's make a list of free image editing tools.

I'll kick things off with a less known one, Artweaver. It is basically a freeware clone of Photoshop 6. It's shortcuts aren't particularly well thought out, and I don't think it's well suited for pixelart, but apart from that it's quite good.

Here's another one: http://mayang.com/textures/, 20 files per 24 hours.

Hi everyone.

I have several large background objects I keep locked, but sometimes I need to make small adjustments to one of them. I need to unlock all of them, re-lock all I don't want to change, and then change the single one i need.

It would be great to have an "Unlock selected" option in the object context menu, so that I could select the needed object(s) from the object list and unlock just those objects.

It is hopefully easy to implement and it would save a lot of time in large projects with complex layouts.

Hi, everyone.

I decided to make a thread about "features" that are useful, or simply cool, but that are either difficult to implement (to the point of rewriting Construct from scratch to make them possible), or simply have very low priority until Construct 1.0 is out. Features that only a few people would benefit from can also go here, I guess.

To get things going, here's a couple ideas I came up with.

Feature-based programming

Okay, proper explanation of this would take a while to write, and an even longer while for anyone to read. The idea is that we have packages like "Double jumping", "Swimming" and so on. Similar to behaviors, but affecting more than one object, or modifying other events, or in some other way outside of what behaviors can do.

Tiled picture plugin

(This is somewhat different from the plugin for tileset support that is currently in the works.)

Remember old consoles that had all the graphics sliced up into 8x8 parts and basically shown as a mosaic? This can be done with a pixel shader using only two textures (a tile atlas and a tile index matrix). This way the whole level (all the platforms, walls, or whatever you have there) can be drawn as one batch. Also it can help with collision detection (say, use the tile index matrix as a collision mask).

Assembler compiler

So you want to have some complex math in your game, but can't write another plugin just for that? Have no fear, Assembler object will help you! Just write your function in, say, L.in.oleum, and Construct will compile it for you. Linoleum is fast, so you can make all kinds of fancy staff without fear of slowdown. Well, the slight problem is that assembler is damned tough to learn, but Linoleum seems way more readable and understandable then regular assembler.

Translate games to ZGameEditor

Okay, some of you might know that there's a tool called ZGameEditor that can be used to make games that are less then 100k in size. Procedural generation and all that. Well, it cannot rival full version of .werkkzeug (as in, you can't make another .kkrieger with it), but it's free and open-source. However, when I tried it, I found it quite hard to use. What if it is possible to translate Construct games (or at least a limited subset thereof) from .cap format to the format ZGameEditor uses? Use user-friendly Construct to make them, and computer-friendly ZGameEditor to cram them into the smallest size possible and make them run faster (I think that ZGameEditor uses some kind of assembler voodoo magic to make the games run fast).

Like BenH said, it's very impressive. However, I don't quite like the way tank's body 'vibrates' when you shoot. I don't think it's meant to do it. Also, the recoil is way too strong. Another thing that can be improved - there are gaps in the threads when the tank is over any sharp 'spike' in the terrain:

<img src="http://img33.picoodle.com/img/img33/3/1/14/f_TankThreadEm_f00099b.png">

This is probably you have thread segment sprites look that like this:

<img src="http://img26.picoodle.com/img/img26/3/1/14/f_ThreadSegmem_4c42eb3.png">

You can try using differently shaped segments:

<img src="http://img19.picoodle.com/img/img19/3/1/14/f_ThreadSegmem_f59930a.png">

Other segments will cover those rounded ends, but in situations like that red 1 on the picture there won't be a hole in the thread.

I have no idea how to help with the problem number 2. Anyway, it's a lot less noticeable than #1.

I don't know where this belongs, so I'm posting it here.

You see, I wanted to find some info about the Layout object, and apparently there is none in the wiki, so I tried to search the forum, and that's what I've got^

[quote:3ogz36nt]The following words in your search query were ignored because they are too common words: layout object.

You must specify at least one word to search for. Each word must consist of at least 3 characters and must not contain more than 14 characters excluding wildcards.

Guys, that's just plain mean.

After some thinking I've arrived at the idea that the hypothetical camera behavior we're discussing can (and possibly should) be fairly minimal. You see, there's a lot of contrived situations, and it's a good idea to minimally restrict the user. So here's what I suggest.

Add a 'Camera' behavior (and possibly ditch the 'Center view on me' attribute, I'm not sure there'll be a use for it with this Camera behavior) and a 'Camera boundary' attribute. Objects with Camera behavior won't be able to pass through Camera boundary objects (those are effectively camera-specific solids). Give the Camera behavior a bunch of parameters:

• Rotate camera - equivalent to the event Always set display angle to Self.Angle
• Scale camera - similar, only links zoom to object's size
• Make 1:1 - on layout start makes the view show only the area covered by the sprite. Probably redundant, but it eliminates the need to change both the camera object size and the initial zoom factor when you decide to change the size of the viewport during development. Likewise, eliminates the need to change the initial zoom factor when you decide to change the window's size.
• Create default boundaries - on object creation creates four rectangular objects with the 'Camera boundary' attribute framing the layout, so that the user doesn't have to do it manually.
• Invisible on start - on by default (I see no reason to leave this object visible, but someone might want to...). Sprite object already was this in 'Appearance' , but it might be a good idea to duplicate it in the Camera behavior, so that all relevant things are grouped in one section. However, that could probably cause untold problems with resolving two identical properties. By the way, why don't, say, Tiled Background objects have this property? Also, why there's a way to edit the image associated with a Tiled Background object (Properties/Properties/Image), but no way to do the same with a Sprite object?

This will hopefully take care of the basic things. Now about 'Pan to object' and 'Follow object' Deadeye mentioned. Those should probably be separate behaviors, or one behavior with a lot of parameters. So that the object has 'Camera' behavior to actually control the viewport, and another behavior to follow the character or whatever object is 'in focus' right now. After all, there seems to be no 'Chase another object' behaviors right now, and having one would be very useful. There's a lot of useful features that can be crammed into such behavior, I'm not ready to say anything useful about it right now.

Why bother and split it into two behaviors? Well, 'Chase' behavior is useful on its own, and besides there are always times when canned behavior doesn't cut it, and user will want to have a different way of moving the camera - using events and/or other behaviors.

Now about tilting, wobbling and shaking. Well, there already are some utility behaviors for that, but I have a different idea. What if someone wants to use Sine behavior, only applied to object's angle, not it's position? Or a cycloid instead of a sine wave?

A while ago I tinkered a bit with Ogre3D (and in the end decided that it's way to early for me to dig into full-blown C++ programming and 3D), and stumbled upon a great feature: controllers.

The basic idea is that you attach a function to a variable, so that the variable changes on its own without the need to explicitly change it's value each step (or, in Construct's case, no need to clutter event sheets with technical calculations). So a controller has a value it changes, probably some values it takes as input (TimeDelta is the first that comes to mind), and a function that calculates the new value based on the input values (and possibly the old value). The function can be programmed to be anything, of course.

I have no idea if it's at all possible to implement it in Construct, but that would be a very cool feature. Anyway, it can be emulated with events, but not all that easily. The way I'm seeing controllers, they attach to the specific variables of the specific objects, so when you try to simulate them with events you need to pick the exact object you need.

So all in all there'll be up to three different aspects to implement a good camera: Camera behaviour to attach the camera to the object, Chase behavior to make this object follow the player, and some controllers to shake this object (and the camera with it), if it is needed.

There are two things I haven't thought about: multiple cameras (Imagine that we want to have different boundaries for each camera in the layout. A single 'camera boundary' attribute is insufficient for that. Now if it stored an object ID...) and camera-specific effects. That is, effects that 'live' in the local coordinate space of the camera, and not in the global coordinate space of the layout. Say, horizontal waves on the screen representing dizziness. Now those should stay horizontal (respective to the camera) no matter how the camera is rotated. UI overlays also fall in the same category. So, there's the need to rotate some of the layers together with the camera objects. Now that I think of it, controllers could help with that, linking the required layers' angles to the camera object's angle via the trivial 'output=input' function. That might be a bit counterintuitive, however...

The workaround you suggest is great, especially if you use a separate invisible rectangular 'camera' object (with 'Always scroll to object' event), since it will give the extra convenience of generating events on collision between this object and 'borders'. This way there'll be no need to make the borders solid, or otherwise make them interact with something - they will only interact with the camera object. It will also solve that 'scroll first and zoom later' issue, since you can change the size of camera object's rectangle. This setup can facilitate such complicated scenarios as "don't scroll outside of layout's bounds, except for the screen shake effect". Or even restrict the camera to some complexly shaped area in the layout. Or make the camera move 'on rails'. Not to mention that I always ended up using this 'camera' object anyway - every time I wanted non-trivial camera behavior, i.e. scroll a bit more in the direction the character is looking in.

The only problem with it is that you need to manually reproduce it in every game. One could move all the necessary objects and events to a template, but what if there is need to use another template?

All in all, what do you think that about adding a special Camera object? Or, better yet, it could be implemented as a Camera behavior and replace (or simply add to) the 'center view on me' attribute. This way, it can be implemented via the SDK by someone else (like myself), so that you can stay focused on more important things.

You know, the more I think about bounded scrolling... rotating and zooming seem to be implemented with unbounded scrolling in mind (Ashley, please correct me if I'm wrong, after all, chances are it's your mind I'm talking about ).

It is, of course, possible to circumvent those limitations of zooming and rotating I mentioned by enabling unbounded scrolling and manually create events that will keep it in check. However, it somewhat beats the purpose of bounded scrolling's existence, since it's purpose, as I see it, is mainly convenience.

Well, it's really up to you - whether to leave it as it is and therefore provide a simple sensible behavior that has to be manually reproduced when the user needs to make small modifications to it, or to spend more of the valuable time to make it more fool-proof. After all, fool-proofing is a fairly thankless job, since there's always some contrived situation you didn't think about (I can name one right off the top of my mind).

There are various levels of 'foolproofness', however, and I still think it might be a good idea to change the way System/Set Zoom action works, so that it can work better with bounded scrolling.

I was hoping the Layout object (which can display a different but not the same layout) could be upgraded to do this soon.

Okay, I gather that's a bit too serious for me right now, so I'd rather not mess with it, and leave it to the professionals.

As far as I know, zoom works relative to the scrolled position, so at any zoom level with unbounded scrolling, the object you are scrolling to should always be in the centre. Maybe there's a bug stopping that from working normally. Upload a .cap perhaps?

Everything is fine with unbounded scrolling, as far as I can tell. I messed the explanation with that double negative, sorry. "Disable unbounded scrolling". Ouch.

The deal is that when the scrolling is bounded, Construct apparently first resolves those bounds and then zooms. So, for example, if you have a layout that is just exactly as big as the screen, but you still set up all what's needed for scrolling. Zooming in won't enable scrolling like you'd expect (or, rather, like I expected), since it first scrolls to the needed point (in this case it stays in place, since the scrolling is set to bounded, and there's nowhere to scroll to), and then zooms - to the center of the layout, not to the object with 'center view on me' property.

It might be better to apply zoom first (so it changes camera viewport size before scrolling), and then scroll to the desired object. Hope this makes sense, I suck at explanations...

By the way, what do you think about that 180 degrees quirk? This one:

It's particularly interesting to set the display angle to 180 - sometimes it will work properly (everything is drawn upside-down), and sometimes not (switching back and forth between normal and upside-down as you jump).

Maybe it happens because of rounding errors? Those can be hard to fix...

Well, I've just logged in the wiki using my SF username. Probably that's the missing step - I dunno, creates preferences page, database record or whatever. Hope that did it, since I can't think of anything else.