Problema di compatibilità

[^TiGeRShArK^]

Originariamente inviato da BlueDragon

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???
prova ad aggiungere

-Djava.library.path=lib/win32

prima di -cp... io non posso provare xkè da me funziona senza...

[cover]

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... )

[Vifani]

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.

[Vifani]

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^]

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]

Originariamente inviato da Jocchan

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]

Originariamente inviato da Vifani

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]

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]

Originariamente inviato da cdimauro

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).

[Jocchan]

Originariamente inviato da Vifani

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?

Originariamente inviato da ^TiGeRShArK^

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.

Originariamente inviato da cdimauro

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

[fek]

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

[Jocchan]

Originariamente inviato da fek

- Usiamo OpenGL 1.1 e SDLJava
- Usiamo Java5

Come mai?
Avevamo appena detto di provare a tornare a Java 1.4 ed escludere SDL

[fek]

Originariamente inviato da Jocchan

Come mai?
Avevamo appena detto di provare a tornare a Java 1.4 ed escludere SDL

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.

[Jocchan]

Ok, allora per adesso andiamo avanti così, e iniziamo la seconda storia.

[BlueDragon]

Originariamente inviato da ^TiGeRShArK^

ma xkè da me funziona senza mettere quella dannata opzione???
prova ad aggiungere

-Djava.library.path=lib/win32

prima di -cp... io non posso provare xkè da me funziona senza...

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

[fek]

Originariamente inviato da BlueDragon

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?

[Jocchan]

Come prevedibile, sul PC con scheda video Matrox l'errore rimane lo stesso di sempre.
Oggi pomeriggio vedrò di testare il tutto sulla Radeon

[Jocchan]

Grandissimo Vifani, ora il gioco funziona anche sulla scheda video schifMatrox!

[fek]

Ma bravissimo!

[cover]

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...