Newsgroup: it.comp.java
Titolo: Creare giochi 2D in Java

Salve a tutti,
per chi fosse interessato sul sito 
www.gameprog.it
  nella sezione
Linguaggi-Java c'è un tutorial scritto da me per creare videogiochi 2D
in FullScreen. Dategli un'occhiata se vi interessa l'argomento oppure
date qualche opinione. Grazie a tutti! :)


Ciao, innanzitutto i miei complimenti!
Inizialmente non riuscivo a capire come rintracciare l'articolo, per cui
mi permetto di postare il link diretto :)
http://www.gameprog.it/index.php?resource=995
Tempo fa (quando potevo :)) mi dilettai anch'io a creare un
miniframework per applicazioni 2D. Il double buffering lo realizzavo "a
mano" mediante una bufferedImage, l'animazione ne veniva fuori
sufficientemente fluida e veloce; ma immagino che l'utilizzo del
BufferStrategy dia dei vantaggi rispetto a questa tecnica giusto?
Se mi è consentito :) mi permetto solo un piccolo appunto relativo alla
performance. Il loop principale che muove il gioco, gameLoop(), chiama
internamente il metodo draw() e successivamente fa la chiamata a
Thread.sleep() per ogni ciclo. Immagino che il metodo draw() andrà
completato in seguito col disegno vero e proprio del gioco (per ora
disegna soltanto lo sfondo). Questo metodo sarà quindi quello più
dispendioso in termini di risorse.
Ora mi chiedo, come mai il loop principale rimane in attesa senza far
nulla per tot millisecondi quando c'è tanto lavoro da fare per calcolare
la schermata successiva?
Per ovviare al problema io facevo eseguire il lavoro da due thread
paralleli: uno che si occupa dello switch del buffer a video e uno che
calcola le schermate. Il secondo thread non fa mai un vero e proprio
sleep(), ma tramite una wait() sul primo thread aspetta semplicemente il
momento per poter riprendere a calcolare la schermata successiva. Tale
momento è l'istante immediatamente successivo a quello in cui il primo
thread ha finito di riportare a video il buffer. In questo modo mentre
il giocatore sta vedendo un frame a video il gioco sta già preparando il
  successivo, e il timing deill'animazione è più "garantito".
Ovviamente poi esistono varie situazioni da gestire; in caso di calcoli
complessi il gioco dovrebbe anche essere in grado di "saltare" tot frame
pur di non dare un feedback di lentezza etc.; tutte cose comunque
gestibili attraverso i due thread paralleli e una gestione accurata
della sincronizzazione.
Mi rendo comunque conto che per rispetto alla leggibilità dell'articolo
non si poteva entrare così nel dettaglio. Magari qualche appendice in
seguito... :P
Inoltre non ho capito bene il motivo per cui fai il dispose() del
contesto grafico ad ogni frame. Secondo la documentazione
"For efficiency, programmers should call dispose when finished using a
Graphics object only if it was created directly from a component or
another Graphics object."
Visto che generalmente nei giochi 2D si utilizza l'algoritmo del pittore
(disegni lo sfondo, poi sopra i vari sprites) la cosa più logica non
sarebbe mentenere sempre lo stesso riferimento alla variabile g e ogni
volta "ridipingerci" sopra?
Scusa la prolissità, ma si tratta di un argomento che mi ha sempre
coinvolto molto (sfortunatamente non al punto che mi sarebbe piaciuto :))
Nel complesso un bell'articolo, "succoso" di codice e dal design ben
impostato. Sarò sicuramente tra i lettori del seguito ;)
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it