Newsgroup: it.comp.java
Titolo: Cerco testo per scrivere giochi in java

Salve qualcuno sa un testo che illustra lo sviluppo di giochi (2D) in
java usando *ESCLUSIVAMENTE* SWT.

 java usando *ESCLUSIVAMENTE* SWT.
Ciao,
non conosco un testo simile, ma sono curioso: perche vuoi/devi usare 
esclusivamente SWT?
Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 java usando *ESCLUSIVAMENTE* SWT.
Secondo me fai prima a trovare un testo sullo sviluppo di giochi e uno 
sull'uso di SWT.
Hai provato google?
-- 
Andrea Francia
alias rm='trash' #use trash command instead of removing
rm -Rfv file     #put the file in the KDE trashcan
http://www.andreafrancia.it/trash

Si ho provato con google e ho consultato anche altre fonti, ma non ho
trovato niente, pesavo che ci fosse qualcosa per questo ho postato
qualcosa qui.
Per Lucio Benfante: Perche usare SWT? Un pò perche devo impararla, e
secondo: perchè usare un'atra API(Swing, AWT)? Al più mi avresti
dovuto chiedere perchè scrivere giochi in java?

ari...@tiscali.it
 ha scritto:

Beh, ad esempio attualmente ci sono ottime ragioni per preferire Swing a 
SWT:
* totale portabilità
* disponibilità di un maggiorn numero di componenti preconfezionati
* ottime performance, soprattutto con Java 6, grazie anche ai binding OpenGL
Più o meno per le stesse ragioni non mi sembra un'idea tanto strana 
voler sviluppare giochi in Java.


 dovuto chiedere perchè scrivere giochi in java?
La domanda sul motivo per cui hai scelto SWT è sensata secondo me...
Io sto sviluppando dei giochi in Java (non per cellulari) e non serve a 
nulla secondo me SWT. Bastano le API Java2D... anzi bastano le API per 
stampare un'immagine sul un JPanel.. non servono componenti, pulsanti o 
altro.. o comunque io non li uso, un gioco 2D non è altro che una 
sovrapposizione di immagini in movimento..
Se poi vuoi il 3D ci sono anche altre possibilità...
FF

 writes:
LB> Beh, ad esempio attualmente ci sono ottime ragioni per preferire
LB> Swing a SWT:
LB> * totale portabilità 
SWT non la ha ? So che ti devi portare dietro il runtime, ma non mi
pare pregiudichi la portabilià.
LB> * ottime performance, soprattutto con
LB> Java 6
Con Java 6 SWT ha tempi di risposta accettabili ? Ho visto vari tool
che usano swt che sotto Windows girano bene e sotto Linux sonno lumache.
Con la 1.4 il tempo di creazione di una finestra era biblico, con la 1.5
è migliorato ma da qui a dire che siano buoni...
Non so, oggi come oggi preferirei usare SWT se dovessi fare una
applicazione desktop.
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
a 
fn...@rat.vg
                    | me at 
fn...@rat.vg

 
Io no. SWT è nata in tempi in cui effettivamente Swing era quasi 
inutilizzabile, per ragioni di performance. Oggi non ha quasi più senso 
di esistere.


> pare pregiudichi la portabilià.
LB> Deve esserci l'implementazione SWT per la piattaforma su cui intendi
LB> far girare il codice. I requisiti di Swing sono invece la "sola"
LB> piattaforma Java.
Questo è vero, ma le GTK cominciano ad avere una certa diffusione...
LB> Io parlavo di Swing, che con Java 6 è molto veloce. Un esempio?
LB> Provate a far girare un applicazione Swing (ad esempio NetBeans) con
LB> Java 5 e con Java 6. Con la seconda sarà impossibile notare dei
LB> tempi di refresh.
Sotto Windows o sotto cosa ?
LB> ...con SWT non c'è nessuna differenza. (e non è un pregio :) )
Bella  battuta. Sotto  c'è codice  (nativo) che  già da  qualche  anno è
efficente...


 
In questo momento non quanto quello Swing. E il problema era appunto 
questo: dovendo iniziare uno sviluppo ora scelgo SWT o Swing. Tempo fa 
la risposta era SWT. Ora è Swing, per i motivi già detti in questo thread.



Da quanto ho capito ora Swing è più veloce di prima ok. Ma cmq Swing
disegna i componenti in un modo diverso dal sistema operativo
sottostante e ciò potrebbe portare a scrivere applicazioni che dal
punto di vista dell'utente sono meno gradevoli perchè magari tale
utente ha sempre visto una certa interfaccia(quella del suo sistema
operativo) e quindi un applicazione scritta in Swing potrebbe avere
poco successo in ambito commerciale.(se ho scritto una bufala non
linciatemi)

 poco successo in ambito commerciale.
Il successo non dipende esclusivamente dal fatto che l'interfaccia 
grafica sia simile con quella nativa del sistema operativo. Spesso ci 
sono cose più importanti che vengono valutate prima dell'interfaccia 
grafica. Ci sono dei programmi gestionali di successo che sono orridi da 
vedere.
Comunque IMHO se usi i Swing con il look and feel Windows l'intefaccia 
della tua applicazione non stona molto con il resto.
-- 
Andrea Francia
http://www.andreafrancia.it/

 wrote:

Non sono d'accordo con te, l'interfaccia è la *PRIMA COSA* tutto il
resto viene dopo, l'utente ne risente molto di queste cose, e se vede
qualcosa di minimamente diverso inorridisce= prodotto invenduto.
Diciamo che questo è la base di quando apri un libro di ingegneria
del software(non è che uno deve fare come sta scritto sui libri ma se
i maggiori esperti affermano ciò significa che qualcosa di vero c'è).
Ciò è dimostrato ti faccio un esempi calzante: Secondo te perchè gli
utenti che hanno usato un sistema operativo diffidano del passare ad
un altro anche se potrebbe essere più vantaggioso farlo? Bhe non tanto
perchè il sistema operativo è organizzato in modo diverso, perche tale
astrazione l'utente non deve vederla, ma perchè ha *UNA DIVERSA
INTERFACCIA*, ed ha programmi che hanno una *DIVERSA INTERFACCIA*.
Diciamo che questo è la base di quando apri un libro di ingegneria
del software(non è che uno deve fare come sta scritto sui libri ma se
i maggiori esperti affermano ciò significa che qualcosa di vero c'è).
Ma questi programmi gestionali  hanno successo perchè non hanno nessun
rivale, ti faccio vedere io se tali programmi vengo scritti come si
deve.
O cmq sono programmi commerciali che l'utente non ha deciso lui di
comprare, ma ci sono stati imposti dall'azienda e che nel corso degli
anni ha voluto tenere la stessa intefaccia orrida per non perdere i
clienti che già ha acquistato.
Un altro esempio è questo che ti ho fatto prima: Alcune applicazioni
continuano a tenere un interfaccia orrida perchè hanno gia un
clientela che usa tale interfaccia: se la migliorano gli utenti
protestano e non la usano più: è strano ma questo è quello che il
nostro cervello fa. Ora si tu sei un esperto, ti piace smanettare ecc
ecc... ma se non lo fossi?*Le applicazioni sono pensate per l'utente
medio*.
Un altro esempio ancora più lontano da questa discussione è : perche
da quando sono state invente le auto i pedali hanno sempre lo stesso
siglificato? Non potenvano cambiarli? Magari avrebbe permesso un
organizzazione interna del motore più favorele(sto dicendo una
Caz,,,,) ma non sono stati mai cambiati da quando l'auto esiste
perché?
SWT rimane cmq la scelta professionale per me, tra l'altro non ho
visto nessuna applicazione commerciale in Swing. Non so se ne esistono
pero, mente di SWT come sappiamo possiamo apprezzare il nostro
bellissimo Eclipse( va bhe in questo caso la scelta di SWT è più
legata a questioni di marketing) e alte che non ricordo.
Ma nel look e feel Windows cmq qualcosa cambia, mi sembra che gli
eventi che un componente più generare sono diversi dallo stesso
componente peer del sistema sottostante.

 legata a questioni di marketing) e alte che non ricordo.
Francamente, Eclipse e derivati a parte, io ho visto pochissime 
applicazioni in SWT, mentre ce ne sono parecchie Swing. Quelle che 
ricordo e uso, in ordine sparso:
* NetBeans (
www.netbeans.org
)
* SquirrelSQL (
squirrel-sql.sourceforge.net
)
* Azureus (
azureus.sourceforge.net
)
* BlueMarine (
bluemarine.tidalwave.it
)
* jUploadr (
juploadr.org
)
...sicuramente la lista č piů lunga.
Ciao
   Lucio
-- 
Lucio Benfante


 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
 
http://www.jugevents.org
Ma credo nel caso cmq di applicazioni Swing come queste lo spirito di
usare Swing non era certo dettato dallo slogan "lanciare un prodotto
sul mercato e vendere quanto più possibile ", ma più che altro che in
un certo senso sponsorizzare appunto le tecnologie usate come Swing,
propio come credo Eclipse faccia con SWT.
Poi l'ultima battuta l'ho gettata li, è ovvio che non significata
niente se vi sono molte applicazioni scritte con questa tecnologie non
significa per forza che tale tecnologia la si debba usare in tutti i
casi.

 qualcosa di minimamente diverso inorridisce= prodotto invenduto.
Rispetto la tua opinione ma secondo me la prima cosa sono le funzionalità.
C'e' un programma che si chiama APRI di Zucchetti che serve ai 
commercialisti per fare le paghe.
L'interfaccia utente è fatta da un simil emulatore di terminale da 80 
colonne e 25 righe, per spostarti tra i menu del programma devi digitare 
<numero del menu> e Invio. Se premi 99 e Invio esci dall'applicazione.
In questo caso anche se l'interfaccia non prevede bottoni disegnati bene 
il prodotto vende bene e costa pure tanto.
Al resto del post per adesso non rispondo perché è troppo lungo e non ho 
avuto voglia di leggerlo.


ari...@tiscali.it
 wrote:
 > ...
Adesso lo letto tutto, mi sembra che usi in modo intercambiale il 
concetto di usabilità e quello di appeal grafico.
Per fare un applicazione con una buona intefaccia prima dev'esserci uno 
studio dell'interfaccia utente, la scelta tecnologica Swing / SWT 
francamente mi sembra meno importante.


> Sotto Windows o sotto cosa ?
LB> Io lo uso normalmente sotto Linux, ma anche in Windows è lo
LB> stesso. (Mac o altro, non ho provato)
La domanda non era faziosa. Io usualmente uso Linux, per farmi fare il
boot con Windows sul computer di lavoro devono proprio forzarmi.
Però sotto Windows le GUI funziona(vano) molto meglio.
Con la 5  le GUI sotto linux sono diventate  usabili, dovrei provare con
la 6 ma sulla  macchina di ufficio devo vedere se lo  posso fare. A casa
proverò  a tirare giù  la versione  IBM della  6. Non  è la  stessa cosa
dell'implementazione di Sun (in certi  punti si sono presi alcuni rischi
che se  tutto va bene fanno  risparmiare tempo in esecuzione)  ma non mi
pare ci sia altro...
LB> In questo momento non quanto quello Swing. E il problema era appunto
LB> questo: dovendo iniziare uno sviluppo ora scelgo SWT o Swing. Tempo
LB> fa la risposta era SWT. Ora è Swing, per i motivi già detti in
LB> questo thread.
Ci sono dei benchmark ? (no, non è polemica)
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
a 
fn...@rat.vg
                    | me at 
fn...@rat.vg
P.S.
RMS ha scelto GTK come unico toolkit X per l'ammiraglia del progetto
GNU...

>>>>> "AF" == Andrea Francia <andrea....@gmx.it.invalid> writes:
AF> C'e' un programma che si chiama APRI di Zucchetti che serve ai
AF> commercialisti per fare le paghe.  L'interfaccia utente è fatta da
AF> un simil emulatore di terminale da 80 colonne e 25 righe, per
AF> spostarti tra i menu del programma devi digitare <numero del menu> e
AF> Invio. Se premi 99 e Invio esci dall'applicazione.
Questo mi sembra tanto il far sopravvivere una certa interfaccia utente
al sistema che la ha generata. E questo perché gli utenti sono abituati
a quella interfaccia.
E  non sarebbe  il primo  caso  che vedo  di nuovi  programmi con  nuove
tecnologie  che cercano, con  maggiore o  minore successo,  di replicare
quella del programma che vanno a sostituire.
Nel caso del programma per le paghe, da una parte l'applicazione in se è
più   importante  del   sistema  sottostante   (il  sistema   serve  per
l'applicazione),  dall'altra  quanti prodotti  concorrenti  ci sono  che
possono sostituire -in questo caso  anche con la celerità nelle risposte
ai cambiamenti normativi- al prodotto di Zucchetti ?
Dove invece  una certa  "concorrenza" c'è, il  tema della  conformità al
resto del sistema  si fa sentire, e questo in alcuni  sistemi più che in
altri  (spannometricamente  direi che  sui  Mac  è  quasi una  questione
religiosa,  poi sotto  Windows è  un po'  meno importante  ed in  Unix e
GNU/Linux  un zinzino-ino-ino  meno per  la presenza  di  alcune vecchie
volpi che sono oramai abituate a saltare da un modello ad un altro).
Peraltro nei giochi ho visto fare quel che girava al programmatore :).


 writes:
LB> In questo momento non quanto quello Swing. E il problema era appunto
LB> questo: dovendo iniziare uno sviluppo ora scelgo SWT o Swing. Tempo
LB> fa la risposta era SWT. Ora č Swing, per i motivi gią detti in
LB> questo thread.
Dimenticavo. Swing si portava dietro abbastanza AWT da generare problemi
col multithreading  (AWT sotto Unix  e GNU/Linux almeno una  volta usava
Motif che non č thread safe). Rimane  la cosa ? Che ho almeno un esempio
di  applicazione (jCVS  II) dove  la cosa  genera problemi  quando sotto
GNU/Linux usi una JVM con i thread nativi...


 ai cambiamenti normativi- al prodotto di Zucchetti ?
Ma che stai dicendo? APRI ha concorrenti. Non sono un esperto ma credo 
che IPSOA abbia un
La tua teoria secondo la quale un programma con interfaccia utente piu' 
raffinata avrà piu' successo di uno con interfaccia utente meno 
raffinata ha qualche fondamento ma non descrive la realtà nelle sue 
divere sfaccettature.
La trovo una teoria semplicistica che non prende in considerazione tutti 
gli aspetti che concorrono al successo del programma e non prende in 
considerazione il fatto che il valore relativo degli aspetti cambia a 
seconda dell'ambito in cui il programma è venduto.


 GNU/Linux usi una JVM con i thread nativi...
I componenti Swing (e AWT) non garantiscono la sincronizzazione. Per 
utilizzarli č necessario accedergli da un Thread solo alla volta, cioč 
la sincronizzazione č a carico del client. Per questo motivo esiste il 
metodo SwingUtilities.invokeLater().
Sono d'accordo sul fatto che questo possa non piacere e che sia scomodo. 
Pero' secondo "Java Cuncurrency in Pratice" di Brian Goetz et. al. si 
tratta di una scelta architetturale precisa.
Scusatemi ma non sono in grado di riassumere efficacemente i concetti 
che giustificano la scelta, pero' ci sono sul libro. L'ho scritto giusto 
per informazione per chi legge.
Comunque a questo indirizzo ci sono scritte alcune delle motivazioni:
http://weblogs.java.net/blog/kgh/archive/2004/10/
Comunque la domanda che volevo fare a Gian Uberto Lauri č questa: questi 
problemi che citi esistono anche con SWT o sono tipici di AWT/Swing?
