spel sneller op tragere computer?

[Jan]

Kan iemand me uitleggen waarom de snelheid van mijn bal verschilt per PC en per browser en nog sneller gaat in de testomgeving? En vooral wat ik daaraan kan doen of hoe ik dit kan opvangen? :S De bal beweegt in/dmv een onEnterFrame.

3 filmpjes die je simultaan kan laten lopen en die de situatie tonen:
http://users.telenet.be/jansurf/stream/spel.html

Een oplossing voor mijn hitTest probleem is ook altijd welkom. Mijn bal is in werkelijkheid een vierkant: bounding box van de mc... Hierdoor kan hij dus 2 blokken tegelijk kan raken, wat niet altijd het gewenste effect oplevert.
Ik heb zelf al verschillende oplossingen gevonden die effectief werken maar die vreten allemaal tot bijna 100% van mijn CPU en vertragen het spel natuurlijk immens.
http://adnezgame.atwebpages.com/breakout.html
http://adnezgame.atwebpages.com/breakout.swf

Groeten,
Jan
edit: Op spatiebalk drukken of de UP toets om de bal te launchen. ;)

[damarez]

de enige manier hoe je een spelletje op elke computer met dezelfde snelheid kan laten spelen is d.m.v Timebased animations i.p.v Framebased
dus met een Timer
zoek maar es op google op Timebased animation

[Jan]

Thanks damarez. Met Timer bedoel je toch setInterval, veronderstel ik. (Dat is redlijk eenvoudig aan te passen in mijn geval.)
Maar ik zou denken dat het spel sneller zou gaan op een 'snellere' computer ipv trager.

Jan

[Erwinzzz]

Op het snelheidsprobleem is denk ik inderdaad de beste oplossing om het time-based te doen.

De oplossing in je hitTest probleem moet denk ik wel op te lossen zijn via een punt-vierkant detectie. Hierbij gebruik je dan als punt de bovenkant van de bal (midden bovenaan). Dit kan gewoon met hitTest:

if(vierkant.hitTest(punt.x, punt.y,true)){

[Jan]

De oplossing in je hitTest probleem moet denk ik wel op te lossen zijn via een punt-vierkant detectie. Hierbij gebruik je dan als punt de bovenkant van de bal (midden bovenaan). Dit kan gewoon met hitTest:

if(vierkant.hitTest(punt.x, punt.y,true)){

En wat als een rechteronderhoek van een blokje de bal raakt op 10uur?

Daarenboven is de situatie nog iets gecompliceerder want als je een blokje aan de boven of onderkant raakt dan keert de verticale richting om (rv*=-1), en als je een blokje aan de linker of rechterkant raakt dan keert de horizontale richting om (rh*=-1).
En dit is uiteindelijk ook de kern van het probleem met een 'vierkante bal'. Als hij twee blokken tegelijk raakt langs de zijkant dan wordt de richting horizontaal (=rh):
rh*=-1, rh*=-1 met als resultaat: rh*=+1 en dus loopt ie gewoon door ipv van richting om te keren.

Om even terug te komen op je voorgestelde oplossing:
Ik had zelf al iets gelijkaardigs geprobeerd maar alleen checkte ik niet op 1 (punt.x,punt.y) van de bal maar op alle (punt.x,punt.y) van de omtrek van elke blokje en daarbij liep ik dmv een extra for loopje (binnen de algemene for loop die alle 80 blokjes checkt) de punt.x en punt.y van een zijde van elke blokje af :


function hitchecken()
{
for(var b:Number=0;b<80;b++)// we checken de hitstatus voor alle 80 blokjes
{
//onderkant hitchecken
for(var h:Number=0;h<this["brick"+b]._width;h++)// we checken elk punt van de onderkant van een blokje
{
if(bal.hitTest(this["brick"+b]._x+h,this["brick"+b]._y+this["brick"+b]._height,true))
{
hitsound.start();
rv*=-1;
this["brick"+b].geraakt+=1;
this["brick"+b]._alpha=Math.ceil(((nodigehits-this["brick"+b].geraakt)/nodigehits)*100);
if(nodigehits-this["brick"+b].geraakt==0)
{
points+=this["brick"+b].point;
aantalbricks-=1;
removeMovieClip(this["brick"+b]);
}
}
}
//idem voor de bovenkant
//idem voor de linkerkant
//idem voor de rechterkant
}
}
setInterval(hitchecken,20);
//de omtrek van 1 blokje is 100px en dat maal 80 blokjes = 80.000 pixels hittesten.
Maar dat vreet zoveel cpu dat het heel traag en schokkerig wordt. Naarmate je minder blokjes overhoudt loopt het wel beter en sneller.

Ik heb dat dus verder verfijnd met een hoop if's zodat ie niet hoeft te checken op blokjes die hij op dat moment nog niet kan raken (en extra voorwaarden toegevoegd zoals: als de bal naar links beweegt kan hij geen linkerkanten raken, als hij naar boven beweegt kan hij geen bovenkanten raken etc) maar dat hielp nog onvoldoende.

Ik heb ook wat dingen geprobeerd via de BitmapData class (iets gelijkaardig als wat hier gedaan wordt: http://www.gskinner.com/blog/archives/2005/10/source_code_sha.html),
En dat werkt in theorie allemaal perfect maar mijn PC's kunnen dat gewoon niet 'trekken' qua snelheid van uitvoeren)

Al bij al stond ik er weer maar eens van versteld wat er zelfs bij zo'n simpel spel als dit allemaal komt kijken en waar je allemaal rekening mee moet houden en tegen welke onverwachte problemen je aanloopt onderweg.

Alle suggesties zijn welkom.

Jan

PS: Momenteel bevat elk blokje 4 mc's (elke zijde is een mc) en dan moet ik de situatie misschien omkeren en alle punten op de omtrek van de bal checken ipv alle punten op de omtrek van elk blokje. Dat vermindert alleszins het aantal keren dat er door een for loop moet gelopen worden.
80 blokjes x 4zijdenMC's x 70punten op de balomtrek=22400 pixels hittesten (ipv 80.000 pixels hittesten) Of het voldoende minder is dat betwijfel ik eigenlijk. En ik zou het helemaal moeten omgooien. :X

[Emveedee]

Ik denk dat er een betere oplossing is.
Je kijkt met welke snelheid de bal beweegt
in totaal, dus wortel(horizontale snelheid ^2 + verticale snelheid^2)
(je kent dat wel, pythagoras.)
Vervolgens heb j n array nodig van alle blokjes die nog in het spel zijn.
In deze array moet ook de locatie van de blokjes staan.
Dan kijk je of het blokje binnen het 'bereik' (de totale snelheid dus)
van de bal is, vervolgens kijk je nog of hij in de richting van de bal is,
en dan pas ga je hittest uitvoeren. Zo hoef je maar enkele blokken te
hittesten en dat scheelt n hoop cpu lijkt me.

[Jan]

Thanks voor de suggestie Emveedee. Dat is zeker het overwegen/proberen waard.
Op de manier die jij vooropstelt weet het script dus op elk moment welk blokje de bal zal gaan raken, dus moet je enkel nog wachten tot dat specifieke blokje geraakt wordt.
Het zal wel wat denk- en scriptwerk vereisen om dat erin te verweven maar theoretisch moet het zeker werken.

Jan

Groeten,
Jan

[damarez]

getTimer is echt timebased