First of all:

Look at the xml file associated with the effect

	<!-- Parameters -->
	<parameters>
		<param>
			<name>Radius</name>
			<description>Magnitude of the radial blur.</description>
			<type>percent</type>
			<initial>0.4</initial>
			<uniform>radius</uniform>
		</param>
		<param>
			<name>Intensity</name>
			<description>Intensity level, from 0 to 100.</description>
			<type>percent</type>
			<initial>1</initial>
			<uniform>intensity</uniform>
		</param>
	</parameters>[/code:1gma6wz9]

I'm sure you could figure out how to add a new param to this, you're going to need 2. one for x offset, one for y offset.

notice that the two things in the two files have the same name: lowercase "intensity"
<uniform>intensity</uniform>
uniform float intensity;

theres a similar comparison you can make with the uniform for radius. Just from the fact these are the things you can change in construct im sure you have an understanding of what a uniform probably is: a value you can pass into the shader to control it with.

im sure you can figure out how the writing in the xml relates to the declaration of the variable uniform float intensity.

so now you're able to get two new values to your shader.

Inspect the code more carefully within the the "main" function and see how things inter-relate.

theres a bunch of stuff which you don't need to concern yourself with, in fact i haven't written any GLSL shaders so i don't know whats going on all that much either, but if you look at the code you have "dir" which probably means direction, and as you've easily deduced in the top 4 lines theres something that likely determines the position of the center.

I haven't tried this but just looking at those 4 lines, theres a 2D vector called dir, which is set from " 0.5 - vTex " 0.5 is one half, the center of a screen is halfway in both the x and y directions, i don't know glsl but i can tell this has a result which is a 2d vector by the next line that says dist = sqrt(dir.x*dir.x + dir.y*dir.y). dist is some distance obviously because of A the name, and B the fact that the expression is the square root of two positions squared, which is the formula for euclidean distance/ Pythagorean theorem. notice that dir has a component dir.x and dir.y soooooo, the above line probably means

vec2 dir = 0.5 - vTex
which is equivalent to
dir.x = 0.5 - vTex.x
dir.y = 0.5 - vTex.y

if you made two uniforms offsetx and offsety, you could probably replace the first line with the following

vec2 dir = 0.5 - vTex --> replace with stuff below

vec2 dir;
dir.x = vTex.x + offsetx;
dir.y = vTex.y + offsety;

and then in construct you set the values to something between 0 and 1 to select a fractional position between the top left (0)(0) and bottom right (1)(1). this is all you really need.

im sure if you modified effect code and added/multiplied uniforms to/with existing expressions to test what they did you could find all this out on your own. Combine that with google searching terms you don't quite understand (for example vec2 if you didn't know what it meant) and the fact that you already have an intuitive grasp of what things do, and im sure you could have figured this all out on your own.

it wont take you months, look at the GLSL code for the effects you're looking at, add 2 parameters, and add an offset by adding the value of those parameters to whatever is choosing the blur position, voila you're done. If you can code in construct you can do this

I feel like C2 is currently lacking a lot of features for plugin developers with regards to the edittime. I'm constantly trying to make my plugins more user friendly and simpler to interact with through the edittime, and continually hit roadblocks which prevent me from doing anything to that end because of the current lack of features implemented into the edittime sdk.

For these reasons i though we could all come together and suggest features which we would like to eventually see added to SDK, compiled into a neat wishlist. Hopefully scirra will see it and at least implement some of them so that we can extend construct more-so than we already are. I added some features i'd like to see and will edit the thread to summarize what people are posting. Please write the feature you'd like to see with a short description that will fit on one or two lines.

Edittime Wishlist

- "Object Type" properties

***The ability to set properties which are global to a specific type, rather than specific instance of that type

- Ability to detect mouse events and position in the layout editor

***for example to implement custom click to drag controls

- Ability to create custom windows for setting properties

***Object with many properties end up with a giant disorganized list in the current system, extra GUI control could go a long way

Your best bet is to learn to do it on you own. Hiring people is full of cons

a) costs a lot of money

b) doesn't guarantee good or even ok results

