mmmmmm, liquid grid - http://soap.com.au/chris/geom/gridV2.html
damn those loops. I know it runs bad, 28fps here, but it just looks so juicy.
V, if you can pull an effect like this off with displacement maps, then you're the best.
Printable View
mmmmmm, liquid grid - http://soap.com.au/chris/geom/gridV2.html
damn those loops. I know it runs bad, 28fps here, but it just looks so juicy.
V, if you can pull an effect like this off with displacement maps, then you're the best.
http://www.birchlabs.co.uk/ForMalee.swf
:)
Press space to toggle the displacement channel overlay. You'll notice how when the ripples all clump together, it gets pretty grainy. 'Fraid I can't do anything about that.
And you call 28 fps BAD? I'm getting less than 5 fps on it IN THE STANDALONE PLAYER.
The beauty of using the displacement map is that you can keep experimenting with different ways of drawing the map. Adding a blur is a great way of keeping it smooth, but there's plenty else you can do.
malee... that grid looks awesome. Something tells me it can be optimised a lot.. the resting framerate doesn't seem much lower than when it's all over the place.
get a PC dude :D
yeah, its bad, nothing really much you can do. It needs loops, it needs maths on every iteration and it needs to draw. Can't go faster than a while loop. Maths can't be optimized any further (to my knowledge) and bitmap rendering is slower than DAPI.
while yours performs nicely, I'm not feeling the love with the effect :( have you tried two channels for displacement?
edit - I might be able to decrease the amount of lines drawn if i flag a point as drawn, or simply draw points to the right and below of the current point. Atm its going back, so you see lines with new positions and lines with old positions, meaning needless rendering.
Mr M, that's the money shot mate, looks excellent ( Only 13fps here though ).
Tell us how it works so I can steal it.
Squize.
Yeah, but it seems to be doing a lot even when it's resting....
Surely you can skip code and drawing for resting grid lines?
Squize, nothing special at all, maths is from liquid journey :D, I think you know them too. Dont have the source here now, its at work, if you can hold on for 13hrs then I'll post er up.
Lesli, yeah thought of that, but in order to do so, i have to run the maths anyway to figure out if it needs resting, then perform more to check if it is. Turns out its worse to do that. But hey, maybe you can have a crack.
its not in anyway elegant:
define grid width and height (small)
define a scale value
draw into movie clip
scale movie clip up
scale forces down
add points into a 2D and 1D array
find adjacent points to all points using 2D array
loop over all points in 1D array
run maths
loop over connections of current point
draw all connections
so like i said before, i think i can eliminate some of the drawing if i make it draw only right and down.
EDIT - actually i could be wrong about the maths, if i store the magnitude of the velocity after the points update then check that velocity next iteration, if its small enough i could stop it. To re-init a point, all i have to do is check whether the distance from the mouse is less than the required to move it. Hopefully ;)
Arse, either I didn't download the best example on there, or you've just made it a lot better :)
It's hard to compare speed wise with the version I've got up and running 'cause you've got a load more squares ( All mine are 24x24, 26 across, 18 down ).
I was all ready to stop working on this, at the end of the day it's just background eye-candy, but seeing your example has inspired me again.
Squize.
yep, even without the rendering, just pure maths and loops, with a target fps of 120, you get about 40fps, so yeah the grid size is a big factor.
I'll post the source tomorrow, then the optimization battle can begin :D
It's a date :)
Squize.
Sorry to go off topic...Quote:
Originally Posted by Squize
Talk like this (pixel by pixel manipulation) in flash makes me wonder why devs don't just move on to other languages when they want to do this kind of thing. Is it the enjoyment of pushing flash as far as it can go? I can certainly appreciate the enjoyment of a challenge.
As an authoring environment, I went to flash for my first game because of the ease of using movieclips and not having to worry about things like blitting and damage maps and such.
I applaud all the super cool work that is being done, but am curious what remains to draw higher level programmers to flash and not going off and using C++ or something instead.
Is it because you can run it in a browser? Are people too lazy these days to download and install a new game? I honestly think they just might be.
In the past month, I've used six different machines. One was a mac, one was my pc at home, of the remaining four, I didn't have sufficient user rights on two of them to install software.Quote:
Originally Posted by Alluvian
This is why people use web applications.
For me, it's nice to try and push Flash, and with F8/9 there's all these new toys to play with, it'd be rude not to have a bit of a fiddle under the hood.
As to why Flash and not C++, Flash is a level playing field. Anyone visiting FK could make the best game ever made in Flash. You'd be hard pressed to say the same about most other environments. It's very restrictiveness is it's strength.
Perhaps we should go back to the subject, poor V's thread has been pushed and pulled away from him quite badly.
Squize.
The latest one is looking nice, VENGEANCE MX... runs at 30fps.
Oh boy, I can't wait! WWE DisplacementMapFilters vs. PureMath. Wednesday, Wednesday, Wednesday!Quote:
Originally Posted by mr_malee
Squize, I think you should put in a word for that hijack tag.
Whatever you do, don't right-click -> Zoom in. FPS goes to < 9.
[offtopic=verymuch] Thanks for the tip my browser esplode. [/offtopic]Quote:
Originally Posted by ImprisonedPride
tada
already took the liberty of doing the gfx optimization i talked about, only draws Max two lines for every point, much better :)
If someone's got maths skills, please be my guest
here's the preview, i get 45fps, when before i got around 28fps :D
http://soap.com.au/chris/geom/gridV2.html
file is attached (CS3) format, if you need F8 let me know
EDIT -also took out the scaling, was just a silly thing which did absolutely nothing
It's always on-topic in my book if it's about making things run faster. :)
Hmmm there isn't a lot of room for loop optimisation there. It's got a lot less going on than the maths I've got running in mine ( And looks better ).
Hopefully tomorrow I'll have time to play a little with it, pulling an all nighter atm.
Squize.
ouch. Yeah, i dont see anything else apart from maybe the maths. I dont see how i could use bitmapData for the lines, as it requires more loops to draw them.
I've squeezed out 1 more fps just by doing minor bits and bobs ( And yeah I wasn't go to play with it and finish my current nightmare project ).
I think putting the point objects into their own class will help quite a bit. The version I've got isn't a million miles away from this code, and I did it in there and it helped. So if the flex function is only called on data within the p object, then that can become a method of that and it'll save some look-ups.
Same with anything like that, any calculations which can be done within the point class. I know you get a cost calling the actual method, but it's less than a load of look-ups.
As to bitmap drawing, I'll be using dots rather than lines, which is quicker. As a test I altered mine to be 50 across, 40 down and each tile being 10x10px ( The same as yours ) and I was getting 50/60 fps, that's with a lot more maths going on ( Although I do use a flip flop for the plotting, so it's not every frame ).
I really want to hit this hard, damn proper work, damn you to hell.
Squize.
oooh nice. I am also doing proper work, when the "man" isn't looking i'll load er up ;)
Oops also forgot to say, the other perk of having a class with all the goodness in is that you get to data type it, so
private var px:Number;
Will be nice and quicker than
obj.px
Oh, and if your boss is giving you grief, just stand up and say "I go now", spit in his face and run out the room laughing like a big mental. Honestly, nothing bad will come of it, if anything he'll respect you all the more.
Squize.
haha, your forgetting the Delete button on the HDD :)
Malee, I've had a quick play with it. It's tightly coded.
If you double the cell width it runs at a silly speed.
So... how about cheating and plotting four squares instead of one, I can't get it to work, I don't have too much time unfortunately.
not sure i follow
wont those "fake" squares need maths performed on them too, or do you mean divide up the space between points (subdivide) and only draw lines to those points?
it may work, not sure how it'll look though.
I absolutely love playing with your example!
For example changing these lines (89, 90):
for(py = 0; py<gy; py++){
for(px = 0; px<gx; px++){
to:
for(py = 0; py<gy; py=py+2){
for(px = 0; px<gx; px=px+2){
makes it look like embossed squares. Ooo the fun to be had! You legends!
yeah, interpolate the points with fake points, so one square becomes four squares. Just interested to see how it'd look...
lets see what 1 hour can do before gym time :)
people I present success (well kinda) by subdividing and converting code into classes, well the numbers speak for themselves:
before subdivision and no class, cellW 10: 23 - 24
after subdivision and no class, cellW 20: 36 - 40
after subdivision and class, cellW 20: 46 - 58
and the results seem the same.
if you open up the source, open GridPoint and find the method "getCenter" you can see that its possible to use some bit shifting here, now i have tried it, bu the grid stays ever so slightly wobbly because of the conversion to int. So if someone can port a fast bitmap version then i'd say we could see 70fps on the board. Also, one of you could probably do a better job a subdividing too.
With no rendering i get a flat 120fps.
Without rendering (but still computing) subdivision, i get 85-90fps.
the sponge may be dry but it can be rung once more ;)
http://soap.com.au/chris/geom2
here's the source y'all
EDIT - you might notice that the effect is now inverted ;) change the power sign.
Wow, it's running pretty well now. Looks better than mine, and it's a lot closer to the original Geometry Wars effect. Mind if I use it in Polygon? :)
Excellent work.
Getting around 38/42 fps with the latest beta ( High 20's with the stinky old FP ).
If it weren't for debugging ghosts I'd be all over this like a free bar.
Squize.
PS. Anyone else having to use IE to view FK today ? That new header seems to be badly broken in FF.
thanks Squize and V
Squize, nah, looks ok to me.
V, do whatever you wish, but i'd say as soon as anything else enters that stage you'll be catching the express to chug town.
Wow..
That works better than I thought.... I had to look really carefully to see that the cells were doubled up.
you might even get away with 30px cells and dividing into 3 squares...
Though I don't understand how dividing it up into classes speeds it up?
I'm gonna have another play with the code tonight. Another optimisation idea I had was to alter the resolution for the more active parts of the grid dynamically... so the cells are 100 - 50 px for the slow moving parts of the grid, and more detailed for the more active parts of the grid.
Not sure if that's even feasable, it may take too much processing to be worth doing.
I'd like to know this too.Quote:
Originally Posted by lesli_felix
Great work mr_malee! I'm gonna see if the rasterized version turns out faster. Oddly enough it runs slower in the standalone player than before but runs faster in the browser. How do you check to see that its faster? Do you publish it every time? Guys OOP always prevails, one way or the other! Hail king OOP. :p
Quote:
Originally Posted by Cortana
I haven't looked at either code, but my guess is that one implementation uses parallel arrays of Numbers, and the other uses a single array of classes:Quote:
Originally Posted by Cortana
// Code 1
var x_array : Array;
var y_array : Array;
var dx_array : Array;
var dy_array : Array;
for i=1:N
x_array[i] += dx_array[i];
y_array[i] += dy_array[i];
// Code 2
class Point {
var x,y,dx,dy : Number; f
function update() :void { x+=dx; y+=dy }
}
var pointArray : Array;
for i=1:N
var p : Point = pointArray[i];
p.update();
I think the latter is faster because it only performs one array lookup [] per point update, instead of 4. That lookup operation is probably slower than the . access operator (which is implicit in the update function, this.x += this.dx, etc).
I'd like to know the whole story myself.
Well if anyone's interested here is the raster version: http://www.devkiwi.com/project/geowars/gridV4.html
Source: http://www.devkiwi.com/project/geowars/V4.zip
If there would be a way to clear only the affected areas that would probably improve the speed but currently there is no speed improvement. And I wasn't able to stop the cage from shaking. It's probably due to the fact that the raster fields are defined as int.
Runs about 15 fps faster for me.
Malee’s version gets an average of about 50 fps, yours about 65. Im sure you could fix the shaking by setting values to 0 if they are below a certain number?
Ali
At the top of the page I made a couple of posts about why using a class for an object is quicker.
"If there would be a way to clear only the affected areas"
I was thinking of playing with getColorBounds. If you're using the bitmap line code I posted on the blog you'll notice there are special cases for straight lines.
What I was planning on trying is altering the colour slightly when it's not a straight line and then using getColorBounds on that colour to return the size of the changed rect., which would be the size to use the fillRect on.
Squize.