Diamonds for SDL: first release

[cdimauro]

La prima versione del porting di Diamonds per le SDL è finitoe ed è disponibile nel repository in branches/SDL.

PER USARLO

1) vi consiglio di effettuare un checkout completo del progetto;
2) le librerie SDL (non SDLJava) che stanno in libs/win32 devono essere raggiungibili dal path di sistema;
3) la libreria jpeg.dll dev'essere la prima a esser raggiunta dal path di sistema; purtroppo è diversa da quella che si trova nek JDK o nella JRE (io ho dovuto cambiare il nome a quelle presenti in jdk/bin e jre/bin).

TODO

1) La pulsazione: non sono riuscito a trovare la libreria sdlgfx.dll, che implementa delle API per la rotazione, lo zoom, ecc., per cui tutte le texture (in SDL si chiamano "Surface" ) vengono disegnate sempre allo stesso modo; si potrebbe al limite realizzare un'artiginale routine di zoom.
2) Per Linux e MacOS X c'è da aggiungere le rispettive librerie (.so e .dynlibs, mi pare) e testare se tutto funziona.
3) C'è da implementare gli alertbox che in LWJGL sono implementate in org.lwjgl.Sys (mi pare).

NOTE SUL CODICE

Ho cercato di togliere di mezzo tutti i riferimenti al carattere "/" come separatore per i nomi di file, sostituendolo con l'apposita API che Java mette a disposizione.
Ho eliminato qualche test di Sound, in quanto divenuto inutile.
Ho modificato DisplayInterface ed EngineInterface, spostando drawQuad in esse, e cambiandole nome in drawTexture (che è più comprensibile).
A Texture ho dovuto aggiungere il metodo pubblico getSurface(), che restituisce una SDLSurface, necessaria per effettuare il blitting di quest'immagine sullo schermo (SDL funziona in modo diverso da LWJGL/OpenGL, per cui era necessario).
GameLoop adesso estende KeyboardListener e mantiene un suo mapping per la tastiera (è stato aggiunto anche a KeyMapping un create appositamente per GameLoop). Questo si è reso necessario per poter intercettare la pressione del tasto Escape e del "tasto" Quit (la chiusura della finestra) in quanto non era possibile uscire da Diamonds (dipendeva soltanto dalla chiusura della finestra, che in SDL è un evento come un altro ed è gestito quindi come tastiera, mouse, joystick, eventi di sistema, ecc.).
Ho dovuto modificare molti test per aggiungere la creazione di un oggetto Audio, in quanto senza engine audio attivato non era possibile caricare i suoni (questo, comunque, era dovuto al fatto che non veniva usato Sound.createForTesting(), come ho scritto nell'altro test).
Ho dovuto modificare la creazione e la finalizzazione degli oggetti (in BootStrap). Adesso l'ordine è engine, audio, tastiera per la creazione e l'opposto per la finalizzazione. Questo perché engine crea e inizializza il subsystem "principale".

Purtroppo mi rendo conto che alcune parti del codice andrebbero risistemate, e soprattutto aggiunti dei test, ma il mio obiettivo era quello di cercare di far funzionare Diamonds con le SDL, cercando di modificare quanto meno possibile il codice esistente, specialmente a livello di "interfaccia".

Scusatemi per questo, e se mi sono sfuggite altre cose che dovevo dire, ma ho effettuato troppe modifiche per ricordarmi di tutti i cambiamenti.

Se qualcuno può effettuare qualche test e riportarmi le sue impressioni, mi farebbe cosa assai gradita.

[Jocchan]

Grandissimo

[VICIUS]

Interessante. A prestazioni video come sono cambiate le cose?

ciao

[cdimauro]

Sinceramente non ti so dire: il gioco mi sembra fluido e senza scatti, e la JVM sulla mia macchina gira intorno all'80-90% della CPU.

Comunque ci sono diversi margini di miglioramento, perché è possibile:
- utilizzare l'accelerazione hardware (in full screen, se non ricordo male);
- utilizzare il double buffering;
- utilizzare la memoria video anziché quella di sistema per lo schermo e per le immagini (superfici);
- convertire le immagini caricate nel formato dello schermo (attualmente le carico e basta: poi è la routine di blitting che si occupa delle conversioni nel pixel format usato dallo schermo).

Per i primi 3 punti dipende chiaramente dalla capacità della piattaforma di supportare queste caratteristiche.

Altri benefici che si hanno sono i seguenti:
- immagini di dimensioni arbitrarie, e quindi non più con coordinate che devono essere potenze di 2 (e questo permetterà un consistente risparmo di spazio);
- numerosi formati supportati per le immagini;
- accesso diretto alle superfici (memoria di sistema o memoria video), e quindi la possibilità di implementare velocemente e in maniera efficiente manipolazioni sui pixel;
- utilizzo di font true type (serve la dll freetype);
- utilizzo di numerosissime API per primitive grafiche (tra cui lo zoom, che c'interessa per la pulsazione), anche con antialiasing, con la libreria gfx (serve la sdlgfx.dll);
- possibilità di caricare e suonare musiche in formato MOD (.mod .xm .s3m .669 .it .med e altri) e MIDI;
- possibilità di caricare e suonare, oltre ai .wav, anche .aiff, .voc e formati compressi come .ogg e .mp3 (con le apposite .dll);
- numero di canali per i sample molto elevato (di default, come dagli esempi che ho visto, obbligo il mixer a crearne 32, ma c'è scritto che si può andare anche ben oltre );
- gestione del fade dei sample e delle musiche;
- gestione di panning, distance ed eventuali effetti custom per i canali audio;
- gestione "centralizzata" e "omogenea" (discendono tutti dalla stessa classe) di tutti gli eventi di input (tastiera, mouse, joystick ed eventi di sistema);
- accesso al CD-ROM (non ce ne frega niente, ma non si sa mai );
- possibilità di usare le OpenGL (in maniera similare a LWJGL) e una libreria per le font per OpenGL.

Una cosa molto importante, per risparmiare molta memoria, sarebbe quella di implementare un sistema di "caching" per le immagini e i sample .wav: basta averne una copia in memoria, condivisa da tutti gli oggetti che ne fanno uso. Non so se questo avviene già adesso, non ho controllato.

Comunque devo dire che mi ha impressionato Diamonds: dopo aver finito il porting, alla prima esecuzione già funzionava!!!
Questo è indice di un buon design e di un ottimo lavoro: complimenti a tutti!

[cdimauro]

Ho aggiunto il codice per liberare la memoria utilizzata a Texture.cleanup().

ho aggiunto la libreria SDL_gfx.dll per poter usare le API di SDLGfx (ci sono un sacco di funzioni utili, come dicevo prima, tra cui quelle di zoom), e ho scritto il codice per effettuare lo zoom (e quindi la pulsazione delle gemme), ma purtroppo non funziona perché non riesce inizializzare correttamente questa libreria; anche eseguendo il test in dotazione a SDLJava, testgfx.bat che si trova nella cartella bin, ottengo lo stesso errore:

C:\T\sdljava-0.9.1>java -cp .\lib\sdljava.jar -Djava.library.path=.\lib sdljavax.gfx.SDLGfxTest
Native code library failed to load.
java.lang.UnsatisfiedLinkError: C:\T\sdljava-0.9.1\lib\SDLJava_gfx.dll: Routine di inizializzazione della libreria di collegamento dinamico (DLL) non riuscita

E' possibile, quindi, che la libreria SDL_gfx.dll che ho trovato non sia compatibile con SDLJava.dll o SDL.dll, ma non ne ho trovate altre.
Per cui ho dovuto commentare il codice (si trova in DisplayImplementation)) che effettuare lo zoom.

Ho aggiunto anche due righe di codice per convertire l'immagine caricata nel formato dello schermo. Già solo questo ha aumentato notevolmente la velocità di esecuzione, e la CPU si assesta sul 50-60%; il gioco, tra l'altro, sembra molto più fluido.
Sfortunatamente ho dovuto commentare anche questo codice (si trova in Texture.loadFromFile), perché eseguendo la build con ant alcuni test fallivano. Questo succede perché, non essendo stato inizializzato / aperto nessuno schermo (ma soltanto l'engine video), non la conversione non è ovviamente possibile.

Da tutto ciò penso che per Diamonds sia necessario separare ulteriormente il confine fra il codice di produzione e quello di test. In fase di test non esistono schermi e canali audio, e alcune API di SDL non funzionano di conseguenza.
Il lavoro non è facile, visto che ci sono troppi test che non fanno uso delle versioni createForTesting() delle istanze create (e bisognerebbe creare questo metodo anche per Texture, a questo punto).

Cosa ne pensate?

[Ufo13]

Intanto sarebbe utile vedere se cisc risolve con le SDL e cominciare a valutare l'importanza del passaggio.

Più che altro ora come ora ci sono molte attività ad alta priorità da svolgere

Cisc ci sai dire qualcosa?

[cdimauro]

Perfettamente d'accordo. Infatti finché non si prende una decisione io non posso continuare, ma per prenderla bisogna che il porting SDL venga testato, possibilmente da tutti (mancano gli ambienti Linux e MacOS X, ad esempio).

[cdimauro]

Ho finalmente trovato una libreria SDL_gfx.dll funzionante. L'ho aggiunta alle altre, e ho messo pure smpeg.dll, che serve per caricare file audio .mp3.

Ho modificato il codice per lo zoom, e adesso funziona, anche se c'è qualche problemino da risolvere con la maschera per l'alpha channel.

Senza convertire le immagini nello stesso formato dello schermo l'esecuzione diventa più pesante.
Con la conversione, invece, la CPU si mantiene sul 50-60%, come prima.

Per questo fine settimana è tutto. Non ho altro tempo da dedicarci.

Invito, nuovamente, a tutti (ognuno in base alle proprie possibilità) di testare questa versione di Diamonds per le SDL, e di riportare eventuali problemi, osservazioni o idee.

[fek]

Ottimo, ottimo lavoro. Soprattutto perche' ha portato alla luce diverse magagne nel codice del trunk che hanno bisogno di refactoring.

Non so se sia il caso di passare a SDL oppure no, ma penso che la stada giusta da seguire sia di migliorare ancora la separazione fra engine e game code, di migliorare la separazione fra test code e game code come suggerito da Cesare e di far convergere tutto il codice esterno all'engine verso una versione comune ai due branch. Quindi io implementerei pian piano in versione testata i refactoring che Cesare ha fatto sulla versione SDL. Quando le due versioni saranno abbastanza simili, potremmo valutare uno switch indolore fra gli engine con piu' precisione.

Cesare ti occupi tu di portare i refactoring anche nel main trunk? Soprattutto la classe game come InputListener mi pare un'ottima idea.

[cdimauro]

OK Fran, me ne occupo io, ma adesso e questo fine settimana non posso. Se ne parla lunedì.

Fortunatamente sotto Windows ho Total Commander che mi dà un grande aiuto Santo Windows.

Ho già qualche idea per sistemare engine e display, in modo da avere un'interfaccia quanto più generale possibile. Penso di introdurre anche un'interfaccia per Audio, Sound e Texture, e far convergere tutto il codice legato alla libreria nelle rispettive "Implementation".

[fek]

Perfetto. Prosegui pure.

[cisc]

scusatemi, mi sto preparando un esame tosto per lunedì, quindi fino ad allora non riesco a seguirvi costantemente, adesso faccio il checkout del porting di cdimauro, e vi faccio sapere se sdl risolve i miei problemi....