I've always though it would be a stupid idea but, I don't know why, it seems that in the cases where every concerned object is on screen and has collisions activated, picking the nearest object only before doing the collision check seems to work a little better than actual collisions check alone (at least it seems from what the debugger stated), so I wonder, wha tdo you think about it?

I don't have the error message by clicking on the link you gave.

This is what C2 does to alert people that run it in preview:

<script>
	// Issue a warning if trying to preview an exported project on disk.
	(function(){
		// Check for running exported on file protocol
		if (window.location.protocol.substr(0, 4) === "file")
		{
			alert("Exported games won't work until you upload them. (When running on the file:/// protocol, browsers block many features from working for security reasons.)");
		}
	})();
	</script>
[/code:9z9bazja]

However, that should not happen outside when uploaded and loaded from the public link.Can you confirm that the browser URL is the public link of the game?

I love you Fishy.

I've made a little mistake, I've corrected it now (I was doing + 180 instead of *(-1) so it didn't worked when behind the tower, I've updated the files that the links gives)

epicjelly

https://dl.dropboxusercontent.com/u/100 ... index.html like this sort of I guess (left and right arrows for a epic adventure!!).

capx (need license because of families): https://dl.dropboxusercontent.com/u/100 ... aring.capx

capx if you don't have a license (only has black blocks): https://dl.dropboxusercontent.com/u/100 ... amily.capx

just place the objects in the layout view on the tower, and set the boolean that says if it is in front of the tower or not, and have fun

I would say definitelly doable, the position of the objjects are basically angles tranfered to a X value, how to explain... Imagine having the relative angle of the tower you want, in °, put it inside a formula like Radius*cos(angle), and it will be placed, the Z-ordering is more a challenge, as for moving your character, it is just changing the view of the angle, moving the ennemies could be done via a linear interpolation between their angle and their two reference positions.

a little Chalenging mathematically but doable

"Yes I think it's just flat blocks but pushing the arrows buttons creates events that resize the blocks."

I do not see them changing size, only getting darker and hidden by the block in front of them

Event 224 of the event sheet 1:

You are using subevents, sub-events only occurs when the events above them are true, and of course, the variable action of the dog cannot be equal to both "left" and "right" at the same time

Also try not to use the "Else" condition for instances, since it does not pick the good instances in most cases

And also, I suggest you not to have too many opened layout and event sheets in the editor, my computer wasn't responding (my computer is bad but it is still one of the cause of regular crashing issue for some users)

> Here are the formulas:

> qarp(a, b, c, t) = lerp(lerp(a,b,t), lerp(b,c,t), t)

> cubic(a, b, c, d, t) = lerp(qarp(a,b,c,t), qarp(b,c,d,t), t)

> cosp(a, b, t) = (a+b+(a-b)*cos(t*180))/2

>

>

thanks R0J0hound

When I've use lerp to move sprites it seems to have built in "slow down" toward the end which is great. If I wanted this "slow down" at the beginning and the ending would I use qarp? (or your lerp(lerp(a,b,t), lerp(b,c,t), t)). I tried it when zooming out the layout and it doesn't seem to work like I expected...still feels like a regular old lerp.. since it starts zooming fast then gradually slows.

> Set Layout scale to lerp(lerp(LayoutScale,1,0.5*dt), lerp(1,4,0.5*dt), 0.5*dt)           
[/code:f8psydme]

a=LayoutScale (which starts at 1.3)
b=1
c=4 (wasn't sure how steep to make the curve)
t=0.5*dt

The "built in slowdown" comes from the use of lerp you are using, a is the variant in your case, so you have a "suite arithmétique" (not sure of the english term for that), that will go slower and slower towards the point. (it shouldn't even reach it, I never understood why people are using lerp like this)

To be exact, lerp(a, b, x) return the value between a and b, corresponding to the percentage (reminder of math: 1 = 100%) x, from a to b

lerp(a,b, 0) will return a, lerp(a, b, 1) will return b, lerp(a, b, 0.5) will return (a+b)/2.

The intended use is to make x varie (generally from 0 to 1, but it can go over that), for your zoom, you can have lerp(min value, max value, zoom percentage), and make the zoom percentage varying from 0 to 1 or 1 to 0 as you want it.

The qarp will be the same logic, but applied not in a linear fashion (a quadratic one, which I think means that a and c will be min and max, but b will be affecting the way it evolves with each values of t)

qarp (a, b, c, 0) will return a, qarp(a, b, c, 1) will return c, qarp (a, b, c, 0.5) will return ((a+b)/2+(b+c)/2)/2 = ((a+c)/2+b)/2 I think

use granpa method but the first condition has to be the System condition "For Each" (with the object that has to be affected)

Since otherwise not all instance of the object will be used in the "Compare two values"

roberto : I think peterbot1970 was referring to a "spread the payment over time, but the same amount at the end", which is similar to what you are suggesting to an extend.

Which is something I agree for, since Nobody can make money using Free C2, it could be an interresting thing, since even more people could afford to make money while paying less at one time (it is harder to have something like 100€ to keep to pay the program, while beginning to pay for it, and using it is much more affordable I think, since the same price is at the end, just more convienient, just my opinion)

maybe you are using animations with too many frames (like, how to explain, 2D video games generally uses not 60 frames at 60 fps for the animation that are clean even paused, but a lot less frames that are designed to be seen in motion only, since they have some blur applied, or other artefacts that looks really good in motion only, and that reproduces the illusion of motion with a lot less ressources)

EDIT: Of course the 60 frames 60 fps is the worst case scenario, but it seems to be a common mistake.

You can do it, they are just here because they are the original files and so if you want to change them, they are here, but keep the original somewhere safe in case you need to modify them later on /!

EDIT: Delete them from C2's interface itself

Normally C2 does a destroy on all non global object after each layout (however if you spawn other object on destroyed, they'll not be erased)

However it could have changed slightly from the last time I worried about this, so maybe there is a problem indeed