Come posso determinare l'ordine di estrazione in un gioco flash con vista isometrica?

Questo è per un gioco flash, con vista isometrica. Devo sapere come ordinare l'oggetto in modo che non sia necessario il controllo del buffer z durante il disegno. Questo può sembrare facile ma c'è un'altra limitazione, una scena può avere oltre 10.000 oggetti, quindi l'algoritmo deve essere eseguito in meno di O (n ^ 2). Tutti gli oggetti sono scatole rettangolari e ci sono 3-4 oggetti che si muovono nella scena. Qual'è il miglior modo per farlo?

AGGIORNARE

in ogni riquadro c'è solo un oggetto (intendo che gli oggetti non possono sovrapporsi). e accediamo a entrambe le mappe di oggetti e oggetti hanno la loro posizione.

UPDATE2

vedi queste figure:

nel primo un primo oggetto blu dovrebbe essere disegnato poi verde poi rosso. mentre nel secondo devi disegnarli in ordine inverso. devi disegnare prima il rosso e poi l'oggetto verde e infine blu. come puoi vedere non c'è alcuna differenza nella posizione degli oggetti blu e rossi, entrambi hanno una distanza diversa dalla fotocamera e così via. ma a causa della loro posizione relativa alla casella verde, è necessario modificare l'ordine di disegno tra due immagini. questo è ciò che rende questo problema un casino.

nota a margine: poiché tutti gli oggetti sono prismi rettangolari, è matematicamente dimostrabile che esiste almeno un ordine di disegno per soddisfare le esigenze problematiche.

Questo è in realtà molto semplice se i tuoi oggetti si abbinano alle tue tessere isometriche. Dai un'occhiata a questa immagine:

Dovresti prima disegnare l'oggetto nella posizione rossa, quindi gli oggetti in blu, poi in verde, poi in giallo, poi in magenta e così via ... Dovrebbe essere abbastanza ovvio come implementarlo se la tua scheda contiene degli oggetti al posto degli oggetti avendo posizione come attributo. In caso contrario, dovresti mantenere una struttura di dati separata, aggiornandola ogni volta che si sposta un oggetto (che dovrebbe essere anche abbastanza facile).

Questo ha un nuovo problema: puoi facilmente vedere come ora la sua complessità è O (N) dove N è la dimensione della tua scheda ( N=W*H). Per ovviare a questo problema basta creare una nuova struttura di dati lineare in cui ciascun indice nella propria struttura corrisponda a una determinata profondità, aggiornandolo ogni volta che un oggetto cambia profondità.

Il caso in cui un oggetto non corrisponda a una singola tessera è un po 'più difficile, quindi lo posterò se ne avrai bisogno non appena aggiorni la tua domanda.

Non ho alcuna conoscenza speciale su questo argomento, ma ecco un pensiero.

Inizia contrassegnando ogni cella come "non disegnata". (O, equivalentemente, usa un array per rappresentare la posizione della cosa "disegnata" più vicina su ogni "linea vicina" di celle, o un insieme, ecc.) Quindi, per ogni cella (probabilmente li attraverserei in l'ordine kaoD descritto): controlla se quella cella è stata disegnata; se non è stato disegnato e contiene un oggetto, controlla se ogni cella che sarebbe stata oscurata da quell'oggetto è stata disegnata e se non lo disegna ricorsivamente; disegna l'oggetto contenuto da quella cella se necessario; e contrassegnare quella cella e tutte le celle occupate dal suo oggetto come "disegnate".

Suppongo che puoi mappare rapidamente una cella all'oggetto al suo interno, se presente. Credo che questo sia O (n) tempo, anche se potrebbe finire per costruire un grande stack (che potresti voler trasformare in un elenco collegato se sei preoccupato di rimanere senza spazio nello stack).

Se hai davvero bisogno di un elenco, puoi aggiungere un elenco invece di disegnare. Ho il sospetto che iniziare con un elenco per lo più ordinato non aiuta.

Userei l' algoritmo del pittore a una distanza di taxi dalla cella più lontana dalla fotocamera, disegnando prima quelli più vicini alla fotocamera e poi spostandomi verso l'esterno.

Modifica: non funziona a meno che non sia possibile disegnare i contenuti di ciascuna cella singolarmente.

Cosa ti fa credere che sia "matematicamente dimostrabile che esista almeno un ordine di sorteggio per soddisfare le esigenze problematiche"? Ecco un banale controesempio in cui non puoi fare affidamento su oggetti di ordinamento z: