So già che questo topic avrà meno visualizzazioni-commenti di un qualsiasi browser o blocco note del piffero, ma comunque:
Eccoci qua,questa non è propriamente una guida, ma ci va vicino. Tutto è iniziato quando nei miei giochi avevo il grosso problema di gestire molte collisioni, poichè, per controllare le collisioni come si fa? prendi un oggetto e controlli se va in collisione con tutti gli altri, ma è ovvio che ciò andrà a gravare molto sulla cpu dovendo ad esempio avendo 10 oggetti per ognuno controllare tutti gli altri dovendo fare 10^2 cicli quindi per soli 10 oggetti devi fare 100 controlli,per 100 dovrete fare ben 10.000 controlli, insomma un bel problema.
Allora mi sono detto, perchè controllare le collisioni anche se due oggetti sono molto distanti tra loro ? Quindi ho fatto in modo che escludesse gli oggetti più lontani, malgrado le prestazioni siano migliorate non era ancora granchè visto che comunque per controllare la distanza tra tutti gli oggetti doveva comunque processarli tutti. Dopo un po' sono arrivato ad una soluzione ottimale: Dividere la scena in parti e processare gli elementi per gruppi contenuti nelle aree.
La scelta si è rivelata vincente e neanche troppo complicata da realizzare, altrimenti sono qui a postare il progetto e l'eseguibile.
Ma passiamo ai fatti
Ecco come funziona:
Allora, innanzi tutto potete notare come la scena sia divisa in questo caso in due aree, difatti nelle scritte a lato avremo due aree, con il relativo numero di indice e il numero di oggetti che contengono.
Le palline sono gli oggetti che si muovono in due direzioni, hanno le superfici di contatto visibili (il rettangolo) quando due palline collidono si illuminano di rosso.
Le collisioni Numero | Numeromax Sono quante collisioni processa rispetto a quanti ne processerebbe col 'vecchio' algoritmo.
Sotto infatti possiamo vedere il guadagno prestazionale in percentuale.
La scena può essere divisa in 2,4,16 parti:
Come vedete il guadagno aumenta con il numero delle aree, ma non bisogna esagerare !
Un po' di dati:
Con circa 300 oggetti
Due Aree: 24334 | 97969 (75%)
Quattro Aree: 13250 | 106726 (88%)
Sedici Aree: 3392 | 117649 (97%)
Come funziona ?
Ogni gioco è come un ciclo continuo ->Calcoli-Disegno-> per prima cosa ordina tutti gli oggetti in ogni area a seconda se ci sono dentro,( questa è l'unica operazione che scorre effettivamente tutti gli oggetti) Dopo averli ordinati gli muove.
Dopo aver ordinato e spostato tutti gli oggetti c'è il controllo delle collisioni, ogni area ha la propria parte di oggetti che viene processata, se due (o più) oggetti collidono allora modifica la proprietà 'Colore' in rosso, in caso contrario la setta nuovamente a bianco e continua.
Infine viene disegnato ogni oggetto contenuto nelle varie partizioni, avrei potuto disegnare tutti gli oggetti nella lista il risultato sarebbe stato lo stesso, ma era per rendere il codice più versatile.
Screen
Download
Eccoci qua,questa non è propriamente una guida, ma ci va vicino. Tutto è iniziato quando nei miei giochi avevo il grosso problema di gestire molte collisioni, poichè, per controllare le collisioni come si fa? prendi un oggetto e controlli se va in collisione con tutti gli altri, ma è ovvio che ciò andrà a gravare molto sulla cpu dovendo ad esempio avendo 10 oggetti per ognuno controllare tutti gli altri dovendo fare 10^2 cicli quindi per soli 10 oggetti devi fare 100 controlli,per 100 dovrete fare ben 10.000 controlli, insomma un bel problema.
Allora mi sono detto, perchè controllare le collisioni anche se due oggetti sono molto distanti tra loro ? Quindi ho fatto in modo che escludesse gli oggetti più lontani, malgrado le prestazioni siano migliorate non era ancora granchè visto che comunque per controllare la distanza tra tutti gli oggetti doveva comunque processarli tutti. Dopo un po' sono arrivato ad una soluzione ottimale: Dividere la scena in parti e processare gli elementi per gruppi contenuti nelle aree.
La scelta si è rivelata vincente e neanche troppo complicata da realizzare, altrimenti sono qui a postare il progetto e l'eseguibile.
Ma passiamo ai fatti
Ecco come funziona:
Allora, innanzi tutto potete notare come la scena sia divisa in questo caso in due aree, difatti nelle scritte a lato avremo due aree, con il relativo numero di indice e il numero di oggetti che contengono.
Le palline sono gli oggetti che si muovono in due direzioni, hanno le superfici di contatto visibili (il rettangolo) quando due palline collidono si illuminano di rosso.
Le collisioni Numero | Numeromax Sono quante collisioni processa rispetto a quanti ne processerebbe col 'vecchio' algoritmo.
Sotto infatti possiamo vedere il guadagno prestazionale in percentuale.
La scena può essere divisa in 2,4,16 parti:
Come vedete il guadagno aumenta con il numero delle aree, ma non bisogna esagerare !
Un po' di dati:
Con circa 300 oggetti
Due Aree: 24334 | 97969 (75%)
Quattro Aree: 13250 | 106726 (88%)
Sedici Aree: 3392 | 117649 (97%)
Come funziona ?
Ogni gioco è come un ciclo continuo ->Calcoli-Disegno-> per prima cosa ordina tutti gli oggetti in ogni area a seconda se ci sono dentro,( questa è l'unica operazione che scorre effettivamente tutti gli oggetti) Dopo averli ordinati gli muove.
Dopo aver ordinato e spostato tutti gli oggetti c'è il controllo delle collisioni, ogni area ha la propria parte di oggetti che viene processata, se due (o più) oggetti collidono allora modifica la proprietà 'Colore' in rosso, in caso contrario la setta nuovamente a bianco e continua.
Infine viene disegnato ogni oggetto contenuto nelle varie partizioni, avrei potuto disegnare tutti gli oggetti nella lista il risultato sarebbe stato lo stesso, ma era per rendere il codice più versatile.
Screen
Download
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
Ultima modifica: