Rubberick
04-05-2006, 09:40
Che ne pensate? e' un'idea fattibile o una cavolata assurda? ovviamente sarebbe un qualcosa tipo single player a punti... ne girano di cosi' schifosi di giochi sui cell sarebbe la volta buona che passa qualcosa di figo ^^
View Full Version : Diamond Crush sul Cellulare
cionci
04-05-2006, 09:43
Fek aveva già fatto una prova... Comunque credo che siano necessarie molte modifiche... Il numero di classi, interfacce e packages di Diamonds sarebbe troppo elevato...
fek
04-05-2006, 10:14
Fek aveva già fatto una prova... Comunque credo che siano necessarie molte modifiche... Il numero di classi, interfacce e packages di Diamonds sarebbe troppo elevato...
Dipende dal modello di cellulare che vogliamo supportare. MIDP2 non grandi limitazioni rispetto a Diamonds, ci girerebbe quasi nella sua interezza (ovviamente un solo schermo). Avevo inizato il porting, ho una gemma di Diamonds sul mio cellulare :)
Mi sono bloccato perche':
- Mi e' piombato addosso il GDC 2006
- Non avevo un'idea chiara su come condividere codice fra due progetti diversi in Eclipse
- Non riuscivo a far funzionare Antenna, l'Ant task per fare il build di MIDP
- Java mobile supporta solo 1.4
Il primo problema e' risolto :)
Se qualcuno puo' aiutarmi sul secondo problema ne sarei grato. Il terzo problema richiede solo un po' di sbattimento. Il quarto problema richiede la riscrittura di un po' di codice ma nenmmeno troppo.
Non escludo che alla fine del progetto si possa fare un porting per cellulari, non dovremmo impiegare troppo, uno o due mesi secondo me.
Dipende dal modello di cellulare che vogliamo supportare. MIDP2 non grandi limitazioni rispetto a Diamonds, ci girerebbe quasi nella sua interezza (ovviamente un solo schermo). Avevo inizato il porting, ho una gemma di Diamonds sul mio cellulare :)
Mi sono bloccato perche':
- Mi e' piombato addosso il GDC 2006
- Non avevo un'idea chiara su come condividere codice fra due progetti diversi in Eclipse
- Non riuscivo a far funzionare Antenna, l'Ant task per fare il build di MIDP
- Java mobile supporta solo 1.4
Il primo problema e' risolto :)
Se qualcuno puo' aiutarmi sul secondo problema ne sarei grato. Il terzo problema richiede solo un po' di sbattimento. Il quarto problema richiede la riscrittura di un po' di codice ma nenmmeno troppo.
Non escludo che alla fine del progetto si possa fare un porting per cellulari, non dovremmo impiegare troppo, uno o due mesi secondo me.
thebol
04-05-2006, 10:40
Dipende dal modello di cellulare che vogliamo supportare. MIDP2 non grandi limitazioni rispetto a Diamonds, ci girerebbe quasi nella sua interezza (ovviamente un solo schermo). Avevo inizato il porting, ho una gemma di Diamonds sul mio cellulare :)
Mi sono bloccato perche':
- Mi e' piombato addosso il GDC 2006
- Non avevo un'idea chiara su come condividere codice fra due progetti diversi in Eclipse
- Non riuscivo a far funzionare Antenna, l'Ant task per fare il build di MIDP
- Java mobile supporta solo 1.4
Il primo problema e' risolto :)
Se qualcuno puo' aiutarmi sul secondo problema ne sarei grato. Il terzo problema richiede solo un po' di sbattimento. Il quarto problema richiede la riscrittura di un po' di codice ma nenmmeno troppo.
Non escludo che alla fine del progetto si possa fare un porting per cellulari, non dovremmo impiegare troppo, uno o due mesi secondo me.
quale parte di codice vorresti dividere?
potrei pensarci io.
Mi sono bloccato perche':
- Mi e' piombato addosso il GDC 2006
- Non avevo un'idea chiara su come condividere codice fra due progetti diversi in Eclipse
- Non riuscivo a far funzionare Antenna, l'Ant task per fare il build di MIDP
- Java mobile supporta solo 1.4
Il primo problema e' risolto :)
Se qualcuno puo' aiutarmi sul secondo problema ne sarei grato. Il terzo problema richiede solo un po' di sbattimento. Il quarto problema richiede la riscrittura di un po' di codice ma nenmmeno troppo.
Non escludo che alla fine del progetto si possa fare un porting per cellulari, non dovremmo impiegare troppo, uno o due mesi secondo me.
quale parte di codice vorresti dividere?
potrei pensarci io.
fek
04-05-2006, 11:17
quale parte di codice vorresti dividere?
potrei pensarci io.
Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.
potrei pensarci io.
Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.
thebol
04-05-2006, 11:28
Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.
basta creare 2 progetti(game e engine).
Poi game si linkera a engine(o al futuro engine_cell). I riferimenti non possono essere incrociati(il progetto game puo usare il progetto engine, ma non viceversa).
Stasera provo a individuare la parte di engine, ne discutiamo e poi provo a dividerle.
Risultato ci troveremo 2 progetti da dover sincronizzare(che può portare parecchi vantaggi)
basta creare 2 progetti(game e engine).
Poi game si linkera a engine(o al futuro engine_cell). I riferimenti non possono essere incrociati(il progetto game puo usare il progetto engine, ma non viceversa).
Stasera provo a individuare la parte di engine, ne discutiamo e poi provo a dividerle.
Risultato ci troveremo 2 progetti da dover sincronizzare(che può portare parecchi vantaggi)
Rubberick
04-05-2006, 11:41
a questo punto dopo aver fatto tutte le revisioni del caso per la prox release di diamonds vi converrebbe riordinare la struttura delle directory nell'svn ;)
appro :p fek ti ricordo che i backup sono ancora li e hanno raggiunto la bella cifra di 900mb :P quando ti logghi e fai un po' di pulizia?
appro :p fek ti ricordo che i backup sono ancora li e hanno raggiunto la bella cifra di 900mb :P quando ti logghi e fai un po' di pulizia?
fek
04-05-2006, 11:57
basta creare 2 progetti(game e engine).
Poi game si linkera a engine(o al futuro engine_cell). I riferimenti non possono essere incrociati(il progetto game puo usare il progetto engine, ma non viceversa).
Stasera provo a individuare la parte di engine, ne discutiamo e poi provo a dividerle.
Risultato ci troveremo 2 progetti da dover sincronizzare(che può portare parecchi vantaggi)
thebol, ne parliamo un po' piu' in la'? Ora il refactoring che stai facendo e' molto piu' importante.
Rubbe, lo so, sono colpevole, lo devo fare :)
Poi game si linkera a engine(o al futuro engine_cell). I riferimenti non possono essere incrociati(il progetto game puo usare il progetto engine, ma non viceversa).
Stasera provo a individuare la parte di engine, ne discutiamo e poi provo a dividerle.
Risultato ci troveremo 2 progetti da dover sincronizzare(che può portare parecchi vantaggi)
thebol, ne parliamo un po' piu' in la'? Ora il refactoring che stai facendo e' molto piu' importante.
Rubbe, lo so, sono colpevole, lo devo fare :)
^TiGeRShArK^
04-05-2006, 14:18
immagno che potrei dare una mano qui..
diciamo che una certa esperienza in questo campo ce l'ho ;)
..anke se ho sempre usato ant anzikè antenna :mbe:
devo imparare ad usare quello perkè immagino ke sia molto + facile :sofico:
diciamo che una certa esperienza in questo campo ce l'ho ;)
..anke se ho sempre usato ant anzikè antenna :mbe:
devo imparare ad usare quello perkè immagino ke sia molto + facile :sofico:
cdimauro
05-05-2006, 11:31
Col refactoring di Engine, Audio, Keyboard, ecc. a cui sto lavorando dovrebbe essere molto più semplice effettuare il porting per qualunque piattaforma.
jappilas
14-05-2006, 14:15
un mio amico mi ha messo la pulce nell' orecchio ieri sull' utilizzo di cellulari Bluetooth...
perchè non usarli non come piattaforma di gioco ma come dispositivo di input (a mo' di gamepad wireless :D) per il multiplayer?
utilità e fattibilità di una cosa simile secondo voi, ? :mbe: :D
perchè non usarli non come piattaforma di gioco ma come dispositivo di input (a mo' di gamepad wireless :D) per il multiplayer?
utilità e fattibilità di una cosa simile secondo voi, ? :mbe: :D
71104
14-05-2006, 21:37
hum, come cavolo facciamo a stabilire la connessione via Blue Tooth... io non so niente di Blue Tooth, comunque l'idea del tuo amico è carina; però la lascerei come opzione, nel senso che la possibilità di giocare solo sul cellulare secondo me deve esserci :)
cdimauro
15-05-2006, 09:21
Quando sarà terminata l'ultima grande rifattorizzazione, che riguarda Keyboard & Event, sarà molto semplice realizzare quanto chiesto. ;)
fek
15-05-2006, 10:23
Quando sarà terminata l'ultima grande rifattorizzazione, che riguarda Keyboard & Event, sarà molto semplice realizzare quanto chiesto. ;)
E sara' anche molto YAGNI :D
E sara' anche molto YAGNI :D
cdimauro
15-05-2006, 10:31
La rifattorizzazione o il porting per i cellulari? :fiufiu:
jappilas
15-05-2006, 12:39
La rifattorizzazione o il porting per i cellulari? :fiufiu:
credo il fatto di usare i cell come gamepad :D
credo il fatto di usare i cell come gamepad :D
thebol
20-05-2006, 21:22
Voglio che grosse porzioni del codice del gioco siano condivise, mentre l'engine sia sostituito interamente.
Ho fatto l'esperimento di togliere dal progetto le librerie ogl e audio, e le classi che danno errore(cioè che si potrebbero spostare) sono 6(quelle che incominciano con OpenAl e LWJGL, ottima nomenclatura =D ).
Poi falliscono anche game e gameLoop perche utilizzano l'oggetto Sys di lwjgl per scrivere il msg box di errore e di info in caso di no audio, e per ottenere le info dell adapter e la versione del display.
Incorporando queste 2 funzioni in displayInterface, penso si possa dividere il gioco dall'implementazione che ci gira sotto =D
Ho fatto l'esperimento di togliere dal progetto le librerie ogl e audio, e le classi che danno errore(cioè che si potrebbero spostare) sono 6(quelle che incominciano con OpenAl e LWJGL, ottima nomenclatura =D ).
Poi falliscono anche game e gameLoop perche utilizzano l'oggetto Sys di lwjgl per scrivere il msg box di errore e di info in caso di no audio, e per ottenere le info dell adapter e la versione del display.
Incorporando queste 2 funzioni in displayInterface, penso si possa dividere il gioco dall'implementazione che ci gira sotto =D
cionci
21-05-2006, 10:28
Però non hai considerato che per J2ME sei obbligato a compilare per Java 1.4...
thebol
21-05-2006, 10:55
Però non hai considerato che per J2ME sei obbligato a compilare per Java 1.4...
pensavo piu al fatto di dividere il gioco dal motore video e audio.
Il fatto della 1.4, sarà il problema piu grosso...
Si potrebbe fare del refactoring(in eclipse cè un framework per realizzare funzioni di refactoring), oppure fare un parser, che trasformi i template e i for each in costrutti java 1.4 compatibili(non è banale, ma neanche impossibile).
pensavo piu al fatto di dividere il gioco dal motore video e audio.
Il fatto della 1.4, sarà il problema piu grosso...
Si potrebbe fare del refactoring(in eclipse cè un framework per realizzare funzioni di refactoring), oppure fare un parser, che trasformi i template e i for each in costrutti java 1.4 compatibili(non è banale, ma neanche impossibile).
thebol
21-05-2006, 11:04
Compatibility compilation (Use Java 1.5 language features with Java 1.4 VMs)
Depending on the VM compatibility setting in the Build | Internal build section of the Project Settings dialog CodeGuide can generate .class files compatible with a specific VM version. With this feature applications using Java 1.5 language features can be run on Java 1.4 VMs. In contrast to Sun's protoype modification of the bootclasspath or including any custom JAR files is not necessary.
appena scoperto =D
ora mi informo meglio
Depending on the VM compatibility setting in the Build | Internal build section of the Project Settings dialog CodeGuide can generate .class files compatible with a specific VM version. With this feature applications using Java 1.5 language features can be run on Java 1.4 VMs. In contrast to Sun's protoype modification of the bootclasspath or including any custom JAR files is not necessary.
appena scoperto =D
ora mi informo meglio
thebol
21-05-2006, 11:10
appena scoperto =D
ora mi informo meglio
ho provato in eclipse, ma sembra che si possa solo forzare a genere codice 1.4 compatibile con la 1.5, non viceversa...
ora mi informo meglio
ho provato in eclipse, ma sembra che si possa solo forzare a genere codice 1.4 compatibile con la 1.5, non viceversa...
thebol
21-05-2006, 11:15
infatti...
Downward source compatibility is not supported. If source files use new language features or Java 2 platform APIs, they will not be usable with an earlier version of the Java platform.
Downward source compatibility is not supported. If source files use new language features or Java 2 platform APIs, they will not be usable with an earlier version of the Java platform.
cdimauro
22-05-2006, 09:25
Ho fatto l'esperimento di togliere dal progetto le librerie ogl e audio, e le classi che danno errore(cioè che si potrebbero spostare) sono 6(quelle che incominciano con OpenAl e LWJGL, ottima nomenclatura =D ).
:)
Poi falliscono anche game e gameLoop perche utilizzano l'oggetto Sys di lwjgl per scrivere il msg box di errore e di info in caso di no audio, e per ottenere le info dell adapter e la versione del display.
Purtroppo ho cercato fra le classi delle librerie di Java se ne ce fosse qualcuna per poterlo sostituire, ma non ho trovato niente del genere.
Si potrebbe utilizzare AWT o qualcosa di simile, ma al pensiero di far caricare 600 (per AWT) classi per un banale "Hello, world", mi vengono le crisi.
Incorporando queste 2 funzioni in displayInterface, penso si possa dividere il gioco dall'implementazione che ci gira sotto =D
Io DisplayInterface pensavo di eliminarla del tutto, visto che c'è già EngineInterface, e le sue API non fanno altro che richiamare le corrispondenti dell'istanza di DisplayInterface.
In sostanza, visto che adesso il Diamonds è regolato (quasi) interamente dalle interfacce (a parte KeyMappings che dev'essere ancora fatto fuori), si tratta di un'interfaccia (e implementazione) ridondante.
Infatti MockEngine implementa EngineInterface, ma non DisplayInterface. ;)
:)
Poi falliscono anche game e gameLoop perche utilizzano l'oggetto Sys di lwjgl per scrivere il msg box di errore e di info in caso di no audio, e per ottenere le info dell adapter e la versione del display.
Purtroppo ho cercato fra le classi delle librerie di Java se ne ce fosse qualcuna per poterlo sostituire, ma non ho trovato niente del genere.
Si potrebbe utilizzare AWT o qualcosa di simile, ma al pensiero di far caricare 600 (per AWT) classi per un banale "Hello, world", mi vengono le crisi.
Incorporando queste 2 funzioni in displayInterface, penso si possa dividere il gioco dall'implementazione che ci gira sotto =D
Io DisplayInterface pensavo di eliminarla del tutto, visto che c'è già EngineInterface, e le sue API non fanno altro che richiamare le corrispondenti dell'istanza di DisplayInterface.
In sostanza, visto che adesso il Diamonds è regolato (quasi) interamente dalle interfacce (a parte KeyMappings che dev'essere ancora fatto fuori), si tratta di un'interfaccia (e implementazione) ridondante.
Infatti MockEngine implementa EngineInterface, ma non DisplayInterface. ;)
thebol
22-05-2006, 09:33
:)
Io DisplayInterface pensavo di eliminarla del tutto, visto che c'è già EngineInterface, e le sue API non fanno altro che richiamare le corrispondenti dell'istanza di DisplayInterface.
Beh si potrebbero cmq infilare in quell'interfaccia. Le info sono a questo punto correlate con l'engine. Per le infoBox possiamo fare che l'engine fornisce un metodo per mostrare errori :)
Io DisplayInterface pensavo di eliminarla del tutto, visto che c'è già EngineInterface, e le sue API non fanno altro che richiamare le corrispondenti dell'istanza di DisplayInterface.
Beh si potrebbero cmq infilare in quell'interfaccia. Le info sono a questo punto correlate con l'engine. Per le infoBox possiamo fare che l'engine fornisce un metodo per mostrare errori :)
cdimauro
22-05-2006, 12:06
Il problema è che SDL, ad esempio, non mi sembra che abbia un'API standard per far apparire un messaggio d'errore.
E lo stesso si potrebbe verificare coi telefonini.
L'API la possiamo mettere a disposizione comunque: sarà l'implementatore poi a farsi carico di implementarla in qualche maniera.
E lo stesso si potrebbe verificare coi telefonini.
L'API la possiamo mettere a disposizione comunque: sarà l'implementatore poi a farsi carico di implementarla in qualche maniera.
fek
22-05-2006, 12:11
Ho fatto l'esperimento di togliere dal progetto le librerie ogl e audio, e le classi che danno errore(cioè che si potrebbero spostare) sono 6(quelle che incominciano con OpenAl e LWJGL, ottima nomenclatura =D ).
Gran lavoro di Cesare. E' interessante notare come abbiamo ottenuto un quasi perfetto disaccoppiamento fra il gioco e l'engine a basso livello senza imporre il design up front, ma semplicemente rifattorizzando il codice di volta in volta.
Gran lavoro di Cesare. E' interessante notare come abbiamo ottenuto un quasi perfetto disaccoppiamento fra il gioco e l'engine a basso livello senza imporre il design up front, ma semplicemente rifattorizzando il codice di volta in volta.
thebol
22-05-2006, 12:17
Il problema è che SDL, ad esempio, non mi sembra che abbia un'API standard per far apparire un messaggio d'errore.
E lo stesso si potrebbe verificare coi telefonini.
L'API la possiamo mettere a disposizione comunque: sarà l'implementatore poi a farsi carico di implementarla in qualche maniera.
esatto, se sdl non ha quella funzione, userà awt/swing/console per mostrare l'errore :)
E lo stesso si potrebbe verificare coi telefonini.
L'API la possiamo mettere a disposizione comunque: sarà l'implementatore poi a farsi carico di implementarla in qualche maniera.
esatto, se sdl non ha quella funzione, userà awt/swing/console per mostrare l'errore :)
cdimauro
22-05-2006, 12:27
Ci siamo capiti perfettamente: è esattamente quello che avevo in mente. :)
x fek. Grazie per i complimenti.
x fek. Grazie per i complimenti.
^TiGeRShArK^
23-05-2006, 17:18
:)
Purtroppo ho cercato fra le classi delle librerie di Java se ne ce fosse qualcuna per poterlo sostituire, ma non ho trovato niente del genere.
Si potrebbe utilizzare AWT o qualcosa di simile, ma al pensiero di far caricare 600 (per AWT) classi per un banale "Hello, world", mi vengono le crisi.
ehm...
non ho capito... :mbe:
x MIDP non è possibile usare le awt, ma solo un suo sottoinsieme...
L'equivalente del popup di errore è l'alert.
Per utilizzare l'alert è sufficiente fare Display.getDisplay(diamondMidlet).setCurrent(errorAlert);
dove diamondMidlet è la midlet della nostra applicazione e errorAlert è l'alert di errore da visualizzare.
Purtroppo ho cercato fra le classi delle librerie di Java se ne ce fosse qualcuna per poterlo sostituire, ma non ho trovato niente del genere.
Si potrebbe utilizzare AWT o qualcosa di simile, ma al pensiero di far caricare 600 (per AWT) classi per un banale "Hello, world", mi vengono le crisi.
ehm...
non ho capito... :mbe:
x MIDP non è possibile usare le awt, ma solo un suo sottoinsieme...
L'equivalente del popup di errore è l'alert.
Per utilizzare l'alert è sufficiente fare Display.getDisplay(diamondMidlet).setCurrent(errorAlert);
dove diamondMidlet è la midlet della nostra applicazione e errorAlert è l'alert di errore da visualizzare.
cdimauro
24-05-2006, 08:42
Ho fatto qualche ricerca su Display e alert, ma non ho trovato niente. :(
OK, visto che te ne intendi, dire che abbiamo un volontario per realizzare questa parte. :D
OK, visto che te ne intendi, dire che abbiamo un volontario per realizzare questa parte. :D
^TiGeRShArK^
24-05-2006, 14:08
Ho fatto qualche ricerca su Display e alert, ma non ho trovato niente. :(
OK, visto che te ne intendi, dire che abbiamo un volontario per realizzare questa parte. :D
infatti mi ero già proposto prima :D
mmagno che potrei dare una mano qui..
diciamo che una certa esperienza in questo campo ce l'ho
..anke se ho sempre usato ant anzikè antenna
devo imparare ad usare quello perkè immagino ke sia molto + facile
cmq non sarà un lavoro semplicissimo....
purtroppo abbiamo parecchio codice java5 che non potrà esistere in alcun modo sul telefonino....
e abbiamo anke limitazioni sul tipo di classi....
ad esempio non esiste ArrayList ma c'è solo Vector tnt x dirne una.....
cmq secondo me la cosa + logica da fare sarebbe finire diamonds su pc e poi fare il porting.....
OK, visto che te ne intendi, dire che abbiamo un volontario per realizzare questa parte. :D
infatti mi ero già proposto prima :D
mmagno che potrei dare una mano qui..
diciamo che una certa esperienza in questo campo ce l'ho
..anke se ho sempre usato ant anzikè antenna
devo imparare ad usare quello perkè immagino ke sia molto + facile
cmq non sarà un lavoro semplicissimo....
purtroppo abbiamo parecchio codice java5 che non potrà esistere in alcun modo sul telefonino....
e abbiamo anke limitazioni sul tipo di classi....
ad esempio non esiste ArrayList ma c'è solo Vector tnt x dirne una.....
cmq secondo me la cosa + logica da fare sarebbe finire diamonds su pc e poi fare il porting.....
Bonfo
24-05-2006, 14:24
cmq secondo me la cosa + logica da fare sarebbe finire diamonds su pc e poi fare il porting.....
E su questo direi che siamo tutti d'accordo :D :D :D
E su questo direi che siamo tutti d'accordo :D :D :D
cdimauro
24-05-2006, 14:33
infatti mi ero già proposto prima :D
Non me n'ero accorto: sarà colpa delle k... :p
Non me n'ero accorto: sarà colpa delle k... :p
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.