@Zoyt is this for scaling? I’ve never used 9 slice for scaling but I can see the use of it if I add in rounded boxes and other sorts, I will definitely look in to it for the outlines of boxes etc. I’m not sure how well this will pan out though as it would mean setting presets of the slice position inset for each shape…
@Luatee Here is what I meant about factoring out code:
//Default precision qualifier
precision highp float;
//This represents the current texture on the mesh
uniform lowp sampler2D texture;
//The interpolated vertex color for this fragment
varying lowp vec4 vColor;
//The interpolated texture coordinate for this fragment
varying highp vec2 vTexCoord;
uniform highp float time;
uniform highp float freq;
uniform highp vec2 res;
void main(void)
{
highp vec2 tc = vTexCoord.xy-vec2(0.5,0.5);
highp float len = length(tc*2.0);
highp vec2 uv = tc + (tc/len)*freq*vec2(sin(len*5.0-time*10.0)*0.2
,cos(len*5.0-time*10.0)*0.3);
highp vec2 tx = vTexCoord.xy;
highp vec2 py = (-1.0 + 2.0*tx)*res;
// these were broken out as they were computed twice
float theXbit = 5.0+sin(res.y*tx.y*0.1+time*10.0)*3.0
float theYbit = 5.0+sin(res.x*tx.x*0.1+time*10.0)*3.0
if((py.x<res.x- theXbit &&py.x>res.x-12.0)
||(py.x>theXbit -res.x &&py.x<12.0-res.x)
||(py.y<res.y- theYbit &&py.y>res.y-12.0)
||py.y>theYbit -res.y &&py.y<12.0-res.y)
gl_FragColor = vec4(0,0.6,1,1)*(length(uv)*2.0)*(1.0-length(tc*2.0)+
length(res)*0.0005)*3.0;
else
discard;
}
Depending on how this code is interpreted/compiled, theXbit and theYbit is only computed once and fetched twice, versus computed twice each. Some optimizing compilers will do this automatically, while others well, won’t. You will see that I also reversed the unary minuses about to turn them into subtracts. Again, I’m not sure how the numbers are stored internally, but this may be faster in some instances.
Sin calls can be expensive. In the old days, even when we had 16K RAM, sins were often held in lookup tables rather than computed by the built-in lib. Not really helpful here, but a point of interest. 
I hope this makes sense.
@Syntonica yes I had factorised quite a few equations such as making the sin a variable to make it faster to call multiple times but this has around a 4-8 fps increase whereas no sin has about 8-12 fps increase (these are blocks of about 400x400). I see what you meant about the minuses now, it was a bit messy 
I think calling the texcoord twice could be changed and other stuff such as 4 length calls but even so its a bit slow for what it is! Thanks for the help, I’ll play around and identify the second culprit (apart from sin) slowing down the shader.
Edit: 32fps from 60fps at this size, gives you an idea. https://www.dropbox.com/s/eq4pc388lgdz9e5/Photo%2003-01-2014%2013%2055%2005.jpg
Was around 25 without your optimizations @syntonica, thanks! Still wondering if I can discard the inside pixels before they’re equated, because atm the discard is at the end so it’s calculating the whole pattern then getting rid of the pixels in the middle. And for just an outline its not worth calculating the whole box.
@Luatee can this run on ipad1? Because if it can i like to be a beta tester
@Jessevanderheide no reason why not, I’m running it on ipad3, it would be nice to see how it runs on others. It’s 60 FPS on mine but the shaders may act up, depends.
@Luatee Since uv (highp vec2 uv = tc + (tc/len)*freq*vec2(sin(len*5.0-time*10.0)*0.2 ,cos(len*5.0-time*10.0)*0.3);) is not needed unless that massive OR statement passes, you could move it into that loop so it’s only computed if needed.
if ((py.x<res.x- theXbit &&py.x>res.x-12.0)
||(py.x>theXbit -res.x &&py.x<12.0-res.x)
||(py.y<res.y- theYbit &&py.y>res.y-12.0)
||py.y>theYbit -res.y &&py.y<12.0-res.y)
{
highp vec2 uv = tc + (tc/len)*freq*vec2(sin(len*5.0-time*10.0)*0.2 ,cos(len*5.0-time*10.0)*0.3);
gl_FragColor = vec4(0,0.6,1,1)*(length(uv)*2.0)*(1.0-length(tc*2.0)+
length(res)*0.0005)*3.0;
}
else
discard;
@Syntonica you’re good at this I think that will help a bit. If I change all length calls to pythagoras that should speed it up a bit too…
New tool update: Stacker tool, allows for precise stacking ability.
http://www.youtube.com/watch?v=twUDBwF2C2Y
@Luatee do you already know how the character is going to look like?
@Jessevanderheide I do from a 3d point of view, I’m just not great at graphics so I’m not tempted to try to make the player…
Very nice! This will be amazing when the physical particles come out in Codea.
Thanks!
@Zoyt Thanks, I need your help with something so I’ll send you a pm. And I can’t wait for the particle physics in the next version!
@Luatee I grew up on a TRS-80 and learned how to squeeze every cycle out of the 1.774 MEGAhertz processor. My last project, up to version .99, is a bookseller’s database written in Java that was written to include very complete filtering and sorting capabilities. It used to have a Java-based database to hold all the data. It was too slow, so I threw out the database and save everything in a flat-file. The program went from 5MB in size down to 400K and it now runs rather perkily on my 1.6Gh Atom-based Netbook. Unfortunately, I needed to add secure FTP to it to upload to websites, so it gained another 75K. 
Optimization in speed and memory is my life! :)>-
@Luatee will you be sharing the source code here or publishing it to the App Store?
Publishing to the App Store then releasing the source code.
@Luatee I’m assuming it’ll be free if it’s open source…?
@Luatee - Sounds great. Let me know if you want any help with graphics. While mine are by far not the best, they’re available as a free resource.
@SkyTheCoder I don’t ask for much;) no the price is 69p on the AppStore and the open source will be a couple versions behind that or maybe just one, but only the codea community can use it (people who pay $10 for codea) so I doubt anyone who does not own codea will buy it just to load the code of a 69p game in to it, so it’s a win win in my eyes. Plus I’ll have to clean up and organise more before the open source. I also wanted to make it open source for the people in the community so they can add ideas to the game if they want and then it’s easily updated with cool features written by the community.
@Zoyt I might have to take you up on a bit of graphics, not much at all and I would like to learn a couple things about it if you have already learnt how to deal with sprite sheets and texture coordinating. And not the best, I think you should take an up close view of my physics gun a tool gun, they’re kinda crappy… I doubt that you’ll be making graphics that bad!
Oh cool then
Small update:
http://www.youtube.com/watch?v=AVgXX-OCBto
To the left is the terrain which is on my channel I think, take a look!
What do you think about the fragmentation effect?