View Full Version : Problema di compatibilità
Ne ho già parlato con Fek, Vicius e Vifani, ma ora data la situazione apro un topic a parte per segnalarvi un problema di compatibilità di Diamonds.
In pratica, essendo senza PC per cause di forza maggiore, l'ho testato su altri tre computer. In nessuno dei tre ha funzionato. Dà una exception di OpenGL, e la finestra si chiude immediatamente.
Più nel dettaglio, i PC in questione erano:
- Pentium2 400MHz, 128MB RAM, scheda video Matrox Marvel G200, Win98
- Pentium4 2GHz, 256MB RAM, chip video built-in Sis 650, WinXP Home
- Pentium4 1GHz, 256MB RAM, scheda video ATI Radeon serie 7000, Win 98
Ora, dopo il fallimento con i primi due, e dopo essere stato tranquillizzato sulla poca incidenza della cosa, mi ero convinto di avere avuto solo sfiga. Ma per quanto io possa essere sfigato, se il gioco non funziona su 3 PC su 4, un problema di fondo ci deve essere.
Quindi, chiedo a tutti voi di provare a testare il gioco anche su altri PC, possibilmente concentrandovi su quelli che usano Windows98.
Dobbiamo isolare il problema, valutare la sua reale incidenza e vedere di risolverlo. Per questo, utilizzeremo questo topic.
Link allo zip con l'exe aggiornato al 3/11:
http://lnx.rc6.it/diamonds/diam03112k5.zip
Ma da dove sei partito a provarlo ? Hai lanciato semplicemente Diamond.bat ? C'erano i file in bin ?
Ogni volta che devo testarlo, Fek o Vicius mi preparano una build con l'exe del gioco. Possiamo dire che si tratta di una versione di distribuzione, ogni volta aggiornata al punto a cui ci troviamo.
Quindi, dobbiamo fare in modo che questa funzioni su più configurazioni possibile (e, dato il problema che sta sorgendo, occorrono dei test per capire cosa c'è che non va).
ma perché in teoria quel bat presente in trunk dovrebbe addirittura funzionare? :D a me col cavolo che funziona... :cry:
non ho provato a vedere che errore da', ora provo... comunque a me quel bat apre una finestra di console che si richiude subito :mbe:
edit: l'errore che mi da è il seguente:
Exception in thread "main" java.lang.NoClassDefFoundError: it/diamonds/Game
e l'ho lanciato dalla directory trunk; forse dovevo lanciarlo da un'altra directory?
una cosa utile che potremmo provare a fare è, dopo aver trovato un PC su cui il gioco non funziona, provare ad installare Eclipse su quel PC e farlo partire da Eclipse anziché dal bat; se non altro potremmo fare il debug :)
A me sinceramente non riesce far partire Game.class da riga di comando... Come si fa ?
una cosa utile che potremmo provare a fare è, dopo aver trovato un PC su cui il gioco non funziona, provare ad installare Eclipse su quel PC e farlo partire da Eclipse anziché dal bat; se non altro potremmo fare il debug :)
Si può fare, ma consideriamo che si tratta della versione di distribuzione... quindi, il problema - se è esteso come sembra - affliggerà il gioco finito.
Per questo, dobbiamo assicurarci di trovarne la causa, e fare in modo di eliminarla.
Si può fare, ma consideriamo che si tratta della versione di distribuzione... quindi, il problema - se è esteso come sembra - affliggerà il gioco finito.
Per questo, dobbiamo assicurarci di trovarne la causa, e fare in modo di eliminarla. be' a parte tutto io non capisco come mai sui computers degli sviluppatori funziona sempre tutto a parte i bug noti e su quello dei customers non funziona mai nulla... :mbe:
oltrettutto hai detto che il programma ha dato eccezione anche su un PC con XP!!! :confused:
mah, è assurdo ma io ho la sensazione che se avviassimo con Eclipse funzionerebbe tutto... forse il problema sta proprio nel modo in cui viene generato l'exe... potete mandarmene una copia rarrata please? così oltrettutto vedo se riesco a farlo partire io, considerando che da me con Eclipse parte perfettamente ;)
be' a parte tutto io non capisco come mai sui computers degli sviluppatori funziona sempre tutto a parte i bug noti e su quello dei customers non funziona mai nulla... :mbe:
oltrettutto hai detto che il programma ha dato eccezione anche su un PC con XP!!! :confused:
mah, è assurdo ma io ho la sensazione che se avviassimo con Eclipse funzionerebbe tutto... forse il problema sta proprio nel modo in cui viene generato l'exe... potete mandarmene una copia rarrata please? così oltrettutto vedo se riesco a farlo partire io, considerando che da me con Eclipse parte perfettamente ;)
Il guaio è questo: non possiamo permetterci di avere un gioco che, una volta finito, su un numero incognito di PC girerà solo usando Eclipse :P
Sinceramente, credo che il problema riguardi Win98, e che quello di XP sia stato solo un caso (colpa della scheda video integrata Sis), però non posso dirlo con certezza: per poterlo fare bisogna testare la build di distribuzione su più computer possibile.
P.S.: Ne parliamo su MSN :P
be' a parte tutto io non capisco come mai sui computers degli sviluppatori funziona sempre tutto a parte i bug noti e su quello dei customers non funziona mai nulla... :mbe:
Fatti un giro nel forum Giochi e vedi che succede poi quando lo distribuisci a 2 milioni di persone :(
Testare su piu' computer possibile? Testing Lab? Bug report? Performance report? EALA? Oddio, mi tornano gl'incubi... dov'e' l'X360? Dov'e'? Dov'e??????
Testare su piu' computer possibile? Testing Lab? Bug report? Performance report? EALA? Oddio, mi tornano gl'incubi... dov'e' l'X360? Dov'e'? Dov'e??????
il ricordo di B&W2 fa brutti scherzi? :Prrr: :Prrr:
Io l'ho provato da questo (PIV 3.4, 2gb ram, 6800gt, win xp pro) e dal notebook (centrino 1.4, 512 mb, 9600, win xp home + suse 10) e in tutti e due funziona, però l'ho lanciato direttamente da eclipse, se mi passate l'exe ( cover3000 at email.it ) domani mattina lo provo su una decina di pc (sperando ci sia java installato :mbe: ) e di pomeriggio se trovo abbastanza tempo provo su 98, me e 2000
BlueDragon
04-11-2005, 22:03
Ho provato ad usare uno zip che era allegato in un'altra discussione con l'exe di Diamonds e...sorpresa! Non mi funziona. Win2000 e scheda video AsusV9520.. che non ha nessun problema a far girare il progetto da Eclipse.
Mi sa che è la fabbricazione dell'exe a creare qualche problema..:)
Ho provato ad usare uno zip che era allegato in un'altra discussione con l'exe di Diamonds e...sorpresa! Non mi funziona. Win2000 e scheda video AsusV9520.. che non ha nessun problema a far girare il progetto da Eclipse.
Mi sa che è la fabbricazione dell'exe a creare qualche problema..:)
Azz allora il mio non è un caso isolato... dobbiamo provvedere assolutamente. Anche a te dà un'exception di OpenGL che scompare immediatamente?
Per comodità, vi uppo l'exe sul mio server.
http://lnx.rc6.it/diamonds/diam03112k5.zip
Riporto il link anche nel primo post, così ha più visibilità.
Io l'ho provato da questo (PIV 3.4, 2gb ram, 6800gt, win xp pro) e dal notebook (centrino 1.4, 512 mb, 9600, win xp home + suse 10) e in tutti e due funziona, però l'ho lanciato direttamente da eclipse, se mi passate l'exe ( cover3000 at email.it ) domani mattina lo provo su una decina di pc (sperando ci sia java installato :mbe: ) e di pomeriggio se trovo abbastanza tempo provo su 98, me e 2000
Facci sapere ;)
Brutta notizia... Su questo (PIV 3.4) funziona, l'ho provato sull'altro fisso qua vicino (2200+, 256 ram, matrox g400, win xp) in cui c'è installato java 5...errore in allegato... :(
http://img476.imageshack.us/img476/6702/immagine5wt.th.jpg (http://img476.imageshack.us/my.php?image=immagine5wt.jpg)
Edit: ho provato a mettere sul 2200+ eclipse + il progetto e compilarlo, stesso errore...in questo caso penso sia il pc (...g400 :doh: ), domani provo a scuola, anche se però non sò cosa c'è di video, al massimo provo sui portatili dei compagni :rolleyes:
BlueDragon
04-11-2005, 22:44
Azz allora il mio non è un caso isolato... dobbiamo provvedere assolutamente. Anche a te dà un'exception di OpenGL che scompare immediatamente?
Non ti so dire..scompare così velocemente che non leggo nulla..non vedo nemmeno se c'è scritto qualcosa :p
ragazzi questo exe me lo passate si o no? ^^
comunque già avere il messaggio di errore è indicativo: il messaggio parla di pixel format, dice che non riesce a trovarne uno valido...
ma perché in teoria quel bat presente in trunk dovrebbe addirittura funzionare? :D a me col cavolo che funziona... :cry:
non ho provato a vedere che errore da', ora provo... comunque a me quel bat apre una finestra di console che si richiude subito :mbe:
Colpa mia :D
Prima stavano in bin/ poi li ho spostati nella root perchè eclipse li cancellava in continuazione. Il .sh l'ho sistemato e provato ma per il .bat sono andato alla cieca. Vedete di risolvere voi utenti con windows che io non ho voglia di accendere il portatile :p
ciao ;)
Brutta notizia... Su questo (PIV 3.4) funziona, l'ho provato sull'altro fisso qua vicino (2200+, 256 ram, matrox g400, win xp) in cui c'è installato java 5...errore in allegato... :(
http://img476.imageshack.us/img476/6702/immagine5wt.th.jpg (http://img476.imageshack.us/my.php?image=immagine5wt.jpg)
Edit: ho provato a mettere sul 2200+ eclipse + il progetto e compilarlo, stesso errore...in questo caso penso sia il pc (...g400 :doh: ), domani provo a scuola, anche se però non sò cosa c'è di video, al massimo provo sui portatili dei compagni :rolleyes:
Il problema in quel caso è il pixel format che non viene trovato. Prova a sostituire i 24 con 32 e probabilmente funziona. Cmq ragazzi ancora una volta è necessario definire dei paletti e cioè il tipo di hardware che intendiamo supportare. E' chiaro che SiS e Matrox hanno un'implementazione dei driver OpenGL (specie per prodotti vecchi come le G400 sulle quali non a caso faticava a girare Quake III Arena) penosa.
Riguardo la Radeon 7000 testata da Jocchan mi viene una domanda da fare: che versione della JVM è installata? Che versione dei driver Catalyst è installata?
Un'ultima cosa: io eviterei di creare gli eseguibili con i vari compilatori che si trovano. E' un progetto Java e non c'è bisogno di creare l'EXE, ma basta un banale .bat ed un collegamento sul desktop creato in fase di installazione con un'icona carina. Se volete vi preparo io un installer con Windows Installer.
^TiGeRShArK^
05-11-2005, 01:25
ma perché in teoria quel bat presente in trunk dovrebbe addirittura funzionare? :D a me col cavolo che funziona... :cry:
non ho provato a vedere che errore da', ora provo... comunque a me quel bat apre una finestra di console che si richiude subito :mbe:
edit: l'errore che mi da è il seguente:
Exception in thread "main" java.lang.NoClassDefFoundError: it/diamonds/Game
e l'ho lanciato dalla directory trunk; forse dovevo lanciarlo da un'altra directory?
bisogna controllare il classpath... quel bat l'avevo fatto io x lanciarlo da windows, ma poi nn l'ho + aggiornato xkè credevo ke tutti lo lanciassero da eclipse...
se serve qdo ho un pò di tempo gli posso dare un okkiata e lo aggiusto....
D'accordo sul non distribuire l'exe, ma solamente i vari script di shell (o al limite piccoli exe) che lanciano il gioco e i file jar...
Il problema in quel caso è il pixel format che non viene trovato. Prova a sostituire i 24 con 32 e probabilmente funziona. Cmq ragazzi ancora una volta è necessario definire dei paletti e cioè il tipo di hardware che intendiamo supportare. E' chiaro che SiS e Matrox hanno un'implementazione dei driver OpenGL (specie per prodotti vecchi come le G400 sulle quali non a caso faticava a girare Quake III Arena) penosa.
Riguardo la Radeon 7000 testata da Jocchan mi viene una domanda da fare: che versione della JVM è installata? Che versione dei driver Catalyst è installata?
Un'ultima cosa: io eviterei di creare gli eseguibili con i vari compilatori che si trovano. E' un progetto Java e non c'è bisogno di creare l'EXE, ma basta un banale .bat ed un collegamento sul desktop creato in fase di installazione con un'icona carina. Se volete vi preparo io un installer con Windows Installer.
L'errore che capita a me, in tutti e tre i casi, è diverso.
Si tratta di questo:
http://lnx.rc6.it/diamonds/stuff/error01.jpg
Per i paletti, data la relativamente poca complessità del progetto, teoricamente dovremmo poterci riferire ad un ampio numero di macchine (anche il pentium2 che sto usando adesso dovrebbe riuscire a far girare il progetto).
Per la versione della JVM e di Catalyst della Radeon, comunque, posso dirtelo solo domani pomeriggio ;)
Se è possibile, inoltre, creare un eseguibile in maniera diversa, o anche accontentarsi del bat, per favore che qualcuno di buona volontà provveda (e me lo passi).
@71104: il link all'exe creato con Eclipse lo trovi nel primo post ;)
Colpa mia :D
Prima stavano in bin/ poi li ho spostati nella root perchè eclipse li cancellava in continuazione. Il .sh l'ho sistemato e provato ma per il .bat sono andato alla cieca. Vedete di risolvere voi utenti con windows che io non ho voglia di accendere il portatile :p
ciao ;)
Avevo risolto io il problema trasformando il .jar in .exe che lancia il gioco con il classpath giusto. Perche' non funziona piu'?
Il problema in quel caso è il pixel format che non viene trovato. Prova a sostituire i 24 con 32 e probabilmente funziona. Cmq ragazzi ancora una volta è necessario definire dei paletti e cioè il tipo di hardware che intendiamo supportare. E' chiaro che SiS e Matrox hanno un'implementazione dei driver OpenGL (specie per prodotti vecchi come le G400 sulle quali non a caso faticava a girare Quake III Arena) penosa.
Riguardo la Radeon 7000 testata da Jocchan mi viene una domanda da fare: che versione della JVM è installata? Che versione dei driver Catalyst è installata?
Credo che in questo caso il problema sia dovuto da una parte alla scarsa compatibilita' dei driver OGL (Matrox), ma dall'altra dal fatto che il desktop e' settato a 16bit mentre la nostra routine richiede 24bit di profondita'. Un semplice fix che dovrebbe risolvere molti di questi problemi e' rilassare il metodo che cerca un pixelformat compatibile e accettare anche quelli a 16bit e 32bit che vanno benissimo per il tipo di gioco che stiamo scrivendo.
Te ne vuoi occupare tu?
Riguardo all'hardware: il nostro target e' il piu' ampio possibile, se riusciamo a supportare anche ciofeche tipo la Matrox tanto di guadgnato.
Un'ultima cosa: io eviterei di creare gli eseguibili con i vari compilatori che si trovano. E' un progetto Java e non c'è bisogno di creare l'EXE, ma basta un banale .bat ed un collegamento sul desktop creato in fase di installazione con un'icona carina. Se volete vi preparo io un installer con Windows Installer.
Ho fatto in modo di creare in fase di build uno stub che trasforma il .jar in .exe con i classpath giusti che viene lanciato semplicemente con un doppio click. La stessa cosa puo' essere fatta per linux. La soluzione funzionava ragionevolmente bene e non richiedeva alcuna compilazione o file batch.
Al momento e' la soluzione piu' pulita che preferisco.
Credo che in questo caso il problema sia dovuto da una parte alla scarsa compatibilita' dei driver OGL (Matrox), ma dall'altra dal fatto che il desktop e' settato a 16bit mentre la nostra routine richiede 24bit di profondita'. Un semplice fix che dovrebbe risolvere molti di questi problemi e' rilassare il metodo che cerca un pixelformat compatibile e accettare anche quelli a 16bit e 32bit che vanno benissimo per il tipo di gioco che stiamo scrivendo.
Te ne vuoi occupare tu?
Riguardo all'hardware: il nostro target e' il piu' ampio possibile, se riusciamo a supportare anche ciofeche tipo la Matrox tanto di guadgnato.
Ho fatto in modo di creare in fase di build uno stub che trasforma il .jar in .exe con i classpath giusti che viene lanciato semplicemente con un doppio click. La stessa cosa puo' essere fatta per linux. La soluzione funzionava ragionevolmente bene e non richiedeva alcuna compilazione o file batch.
Al momento e' la soluzione piu' pulita che preferisco.
Faccio un piccolo aggiornamento di quel metodo: se non si trovano i 24 bit, si cercheranno i 16 bit, fermo restando che un driver decente dovrebbe far funzionare cmq applicazioni in finestra con un pixel format diverso da quello del desktop. Invito, specie chi ha schede video molto vecchie, ad aggiornare i driver perché il supporto OpenGL in taluni casi, vedi Matrox, ma anche ATI, è stato migliorato solo negli ultimi anni. Se il sistema si ritrova ad esempio i driver che mette Windows all'installazione del sistema operativo, non funzionerà mai perché non c'è supporto OpenGL (o se non erro non oltre l'OpenGL 1.1).
Faccio un piccolo aggiornamento di quel metodo: se non si trovano i 24 bit, si cercheranno i 16 bit, fermo restando che un driver decente dovrebbe far funzionare cmq applicazioni in finestra con un pixel format diverso da quello del desktop. Invito, specie chi ha schede video molto vecchie, ad aggiornare i driver perché il supporto OpenGL in taluni casi, vedi Matrox, ma anche ATI, è stato migliorato solo negli ultimi anni. Se il sistema si ritrova ad esempio i driver che mette Windows all'installazione del sistema operativo, non funzionerà mai perché non c'è supporto OpenGL (o se non erro non oltre l'OpenGL 1.1).
Ok.
Però dobbiamo verificare se il problema rimane anche se l'exe di distribuzione NON viene creato da Eclipse.
Inoltre, su schede non troppo vecchie (come invece lo è la mia Marvel G200, i cui ultimi driver sono datati luglio 2001, ed il cui supporto OpenGL è solo beta, aggiornato al 1999, e che quindi non fa testo) dovremmo fare in modo da evitare di costringere ad aggiornare i driver. Ad esempio, sulla Radeon 7000 che ho testato ieri questo non dovrebbe essere necessario (avrà tre annetti di sopra, non di più), vista la non eccessiva complessità del progetto.
Voglio dire, posso capire che B&W2 possa necessitare di DirectX e OpenGL aggiornati all'altro ieri, ma visto che stiamo lavorando ad un titolo che potrebbe (dovrebbe) andare a invadere più pc possibili, non solo quelli di chi gioca abitualmente ma anche quelli degli uffici (lol), generalmente risalenti al giurassico e dove non ci si mette certo ad installare driver, credo che sia necessario intervenire per semplificare tutto.
@71104: il link all'exe creato con Eclipse lo trovi nel primo post ;) l'ho provato da me e funziona; Windows 2000 pro, schedina grafica di m***a Intel 82865G.
poi quando ho voglia lo provo sul portatile, centrino Windows XP pro, ATI Radeon non mi ricordo quale :p
l'ho provato da me e funziona; Windows 2000 pro, schedina grafica di m***a Intel 82865G.
poi quando ho voglia lo provo sul portatile, centrino Windows XP pro, ATI Radeon non mi ricordo quale :p
Ottimo, grazie ^^
La priorità ora, comunque, è diventata verificare se è possibile creare una versione di distribuzione senza usare Eclipse, e testare il funzionamento di quella.
Probabilmente dipende anche da come Eclipse costruisce l'exe.
Ok.
Però dobbiamo verificare se il problema rimane anche se l'exe di distribuzione NON viene creato da Eclipse.
Inoltre, su schede non troppo vecchie (come invece lo è la mia Marvel G200, i cui ultimi driver sono datati luglio 2001, ed il cui supporto OpenGL è solo beta, aggiornato al 1999, e che quindi non fa testo) dovremmo fare in modo da evitare di costringere ad aggiornare i driver. Ad esempio, sulla Radeon 7000 che ho testato ieri questo non dovrebbe essere necessario (avrà tre annetti di sopra, non di più), vista la non eccessiva complessità del progetto.
Voglio dire, posso capire che B&W2 possa necessitare di DirectX e OpenGL aggiornati all'altro ieri, ma visto che stiamo lavorando ad un titolo che potrebbe (dovrebbe) andare a invadere più pc possibili, non solo quelli di chi gioca abitualmente ma anche quelli degli uffici (lol), generalmente risalenti al giurassico e dove non ci si mette certo ad installare driver, credo che sia necessario intervenire per semplificare tutto.
E' assolutamente impossibile evitare di richiedere l'aggiornamento dei driver. Noi facciamo uso di OpenGL e i driver devono essere aggiornati. Se si vuole garantire il funzionamento del gioco della serie, "ci clicco sopra e parte senza problemi e senza richiedere installazioni varie", allora non solo non si usa OpenGL (ma se è per questo anche OpenAL), ma non dovremmo usare neanche Java. Se una persona è in grado di installare Java, allora può installare anche i driver più aggiornati.
La Radeon 7000 è un prodotto di qualcosa come 4/5 anni fa e gli ultimi driver per Windows 98/ME sono i Catalyst 5.9 usciti un mese fa. Se ci sono driver vecchi di tre anni è assolutamente probabile il non funzionamento di un gioco OpenGL (per quanto semplice sia) perché all'epoca il driver OpenGL di ATI era fatto solo per Quake II, Quake III e derivati.
Ripeto: Diamonds fa uso di OpenGL (versione 1.3 attualmente) e se il driver OpenGL non è fatto a dovere ci possono essere problemi. Le cose sono due: o non si usa OpenGL e neanche Java, ma usiamo il C e ci mettiamo a disegnare via software ogni singolo pixel, oppure si pretende l'installazione di driver aggiornati.
Il problema in quel caso è il pixel format che non viene trovato. Prova a sostituire i 24 con 32 e probabilmente funziona.
Era già impostato a 32, ho provato a cambiare a 16 stesso errore, 24 non c'è :mbe:
Comunque a scuola non c'era installata nemmeno una versione di java... -.- e la password dell'account amministratore locale l'hanno cambiata, dovrò rimettermi e ritrovarla :muro:
Però sono riuscito a provarlo su un portatile (3400+64, 512/1024mb, ati x200, xp pro.. se non ricordo male..) in cui c'è java 5 e ultimi (o quasi driver) e funziona senza problemi.
Io a questo punto sarei per l'aggiornamento dei driver, magari (non sò se è possibile tramite java) con un controllo per sapere quali sono installati e in caso avvisare l'utente. Disegnare tramite C tutti i pixel mi sembra solo una pazzia... :stordita:
Era già impostato a 32, ho provato a cambiare a 16 stesso errore, 24 non c'è :mbe:
Infatti molte Matrox non hanno 24 bit di profondità di colore...
Riguardo alla JVM...deve essere assolutamente 1.5 o maggiore...e da questo non ci si scampa...
Ok.
Però dobbiamo verificare se il problema rimane anche se l'exe di distribuzione NON viene creato da Eclipse.
Inoltre, su schede non troppo vecchie (come invece lo è la mia Marvel G200, i cui ultimi driver sono datati luglio 2001, ed il cui supporto OpenGL è solo beta, aggiornato al 1999, e che quindi non fa testo) dovremmo fare in modo da evitare di costringere ad aggiornare i driver. Ad esempio, sulla Radeon 7000 che ho testato ieri questo non dovrebbe essere necessario (avrà tre annetti di sopra, non di più), vista la non eccessiva complessità del progetto.
Voglio dire, posso capire che B&W2 possa necessitare di DirectX e OpenGL aggiornati all'altro ieri, ma visto che stiamo lavorando ad un titolo che potrebbe (dovrebbe) andare a invadere più pc possibili, non solo quelli di chi gioca abitualmente ma anche quelli degli uffici (lol), generalmente risalenti al giurassico e dove non ci si mette certo ad installare driver, credo che sia necessario intervenire per semplificare tutto.
Esatto. Nella nostra situazione (un gioco open source in java di basso profile) non possiamo richiedere l'aggiornamento dei driver, ma dobbiamo funzionare con il piu' ampio range di configurazioni hardware/software possibile. Per ora direi che l'unico problema e' rilassare la ricerca delpixel format e accontentarsi anche di 16bit o 32bit.
Ottimo, grazie ^^
La priorità ora, comunque, è diventata verificare se è possibile creare una versione di distribuzione senza usare Eclipse, e testare il funzionamento di quella.
Probabilmente dipende anche da come Eclipse costruisce l'exe.
Creo l'exe di distribuzione direttamente da Ant senza passare da Eclipse.
Quali sono le parti del progetto che richiedono OpenGL 1.3 e non funzionano con OpenGL 1.1 ?
Ripeto: Diamonds fa uso di OpenGL (versione 1.3 attualmente) e se il driver OpenGL non è fatto a dovere ci possono essere problemi. Le cose sono due: o non si usa OpenGL e neanche Java, ma usiamo il C e ci mettiamo a disegnare via software ogni singolo pixel, oppure si pretende l'installazione di driver aggiornati.
Si' puo' anche cercare di funzionare col piu' ampio range di driver possibile. Se poi il driver e' assolutamente incompatibile e troppo vecchio, amen. Ma la ricerca della massima compatibilita' possibile date le nostre scelte (Java 1.5 e OpenGL 1.3) e' d'obbligo.
Ehm... :(
Ho aggiornato agli ultimi driver (26/10/04) per la g400. Ok, mi vede i 24.
Provo a 16, niente...
Provo a 24, niente...
Provo a 32, niente...
:cry:
Stesso errore postato ieri, anche a 24
Il fatto è che se si vuole "conquistare il mondo" di uffici/scuole l'aggiornamento dei driver sarebbe meglio escluderlo (ma a quanto ho capito non è possibile). Difficilmente si trovano pc (soprattutto scuole, uffici sul mio avevo di tutto e di più ^^ però dubito che quello della segretaria ha qualcosa di aggiornato) aggiornatissimi come driver, più che altro interessa che il video funzioni, se poi ci sono gli ultimi non conta molto, tanto alla fine per la didattica che si fa (a meno che è qualche laboratorio di grafica/programmazione 3d o qualcosa che richiede driver aggiornati) non servono a molto. Anzi, solo uno sbattimento in più per il tecnico a dover installare i driver su tutti i pc.
Puoi provare l'ultima versione e darmi l'errore esatto in caso non funzionasse?
Si' puo' anche cercare di funzionare col piu' ampio range di driver possibile. Se poi il driver e' assolutamente incompatibile e troppo vecchio, amen. Ma la ricerca della massima compatibilita' possibile date le nostre scelte (Java 1.5 e OpenGL 1.3) e' d'obbligo.
Francesco, se usi driver del 2002 per una Radeon 7000 ti assicuro che è molto probabile incontrare dei problemi e personalmente non penso sia il caso fare i salti mortali mettendo a rischio la pulizia e la stabilità del codice sulle altre macchine, per risolvere problemi che non sono nostri (e che probabilmente, vedi Matrox vecchie, non sono risolvibili). Qualsiasi problema che si presenta con driver vecchi e che con driver recenti svanisce, non è un nostro problema.
Il discorso del pixel format è un problema secondario che si risolvere con il discorso dei 16 bit e che probabilmente avremmo avuto anche usando un'API come Direct3D. Io sto facendo un discorso più ampio.
Comunque io sto aggiungendo la stampa in console di tutte le display modes disponibili così chi ha problemi può riferircela per capire il problema.
Adesso sto uscendo. Torno tra un paio d'ore. Nel frattempo provate con la nuova versione che ho committato. Chi ha problemi ci incolli esattamente il printout della console.
Francesco, se usi driver del 2002 per una Radeon 7000 ti assicuro che è molto probabile incontrare dei problemi e personalmente non penso sia il caso fare i salti mortali mettendo a rischio la pulizia e la stabilità del codice sulle altre macchine, per risolvere problemi che non sono nostri (e che probabilmente, vedi Matrox vecchie, non sono risolvibili). Qualsiasi problema che si presenta con driver vecchi e che con driver recenti svanisce, non è un nostro problema.
Il discorso del pixel format è un problema secondario che si risolvere con il discorso dei 16 bit e che probabilmente avremmo avuto anche usando un'API come Direct3D. Io sto facendo un discorso più ampio.
Comunque io sto aggiungendo la stampa in console di tutte le display modes disponibili così chi ha problemi può riferircela per capire il problema.
Ascolta, non sto dicendo che dobbiamo fare i salti mortali, sto dicendo che "supportiamo solo gli ultimi driver" non e' per noi una scelta possibile. Abbiamo bisogno della giusta via di mezzo: dove possiamo metterci una pezza in software lo facciamo, dove non possiamo, pazienza.
Sul pixel format sono certo che una pezza riusciamo a metterla.
Stampare per iniziale i pixel format (magari in modalita' di debug) e' un'ottima idea, grazie :)
E' assolutamente impossibile evitare di richiedere l'aggiornamento dei driver. Noi facciamo uso di OpenGL e i driver devono essere aggiornati. Se si vuole garantire il funzionamento del gioco della serie, "ci clicco sopra e parte senza problemi e senza richiedere installazioni varie", allora non solo non si usa OpenGL (ma se è per questo anche OpenAL), ma non dovremmo usare neanche Java. Se una persona è in grado di installare Java, allora può installare anche i driver più aggiornati.
La Radeon 7000 è un prodotto di qualcosa come 4/5 anni fa e gli ultimi driver per Windows 98/ME sono i Catalyst 5.9 usciti un mese fa. Se ci sono driver vecchi di tre anni è assolutamente probabile il non funzionamento di un gioco OpenGL (per quanto semplice sia) perché all'epoca il driver OpenGL di ATI era fatto solo per Quake II, Quake III e derivati.
Ripeto: Diamonds fa uso di OpenGL (versione 1.3 attualmente) e se il driver OpenGL non è fatto a dovere ci possono essere problemi. Le cose sono due: o non si usa OpenGL e neanche Java, ma usiamo il C e ci mettiamo a disegnare via software ogni singolo pixel, oppure si pretende l'installazione di driver aggiornati.
Se è proprio impossibile, allora non sbagliavo quando dicevo di non usare OpenGL.
Stavamo andando nettamente contro le specifiche presenti fin dall'inizio nel documento di design (massima portabilità e compatibilità, anche con macchine di scarsa potenza e con qualche annetto di sopra).
Colpa mia, avrei dovuto oppormi (anche se credevo fosse solo un problema del mio PC, e che l'incidenza fosse tutto sommato quasi nulla... ma non è una scusante, la responsabilità rimane mia).
Noi non abbiamo a che fare con un gioco tecnicamente complesso, come un B&W2, un Doom3 e compagnia bella, per i quali è ovvio l'obbligo di avere tutto aggiornato. Abbiamo a che fare con un gioco che sarebbe potuto benissimo uscire nel 1996, quando ancora OpenGL era fantascienza. Quindi, è assurdo dover sottostare a limitazioni di questo genere, visto che - a quanto sto notando - l'incidenza non è affatto minima, e stiamo tagliando fuori una parte rilevante del target a cui ci rivolgiamo.
Il gioco deve poter funzionare su più computer possibile, e questo concetto dobbiamo tenercelo tutti (io in primis) ben fisso in testa, o non arriviamo da nessuna parte.
Ora, per favore, ditemi esattamente quanto è radicato l'uso di OpenGL nel codice, e cosa possiamo fare per ridurre la sua importanza, o per lo meno cosa potremmo fare per poterci appoggiare anche solo ad una versione precedente delle librerie (sarebbe già un passo avanti).
Sicuramente dobbiamo supportare:
- Tutti i chipset Intel integrati (che detengono la maggioranza del mercato)
- Radeon 7X00 che sono ancora ragionevolmente diffuse in PC low end
- GeForceX (vedi sopra)
Per le Matrox vediamo un po' che si puo' fare ma ho poche speranza.
Oddio, ho una sensazione di dejavu, ho fatto gli stessi discorsi uguali uguali qualche mese fa, ma io ero quello che diceva di supportare solo gli ultimi driver :D
Sicuramente dobbiamo supportare:
- Tutti i chipset Intel integrati (che detengono la maggioranza del mercato)
- Radeon 7X00 che sono ancora ragionevolmente diffuse in PC low end
- GeForceX (vedi sopra)
Per le Matrox vediamo un po' che si puo' fare ma ho poche speranza.
Oddio, ho una sensazione di dejavu, ho fatto gli stessi discorsi uguali uguali qualche mese fa, ma io ero quello che diceva di supportare solo gli ultimi driver :D
Ma sì, non dico che dobbiamo ammazzarci per arrivare ad una compatibilità con le voodoo2, però almeno cerchiamo di attenerci un minimo alle specifiche: non stiamo lavorando a Doom3, ma ad un puzzle game 2D e (risoluzione e numero di colori a parte) ce n'erano anche per Super Nintendo...
Ora, per favore, ditemi esattamente quanto è radicato l'uso di OpenGL nel codice, e cosa possiamo fare per ridurre la sua importanza, o per lo meno cosa potremmo fare per poterci appoggiare anche solo ad una versione precedente delle librerie (sarebbe già un passo avanti).
Piano, la scelta di OpenGL va benissimo e ci garantisce ottima compatibilita'. Ci sono alcune situazioni limite che valuteremo di volta in volta, ma il nostro uso di OGL e' abbastanza limitato da poterlo considerare virtualmente compatibile con tutto e ogni problema sistemabile in software.
Non c'e' ragione di allarmarsi :)
Piano, la scelta di OpenGL va benissimo e ci garantisce ottima compatibilita'. Ci sono alcune situazioni limite che valuteremo di volta in volta, ma il nostro uso di OGL e' abbastanza limitato da poterlo considerare virtualmente compatibile con tutto e ogni problema sistemabile in software.
Benissimo. Però questo significa che, via software, dobbiamo sistemare questi problemi (e lo faremo) :)
Puoi provare l'ultima versione e darmi l'errore esatto in caso non funzionasse?
Comunque io sto aggiungendo la stampa in console di tutte le display modes disponibili così chi ha problemi può riferircela per capire il problema.
320 x 240 x 16 @63Hz
800 x 600 x 32 @72Hz
Exception in thread "main" it.diamonds.engine.DisplayException: The current display mode is not available due to org.lwjgl.LWJGLException: Could not find a valid pixel format
at it.diamonds.engine.DisplayImpl.initDisplay(DisplayImpl.java:140)
at it.diamonds.engine.DisplayImpl.<init>(DisplayImpl.java:34)
at it.diamonds.engine.Engine.create(Engine.java:27)
at it.diamonds.Game.createEngine(Game.java:81)
at it.diamonds.Game.main(Game.java:45)
Quali sono le funzionalità di OpenGL 1.3 che usiamo e che in OpenGL 1.1 non ci sono ? Non converrebbe portare tutto alla schifezza di ICD software presente in molti Windows ?
Quali sono le funzionalità di OpenGL 1.3 che usiamo e che in OpenGL 1.1 non ci sono ? Non converrebbe portare tutto alla schifezza di ICD software presente in molti Windows ?
Questa e' un'opzione da valutare. Per ora solo il fatto di usare Java 5 ci limita molto di piu' il potenziale "mercato".
Per ora solo il fatto di usare Java 5 ci limita molto di piu' il potenziale "mercato".
Sicuramente...e se è solo per i generics ne possiamo anche fare a meno... Anche se questa è una faccenda molto più gestibile (tipo linkare la distribuzione di Java 1.5 dal sito dove si scarica il gioco)...
Questa e' un'opzione da valutare. Per ora solo il fatto di usare Java 5 ci limita molto di piu' il potenziale "mercato".
Come confermato da questa mattina che su quei pc non è presente neanche una versione di java (tecnici pigri :doh: :muro: )
E' sicuramente una situazione migliore rispetto all'avere una versione vecchia ;)
320 x 240 x 16 @63Hz
800 x 600 x 32 @72Hz
Exception in thread "main" it.diamonds.engine.DisplayException: The current display mode is not available due to org.lwjgl.LWJGLException: Could not find a valid pixel format
at it.diamonds.engine.DisplayImpl.initDisplay(DisplayImpl.java:140)
at it.diamonds.engine.DisplayImpl.<init>(DisplayImpl.java:34)
at it.diamonds.engine.Engine.create(Engine.java:27)
at it.diamonds.Game.createEngine(Game.java:81)
at it.diamonds.Game.main(Game.java:45)
Il tuo errore viene generato da questa riga:
Display.create(new PixelFormat(24, 0, 24, 0, 0));
Dove posso trovare un po' di documentazione sulla classe PixelFormat?
Certo, ma una situazione peggiore per il "mercato" :rolleyes:
Sicuramente...e se è solo per i generics ne possiamo anche fare a meno... Anche se questa è una faccenda molto più gestibile (tipo linkare la distribuzione di Java 1.5 dal sito dove si scarica il gioco)...
Esatto. Chi scarica il gioco può scaricare anche le runtime Java.
Fare la stessa cosa per i driver delle singole schede video, diciamo che sarebbe un tantino più complesso :p
Il tuo errore viene generato da questa riga:
Display.create(new PixelFormat(24, 0, 24, 0, 0));
Dove posso trovare un po' di documentazione sulla classe PixelFormat?
http://doc.lwjgl.org/javadoc/org/lwjgl/opengl/PixelFormat.html ?
^TiGeRShArK^
05-11-2005, 15:21
intanto io ho sistemato diamonds.bat per partire da windows col corretto classpath e utilizzando le classi presenti in bin.
Fatremi sapere se ci sono problemi.
Puoi provare l'ultima versione?
Se me la passate via MSN (il-mio-nick-chiocciola-hotmail.it), la testo subito.
P.S.: dopo il tizio strambo che mi ha addato l'altra sera (fek ne sa qualcosa) il mio contatto MSN non lo scrivo più per intero :P
Puoi provare l'ultima versione?
List of available display modes:
320 x 240 x 16 @63Hz
800 x 600 x 32 @72Hz
Best mode: 800 x 600 x 32 @72Hz
Exception in thread "main" java.lang.IllegalStateException: Function is not supported
at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:66)
at org.lwjgl.opengl.GL13.glActiveTexture(GL13.java:113)
at it.diamonds.engine.Texture.enable(Texture.java:121)
at it.diamonds.engine.Texture.enable(Texture.java:143)
at it.diamonds.engine.Engine.drawQuad(Engine.java:82)
at it.diamonds.engine.Sprite.draw(Sprite.java:86)
at it.diamonds.Background.draw(Background.java:52)
at it.diamonds.engine.LayerManager.drawLayer(LayerManager.java:74)
at it.diamonds.engine.LayerManager.drawLayers(LayerManager.java:82)
at it.diamonds.Game.render(Game.java:165)
at it.diamonds.Game.main(Game.java:55)
intanto io ho sistemato diamonds.bat per partire da windows col corretto classpath e utilizzando le classi presenti in bin.
Fatremi sapere se ci sono problemi.
Ma %DIAMONDS_HOME% non è detto che sia definita :what:
List of available display modes:
320 x 240 x 16 @63Hz
800 x 600 x 32 @72Hz
Best mode: 800 x 600 x 32 @72Hz
Exception in thread "main" java.lang.IllegalStateException: Function is not supported
Un problema di ICD ?
intanto io ho sistemato diamonds.bat per partire da windows col corretto classpath e utilizzando le classi presenti in bin.
Fatremi sapere se ci sono problemi.
Faccio l'update con tortoise e mi dà come errore: Failed to add file [...]\Game\diamond.bat: object of the same name already exists
Ho provato a eliminare quello esistente, rifaccio, ristabilisce diamond.bat e di nuovo quell'errore
Succede solo a me? :mbe:
List of available display modes:
320 x 240 x 16 @63Hz
800 x 600 x 32 @72Hz
Best mode: 800 x 600 x 32 @72Hz
Exception in thread "main" java.lang.IllegalStateException: Function is not supported
at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:66)
at org.lwjgl.opengl.GL13.glActiveTexture(GL13.java:113)
at it.diamonds.engine.Texture.enable(Texture.java:121)
at it.diamonds.engine.Texture.enable(Texture.java:143)
Ok, siamo andati oltre almeno. Ora credo che i tuoi driver supportino solo 1.1 e non trovi la relativa funzione 1.3. Pero' il problema del pixel format dovrebbe essere risolto: sostanzialmente ho richiesto nessuno zbuffer, immagino che i tuoi driver non supportassero 24 bit di zbuffer.
Fammi vedere un po' adesso.
Succede solo a me? :mbe:
No, anche a me...
Domanda per Raffaele quando torna: si puo' fare a meno di queste due?
import static org.lwjgl.opengl.GL13.GL_TEXTURE0;
import static org.lwjgl.opengl.GL13.glActiveTexture;
Ci serve l'equivalente GL11.
Domanda per Raffaele quando torna: si puo' fare a meno di queste due?
import static org.lwjgl.opengl.GL13.GL_TEXTURE0;
import static org.lwjgl.opengl.GL13.glActiveTexture;
Ci serve l'equivalente GL11.
Aggiunta la stampa del nome del driver ed eliminate quelle chiamate. Ora Diamonds è OpenGL 1.1 compliant il che significa assicurarsi la compatibilità con il driver software di Windows nel momento in cui non c'è un driver ICD fornito dal produttore del chip video.
Ah, senza quelle chiamate abbiamo rinunciato al multitexturing.
Riprovate adesso.
Si può rilevare la versione dell'ICD ed in tal caso abilitare/disabilitare le estensioni di OpenGL 1.3 ?
Si può rilevare la versione dell'ICD ed in tal caso abilitare future funzioni di OpenGL 1.3 ?
Se si potesse fare, temo ci creerebbe più problemi che altro (dovremmo preoccuparci sia dei PC compatibili con OGL 1.3 che di quelli che non lo sono) :(
Se si potesse fare, temo ci creerebbe più problemi che altro (dovremmo preoccuparci sia dei PC compatibili con OGL 1.3 che di quelli che non lo sono) :(
Chiaro, ma magari se ci serve la 1.3 per un'effetto particolare potremmo sempre ricorrere a questa soluzione...
Chiaro, ma magari se ci serve la 1.3 per un'effetto particolare potremmo sempre ricorrere a questa soluzione...
Se è solo per qualcosa di molto accessorio, e magari attivabile nelle opzioni (leggi: qualche bel pixel shader scritto da fek), allora ben venga un'opportunità di questo genere :)
Si può rilevare la versione dell'ICD ed in tal caso abilitare/disabilitare le estensioni di OpenGL 1.3 ?
Si può rilevare la versione dell'ICD senza troppi problemi, anche se a questo punto non ne vedo l'utilità. Al momento attuale le funzionalità OpenGL 1.3 non ci servono. Se vorremo, possiamo creare più percorsi di rendering, uno safe 1.1, uno più avanzato, uno con gli shaders, ecc... Non c'è alcuna difficoltà nel realizzare questo, solo un piccolo lavoro di rilevamento della versione e conseguente abilitazione/disabilitazione di determinate funzionalità (in tal senso è una manna del cielo aver usato LWJGL che per ogni istruzione ci dice che versione stiamo utilizzando di OpenGL). Per visualizzare quadrati con texture, essenzialmente ciò che facciamo adesso, non è necessario utilizzare OpenGL 1.3. Tra l'altro lo stesso multitexturing può essere emulato in multipass senza troppe difficoltà. Tuttavia è necessario considerare una cosa a questo punto: schede video molto vecchie non supportano texture con risoluzione maggiore di 256x256. Anche in questo caso è possibile rilevare la risoluzione massima utilizzata e decidere come comportarsi: scaliamo le texture tramite DEVIL ad una risoluzione inferiore? (immagino si sfocheranno) oppure i grafici realizzano una versione con texture 256x256 che compongono tutte le superfici di cui hanno bisogno? (lavoro noioso ma è l'unico modo per avere compatibilità al 100% e medesima resa grafica).
Insomma bisogna avviare una serie di task dedicati a queste problematiche.
Aggiunta la stampa del nome del driver ed eliminate quelle chiamate. Ora Diamonds è OpenGL 1.1 compliant il che significa assicurarsi la compatibilità con il driver software di Windows nel momento in cui non c'è un driver ICD fornito dal produttore del chip video.
Ah, senza quelle chiamate abbiamo rinunciato al multitexturing.
Riprovate adesso.
Ottimo!
Si può rilevare la versione dell'ICD ed in tal caso abilitare/disabilitare le estensioni di OpenGL 1.3 ?
Teoricamente direi di si', all'atto pratico per ora non ci serve. Anche il multitexturing non e' qualcosa che a noi possa servire, e' piu' che altro un'ottimizzazione e non credo che disegneremo mai piu' di un migliaio di poligoni e qualche pixel :)
Magari in futuro, una volta finito il gioco, in fase di divertimento, possiamo aggiungere una modalita' avanzata che supporti qualche pixel shader ed effetti speciali, ad esempio. Ma si vedra' in futuro, per ora resterei 1.1.
Tuttavia è necessario considerare una cosa a questo punto: schede video molto vecchie non supportano texture con risoluzione maggiore di 256x256. Anche in questo caso è possibile rilevare la risoluzione massima utilizzata e decidere come comportarsi: scaliamo le texture tramite DEVIL ad una risoluzione inferiore? (immagino si sfocheranno) oppure i grafici realizzano una versione con texture 256x256 che compongono tutte le superfici di cui hanno bisogno? (lavoro noioso ma è l'unico modo per avere compatibilità al 100% e medesima resa grafica).
Giusto, fatto bene a ricordarlo. Jocchan, dicci tu la soluzione che preferisci per questa eventualita'.
^TiGeRShArK^
05-11-2005, 18:09
Ma %DIAMONDS_HOME% non è detto che sia definita :what:
ma infatti l'ho tolto %DIAMONDS_HOME% ...
quello l'avevo messo nella prima versione...
ora uso solo path relativi...
e l'ho messo sotto trunk tra l'altro anzikè sotto bin
^TiGeRShArK^
05-11-2005, 18:12
Faccio l'update con tortoise e mi dà come errore: Failed to add file [...]\Game\diamond.bat: object of the same name already exists
Ho provato a eliminare quello esistente, rifaccio, ristabilisce diamond.bat e di nuovo quell'errore
Succede solo a me? :mbe:
ehm...
quell'errore lo dava anke a me......
(oltre ke x fare l'update mi sono ribekkato quei dannati .java sotto bin :muro: )
apposta l'ho messo sotto trunk il file e lì mi funzionava..
e ora si kiama diamonds.bat non diamond.bat
BlueDragon
05-11-2005, 19:36
Provando diamonds.bat
Exception in thread "main" java.lang.UnsatisfiedLinkError:
no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at org.lwjgl.Sys$1.run(Sys.java:67)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:65)
at org.lwjgl.opengl.Display.<clinit>(Display.java:104)
at it.diamonds.engine.DisplayImpl.initDisplay(DisplayImpl.java:127)
at it.diamonds.engine.DisplayImpl.<init>(DisplayImpl.java:34)
at it.diamonds.engine.Engine.create(Engine.java:27)
at it.diamonds.Game.createEngine(Game.java:81)
at it.diamonds.Game.main(Game.java:45)
Si può rilevare la versione dell'ICD senza troppi problemi, anche se a questo punto non ne vedo l'utilità. Al momento attuale le funzionalità OpenGL 1.3 non ci servono. Se vorremo, possiamo creare più percorsi di rendering, uno safe 1.1, uno più avanzato, uno con gli shaders, ecc... Non c'è alcuna difficoltà nel realizzare questo, solo un piccolo lavoro di rilevamento della versione e conseguente abilitazione/disabilitazione di determinate funzionalità (in tal senso è una manna del cielo aver usato LWJGL che per ogni istruzione ci dice che versione stiamo utilizzando di OpenGL). Per visualizzare quadrati con texture, essenzialmente ciò che facciamo adesso, non è necessario utilizzare OpenGL 1.3. Tra l'altro lo stesso multitexturing può essere emulato in multipass senza troppe difficoltà. Tuttavia è necessario considerare una cosa a questo punto: schede video molto vecchie non supportano texture con risoluzione maggiore di 256x256. Anche in questo caso è possibile rilevare la risoluzione massima utilizzata e decidere come comportarsi: scaliamo le texture tramite DEVIL ad una risoluzione inferiore? (immagino si sfocheranno) oppure i grafici realizzano una versione con texture 256x256 che compongono tutte le superfici di cui hanno bisogno? (lavoro noioso ma è l'unico modo per avere compatibilità al 100% e medesima resa grafica).
Insomma bisogna avviare una serie di task dedicati a queste problematiche.
Ottimo ^^
In ogni caso, dividere le texture in più file da 256x256 non è un problema (sarà poca roba a superare queste dimensioni, quasi esclusivamente i vari layer che comporranno gli sfondi).
Giusto, fatto bene a ricordarlo. Jocchan, dicci tu la soluzione che preferisci per questa eventualita'.
Ovviamente, divideremo tutte le texture che sforano.
Ridimensionare e perdere qualità non credo sia una soluzione accettabile ;)
Bene, quale anima pia mi passa un exe o un bat aggiornato?
^TiGeRShArK^
05-11-2005, 23:27
Provando diamonds.bat
Exception in thread "main" java.lang.UnsatisfiedLinkError:
no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at org.lwjgl.Sys$1.run(Sys.java:67)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:65)
at org.lwjgl.opengl.Display.<clinit>(Display.java:104)
at it.diamonds.engine.DisplayImpl.initDisplay(DisplayImpl.java:127)
at it.diamonds.engine.DisplayImpl.<init>(DisplayImpl.java:34)
at it.diamonds.engine.Engine.create(Engine.java:27)
at it.diamonds.Game.createEngine(Game.java:81)
at it.diamonds.Game.main(Game.java:45)
ma xkè da me funziona senza mettere quella dannata opzione??? :muro:
prova ad aggiungere
-Djava.library.path=lib/win32
prima di -cp... io non posso provare xkè da me funziona senza... :fagiano:
Con -Djava.library.path=lib/win32 su questo funziona, ho aggiornato anche la versione sul server ^^
Domani vedo di installare java 5 sull'altro pc (oggi ho messo suse 10 pure lì) e faccio sapere se col passaggio a opengl 1.1 funziona (prima devo risolvere un "piccolo" problema, non mi prende i driver e mi vede solo fino a 800*600, risoluzione odiosa... :( )
Sotto linux, se non vado errato, con i driver software c'è addirittura il supporto ad OpenGL 1.3. Vidi girare Unreal Tournament in software e andava piuttosto bene nonostante non ci fosse accelerazione hardware. Purtroppo sotto Windows siamo fermi a OpenGL 1.1 grazie a Microsoft.
Comunque io eliminerei Java 5 e tornerei su Java 1.4 che è ben più diffusa. Basta non far uso dei generics e degli static import.
^TiGeRShArK^
06-11-2005, 01:03
concordo...
l'unico problema è ke potremmo perdere un pò di prestazioni dato ke in java 5 era stata effettuata qualke ottimizzazione velocistica se nn sbaglio...
ma cmq meglio sacrificare un pò di velocità per allargare la base di pc installati....
cdimauro
06-11-2005, 07:54
Ottimo ^^
In ogni caso, dividere le texture in più file da 256x256 non è un problema (sarà poca roba a superare queste dimensioni, quasi esclusivamente i vari layer che comporranno gli sfondi).
Secondo me non ce n'è bisogno: basta che sia la classe Sprite o Texture ad occuparsi, al momento del caricamento, della suddivisione dell'immagine in parti di al più 256x256.
L'immagine da 800x600 dello sfondo sarebbe suddivisa in 6 immagini da 256x256, 2 da 32x256 e 1 da 32x88. Al momento del tracciamento su schermo basterebbe "ricomporre" l'immagine originale, piazzandone le parti alla posizione corretta.
Questo permetterebbe di non cambiare di una virgola tutto ciò che s'è fatto finora. ;)
E' un dettaglio implementativo che, IMHO, non deve diventare requisito di progetto.
cdimauro
06-11-2005, 07:54
Comunque io eliminerei Java 5 e tornerei su Java 1.4 che è ben più diffusa. Basta non far uso dei generics e degli static import.
Perfettamente d'accordo.
cdimauro
06-11-2005, 07:56
Per estendere la compatibilità al maggior numero di macchine / sistemi possibile, si potrebbe anche pensare di adottare SDL.
Questo non precluderebbe comunque l'uso di OpenGL, nel caso in cui decidessimo di farne uso.
DanieleC88
06-11-2005, 09:26
Per estendere la compatibilità al maggior numero di macchine / sistemi possibile, si potrebbe anche pensare di adottare SDL.
Questo non precluderebbe comunque l'uso di OpenGL, nel caso in cui decidessimo di farne uso.
SDL era già stata scartata in precedenza perché secondo diverse valutazioni non ve ne era bisogno (ed in effetti distribuire SDLJava con il progetto lo rende più pesante).
Comunque io eliminerei Java 5 e tornerei su Java 1.4 che è ben più diffusa. Basta non far uso dei generics e degli static import.
Perfettamente d'accordo. L'uso di queste feature nel codice è molto diffuso?
concordo...
l'unico problema è ke potremmo perdere un pò di prestazioni dato ke in java 5 era stata effettuata qualke ottimizzazione velocistica se nn sbaglio...
ma cmq meglio sacrificare un pò di velocità per allargare la base di pc installati....
E' anche vero che il progetto di per sè non richiede chissà quale computer ninja per girare, quindi potrebbe essere un compromesso accettabile.
Secondo me non ce n'è bisogno: basta che sia la classe Sprite o Texture ad occuparsi, al momento del caricamento, della suddivisione dell'immagine in parti di al più 256x256.
L'immagine da 800x600 dello sfondo sarebbe suddivisa in 6 immagini da 256x256, 2 da 32x256 e 1 da 32x88. Al momento del tracciamento su schermo basterebbe "ricomporre" l'immagine originale, piazzandone le parti alla posizione corretta.
Questo permetterebbe di non cambiare di una virgola tutto ciò che s'è fatto finora. ;)
E' un dettaglio implementativo che, IMHO, non deve diventare requisito di progetto.
Perfetto, allora vedremo di provvedere in uno dei prossimi cicli ;)
Ok, per fare chiarezza dopo la discussione.
- Usiamo OpenGL 1.1 e SDLJava
- Usiamo Java5
- Decideremo in futuro come risolvere il problema delle texture piu' grandi di 256x256
- Niente file batch, il file jar viene trasformato in un file .exe o .sh a seconda del sistema operativo da un task Ant
Ora torniamo a sviluppare :)
- Usiamo OpenGL 1.1 e SDLJava
- Usiamo Java5
Come mai?
Avevamo appena detto di provare a tornare a Java 1.4 ed escludere SDL :confused:
Come mai?
Avevamo appena detto di provare a tornare a Java 1.4 ed escludere SDL :confused:
Decisioni finali. Usiamo Java5 + OpenGL 1.1 + SDL.
Non abbiamo ancora un gioco, non e' il momento di pensare troppo a problemi di compatibilita'. Prima finiamolo.
Ok, allora per adesso andiamo avanti così, e iniziamo la seconda storia.
BlueDragon
06-11-2005, 11:22
ma xkè da me funziona senza mettere quella dannata opzione??? :muro:
prova ad aggiungere
-Djava.library.path=lib/win32
prima di -cp... io non posso provare xkè da me funziona senza... :fagiano:
Ora il .bat funziona :)
Ma non l'exe...(ho provato scaricando lo zip dell'ultima build dal server di fek).
Si apre e si chiude con la velocità della luce, non vedo nemmeno l'errore :)
Ora il .bat funziona :)
Ma non l'exe...(ho provato scaricando lo zip dell'ultima build dal server di fek).
Si apre e si chiude con la velocità della luce, non vedo nemmeno l'errore :)
Lo puoi lanciare da riga di comando e mi fai dici l'errore?
Come prevedibile, sul PC con scheda video Matrox l'errore rimane lo stesso (http://lnx.rc6.it/diamonds/stuff/error01.jpg) di sempre.
Oggi pomeriggio vedrò di testare il tutto sulla Radeon :)
Grandissimo Vifani, ora il gioco funziona anche sulla scheda video schifMatrox!
Come detto prima in msn a fek sto ancora litigando con i driver per la g400, appena risolvo provo...sempre se non va a finire che rimetto xp almeno per il momento... :muro:
BlueDragon
06-11-2005, 16:08
Lo puoi lanciare da riga di comando e mi fai dici l'errore?
Ci ho provato ma il risultato è lo stesso..apre una nuova finestra che si richiude immediatamente senza farmi vedere nulla....se scrive l'errore, lo scrive nella nuova finestra e non in quella della riga di comando..
Peccato!
Avete testato anche la build 192 committata oggi da Vifani?
Adesso funziona sia sul pc con Matrox che su quello con Radeon.
Se possibile, stasera vedrò di farlo testare anche su quello con la Sis integrata.
Avete testato anche la build 192 committata oggi da Vifani?
Adesso funziona sia sul pc con Matrox che su quello con Radeon.
Se possibile, stasera vedrò di farlo testare anche su quello con la Sis integrata.
Per la SiS la vedo molto nera.... speriam... :D
Per la SiS la vedo molto nera.... speriam... :D
E invece (rullo di tamburi) funziona anche là!!!!!!!!!
Lavoro eccellente, davvero i miei complimenti ^_^
E invece (rullo di tamburi) funziona anche là!!!!!!!!!
Lavoro eccellente, davvero i miei complimenti ^_^
Sono molto felice :)
Hai usato l'ultima build che è online vero?
cdimauro
07-11-2005, 07:47
- Usiamo OpenGL 1.1 e SDLJava
Una curiosità: per cosa useremo SDLJava? C'è già qualche idea?
Sono molto felice :)
Hai usato l'ultima build che è online vero?
Sì, e non c'è stato nessun problema.
Ora su tutti i PC da me testati il gioco funziona perfettamente. :cool:
DanieleC88
07-11-2005, 12:59
Una curiosità: per cosa useremo SDLJava? C'è già qualche idea?
Useremo SDLJava se e quando ci servirà. Per il momento, niente. :)
Sì, e non c'è stato nessun problema.
Ora su tutti i PC da me testati il gioco funziona perfettamente. :cool:
Probabilmente ti funziona anche senza alcun driver installato col driver software OpenGL 1.1 di Microsoft. Comunque è una cosa che voglio indagare. Aggiungerò presto alle varie stampe in console anche una stampa delle estensioni supportate, del nome del dispositivo e della versione del driver. Anzi, e qui mi rivolgo a fek, non sarebbe male fare un qualche task per un motore di logging che stampi il tutto in un bel file di testo. Questo anche per tener traccia di altri problemi (teoricamente tutte le Exception).
Ora vorrei fare un test un pò estremo, ossia vedere se il gioco parte anche su Windows95 (ovviamente installando il driver software OpenGL 1.1, che si può scaricare gratis dal sito della Microsoft).
Se non dovesse andare chissenefrega, è più che altro una curiosità mia :sofico:
Ora vorrei fare un test un pò estremo, ossia vedere se il gioco parte anche su Windows95 (ovviamente installando il driver software OpenGL 1.1, che si può scaricare gratis dal sito della Microsoft).
Se non dovesse andare chissenefrega, è più che altro una curiosità mia :sofico:
Se funziona anche così sarebbe perfetto.
Anzi, e qui mi rivolgo a fek, non sarebbe male fare un qualche task per un motore di logging che stampi il tutto in un bel file di testo. Questo anche per tener traccia di altri problemi (teoricamente tutte le Exception).
Jocchan? (Ricordate che e' sempre il Customer a decidere le feature da implementare).
Via libera per il logging ;)
Vedremo se occuparcene nel prossimo ciclo o in quello dopo ancora, dipenderà dalle priorità del momento (al termine della seconda storia).
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.