Moduli multipli e un unico aggiornamento, funzionerà?

Question

Devo creare un'applicazione in .NET CF con moduli diversi/singoli con molti disegni/animazioni su ciascun modulo. Preferirei avere una singola funzione di aggiornamento [la mia per la gestione dello stato e così via] in modo da poterla gestire i diversi stati, in modo che il mio [codice di gioco J2ME] funzioni senza grandi modifiche. Sono arrivato ad alcuni possibili scenari.Quale sarà perfetto?

1. Avere un unico modulo e aggiungere/eliminare manualmente i controlli, quindi utilizzare uno qualsiasi dei trucchi di gamelooping.
2. Crea moduli diversi con controlli e chiama update e application.doEvents() nel thread principale.[ while(isAppRunning){ UPDATE() Application.DoEvents() }
3. Crea un aggiornamento: dipingi il ciclo su ciascun modulo come richiesto.
4. Qualsiasi altra idea.

Per favore dammi un suggerimento in merito

Answer 1

Se è un gioco, eliminerei la maggior parte dei moduli e lavorerei con gli elementi essenziali, lavorerei su una bitmap se possibile e la renderei sovrascrivendo il metodo di disegno del modulo principale o un controllo che risiede al suo interno (forse un pannello).Questo ti darà prestazioni migliori.

Il problema principale è che il framework compatto non è realmente progettato per un sacco di divertimento dell'interfaccia utente, non ottieni il doppio buffering gratuitamente come nel framework completo, la corretta trasparenza ha a che fare con i controlli WinForm e se ti aggrappi a il thread dell'interfaccia utente per un po' troppo a lungo si verificheranno seri problemi di rendering.Diavolo, potresti anche ottenerli se fai troppo sui thread in background!:O

Non otterrai mai prestazioni ottimali chiamando esplicitamente Application.DoEvents, la mia regola pratica è di usarlo solo durante la risoluzione dei problemi o la scrittura di piccoli hack nell'interfaccia utente.

Potrebbe valere la pena attaccare il gioco su un thread in background e quindi chiamare .Invoke sul controllo per eseguire il marshalling sul thread principale dell'interfaccia utente per aggiornare il display lasciando all'interfaccia utente tutto il tempo per rispondere e gestire anche l'input dell'utente.L'input dell'utente è un altro motivo per cui evito i normali controlli winform, poiché i dispositivi mobili generalmente non hanno molti tasti, è molto utile poterli rimappare, quindi generalmente evito cose come TextBox che hanno eventi/risposte chiave preimpostate.

Eviterei anche di utilizzare moduli diversi poiché mostrare un nuovo modulo può fornire una pausa sottile, generalmente scambio i controlli in un modulo principale per evitare questo problema durante la scrittura di software aziendale.

Alla fine probabilmente vale la pena sperimentare varie tecniche per vedere cosa funziona al meglio.Vedi anche se riesci a ottenere qualche consiglio da persone che sviluppano giochi su CF poiché generalmente mi occupo solo di software aziendale.

HTH!