iopred's example is actually in this thread.
Squize.
Printable View
iopred's example is actually in this thread.
Squize.
Well, I want the colliding clips to move away from one another, just like if the clips where balls.
I search every post in this thread by iopred and found nothing. Am I blind ? Could you post the url to the post.Quote:
Originally posted by Squize
iopred's example is actually in this thread.
Squize.
It's on page 7 of this thread ( The slightly amended version, I guess the original is page 6 ).
Squize.
a thought to help large graphics...
is there any way to set the quality to medium or low on key press and back to high on release?
stoley_101
Erm, yes. Just change the quality setting on a keypress.
But it's a global setting, so the whole screen will change quality, also the screen will noticebly move when changing modes which will just look nasty.
For full speed your game should be running in low quality anyway, using bitmaps instead of vectors.
Squize.
After finally reading this whole thread(except for Squize's FLASM tuts which I'll be sure to look into later(maybe witch in this case...;))) I decided to give some of my own found speed tests. Though I don't have the speed results of each test I did note which was faster.
Note: I am using Flash MX and tested in the publisher's frame. I also didn't test for the slash syntax of Flash 4.
1. Best to use an initobject when using AttachMovie for defining the properties of the object. If you don't wish to use an initobject, use TellTarget to help define the variables if 3 or more are being defined, otherwise use the dot syntax.
2. {} is faster than new Object, and [] is faster than new Array[](though {} is faster than []).
3. Global functions(normal functions) are faster than methods even if using tellTarget or with.
4. For in loop is the fastest loop(Very close to a while(--i) loop but slightly faster).
5. Use tell target when calling more than 1 method of a movielcip(dot syntax equally fast for only 1).
Edit: 6. It is also quite a bit faster to delcare the properties of your object within the {} even if you use with outside of them.
Hope that Helps!
Edit: Its fun to revive a sleeping giant...
I've been thinking, because dynamic textboxes are slow, would it be faster to change the text value of textboxes everytime that the var would change, everyplace you have the code to change it just add thetextbox.text=thevar?
Just wondering if anyone has tried it...
Here's an interesting thing ... from what I can tell using an object instead of an array is faster. Does that seem right to anyone? Can anyone explain this?
---Code:_global.MAX_VALUE = 10000;
function loopObject() {
var a = {};
var ms = getTimer();
trace("start test objects");
for (i=0; i<MAX_VALUE; i++) {
var b = Math.random()*i;
a.b = b;
}
trace("result : "+(getTimer()-ms)+" ms");
trace(a.b);
}
function loopArray() {
var a = [MAX_VALUE];
var ms = getTimer();
trace("start test array");
for (i=0; i<MAX_VALUE; i++) {
var b = Math.random()*i;
a.push(b);
}
trace("result : "+(getTimer()-ms)+" ms");
trace(a[50]);
}
loopObject();
loopArray();
Output
start test objects
result : 68 ms
1695.6690332992
start test array
result : 119 ms
8.696839150507
Yes, that is how it is suppose to be because array is ordered and object properties are not. Array has length, object does not.Quote:
Originally Posted by niwrat
Those two tests aren't comparable. While the object test is testing the access time of a single variable, your array code is resizing the array MAX_VALUE times due to the push operation. The final length of your array is MAX_VALUE * 2.Quote:
Originally Posted by niwrat
Regardless, though, array element access is slightly slower than object property access in flash. It's probably due to bounds checking. If you modify your test to access the same element of the array, similarly to what the object test does, the results will be much closer - in my case the difference was 1ms.
On a final note, declaring variables within the test loop skews the results. There's no way to tell how long it will take for the system to allocate a variable. At any given time it may cross a page boundary, and you'll be adding the time it takes the kernel to serve up a fresh page.
Does it really change the final result of your game to use while instead of for and such things?
Thanks. I realised that my code was a bit dodgy. You can just change:
toCode:a.push(b);
And now it doesn't distend. I keep getting about the same times though. I'm thinking about using objects instead of arrays for holding large lists of information. Does anyone see any reason that this would be a bad idea? I'm guessing objects take a lot more memory maybe?Code:a[i]=b;
Actually now that I say this I'm thinking it would take a lot longer to check/get information from an object. Oh well ...
Again thanks for the quick replies.
No, use whichever you like.Quote:
Originally Posted by fil_razorback
pfiou, then i won't try to optimize thousand lines of code to gain 1 ms :p
Anyone got any pointers for collision detection without checking every frame?Quote:
Not all code has to run every frame, use flip flops for non-100% time critical things ( Even collision detection ! )
Example: Run your collision detection just as you would per frame but do it every second. Only thing you have to do is multiply most of your values (such as velocity) by 2! Do it every 3 frames and multiply them by 3. You could even have an engine that checked how fast it was going (with counters on intervals) and then adjust your checking per frame instead of your frame rate dropping a lot ... hmmm .... not too bad an idea actually ... hmm ....
Other collision detection optimization (which is probably already mentioned in this thread--if not, I am REALLY surprised) is to use regions.
If you have several objects moving around, and you keep track of what region they are in, then you need to only check the collision of objects in the same region as your player. Or in the same region as your bullet. Or whatever it is you are testing.
Imagine your screen split up into several large squares. That is what I mean by region. If your player is in the top left region of the screen and you know that the enemy is NOT within this square, then you know not to bother to check for collisions, because they aren't even in the same space.
I am oversimplifying in laymens terms here, but it should be understandable to most people who have some experience in making games.
I just found something quite interseting regarding distance checks.
I've been doing some equation of circle things in math lately, and I figured out a way to speed up simple distance checks. From what I found it it takes 3/4 of the normal time.
Though you might be able to optimize both more, but here it is.
code:
function distsquare(x1,y1,x2,y2,mindif){
if((x2-x1)*(x2-x1)+(y2-y1)*(y2-y1)<mindif*mindif){
return true;
}else{
return false;
}
}
function dist(x1,y1,x2,y2,mindif){
if(Math.sqrt((x2-x1)*(x2-x1)+(y2-y1)*(y2-y1))<mindif){
return true;
}else{
return false;
}
}
t=getTimer()
for(i=0;i<=10000;i++){
dist(0,0,8,8,12); //About 100ms on my comp
//If you change it to distsquare it runs at 75ms
}
trace(getTimer()-t)
I though this might be handy to someone, without the square root it sure goes a lot faster.
thanks for sharing that - that's really useful to know!
Is their an event that makes it possible to have code run periodically but not every frame? (i use good old flash 6)
You can always use counters to skip frames:Quote:
Originally Posted by helpmeplz
if(mycounter>10){
//run code
mycounter=0;
}
mycounter++;
or use getTimer() to run code after certain time:
if(mytime<getTimer()){
//run code
mytime=getTimer()+3000;
}
I like to use the setInterval for those cases, you can choose every however many milliseconds you want it to runQuote:
Originally Posted by helpmeplz
Let's unearth this famous thread !
Anyone know how I could optimize this test ?
if (Math.abs(this._x-this._width/2-this._parent.progression[mc]._x+this._parent.progression[mc]._width/2)<this._parent.progression[mc].colli+this._width/2-3 and Math.abs(this._y-this._height/2-this._parent.progression[mc]._y+this._parent.progression[mc]._height/2)<this._parent.progression[mc].colli+this._height/2-3) {
It runs dozens (hundreds?) of time per frame in my code so it should be optimized as much as possible :D
Thanks in advance ^^
Firstly, nest the second statement within the first(otherwise it will test both, even if the first one fails, so put the second after the first with no and).
Secondly, if you save a variable of Math.abs, that may be faster.
code:
var _mathabs=Math.abs //Define only once, not every time looped through, so outside of loop
if (_mathabs(this._x-this._width/2-this._parent.progression[mc]._x+this._parent.progression[mc]._width/2)<this._parent.progression[mc].colli+this._width/2-3){
if(_mathabs(this._y-this._height/2-this._parent.progression[mc]._y+this._parent.progression[mc]._height/2)<this._parent.progression[mc].colli+this._height/2-3) {
//It is true
//Do stuff
}
}
That should help a bit.
(Also, you could save a reference to this every time in a local variable, though I don't know if that will help).
you could aslo make a refrence to the _parent.progression[mc] so the script doesn't have to keep looking it up. If it were me i'd make all the variable names nice and small. I think that has a slight impact (if any)
code:
var abs = Math.abs
var ob = this._parent.progression[mc]
//properties, thanks unknownGuy
var w = this._width/2
var h = this._height/2
var obw = ob._width/2
var obh = ob._height/2
var colli = ob.colli
//main loop
onEnterFrame = function(){
//our variables
var x = this._x
var y = this._y
//ob's variables
var obx = ob._x
var oby = ob._y
//check
if(abs(x-w-obx+obw)<colli+w-3){
if(abs(y-h-oby+obh)<colli+h-3){
//do stuff
}
}
}
I've never been sure of this, but Mr. Malee, for the obx, obw, oby, and obj, wouldn't it be faster not to create a local variable since it is only used once(since by creating the variable you are using it once + creating a variable)?
whoops, yes it would, however you need to update the x and y positions
Thanks ! I'll nest the if statements and do a reference to this._parent.progression
I can't make a reference to Math.abs...It's not a constant value but an operation >_<
Anyway, many thanks to both of you :)
why cant you reference Math.abs, are you using it as a function or something?
i do it all the time with Math.floor and Math.sqrt
chuck it on frame one of your main timeline as
_global.abs = Math.abs
O_o
I never tried such a thing. Would it be faster?
Yes.
Just 'cause it's a built in method doesn't mean you can't create a short-cut to it ( I think this was covered in the first few pages of this thread ).
It's no different doing something like
var rnd=Math.random;
than
var health=playerSprite.health;
Squize.
I'm sure this was explained earlier in the thread but I didn't see it. And I haven't looked thorugh all of it but here it is. I've noticed in the very beginning of this thread when you guys were talking about if/else statements. Now when you were talking about this I recall something of a ? statement and how it performs. I'm just wondering what this ? statement is or is just anykind of a statement after the if/else?
As far as I understood it works like this
code:
var myVar= Math.round(Math.random())+1;
var isMyVarEqualToTwo = "The Answer is : " + (myVar == 2 ?"true":"false");
Another question, about collision detection in Shumps...it it less slow to use
code:
everybullet.onEnterFrame = function(){
//test every ennemies with a for...in loop
}
OR
code:
onlyOneMovieClip.onEnterFrame=function(){
for(bullets in the game){
for(ennemies in the game){
//Do hitest
}
}
}
It is generally thought(I believe is true, haven't tested) that one onEnterFrame is the best.
Would I take a performance hit for breaking apart an imported bitmap, edit it, and then regrouping it?
The motivation behind the question is that I am trying find a quick way to break up the frames in a sprite sheet without using trace bitmap (which appears to be really slow). When I copy and paste from an external paint program, the transparency is not preserved, so I have to use break apart + lasso tool to remove the background.
I could preserve transparency by cutting each frame in the sprite sheet and saving them individually, but that is way too tedious.
Any help is appreciated, thanks much!
EDIT: I did some testing, and found that using a bitmap as is was about 3% faster than breaking it up.
I created 60 movieclips of either a bitmap or a broken up one and timed their move across the screen from x=0 to x=600.
Anyone seen similar results?
Jee, sounds like my worst nightmare: breaking apart a bitmap then lasso to create an alpha for sprites: Ahhhhhh! get me out of here.
Well no! get yourself a real image editing program and save your stuff with transparency as gif or png24. I'll go for png24 because that gives you a smoth mask and then in Flash you can compress it as a Jpeg --> optimized as never!
If you cant aford photoshop of one of those, here are some free editing softs, which probably will do the job:
http://www.gimp.org
http://picasa.google.com
http://vicman.net/vcwphoto
http://www.cursorarts.com/ca_imffw.html
http://www.eecs.wsu.edu/paint.net
Some tests were done a while back, using a lassoed alpha is actually faster than if the image has transparency. That said, it is an archaic method, and even though it offers minor speed increases, shouldn't be used.Quote:
Originally Posted by drakz
Try using batch processing in photoshop (or use slices to export the images). If you have Flash 8, try using BitmapData to read from the bitmap instead of cutting it up.
breaking an image apart essentially makes it become a vector shape with a bitmap fill. If it then needs less or more performance than an image with alpha area depends on the amount of curves in the vector shape (so the more curves your "custom alpha mask" has,the more performance it will need).
As pred said its an archaic method,painful to do and a giant time waste.
When did this thread get "unstickied"?