View Full Version : [Java] grafica avanzata
Ciao!
torno a chiedere il vostro aiuto. Mi sto dilettando a sviluppare applet con animazioni e qualche sorta di effetto grafico ma più vado avanti più sento la necessità di usare strumenti avanzati. Mi riferisco a accelerazioni Hardware per gestire gli effetti grafici e così via..
Leggendo su internet ho trovato alcuni esempi che utilizzano jogl come questo Particle Engine (https://jogl-demos.dev.java.net/), qualcuno mi può chiarire le idee in merito?
intendo: a che cosa servono praticamente le librerie tipo jogl? quando è bene utilizzarle?
premetto che sono nuovo in questo campo, quindi qualcuno ha da suggerirmi un libro che tratta di questi argomenti da poter studiare? (anche in inglese ovviamente)
vorrei anche capire quali sono i metodi utilizzati dai programmatori esperti per sviluppare animazioni complesse senza gravare eccessivamente sulle prestazioni...
insomma mi piacerebbe esplorare questo ambito della programmazione e essendo un novizio chiedo a voi da dove iniziare :D
grazie e buone feste :)
EDIT: forse il titolo non è dei migliori:fiufiu:
wizard1993
30-12-2009, 11:03
jogl sta per java binding for open gl
comunque il nome ti può far ben intuire, serve per grafiche avanzate a livello di giochi e di simulazioni 3d. se non erro con tali librerie sono stati creati Scilab e Nasa world wind
jogl sta per java binding for open gl
comunque il nome ti può far ben intuire, serve per grafiche avanzate a livello di giochi e di simulazioni 3d. se non erro con tali librerie sono stati creati Scilab e Nasa world wind
grazie :)
a me interessa il 2D però questo potrebbe interessarmi :p
qualche consiglio sui libri?
Se ti interessa il 2D puoi usare tranquillamente Java2D che è parte delle librerie standard (e usa l'accelerazione hardware dove disponibile).
Il problema è più che altro artistico nel senso che anche una volta che hai a disposizione le API, gli algoritmi e tutta la parte diciamo "meccanica", comunque devi affrontare la questione visiva.
Ad esempio sputare particelle è relativamente semplice. Il problema è che se l'aspetto di quelle particelle fa schifo farà schifo anche l'effetto nonostante l'eventuale raffinatezza del motore particellare.
wizard1993
30-12-2009, 14:34
se ti può interessare c'è una discussione dell'amico banryu su questi temi
http://www.hwupgrade.it/forum/showthread.php?t=1817420
se ti può interessare c'è una discussione dell'amico banryu su questi temi
http://www.hwupgrade.it/forum/showthread.php?t=1817420
lo avevo già letto :P mi è stato davvero utile :D
Se ti interessa il 2D puoi usare tranquillamente Java2D che è parte delle librerie standard (e usa l'accelerazione hardware dove disponibile).
Il problema è più che altro artistico nel senso che anche una volta che hai a disposizione le API, gli algoritmi e tutta la parte diciamo "meccanica", comunque devi affrontare la questione visiva.
Ad esempio sputare particelle è relativamente semplice. Il problema è che se l'aspetto di quelle particelle fa schifo farà schifo anche l'effetto nonostante l'eventuale raffinatezza del motore particellare.
mmm ok si infatti quel programma li è "abbastanza" facile da realizzare se le particelle sono solo degli ovali(java.awt.geom.Ellipse2D) l'aspetto che vorrei approfondire è la creazione delle immagini delle particelle come fa in quel programma, tutte sfumate, con bicolore, etc fare tutto questo in tempo reale senza saturare la cpu. in merito avete qualche libro e/o quida che potrei consultare?
quindi dici che tutte le api di cui ho bisogno sono Java2D?
PS grazie e tutti e due :P
Lì le particelle che vedi sono dei quadrati ai quali è applicata come texture l'immagine di un grosso quadrato nero con al centro un pallino bianco sfumato. Questa texture è poi combinata con un colore. La combinazione applicata fa si che ciò che nell'immagine di base è nero diventi trasparente e ciò che è bianco opaco - con i livelli intermedi interpretati come opacità intermedie.
L'immagine usata per la texture è perciò la classica maschera alpha.
Ci sarà poi una certa funzione del colore, della posizione e della dimensione delle particelle nel tempo il cui effetto totale è quel movimento apparentemente caotico di luci colorate.
Se fai una ricerca per "particle engine" in rete trovi tutto l'armamentario. Puoi farlo sia con Java2D (in 2D) sia in Jogl (in questo caso in 3D sia in proiezione parallela che ortografica che è come il 2D in soldoni).
Il vantaggio di Jogl (cioè dell'uso diretto di funzioni OpenGL) sta in ciò che tra le funzioni offerte ce ne sono di specifiche per realizzare direttamente questo genere di combinazioni colore-maschera.
Lì le particelle che vedi sono dei quadrati ai quali è applicata come texture l'immagine di un grosso quadrato nero con al centro un pallino bianco sfumato. Questa texture è poi combinata con un colore. La combinazione applicata fa si che ciò che nell'immagine di base è nero diventi trasparente e ciò che è bianco opaco - con i livelli intermedi interpretati come opacità intermedie.
L'immagine usata per la texture è perciò la classica maschera alpha.
Ci sarà poi una certa funzione del colore, della posizione e della dimensione delle particelle nel tempo il cui effetto totale è quel movimento apparentemente caotico di luci colorate.
Se fai una ricerca per "particle engine" in rete trovi tutto l'armamentario. Puoi farlo sia con Java2D (in 2D) sia in Jogl (in questo caso in 3D sia in proiezione parallela che ortografica che è come il 2D in soldoni).
Il vantaggio di Jogl (cioè dell'uso diretto di funzioni OpenGL) sta in ciò che tra le funzioni offerte ce ne sono di specifiche per realizzare direttamente questo genere di combinazioni colore-maschera.
:eek: ecco e qui è dove casca l'ignorante come me...
io pensavo di fare chissà cosa :rolleyes: la funzione di aggiustare il colore la posso fare anche io analizzando ogni pixel e prendendone il valore alpha e cambiare solo il colore con quello desiderato, però mi puzza di pesante :what:
per le ombre del testo invece? (hei ora sono curioso:p )
comunque mi devo trovare un buon libro che tratta questi argomenti...
Il principio della colorazione di una maschera alfa è quello lì dei pixel. L'operazione concreta dipende dalle librerie. Ad esempio in Java2D usi una composizione DST_IN. Tutta roba terra terra, intendiamoci. In pratica pigli e ti crei un'immagine della particella trasparente, tipo questa:
http://www.tukano.it/halo.png
e la carichi in una BufferedImage.
Questa è la maschera (chiamiamola mask). Poi crei una BufferedImage vuota, delle stesse dimensioni della particella che sarà il tuo buffer (chiamiamola appunto buffer).
Poi entrano in gioco le regole di combinazione di porter-duff. Si tratta di funzioni precotte che stabiliscono come il colore del punto in cui si disegna può combinarsi con il colore di ciò che gli viene disegnato sopra.
Una di queste regole, "destination in", che in Java2D è rappresentata AlphaComposite.DstIn, dice che il colore della superficie non cambia ma quel colore assume come trasparenza la trasparenza del "pennello".
Significa che se io disegno un quadrato arancione, imposto la regola DstIn e poi disegno su quel quadrato la mia immagine, il risultato sarà i pixel del quadrato resteranno arancioni MA il loro valore di trasparenza cambierà secondo la trasparenza dei corrispondenti pixel dell'immagine.
Dunque dato il buffer, lo riempio del colore che voglio io:
Graphics2D g = buffer.createGraphics();
g.setColor(Color.YELLOW);
g.fillRect(0, 0, buffer.getWidth(), buffer.getHeight());
imposto la composizione DstIn:
g.setComposite(AlphaComposite.DstIn);
e disegno la maschera della particella:
g.drawImage(mask, 0, 0, null);
Il risultato è che "buffer" diventa la mia particella colorata.
E' come colorare pixel per pixel solo che, se l'hardware lo permette, ogni drawImage è realizzato con un'unica invocazione sulla pipeline di rendering.
Posizione e dimensioni sono controllabili con le trasformazioni affini. Dato il buffer "colorato" e il Graphics2D della superficie su cui voglio disegnare la particella (che puoi essere un Canvas o un JComponent o un BufferStrategy eccetera), controllo la posizione con la traslazione e la dimensione con il fattore di scala. Con un secondo AlphaComposite controlli la trasparenza generale della particella.
In breve un metodo Java2D che disegna una particella colorata, partendo da una maschera png "MASK", può essere questo:
private final AffineTransform TRANSFORM = new AffineTransform();
private void drawParticle(Graphics2D graphics, int cx, int cy, double scale, float transparency, Color color) {
AffineTransform t = graphics.getTransform();
Graphics2D g = BUFFER.createGraphics();
g.setPaint(color);
g.fillRect(0, 0, BUFFER.getWidth(), BUFFER.getHeight());
g.setComposite(AlphaComposite.DstIn);
g.drawImage(MASK, 0, 0, null);
TRANSFORM.setToTranslation(cx, cy);
TRANSFORM.scale(scale, scale);
graphics.transform(TRANSFORM);
Composite c = graphics.getComposite();
graphics.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, transparency));
graphics.drawImage(BUFFER, -BUFFER.getWidth() / 2, -BUFFER.getHeight() / 2, null);
graphics.setComposite(c);
graphics.setTransform(t);
}
Questo per quanto riguarda l'aspetto "istantaneo". Poi c'è la questione del "ciclo vitale" delle particelle: appare in una certa posizione, con una certa dimensione, un certo colore, viaggia con una certa velocità in una direzione, cambiando nel frattempo colore, dimensioni e trasparenza. Insomma, c'è di che divertirsi.
Per quanto riguarda l'ombra del testo, so dell'esistenza di svariate tecniche in 3D ma non ne saprei realizzare neppura una. Ci sono comunque diversi motori di rendering 3D in java (JME, Ardor3d o Xith per citarne tre tra i tanti) che hanno le lore funzioni di generazione delle ombre già bell'e e pronte da usare.
In 2D è un "far finta che", realizzato con due livelli di disegno. Prima disegni il testo o la figura geometrica nera, poi disegni il testo o la figura nel suo colore reale, leggermente spostata rispetto al disegno precedente per dare l'illusione di profondita.
Per più oggetti, disegni prima tutte le "ombre" e poi tutti gli oggetti. Il risultato di quella che un semplice disegnare le cose una sopra l'altra è l'illusione ottica di un'ombra.
Sono veramente senza parole, primo per le cose che sai e secondo per la semplicità di java che non credevo arrivasse fino a questo punto!
Grazie mille per l'interessamento e ora so su cosa focalizzarmi, mi prenderò un bel libro che tratta java2D e me lo studio per bene..
esistono metodi preconfezionati per effetti "tipo" blur di sfocamento che non usino ConvolveOp? (risulta troppo pesante se applicato a alti livelli)
PS: curiosità esiste un metodo per capire da applet se sul PC Client è installato java?
Non ci sono alternative predefinite a ConvolveOp.
Per verificare la presenza di un JRE puoi fare riferimento a questa pagina della documentazione Se
http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit
in pratica si tratta di includere un file javascript tramite il quale è possibile automatizzare l'installazione di un JRE nel caso in cui non sia presente.
Non ci sono alternative predefinite a ConvolveOp.
Per verificare la presenza di un JRE puoi fare riferimento a questa pagina della documentazione Se
http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit
in pratica si tratta di includere un file javascript tramite il quale è possibile automatizzare l'installazione di un JRE nel caso in cui non sia presente.
peccato non ci sia qualcosa di predefinito, ma ho trovato ugualmente un metodo per fare le ombre a degli shape, utilizzo delle trasformazioni affini e canale alpha :D
grazie per la dritta sulle applet, quando l'avrò finita vedrò di implementare quel controllo li.
ma ora mi è venuto un dubbio.. sempre in termini di prestazioni, esite la classe VolatileImage che è una immagine salvata nella memoria della scheda video, so che essa può perdere il proprio contenuto in seguito ad azioni che non si possono controllare direttamente ma in teoria non dovrebbe essere moolto più veloce compiere calcoli su immagini volati che su normali? mi è venuto in mente ciò perchè in seguito a un'animazione devo fare scomparire pian piano degli oggetti a schermo.. e mi sono chiesto se al posto di ridisegnare ogni oggetto e applicargli un AlphaComposite diverso non sarebbe stato meglio disegnare tutto dentro una immagine volatile e poi disegnare essa nel mio contesto grafico con un alphaComposite solo, che te ne pare dle mio ragionamento contorto?:rolleyes:
Non vedo un vantaggio nell'operazione che proponi. In questo senso. Disegnano "oggetto per oggetto" esegui questa serie di operazioni:
g.setComposite(trasparenza);
...disegna N oggetti su g
Usando un buffer avremmo:
disegna N oggetti sul buffer
g.setComposite(trasparenza);
g.drawImage(buffer...);
Il fatto è che se puoi disegnare tutto su un'immagine e poi applicare quell'immagine con un unico alphacomposite allora puoi anche organizzare il disegno direttamente su "g" applicando un solo alphacomposite. In altri termini, se devo disegnare 3 oggetti trasparenti, non è necessario dire:
g.setComposite(trasparenza);
g.drawQualcosa
g.setComposite(transparenza);
g.drawQualcosa
g.setComposite(transparenza);
g.drawQualcosa
ma è sufficiente:
g.setComposite(trasparenza);
g.drawQualcosa
g.drawQualcosa
g.drawQualcosa
Questo perchè la regola di composizione (come le trasformazioni) è applicata ad ogni operazione successiva alla sua entrata in vigore.
si si io volevo utilizzare un alphacomposite solo, scrivevo tutto dentro un "buffer" e poi scrivevo quel buffer dentro il mio Graphics a cui impostavo un alpha composite solo :)
mmm però per avere una struttura di questo tipo dovrei cambiare buona parte del codice..
ma ora una domanda, se ho una struttura di questo tipo:
JFrame
JPanel1
JPanel2
JPanel2.1
JPanel2.2
JPanel3
quando io chiamo il repaint del JFrame lui a sua volta scorre tutti i suoi figli e chiama per chiascuno il paint passandogli un graphics che rappresenta la porzione di spazio da loro occupata?
perchè se così fosse io mi farei una struttura personalizzata di questo tipo adattandola alle mie esigenze (cioè potendo applicare trasformazioni affini etc utilizzando un solo drawImage, poi anche fosse peggiore ho imparato smepre qualcosa :rolleyes: :rolleyes: )
Il graphics è uno solo per finestra e tutti i panelli e pannellini contenuti nella finestra ricevono quell'unico graphics.
In pratica io componente genitore disegno me stesso, poi vado a guardare in che punto si trova il figlio, sposto l'origine degli assi del graphics con un'affinetransform, imposto un clip che limita il graphics alla superficie occupata dal figlio e poi gli passo il mio graphics.
Il risultato è che per ogni componente il punto (0,0) corrisponde al suo angolo in alto a sinistra (anche se il componente può trovarsi al centro della finestra).
Insomma, stesso graphics ma sistemi di coordinate diversi.
Occhio che la condivisione del graphics fa sì che eventuali trasformazioni applicate nel padre si riflettano sui figli.
Java != Grafica Avanzata.
Cambia linguaggio, ti fai un favore :asd:
Mai vista una gestione della grafica così lenta e penosa, con lo stesso sforzo impari a fare le stesse cose con la DirectX.
Evvai, iniziamo il 2010 con una bella stronzata.
Java != Grafica Avanzata.
Cambia linguaggio, ti fai un favore :asd:
Mai vista una gestione della grafica così lenta e penosa, con lo stesso sforzo impari a fare le stesse cose con la DirectX.
beh sicuramente non è leggerissima ma (io parlo per me e con la mia esperienza eh) per avere una grafica veloce e bella bisogna studiare e sudare e sudare in java come in qualsiasi altro linguaggio credo, chi più chi meno. Proprio perchè ogni linguaggio ha un approcio differente. Poi se tu parli di librerie la storia cambia, se credi che Java2D non sia sufficientemente performante esponi perchè e un rimedio :) io sono sempre aperto a miglioramenti ;)
PS: comunque personalmente il C++ non mi piace proprio, e poi ti voglio vedere a fare le applet in C++ (a me queste cose servono per quel motivo) :D
Il graphics è uno solo per finestra e tutti i panelli e pannellini contenuti nella finestra ricevono quell'unico graphics.
In pratica io componente genitore disegno me stesso, poi vado a guardare in che punto si trova il figlio, sposto l'origine degli assi del graphics con un'affinetransform, imposto un clip che limita il graphics alla superficie occupata dal figlio e poi gli passo il mio graphics.
Il risultato è che per ogni componente il punto (0,0) corrisponde al suo angolo in alto a sinistra (anche se il componente può trovarsi al centro della finestra).
Insomma, stesso graphics ma sistemi di coordinate diversi.
Occhio che la condivisione del graphics fa sì che eventuali trasformazioni applicate nel padre si riflettano sui figli.
ok come sospettavo :D vedo di studiare qualcosa..
Ma mi puoi dare un parere?
Che te ne pare di fare un contest educativo:D?
Cioè mi spiego meglio: di solito nei contest si cerca il miglior algoritmo per risolvere un certo problema etc etc, invece perchè noi non proviamo a proporre una nostra implementazione di applet così che Voi (intendo programmatori seri) possiate insegnare a Noi (intendo novizi o quasi) come migliorare il codice :)
il primo potrebbe essere una applet quadrata a sfondo nero che al centro abbia una fonte di particelle (eh si mi piacciono:fagiano: :fagiano: ) e che si spostino verso l'esterno a mò di spirale, non porta via molto tempo e può insegnare molto :p (così da entrare nello specifico della grafica)
In tutta onestà al momento sono un po' preso dal tentativo di far muovere le zampe a questo grandissimo figlio di una mesh (e, si sa, la mesh è un po' zoccola)
http://www.tukano.it/jupiter/animate.jpg
La fiera resistenza che sta opponendo è direi quasi ammirevole.
Che è poi la metafora della programmazione di applicazioni grafiche: non è mai un problema di programmazione in sè. Semplicemente a un certo punto devi iniziare a caricare dei contenuti nel tuo programma e allora scopri che non ci sono - o se ci sono non sono gratuiti. E allora devi farti pure quelli. Solo che un conto è programmare, un conto è disegnare.
Evvai, iniziamo il 2010 con una bella stronzata.
Ovvio che trollavo, ma rimane che Java non si sia mai visto usare per la grafica 3D, per quanto oggi un motore grafico può essere leggerissimo per la CPU.
Non credo affatto che si possano trascurare tutti i problemi che java ha nell'ambito delle applicazioni realtime...
Questi fantomatici problemi uno poi dovrebbe anche andare a verificarli se no stiamo qua a parlare del cognato del compagno di stanza di mio cugino che ha sentito dire che.
Problemi nello sviluppo di programmi soft - real time Java SE non ne ha. Per l'hard real time c'è la piattaforma rts (che però richiede un sistema operativo real time, non è un giocattolo). Poi uno decide da sè se vuole farsi del male o no.
In tutta onestà al momento sono un po' preso dal tentativo di far muovere le zampe a questo grandissimo figlio di una mesh (e, si sa, la mesh è un po' zoccola)
La fiera resistenza che sta opponendo è direi quasi ammirevole.
Che è poi la metafora della programmazione di applicazioni grafiche: non è mai un problema di programmazione in sè. Semplicemente a un certo punto devi iniziare a caricare dei contenuti nel tuo programma e allora scopri che non ci sono - o se ci sono non sono gratuiti. E allora devi farti pure quelli. Solo che un conto è programmare, un conto è disegnare.
capisco :asd:
tra l'altro complimenti per quel programma se lo hai fatto tu, lo avevo già visto in azione su youtube tramite la tua firma qualche tempo fa ;)
comunque ho capito abbastanza dove sbagliavo nel pensiero, ora mi devo guardare bene i metodi java come agiscono per usare sempre quello giusto..
ah ho trovato in un tuo vecchio post (http://www.hwupgrade.it/forum/showthread.php?t=1496341&page=2) un link a un articolo veramnete interessante sulle immagini in java, tu ne conosci mica altri di questo genere? e dove posso trovare quelli sempre nuovi? :)
Se è l'articolo di chet haase... adesso lavora per adobe :cry:
Qui:
http://www.javagaming.org/
trovi di tutto e di più.
Ovvio che trollavo, ma rimane che Java non si sia mai visto usare per la grafica 3D prossimamente si vedrá! io e un amico stiamo realizzando per hobby un giochino 3D sotto forma di applet Java (lo diffonderemo come applicazione per Facebook); utilizza JOGL ed é un remake tridimensionale di un gioco vecchiotto che esiste giá e si chiama Blobby Volley. la nostra versione si chiama 3D Volley e si trova a questo sito: http://playbay.altervista.org/Volley
per ora é solo una demo, peró dá un'idea. richiede OpenGL 2.1 ma richiede anche GLSL 1.30, che significa che praticamente richiede OpenGL 3.x. prossimamente degraderemo gli shaders a GLSL 1.20, cosi richiederá veramente OpenGL 2.1. ad eccezione degli shaders é programmato in "forward-compatible OpenGL": in tutto il programma viene sempre usata l'interfaccia GL2GL3 del JSR 231.
fine pubblicitá abusiva :D
caspita è abusiva forte (cit.) :asd:
Comunque, vista la direzione del gaming su pc mi sembra decisamente interessante sapere se l'approccio che seguite voi (applet + facebook lo associo tranquillamente a "gioco da 2 soldi") permette di far girare giochi "pesanti"...
come grafica il vostro gioco come si piazza? avete avuto problemi di compatibilità? cosa richiede all'user oltre ai requisiti grafici? quanto è pesante?
Poter mettere giochi anche pesanti su una web page sarebbe un bel passo avanti per il digital delivery...
Comunque, vista la direzione del gaming su pc mi sembra decisamente interessante sapere se l'approccio che seguite voi (applet + facebook lo associo tranquillamente a "gioco da 2 soldi") permette di far girare giochi "pesanti"... i giochi che vedi come applicazioni su Facebook non sono affatto "da due soldi": l'idea della Playfish dei giochi sociali é stata geniale, quei ragazzi hanno fatto bingo, ci sono rimasto quando ho saputo la cifra per cui EA li aveva acquisiti. semmai possiamo dire che sono tecnologicamente da due soldi: Flash fa cagare.
come grafica il vostro gioco come si piazza? in che senso? :D
per ora nel gioco si vedono solo un cielo di sfondo (banale rettangolo blu), un pavimento infinito e un paio di mesh, quella della palla e quella dei blob; il modello di illuminazione é fatto ad hoc per i singoli elementi, é presente antialiasing sotto forma di multisampling ed abbiamo messo anche il motion blur realizzato renderizzando sul frame corrente il frame precedente con valore alpha < 1. ora ci concentreremo sul completamento delle funzionalitá basilari (fisica, AI, mesh della rete), dopodiché probabilmente metteremo un filtro gaussiano o altra convoluzione per l'effetto di light blooming che secondo me ci sta bene.
particolarmente interessante la tecnica di rendering del pavimento :D
é un pavimento infinito, ma OpenGL non permette di renderizzare oggetti infiniti! :D
per ottenerlo facciamo proiezione prospettica inversa :asd:
ultimamente peró mi stavo chiedendo se non fosse possibile renderizzare poligoni infiniti usando 0 come coordinata omogenea: dovró farmi un paio di conti.
avete avuto problemi di compatibilità? si purtroppo, ma Java non ne ha colpa: quasi nessun utente ha OpenGL 3.x al momento, e i nostri shaders lo richiedono; abbiamo allestito un sistema di error reporting che in caso di requisiti insufficienti o altro crash del gioco invia un report al database del nostro sito, e stiamo vedendo che molti utenti hanno OpenGL 2.1, quindi abbiamo deciso di retrocedere gli shaders a GLSL 1.20.
cosa richiede all'user oltre ai requisiti grafici? niente perché il deploy lo facciamo con JNLP e col deployment toolkit, quindi se sul client non é presente almeno una certa versione del JRE l'installazione dello stesso avviene automaticamente, inoltre JNLP ci permette di far si' che JOGL venga scaricato automaticamente da java.net senza neanche che il nostro applet sia firmato.
ti dovessi dire la veritá é stata una bella lotta eh, ma alla fine i risultati ci sono!
quanto è pesante? pesa il peso di JOGL piu la dimensione del JAR del gioco, che ammonta a circa 150 KB. attualmente il download non é per nulla fastidioso, ma possiamo fare di meglio: in futuro useremo pack200.
Ho tentato ma nulla da fare. In windows è per via dei driver (purtroppo non posso installare quelli più recenti perchè mi impapocchiano la cpu). In Linux - dove ho i driver più recenti - invece credo che il problema sia nel file jnlp perchè non mi carica le api jogl. Avete provato ad usare JNLPAppletLauncher?
Ho tentato ma nulla da fare. In windows è per via dei driver (purtroppo non posso installare quelli più recenti perchè mi impapocchiano la cpu). infatti ci é arrivato stamattina verso le 9 il report di una Mobility Radeon HD 3470: hai GLSL 1.20 anche tu. un giorno funzionerá anche a te! :D
In Linux - dove ho i driver più recenti - invece credo che il problema sia nel file jnlp perchè non mi carica le api jogl. Avete provato ad usare JNLPAppletLauncher? veramente vorrei evitarlo, mi sa tanto di complicazione/ulteriore dipendenza :stordita:
quale puó essere il problema del file JNLP? questo é il file che usiamo:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="http://playbay.altervista.org/Volley/" href="Volley.jnlp" version="0.31">
<information>
<title>3D Volley!</title>
<vendor>Playbay</vendor>
<homepage href="http://playbay.altervista.org/Volley"/>
<description>Playbay 3D Volley!</description>
<offline-allowed/>
<shortcut/>
</information>
<resources>
<java version="1.6+"/>
<jar href="Volley.jar" main="true"/>
<extension name="jogl" href="http://download.java.net/media/jogl/jsr-231-2.x-webstart/jogl-all-awt.jnlp"/>
</resources>
<resources os="Windows">
<property name="sun.java2d.noddraw" value="true"/>
</resources>
<applet-desc
name="Volley"
main-class="com.playbay.volley.ui.VolleyApplet"
width="640"
height="480"
/>
</jnlp>
siamo a conoscenza di problemi del JRE a 64 bit su Linux sui quali non abbiamo ancora investigato; hai Linux a 64 bit? per non sapere ne' leggere e ne' scrivere, se hai tempo e voglia potresti provare con un JRE a 32 bit? :)
grazie del supporto!
Quaggiù vivo ancora nel mondo dei 32 bit.
IL problema è nel file jnlp nel senso che il plug-in di firefox non lo prende (la console dice che manca l'attributo code dell'applet ma il code non ci va se si usa jnlp).
JNLP Applet launcher fa la stessa cosa di jnlp ma lo fa in modo tale da superare le differenze dei diversi plug-in.
Potete usare questa pagina come riferimento
http://download.java.net/media/jogl/demos/www/applettest-jnlp.html
Questa me la carica sia su linux che su windows.
IL problema è nel file jnlp nel senso che il plug-in di firefox non lo prende (la console dice che manca l'attributo code dell'applet ma il code non ci va se si usa jnlp). ah... quindi a parte usare JNLPAppletLauncher non possiamo farci niente, giusto? non siamo noi a scrivere il tag <applet>, lo scrive il javascript del deployment toolkit.
JNLP Applet launcher fa la stessa cosa di jnlp ma lo fa in modo tale da superare le differenze dei diversi plug-in. ma tu su Linux che JRE usi? OpenJDK? IcedTea? JDK 6 della Sun?
Potete usare questa pagina come riferimento
http://download.java.net/media/jogl/demos/www/applettest-jnlp.html
Questa me la carica sia su linux che su windows. ehm, grazie del link :stordita:
il fatto é che in passato lo usavamo il JNLPAppletLauncher ma ci siamo stufati presto perché era una dipendenza inutile visto il sistema di JNLP e perché a un certo punto ci ha smesso di funzionare a causa di un bug noto (che adesso evidentemente é stato corretto) dell'applet launcher che gli impediva di funzionare con l'update, mi pare, 13 del JRE Sun: avevo aggiornato il JRE e non ha piu funzionato.
anzi, non ricordo assolutamente se era il 13 ma credo fosse un update vicino al 15.
anche ora che il bug é stato corretto francamente non ho molta voglia di ritornare a quel coso che non fa altro che aggiungere KB alla dimensione del primo download, preferirei aggiustare le cosette che mi impediscono di fare il deploy tramite JNLP :stordita:
tra l'altro sei il primo utente che manifesta un simile problema: di solito su Linux a 32 bit partiva senza alcun problema, anche se poi la schermata restava nera a causa di GLSL 1.30 e veniva inviato il report.
JRE di Sun, ultima versione (1.6.0_17), Mandriva One. Firefox invece è nella versione 3.5. Forse va con la 3.6 - che ha un sistema diverso di gestione del plug-in java. E' anche possibile che sia la mia installazione del plug-in a non essere corretta. Può darsi che nella creazione dei link simbolici con ln -s /usr/
VIVA WINDOWS!!!
Oh, scusatemi... m'è scappato...
*
Beh davvero interessante, voglio provarlo :D
Più che altro finchè non vedo (che va fluido) non credo :asd:
Certo che richiedere OpenGL 1.30 è una bella pretesa con la concorrenza che non richiede nemmeno la GPU :D
Puoi provare "Bang! Houwdy" se vuoi vedere un gioco 3d in un browser.
JRE di Sun, ultima versione (1.6.0_17), Mandriva One. Firefox invece è nella versione 3.5. Forse va con la 3.6 - che ha un sistema diverso di gestione del plug-in java. E' anche possibile che sia la mia installazione del plug-in a non essere corretta. Può darsi che nella creazione dei link simbolici con ln -s /usr/
VIVA WINDOWS!!!
Oh, scusatemi... m'è scappato... :rotfl:
Beh davvero interessante, voglio provarlo :D
Più che altro finchè non vedo (che va fluido) non credo :asd: apri la pagina e lo vedrai :p
Certo che richiedere OpenGL 1.30 è una bella pretesa con la concorrenza che non richiede nemmeno la GPU :D Direct3D é meglio di OpenGL e su questo non ci piove. comunque non richiediamo OpenGL 1.3, richiediamo GLSL 1.30 che implica OpenGL 3.x, ma a breve sará richiesto solamente OpenGL 2.1 con il suo GLSL 1.20, che hanno in molti.
poi che la concorrenza non richieda nemmeno la scheda grafica é tutto un dire: ho provato il Blobby Volley originale su di un PC di un old, ma di un old, che aveva solamente una scheda VGA; faceva veramente tenerezza, neanche 1 FPS, nel senso che a renderizzare ciascun frame ci volevano un paio di secondi :asd:
e il Blobby Volley originale é 2D!! :sofico:
Orpo mi ero perso il link :asd:
Comunque provato, e mi dispiace dire "definitely not impressed"...
Intanto il download Java ci mette parecchio; poi mi spawna 2 processi javaw da 60 mb e 10% del processore di cui uno rimane, e chrome sale di 10 mb.
Inoltre cliccando options si è bloccato l'intero browser, cosa che trattandosi di chrome mi è capitato vediamo... mai?
O forse l'ultima volta che ho aperto un'applet :asd:
La seconda volta è andata bene, la grafica è carina, per quanto semplice... però il gioco si è arenato al primo tiro perchè l'avversario l'ha buttata fuori dei limiti e poi non è successo nulla :stordita:
Per quanto riguarda la storia "giochi in java" beh mi ha convinto anche meglio che meno se ne fanno e meglio è, mi dispiace... 100+ mb e 20% del processore per un gioco dove manca quasi tutto come quello è proprio distante dal mio gioco ideale.
Il gioco su cui sto lavorando con 20+ personaggi, openal ogre physx e tutto il livello caricato, pesa leggermente di più.
E prima di dire "vabbè è normale" pensate che Fallout 1 girava su 486 con 8 mb di ram.
E che siamo andati sulla luna con un commodore 64.
Eccetera :asd:
Se è l'articolo di chet haase... adesso lavora per adobe :cry:
Qui:
http://www.javagaming.org/
trovi di tutto e di più.
si si era quello :asd:
ma mi ha fatto capire molte cose :D
ora mi sto leggendo tutte le faq e quinde sul forum di javaprogramming che mi hai postato :p
grazzie
prossimamente si vedrá! io e un amico stiamo realizzando per hobby un giochino 3D sotto forma di applet Java (lo diffonderemo come applicazione per Facebook); utilizza JOGL ed é un remake tridimensionale di un gioco vecchiotto che esiste giá e si chiama Blobby Volley. la nostra versione si chiama 3D Volley e si trova a questo sito: http://playbay.altervista.org/Volley
per ora é solo una demo, peró dá un'idea. richiede OpenGL 2.1 ma richiede anche GLSL 1.30, che significa che praticamente richiede OpenGL 3.x. prossimamente degraderemo gli shaders a GLSL 1.20, cosi richiederá veramente OpenGL 2.1. ad eccezione degli shaders é programmato in "forward-compatible OpenGL": in tutto il programma viene sempre usata l'interfaccia GL2GL3 del JSR 231.
fine pubblicitá abusiva :D
a me da un portatile con gm4500M intel non fa nulla, quando torno a casa sulla 8800 con driver aggiornati la riprovo :D
Puoi provare "Bang! Houwdy" se vuoi vedere un gioco 3d in un browser. fico! :eek:
peró non sta nel browser, a me si apre una finestra a parte :p
Intanto il download Java ci mette parecchio; solo la prima volta, poi resta tutto cachato; i jar vengono riscaricati solo quando ce n'é una nuova versione sul server.
comunque hai uno strano concetto di "parecchio": ripeto che il nostro jar é grosso solo 150 KB circa, e scaricare JOGL non é tutta sta tragedia; per dire, i giochi a cui gioco io su Facebook di norma ci mettono di piu a caricare rispetto a quanto ci mette 3D Volley dalla seconda volta in poi.
poi mi spawna 2 processi javaw da 60 mb e 10% del processore di cui uno rimane, e chrome sale di 10 mb. vabbé, finché regge... :stordita:
l'utente medio mica si mette a fare profiling delle applicazioni che usa su Facebook :D
e comunque noi invece lo faremo: ancora non abbiamo messo mano al profiler, ma é probabile che in futuro daremo luogo a diverse ottimizzazioni. il tutto é ancora a livelli embrionali; la scaletta di prioritá é quella dettata dalla norma: first make it work, then make it nice, eventually make it fast.
Inoltre cliccando options si è bloccato l'intero browser, cosa che trattandosi di chrome mi è capitato vediamo... mai?
O forse l'ultima volta che ho aperto un'applet :asd: buono a sapersi :stordita:
La seconda volta è andata bene, la grafica è carina, per quanto semplice... però il gioco si è arenato al primo tiro perchè l'avversario l'ha buttata fuori dei limiti e poi non è successo nulla :stordita: diamine, l'ho scritto molto chiaramente che é solo una demo e che mancano ancora fisica, AI e mesh della rete!! :stordita:
e mancano anche il mare all'orizzonte (sennó che spiaggia é) e la mesh di un paio di palme che volevo mettere dietro al campo.
Per quanto riguarda la storia "giochi in java" beh mi ha convinto anche meglio che meno se ne fanno e meglio è, mi dispiace... 100+ mb e 20% del processore per un gioco dove manca quasi tutto come quello è proprio distante dal mio gioco ideale. ripeto, l'utente non guarda l'uso di risorse V_V
l'uso di risorse non é neanche importante: l'importante é che il gioco funzioni e vada veloce, che é una cosa molto diversa perché se poi per farlo usa piu di 100 MB di memoria chi se ne frega.
tra l'altro puó anche darsi che quei 100 MB attuali siano dedicati prevalentemente all'infrastruttura e che aggiungendo altri elementi l'uso di risorse aumenti di poco. chi vivrá vedrá.
ma infatti la mia non era una critica al gioco, che mi sembra venga su bene anche se la grafica è semplice... non mi aspettavo di trovare un gioco completo :D
Cmq si, ci sono giochi flash che impiegano ben di più per essere caricati _ogni volta_... e si, è ovvio che il vostro gioco sono quei 10 mb su chrome, gli altri 100 son roba di java :asd:
Il problema è che l'utente FA profiling... un gioco che rallenta "un pò" un core2 con 4 gb di RAM manda completamente in panne un eeepc per esempio, e gli eeepc sono fra i maggiori target del "facebook gaming".
Quindi il solo uso di java ti mette in pericolo presso una bella fascia di potenziali giocatori... anche se in effetti non c'erano grosse alternative.
Quali altri modi di fare grafica 3D in-browser ci sono? :stordita:
Quali altri modi di fare grafica 3D in-browser ci sono? :stordita: Flash, ma hai presente ad esempio Bowling Buddies? fa pena :asd:
Quali altri modi di fare grafica 3D in-browser ci sono? :stordita: dimenticavo che a parte Flash il gruppo Khronos (quello che mantiene le specifiche di OpenGL) sta sviluppando una specifica per un binding di OpenGL in JavaScript che permetterá di mostrare grafica 3D all'interno dei browser senza nessun plugin, ne' Flash ne' Java. la specifica é ancora in via di sviluppo e per ora la versione preliminare é integrata in pochissimi browsers che non includono Internet Explorer, quindi chiaramente per adesso ancora non se ne parla.
ma infatti la mia non era una critica al gioco, che mi sembra venga su bene anche se la grafica è semplice... non mi aspettavo di trovare un gioco completo :D
Cmq si, ci sono giochi flash che impiegano ben di più per essere caricati _ogni volta_... e si, è ovvio che il vostro gioco sono quei 10 mb su chrome, gli altri 100 son roba di java :asd:
Il problema è che l'utente FA profiling... un gioco che rallenta "un pò" un core2 con 4 gb di RAM manda completamente in panne un eeepc per esempio, e gli eeepc sono fra i maggiori target del "facebook gaming".
Quindi il solo uso di java ti mette in pericolo presso una bella fascia di potenziali giocatori... anche se in effetti non c'erano grosse alternative.
Quali altri modi di fare grafica 3D in-browser ci sono? :stordita:
Il tuo profiler deve essere un po' strano perchè a me questo risulta:
screenshot profiler (http://www.tukano.it/immagini/applet_profile.jpg)
Il mio profiler è task manager di windows :D
Che poi è l'unica cosa che conta per l'utente finale...
PGI, ma stavi facendo il profiling del nostro gioco? dunque sei riuscito a farlo funzionare? perché ieri sera abbiamo retrocesso gli shaders a GLSL 1.20 :p
Si funziona (in windows, non ho provato in linux).
Ho fatto il profiling perchè il fatto che il programma consumasse così tante risorse quante dette da Tommo mi sembrava strano. Difatti non è così. Il programma parte ha un picco iniziale di sei megabyte e si assesta in seguito sui 3~4 megabyte. Per quanto riguarda l'uso della CPU su un Athlon 64 3200 è praticamente inesistente.
^TiGeRShArK^
05-01-2010, 16:08
su snow loepard con una 9600m non funge... :fagiano:
Ho fatto una prova con Mandriva.
Di primo acchitto mi dava lo stesso problema di ieri, poi ho formattato la partizione e adesso di problemi con mandriva non ne ho più.
@PGI o fero86
mi potete postare o inviare il codice di un vostro metodo render? che sono molto curioso :D:D
@PGI o fero86
mi potete postare o inviare il codice di un vostro metodo render? che sono molto curioso :D:D in che senso un metodo render? io e l'amico con cui sto sviluppando 3D Volley usiamo JOGL, quindi usiamo il metodo GLEventListener.display, ma il codice di redering é sparso in una marea di classi, senza contare gli shaders.
in che senso un metodo render? io e l'amico con cui sto sviluppando 3D Volley usiamo JOGL, quindi usiamo il metodo GLEventListener.display, ma il codice di redering é sparso in una marea di classi, senza contare gli shaders.
ahh :)
no era semplicemente curiosità perchè non sò queste cose avanzate :D
secondo quale logica effettua il rendering il tuo gioco? chi lo chiama?
in che senso un metodo render? io e l'amico con cui sto sviluppando 3D Volley usiamo JOGL, quindi usiamo il metodo GLEventListener.display, ma il codice di redering é sparso in una marea di classi, senza contare gli shaders.
ah volevo anche chiederti dove hai iniziato a imparare jogl :D
libri? se si quali?
secondo quale logica effettua il rendering il tuo gioco? chi lo chiama? prima di essere un'applicazione JOGL il mio applet é un'applicazione Swing, quindi il rendering viene richiesto semplicemente chiamando GLCanvas.repaint, il quale provoca infine una chiamata al metodo GLEventListener.display all'interno del quale faccio il rendering invocando i metodi dell'interfaccia GL2GL3. credo che il metodo display venga invocato nel contesto dell'EDT di Swing.
se ti interessa questo é il codice del nostro metodo GLEventListener.display ma non so quanto possa esserti utile :D
@Override
public void display(GLAutoDrawable drawable) {
GL2GL3 gl = drawable.getGL().getGL2GL3();
gl.glClear(GL_DEPTH_BUFFER_BIT);
for (Drawable element : initializedElements) {
element.draw(gl, camera);
}
gl.glFlush();
if (reportFrameRate) {
frameCount++;
long timestamp = System.nanoTime();
if (timestamp > frameRateTimestamp + 1000000000) {
System.out.println(frameCount + " fps");
frameRateTimestamp = timestamp;
frameCount = 0;
}
}
}
ah volevo anche chiederti dove hai iniziato a imparare jogl :D
libri? se si quali? esistono due OpenGL: quello con la vecchia filosofia (la fixed-function pipeline) e quello nuovo (basato sugli shaders). anni fa imparai a programmare in C++ con quello vecchio leggendo in MSDN la guida ed il reference della versione 1.1, dopodiché lessi i tutorial di NeHe e imparai diverse tecniche; quando venne il momento di buttare tutto al cesso ed imparare la nuova filosofia ero giá abbastanza esperto e in grado di leggere le specifiche, quindi lessi le specifiche di OpenGL 3.2 e GLSL 1.50 :p
le specifiche di GLSL sono semplicissime ma quelle di OpenGL ovviamente lo sono molto meno, quindi saltai diversi pezzi perlopiu relativi a funzionalitá non presenti in OpenGL 2.1. mentirei peró se dicessi di aver appreso la nuova filosofia esclusivamente dalle specifiche: il wiki del sito ufficiale mi é stato di grande aiuto.
ah, poi ovviamente per programmare in OpenGL attraverso JOGL bisogna anche leggere questa pagina: http://download.java.net/media/jogl/doc/userguide/
Fero86 ti segnalo che non riesco a giocare al tuo gioco con una Intel GMA950. L'ho anche aggiornata per l'occasione :D
Fero86 ti segnalo che non riesco a giocare al tuo gioco con una Intel GMA950. L'ho anche aggiornata per l'occasione :D io mi ritrovo tre report di una Intel 945GM, due di ieri sera e uno di oggi; sei tu? in tal caso hai OpenGL 1.4 mentre il gioco richiede OpenGL 2.1, quindi vale quanto hai letto nel messaggio di errore :D
dall'elenco delle estensioni che implementi mi pare di capire che la tua scheda grafica in teoria sarebbe anche abbastanza potente da far girare il gioco, é probabile che la colpa sia solo la pigrizia della Intel ad implementare OpenGL 2.1.
ad ogni modo grazie a tutti del feedback!
ad ogni modo grazie a tutti del feedback!
Si, sono io scusa. Ho provato la prima volta senza aggiornarla, l'ho aggiornata e ho riavviato. E ho provato una volta ieri sera e una volta oggi. Ma niente.
fero ho provato la tua applet e funziona benissimo davvero leggera!!!!!!
(C2D@7x333Mhz + 8800GT)
per gli aiuti che mi avete dato grazie a tutti ora è ora di scrivere un bel pò di codice :asd:
PS: PGI spero che il Mech abbia ceduto :asd:
banryu79
11-01-2010, 09:15
Ciao Fero,
volevo provare la tua demo ma ho qualche problema, aprendo la consolle Java leggo quanto segue:
java.lang.NoClassDefFoundError: javax/media/opengl/awt/GLCanvas
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.media.opengl.awt.GLCanvas
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 23 more
Ciao Fero,
volevo provare la tua demo ma ho qualche problema, aprendo la consolle Java leggo quanto segue:
java.lang.NoClassDefFoundError: javax/media/opengl/awt/GLCanvas
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.media.opengl.awt.GLCanvas
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 23 more
ed ecco uno degli aspetti negativi di Java (o solo di JOGL, non so di chi sia la colpa in questo caso, ma comunque sono entrabi della Sun :asd: ). se ci fai caso lo stack trace non tocca neanche uno dei miei metodi, ha fatto tutto Java; per qualche motivo a me ignoto il tuo JRE non é riuscito a scaricare JOGL. puó darsi che in quel momento il server HTTP che te lo doveva fornire fosse stracarico, ma molto piu probabilmente c'é stato qualche altro problema in locale. per caso eri dietro un proxy? se premi 5 sulla console attivi la modalitá di logging molto verbosa, e da li dovresti capire qual é il problema.
@ *andre*: grazie dell'entusiasmo, apprezzatissimo! :p
banryu79
12-01-2010, 08:39
se ci fai caso lo stack trace non tocca neanche uno dei miei metodi, ha fatto tutto Java;
Sì, avevo visto anch'io, ho postato solo per darti feedback e per vedere se insieme si riusciva a risolvere dato che vorrei soddisfare la mia curiosità e poter apprezzare anche io quello che hai fatto ;)
per qualche motivo a me ignoto il tuo JRE non é riuscito a scaricare JOGL.
per caso eri dietro un proxy? se premi 5 sulla console attivi la modalitá di logging molto verbosa, e da li dovresti capire qual é il problema.
Ho provato a farlo, ma l'output non dice molto di più di prima:
Livello di traccia impostato su 5: tutto ... completato.
basic: Interruzione applet...
basic: Rimosso ascoltatore avanzamento: sun.plugin.util.GrayBoxPainter@194ca6c
basic: Ricerca informazioni...
basic: Rilascio classloader: sun.plugin.ClassLoaderInfo@765291, refcount=0
basic: Caching classloader:
basic: Dimensioni cache classloader attuale: 1
basic: Fine...
basic: Esecuzione join thread...
basic: Distruzione applet...
basic: Eliminazione applet...
basic: Chiusura applet...
basic: Join thread eseguito...
basic: Referenziazione classloader: sun.plugin.ClassLoaderInfo@765291, refcount=1
basic: Aggiunto ascoltatore avanzamento: sun.plugin.util.GrayBoxPainter@a352a5
basic: Caricamento applet...
basic: Inizializzazione applet...
basic: Avvio applet...
basic: completed perf rollup
java.lang.NoClassDefFoundError: javax/media/opengl/awt/GLCanvas
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.media.opengl.awt.GLCanvas
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 23 more
basic: Eccezione: java.lang.NoClassDefFoundError: javax/media/opengl/awt/GLCanvas
Per il discorso del proxy: sì, mi connetto al web dall'interno di una lan aziendale passando per un firewall.
Per il discorso del proxy: sì, mi connetto al web dall'interno di una lan aziendale passando per un firewall. per "firewall" cosa si intende? io per "proxy" intendevo un proxy HTTP, non un router.
in passato ho provato ad avviare un'altra mia applicazione JOGL dai computers dell'universitá, anch'essi dietro un proxy HTTP (per giunta con autenticazione), e ho avuto problemi analoghi. solo in questo momento mi é venuta in mente una possibile soluzione: Pannello di Controllo, Java, tab "General", tasto "Network Settings..." ed imposti manualmente il proxy. all'universitá potró provare solamente venerdi :p
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.