Java robot klasse ikke hurtig nok?

Tags:    java robot

Jeg er igang med at programmere en bot til et spil der hedder superball.
Botten består i at tage et billed, søge efter pixel farven på skærmen(Som er boldens farve) også holde musen på den

Problemet er , det går ikke hurtigt nok, det tager for lang tid at tage billed og søge osv osv
Fold kodeboks ind/udKode 


Der er al min kode.
Spørgsmålet er så, hvad kan jeg gøre for at det bliver hurtigere
Er der andre måder jeg kan gøre det på ?



7 svar postet i denne tråd vises herunder
5 indlæg har modtaget i alt 7 karma
Sorter efter stemmer Sorter efter dato
Det kan være mange ting, men en lille ting du kan optimere er at lade være med at konstruere et nyt Color objekt inderst i loopet, da det tager lang tid at allokere objekter.

int RGB = bufferedImage.getRGB(x, y);
if(RGB == 0x19B217){

Et andet lille trick til at undgå run-variablen, som måske kan hjælpe lidt, men nok ikke meget:

nameOfMyLoop: for(int x = 0 ; x<width/2 ; x++){
...
break nameOfMyLoop;



Umiddelbart tror jeg at det er "createScreenCapture" der tager alt for lang tid. Et screenshot tager en god del at lave hvis man ikke gør det på den rigtige måde.



Nu ved jeg intet om Java og da formålet med metoden er uklar, så tænker jeg, hvorfor ved programmet ikke hvor bolden er.

Der er tale om 2 programmer:
- Spillet
- Bot der spiller spillet

Eftersom han laver det i java, så er den eneste mulighed(så vidt jeg ved) for at finde bolden, ved brug af screenscraping.



Indlæg senest redigeret d. 20.06.2011 10:17 af Bruger #955
Jeg har lige skimtet det lidt igennem

Bolden opstår vel ikke bare på tilfældige steder. Så vidt jeg kan se kan du bede om et rektangel, så istedet for at nappe hele skærmen, nap et område omkring hvor bolden var sidst, hvis dette fejler kan man jo altid tage hele skærmen, eller et større område.

jeg vil også anbefale at lave
for x...
for y...
om til
for y...
for x...
da det vil ændre hukommelses tilgangsmønstret, til noget computeren lidt bedre kan lide. Dette er under antagelse af at billedets pixels ligger gemt linje for linje.

Jesper Kristensens forslag om at undlade color objektet burde også batte en del.

Med hensyn til run variablen, kunne du hive det ud i en nu metode, og anvende return istedet.

Jeg kender ikke Robot klassen, men hvis der er en overloadet udgave af createScreenCapture, hvor man også kan give en buffered image med, så kunne du måske undgå at allokere en masse ram.



Tak for jeres svar.

Nåede dog selv at fixe det igår selv med lidt roden rundt.

Som troels også nævner, tager det RIGTIG meget performance, at nappe hele skærmen, jeg gjorde så den blot nappede spil vinduet og nu kører det flawless.





Medmindre din bold kun er én pixel stor er det vel heller ikke nødvendigt at teste samtlige pixels.

Ikke sikker på at denne ide passer:
Hvis du tester pixels i et grid hvor afstanden mellem hver grid linje er mindre en boldens radius vil mindst et grid punkt være inde i bolden.


Såvidt jeg kan se søger du kun i en kvadrat af skærmen.






Nu ved jeg intet om Java og da formålet med metoden er uklar, så tænker jeg, hvorfor ved programmet ikke hvor bolden er.

Ville det ikke være langt hurtigere at programmet vidste hvor bolden er og så lade programmet tjekke inden for radius af bolden for at "se" om musens placering er ok?



t