[Java] Ottimizzazione prestazioni programma

[Luca_v]

Ciao a tutti,
sto sviluppando un gioco in cui ci sono delle sfere che rimbalzano sullo sfondo e il giocatore deve colpirle sparando dei missili.
Precedentemente avevo implementato ogni sfera e missile in movimento nel campo da gioco con un thread. Oggi ho deciso di sostituire i thread con dei timer, convinto di rendere l'animazione più fluida
Quindi ora tutti questi oggetti hanno un timer che ogni 30 ms chiama un metodo muovi il quale aggiorna le coordinate. Nel pannello principale ho un altro timer che sempre ogni 30 ms si chiama repaint per aggiornare lo schermo.

Ma in qesto modo ho perso fluidità, va tutto più a scatti...
e non solo! ogni volta che aggiungo un nuovo oggetto in movimento tutti quelli gia presenti rallentano e procedono a scatti

Quindi vi chiedo:

°quando conviene utilizzare i thread e quando invece usare i timer?
°consumano più risorse 4 timer o 4 thread (entrambi eseguono semplici incrementi di interi che rppresentano le coordinate x e y dell'oggetto)?
°avete qualche suggerimento per velocizzare pur usando i timer?
°mi suggerite di tornare all'implementazione coi thread?

grazie in anticipo

[U-Boat]

Così a occhio sei andato a incasinarti nel mondo asincrono quando non era necessario.

Se è stata un'imposizione dall'alto (ad esempio realizzare un gioco con i thread) è un conto, altrimenti la domanda corretta che devi porti è "perchè ho scelto questo approccio e non uno più semplice?".
In generale i thread si usano o per aumentare le prestazioni oppure perchè ti permettono di realizzare un sistema più semplice e/o modulare; normalmente in un gioco così semplice l'uso dei thread ti incasina tutto visto che devi usare i lock... ad esempio se richiami il metodo repaint in swing ti sei ricordato di accodare il task?

Un timer non è altro che un thread, quindi sei al punto di partenza... c'è anche da dire che 4 timer sono inutili, te ne basta uno in cui infili i 4 task.

Non conoscendo il tuo programma magari mi sbaglio, ma mi viene da dire che il problema maggiore qui non sono le prestazioni, ma l'architettura che hai scelto: un approccio totalmente sincrono - quindi con un game loop che ad ogni iterazione aggiorna il modello e lo disegna - sarebbe stato certamente più semplice, pulito e probabilmente prestante.

[Luca_v]

Quello che mi fai notare è giusto, è mancata una progettazione iniziale che mi avrebbe sicuramente evitato molte difficoltà...ma di fatto prima di luglio non avevo mai programmato in java, e mi sono dovuto buttare subito su un progetto comlesso senza avere esperienza alle spalle.
Comunque non è stata una imposizione dall'alto, è una tesina da sviluppare in totale libertà.

Il motivo per cui non posso usare un unico loop per riaggiornare le posizioni e ridisegnare il tutto in blocco è che il numero degli oggetti cambia a runtime
(quando una palla viene colpita si divide in due palle più piccole) e affrontando il problema come da te suggerito dovrei poi aggiornare e aggiungere riferimenti.
Penso che non sarebbe un approccio più semplice di quello attuale...o sbaglio?

[^TiGeRShArK^]

puoi avere tutti gli oggetti che vuoi al runtime con l'approccio del game loop che ti è stato suggerito...
è sufficiente tenere in memoria una lista degli oggetti da ridisegnare.
Anche in Diamonds (e presumo in moltissimi altri giochi) abbiamo utilizzato senza alcun problema il modello sincrono del Game Loop.

[Luca_v]

ok, allora adesso studierò come implementarlo! Ma penso proprio che dovrò rifare metà programma -_- grazie a tutti per i consigli!