fake it, going for some A* system would work well for sure, but its definitely way more complicated than it needs to be. keep it simple.

log is what you need as the above poster mentioned

<img src="http://www.purplemath.com/modules/logs/relatani.gif">

this is what it does, but you need to use the change of base relation

<img src="http://upload.wikimedia.org/math/5/6/f/56f7df21ad6bc1d3ce9ddff7ac5bb047.png">

the base k used doesnt matter, so ln or log (base 10) can be used interchangeably

<img src="http://fc05.deviantart.net/fs71/f/2011/013/e/d/blue_orange_self_portrait_by_quazignrlnose-d374u51.png">

first real photo of myself here (sorta)

and no not ginger, just the way i painted it

the slowdown is entirely a result of the physics being a bottleneck. even if you did get some small improvements from particle type sprites it would be pointless.

When i first started making fluidy things my computer was pretty slow so i did a lot of testing on collision types.

it seems plausible at first that having a custom collision polygon with less side# would make the simulation faster, but thats not exactly the case. the physics doesn't have trouble handling points/ edges etc, rather the collisions between objects/points/edges are what cause slowdown. having a triangular or square shape can cause the "particles" of fluid to catch each other and make extremely large slowdown spikes when "compressed", not to mention unrealistic stacking behaviour.

using ellipses actually fixes EVERY problem, circles seem like "higher fidelity" shapes to process, but the reverse is actually true, an ellipse is very simple, and can be defined and have collisions tested against it with one simple distance check, and a few trig functions like sin and cos. checking if two spheres at any angle collide is as easy as checking the distance to see if its less than the sum of the two radii.

you can have WAY more circular colliding physics objects than any other shape, because they're so simple to process and check, so put on those ellipses!

the only problem with this method is the ellipse shape in the physics plugin assumes you want the ellipses to have the width and height of the graphic, the way around this to get the quaziblob effect to work is by using one object for the physics, and putting a separate graphic sprite thats larger in a container with the physics object, then setting its position to that of the physics objects every frame.

like tul said, this is because the visual effect is only 5% the size of the meta-gradient graphic that makes the whole effect work

"I cant do it because i know i cant do it"

yet you don't even seem to know what you have to do, or anyway to do it and that is your problem? what kind of logic is that.

you say that you know 100%, thats the biggest bullshit Ive ever heard, because your not even giving yourself a chance. I don't know how you expect someone to join a team when you seem to only believe in what you can do individually.

Also, please, any request for help should show that you have a considerable amount of effort and a good idea that you can put on the table, your current attitude and lack of anything game related shows the opposite and is almost guaranteeing this wont work.

i remember seeing this picture

http://img840.imageshack.us/i/fluxengine.png/

and having been very impressed, is this your work? or someone elses?

please show more if this is the truth

set position to

x: origin.x+cos(angle)*(ellipse width)

y: origin.y+sin(angle)*(ellipse height)

origin would be the point you want at the center of the ellipse, angle is an angle from 0-359 (well it can be anything really, but thatll just loop it back since its an angular value after all)

the other parameters are pretty self explanatory. to make it spin you just need to alter the angle value.

you should use ini files instead, it'll allow for an non-finite number of objects to be saved, and it'll work essentially how you'd do it with an array, except you could add extra properties to be saved in easily and it's just an overall better way to do it.

Arrays are faster for operations that need to be preformed rather frequently, but for level data an ini file is much more scalable and easy to use, the loading at the beginning is the only loading that'll be done, so the small improvements gained through an array will be pretty negligible. also, an ini will make life simpler, and you wont have to organise objects by numbers and cryptic coordinates.

heres a good tut

And I thought me and Davio were the only LoL'ers on here.

thats the easiest possible thing you can do, just add to a variable when something is collected and when that variable =2 go to the next layout/level

http://gamejolt.com/freeware/games/arca ... atch/3161/

<img src="http://images.cdn.gamejolt.com/games/3161/screenshots/3161_6333.jpg">

A game i made a while ago had a pretty good image editor, and i managed with only sprite canvas and image manipulator, if you figure out the functionality of each object and I'm sure you'll eventually be able to make a paint program.

for color selecting the "common dialogue" object could be of use to you.

for lighting I used two edges of the cube as vectors per face found the cross product to get a 3rd vector that gave me the normal of the cubes face, and then found the dot product of that normal vector and an unchanging "light direction vector" (specified with the variables 'Lx' 'Ly' and 'Lz') that belong to the object L (L is just an object i use to store variables, because its faster to write L than global('etc') all the time), anyways, i find the dot product using the components of the two vectors, then i find the norm of those vectors with distance formula sqrt(x^2+y^2+z^2), the norm of the light is precomputed in the variable ('Ln'). with the norms and the dot product i can get the angle between the vectors that they form in their unique plane, by dividing the dot product by the product of the two norms, and then finding the arccosine of that value. the lighting from therein is just setting the filter of the face to a scaled value of that angle difference. R=G=B=('Anglebetween'/180)*255