c) for small projects usually involves artists abandoning the project if they don't feel they're being paid enough.

The biggest downside in my opinion is that your game usually ends up looking like crap anyway if you hire people and you have no clue about how to make things look good on your own. This is somewhat remedied in AAA development by having a designer watch the work of programmers and suggest tasks for them, but you yourself admit to wanting to take control of the design so you need to learn how to make things look good yourself.

Making games usually requires a good vision of how things should move and animate and piece together. It's easy to tell when the programmer of a game has not put a lot of time or study into how things look, regardless of what the graphics applied to the objects moving around are. Games end up with a lack of atmosphere, lack of polish, lack of interesting movement and lack of interesting visual design. If you want to make good games you have no choice to get better at understanding how to make good looking visuals. Even games like Thomas was Alone or Geometry Wars which have "simple" graphics representing objects/players involve a lot of artistry in getting things to look good. Games with even more complicated graphics involve exponentially more knowledge about visuals and design to end up looking ok.

Construct already does this to some extent for sprites by recycling them, so i'm curious why the discrepancy in performance is so big, ideally it shouldn't be.

Come up with an idea you can build on incrementally, that doesn't require a huge upfront investment of your time. That way you can build on your project in a natural way that budgets your time properly rather than have to make a huge upfront investment of time with little promise of return.

As an example, telling yourself you're going to write your engine from the ground up gives you a mountain to climb before you can start doing anything, find ways to get past mountains by going around or through them rather than over them. Using construct in the first place is a big step in the right direction!

—

I believe the images load automatically if the name specified in the json file for the images matches the name of images in the directory. You need the images for the object to be in added to the files folder in the same way the model is. I tried it with a few models/images from three.js examples and got it to work, so i'm not sure whats causing the issue. Sending me a .capx would be helpful if you're doing everything i stated and its still not working.

— Alright thanks, you'll likely receive a pm or email with information soon. I'll see what i can do.

—

You should be able to import objects with their materials using the three.js json exporters and loading those filetypes.

https://github.com/mrdoob/three.js/tree ... /exporters

My goal is to try and support these files better for the time being, before supporting extra importing options.

—

You're going to have to pm me your paypal name / email address / or some proof i can use of your transaction. Theres no way i can find you otherwise.

I've finally gotten the bulk of the collision system complete. It took a while as i was trying to tweak it to be as efficient as possible (collisions quickly slow the system down without a proper culling phase due to the quadratic nature of testing every object with every object)

I used a 3D spatial partitioning scheme, similar to the 2D system construct uses, also using AABBs and spheres for the broad phase. Right now the system supports 3 collision primitives: bounding spheres, Axis aligned bounding boxes, and Oriented bound boxes. For now this is all there will be but i plan to add capsules, rays, points, and eventually if possible cylinders, ellipses, and cones, but these extra primitives probably wont be in the next update.

I'm now working on automated texture loading and a system for handling textures on objects using the animation system. I'm planning to make it so you'll be able to simply do everything in the image editor, and control the textures like you do sprite animations/frames.

After this i should have something which can be released, but there'll be future mini updates to extend the functionality. What took so much time for this update was that i had to completely reverse engineer and re-purpose construct code for collisions, which was a much bigger undertaking than i anticipated.

I've tried to make the object based plugin in the update as user friendly and efficient as possible. However, the SDK is pretty limited when it comes to the stuff i can do with the edit-time which is unfortunate. I wish Ashley would add more features to the edittime so that plugin devs could make little windows to set properties, because right now there are about 30 properties that are just stacked one above the other in a large list, other than this tho i'd like to think the plugin is straight forward to use.

It'll still be a while till it's out but this is my progress thus far.

Gah thats annoying, guess ill need to find some work around by parsing images to separate textures.

so far when i've tried that i've gotten seperate frames as seperate images, but i haven't used C2 extensively enough to know if there's some threshold or particular number/combination of frames/animations/framesizes that triggers it to start exporting sprite-sheets.

Anyone have any idea? It has to work for webgl mode specifically, as my plugin only works with webgl.