Printable View
alillm, that is odd it runs just about the same speed for me... but then I'm using Opera.
Interesting I'll check that out... in the mean time I uploaded http://www.devkiwi.com/project/geowars/gridV4.html with your raster function and that added 1fps for me :)Quote:
Originally Posted by Squize
awesome work Xploder, at work the last version I posted gets 85fps, your raster version gets 90-100fps, but work computer is a beast and I'm using the new player update.
As to the class question, Squize pointed it out. Classes give you the ability to data type its properties, whereas objects dont. Or i was just doing it wrong. See:
var x:Number = 10;
var y:int = 20;
var ob = {}
ob.x = x;
ob.y = y;
see here, not sure but I'd say that the data type is lost. Whereas in a class it stays.
rachil, i wasn't using arrays for the numbers, just objects, but i guess its kinda the same. All in all, OOP is better in this case.
change grid size to 200x100 and cellW 5.
:D
scaled up a little: http://soap.com.au/chris/geom3/gridV3.html
oh my god... you won't believe the next update... there is currently a slight problem but its a 10fps gain if it works out... that is in the browser. In standalone its a 20fps increase.
I promised I would wow you. Well how does 80fps instead of 60fps sound? Well, now it seems feasable :p At least on my 2GHz core 2 duo laptop where as before it was barely 60fps. I further optimized Squize's line drawing routine. Namely using fillrect instead for horizontal/vertical lines. And for one instance using const. I will release source tomorrow morning. Today its way too late... enjoy: http://www.devkiwi.com/project/geowars/dontbelieve.html
lovely :)
the wobbyl grid is still there, but i'm sure its fixable somehow. Oh and I get 116 - 120fps fps now :D
go team :thumbsup:
"Namely using fillrect instead for horizontal/vertical lines"
Fantastic, never even entered my head. That's one of those great ideas that you wish you'd thought of ( Well, Xploder, you did mate :) ).
Squize.
I still wanna try to stop the maths on stopped points, could add the wobble fix in there as well.
Still busy Squize ;)
"Namely using fillrect instead for horizontal/vertical lines"
Not to sound cheesy or anything, but I actually thought about that last night lying in bed.. (Yes, I dream about flash)
I suppose you dont use any sin or cos to rotate the rectangle? You just make the ends flat right?
Always busy mate, although I am playing with a certain grid effect atm.
T1ger, excellent idea too then :)
Squize.
This is the best I've been able to manage:
http://blog.gamingyourway.com/conten...y/GWars_v3.swf
Lot's of cheats in there, and I'm not overly happy with it, but it shouldn't be too far away from that in the game itself.
I guess in terms of benchmarks I'm kinda out of it now, 'cause I'm going off on a slight tangent to make it viable in a game rather than as eye-candy.
More later, I've really got to get some work done.
Squize.
nice. Do i see trails? or am i just really tired. Its good to see 120fps on the board and still see the effect.
anyway, hopefully tomorrow Exploder will share his great raster code and we can combine this:
http://soap.com.au/chris/geom4/
its a version with some culling still using the DrawingAPI, Its easy to find if i point needs to stop calculating but the thing is the rendering doesn't change so it may/may not be worth it. I think its faster than before but not by much.
Another slight improvement: http://www.devkiwi.com/project/geowars/gridV5.html
Souce:
http://www.devkiwi.com/project/geowars/V5.zip
Enjoy!
Being rushed to release the code early to give everyone a good glance I wasn't able to properly respond to all your comment. So here it goes :)
Thanks Everyone! I didn't get around to worrying about the wobbyl grid. Wow 116 - 120fps you must have some beast of a machine :)Quote:
Originally Posted by mr_malee
Together strong we could make the ultimate flash game. But then again you're all probably too busy.Quote:
Originally Posted by mr_malee
Hey, thanks a lot that means a lot coming from you ;)Quote:
Originally Posted by Squize
I've noticed the best ideas come at night after some intense coding. The fillrect is just a one pixel wide rectangle.Quote:
Originally Posted by T1ger
It was actually surprising to find that it works quicker though. Because behind the scenes flash has to render each pixel anyway. Which leads me to believe that setPixel32 is just a 1x1 fillrect and a for loop of fillrect would take more time than just fillrect.
And... thanks for the rotation idea... as I'm not using fillrect for slanted lines. I'll check if using matrix tranformations for slanted drawn by fillrect will improve the speed. The other solution is to reduce the for loop on the slanted lines by using segments of fillrect.
Its looking quite nice. I'm getting a 100fps average.Quote:
Originally Posted by Squize
Can't wait to see the result! Next Goal 90fps on my lappy.Quote:
Originally Posted by mr_malee
Xploder, did I just hear 'setPixel32'? Change any setPixel32 calls to setPixel in the Raster.as file... I have a hunch it could be faster. ^_^
Funnily enough that's twice I've read that today ( Tom posted the same thing on the blog ).
It's true, but I left it in there 'cause without it you can't have a transparent bitmap, which means no background. Fine in this example, but a bit limiting.
Squize.
Oh... I did check to see if it is faster but it turned out to be about the same speed. Unless if it changes inside the browser. Didn't check it there.Quote:
Originally Posted by VENGEANCE MX
I've let the side down a little in this thread, so here's a bit of an update to the raster line plotter.
It assumes you're running it from the GridPoint class, so it doesn't need that point's x/y passing to it as it's already there.
Bascially the improvement ( Aside from some very minor cosmetics ) is due to plotting from both ends of the line, so it meets in the middle. This in turn halves the number of times we have to run the loop, which is cool 'cause a conditional in a loop is just nasty.Code://-------------------------------------------------------------------------
private function quickLine(x1:int,y1:int):void{
var i:int;
var cumul:int;
var x0:int=x;
var y0:int=y;
var dxL:int= x1 - x0;
var dyL:int= y1 - y0;
var xinc:int = ( dxL > 0 ) ? 1 : -1;
var yinc:int = ( dyL > 0 ) ? 1 : -1;
dxL = (dxL ^ (dxL >> 31)) - (dxL >> 31); //Math.abs
dyL = (dyL ^ (dyL >> 31)) - (dyL >> 31);
var c:Number=0xDD073C89;
//Test for a straight vertical line
if(dxL==0){
bitmap.fillRect(new Rectangle(x0,y0,1,dyL),c)
return;
}
//Horizontal line ?
if(dyL==0){
bitmap.fillRect(new Rectangle(x0,y0,dxL,1),c)
return;
}
//Neither of the above, so let's check which is the major axis and do our thing
if ( dxL > dyL ){
i = cumul = dxL >> 1;
var x2:int=x1;
while(--i>-1){
x0 += xinc;
x2 -= xinc;
cumul += dyL;
if (cumul >= dxL){
cumul -= dxL;
y0 += yinc;
y1 -= yinc;
}
bitmap.setPixel32(x0,y0,c);
bitmap.setPixel32(x2,y1,c);
}
}else{
i = cumul = dyL >> 1;
var y2:int=y1;
while(--i>-1){
y0 += yinc;
y2 -= yinc;
cumul += dxL;
if ( cumul >= dyL ){
cumul -= dyL;
x0 += xinc ;
x1 -= xinc ;
}
bitmap.setPixel32(x0,y0,c);
bitmap.setPixel32(x1,y2,c);
}
}
}
I've not tested it to death, so it may not always draw a perfect line, but it's working pretty well in the grid ( Oh and Xploder I've not checked your last build mate, so there may be some cross over. Feel free to merge them up to make one beautiful method :) ).
Squize.
dxL = (dxL ^ (dxL >> 31)) - (dxL >> 31); //Math.abs
Never seen that before... it can't possibly be faster than conditional assignment, can it?
dxL = (dxL < 0) ? -dxL : dxL
noice, got some free time so i'll do some cutting and pasting and we'll see what happens
rachil, yeah it is, I got it from here:
http://lab.polygonal.de/2007/05/10/b...-integer-math/
I can't even pretend that I could work something like that out myself ( btw, lot's of excellent little speed ups on that page ).
I've realised I've got 2 vars defined in the above code I don't need, but I've got another cheeky special case test that I want to try out, and if it works I'll post the whole thing again ( Out of interest, the y2 and x2 vars don't need defining, it can just use y1/x1 ).
Squize.
Squize, you didn't take into account that a 'width of a rectangle cannot be negative :(' taken directly out of my source code commenting ;) This tormented me for a while but I don't think it makes a huge difference in terms of speed. Otherwise the other part inserted into my code seems to make it 1fps slower :(. And about that part... maybe its better to post it here as a question my comment was:
// TO DO: See if there is any way to check when a few pixels
// in a row need to be drawn and use fillRect thus further reducing the for loop.
// Or: Check to see if a Matrix transformation works better to rotate the fillRect if that's possible.
Sorry mate, like I said, I've not had chance to look at your last version, this was just built on the version I posted on the blog.
The rectangle used in the fill can't be negative though can it ? The width is converted to a positive before the fill occurs and because it's only ever used on straight lines then the starting points will always be less or equal to the end points.
I should check your code out, 'cause I'm missing the point there somewhere.
Also surprised it's running slower when the loops are halved. That's very weird, loop unrolling should always be quicker.
Squize.
The width cannot be negative so the lines that should go to the left will go to the right. Same for the vertical lines. Maybe if that is changed in mr_malee's grid plotting...
I tried dropping my line plotter into your code, and I see what you mean, it did break.
I've not used any of M's math optimisations yet, so that's why I'm not getting any negative widths ( I guess ).
I think this is me done with the line plotter, maths next.
The two new "special case" checks may seem overkill, but in the example they happen a fair bit.Code:private function quickLine(x1:int,y1:int):void{
var i:int;
var cumul:int;
var x0:int=x;
var y0:int=y;
var dxL:int= x1 - x0;
var dyL:int= y1 - y0;
var xinc:int = ( dxL > 0 ) ? 1 : -1;
var yinc:int = ( dyL > 0 ) ? 1 : -1;
dxL = (dxL ^ (dxL >> 31)) - (dxL >> 31); //Math.abs
dyL = (dyL ^ (dyL >> 31)) - (dyL >> 31);
var c:Number=0xDD073C89;
//Test for a straight vertical line
if(dxL==0){
bitmap.fillRect(new Rectangle(x0,y0,1,dyL),c)
return;
} else {
//Horizontal line ?
if(dyL==0){
bitmap.fillRect(new Rectangle(x0,y0,dxL,1),c)
return;
} else {
//Vertical line with just one step ?
if(dxL==1){
var halfHeight:int=dyL>>1;
bitmap.fillRect(new Rectangle(x0,y0,1,halfHeight),c);
bitmap.fillRect(new Rectangle(x1,y1-halfHeight,1,halfHeight),c);
return;
} else {
//Horizontal line with just one step ?
if(dyL==1){
var halfWidth:int=dxL>>1;
bitmap.fillRect(new Rectangle(x0,y0,halfWidth,1),c);
bitmap.fillRect(new Rectangle(x1-halfWidth,y1,halfWidth,1),c);
return;
}
}
}
}
//None of the above, so let's check which is the major axis and do our thing
if ( dxL > dyL ){
i = cumul = dxL >> 1;
while(--i>-1){
x0 += xinc;
x1 -= xinc;
cumul += dyL;
if (cumul >= dxL){
cumul -= dxL;
y0 += yinc;
y1 -= yinc;
}
bitmap.setPixel32(x0,y0,c);
bitmap.setPixel32(x1,y1,c);
}
}else{
i = cumul = dyL >> 1;
while(--i>-1){
y0 += yinc;
y1 -= yinc;
cumul += dxL;
if ( cumul >= dyL ){
cumul -= dyL;
x0 += xinc ;
x1 -= xinc ;
}
bitmap.setPixel32(x0,y0,c);
bitmap.setPixel32(x1,y1,c);
}
}
}
I think from here the only things I can think of is some tests for diagonal lines, and ordering the conditionals differently ( So the normal line plotter routines are tested first, then if it's not one of them try the special cases ).
Squize.
I'm gonna drop in here really quick just to say, this is some really great work you guys are doing and here's my clunky, slow attempt at the same kind of thing in AS2 (use the scroll wheel to change force...you may need to click to get the focus)
I'm jealous of all you people and your CS3...:p
Captain, does that use Clumping by any chance?
If not, I think it might be worth giving this a go ;)
http://www.krazydad.com/bestiary/bestiary_clumping.html
It doesn't...right now it's very poorly optimized, there's an onEnterFrame for each of those little dots calculating it's particular force in relation solely to the current position of the mouse and then applying that force to it's acceleration.
But I'll look into that, thanks for the link.
Hey, I think I came up with another raster optimization approach. It involves precalculating all the possible angles of lines and storing them into a bitmap or it could just load a spritesheet for a set line size. I'll check that possibility out further tomorrow.
Xploder, I've tried that already and it seemed to run slower than the drawingAPI version, but you might have better luck.
there were no updates using displacement map since page 3, so I thought I will jump in, just for fun... clicky (~300kb no preloader)
...btw, there seem to be relevant threads here aleady (like this one)
I hit another beer and changed it to support multiple ripples:
http://xs318.xs.to/xs318/07330/wtfripple2.JPG
that kills FPS if you click it too much :(
not any more :)Quote:
Originally Posted by myself
very nice.
Ok, I see... that's unfurtunate can't say that I won't try anyway though ;)Quote:
Originally Posted by mr_malee
Does anyone know wheater there actually is an improvement if BitmapData.lock() and BitmapData.unlock() is used? I cannot tell wheather there's a difference or not. What is its use anyway?
Found a general graphical speed boost in AS3 which I don't think has been mentioned on FK before... the opaqueBackground property.
Basically, it goes hand-in-hand with cacheAsBitmap. It's faster to cache bitmaps without using an alpha channel, so setting the movie clip's opaqueBackground to a colour value means that it will drop the alpha channel and use a colour instead. Obviously this is only really applicable for alpha backgrounds in front of a flat colour, and in a lot of cases you'll need the alpha channel (parallax, for example). Still, worth knowing. :)