Suite aux commentaires précédents, j'ai mis à jour mon projet :
-il est désormais sous licence GNU GPL
-la visée a été améliorée (sauf pour les applets)

Merci pour tes remarques constructives, malheureusement j'ai un boulot et plus trop le temps en ce moment pour coder mais vu la crise financière gagnant de plus en plus de terrain dans le secteur où je travaille, je sens que j'aurai plus de temps en chômage :(

Pour la licence, je vais y réfléchir
Pour l'applet, c'est étonnant j'ai encore testé tout a l'heure sur mon navigateur (firefox sous windaube), ça fonctionne chez moi...
Pour OpenGL, j'avoue honteusement m'être jamais attelé à cette API (par manque de temps et patience). J'avais vaguement approché le DirectX à une époque.

Bonne continuation
A+

Ouah tout ça ! :)
Pour les performances, j'ai dit que c'était pas ma priorité. De plus, tu peux constater que le jeu est toujours rapide même à des résolutions élevées (certe sur des machines puissantes) car pour afficher les murs, j'utilise une fonction Java2D trés simple (un simple redimensionnement) et optimisé par Java en utilisant des fonctions de la carte graphique (par l'intermédiaire d'OpenGL ou DirectX) certes ça sera toujours plus lent que des accès direct à la carte graphique...
Passer mon code en OpenGl, pourquoi ? il faudrait reprendre à mon avis plein de chose : je sais pas si l'OpenGl peut afficher ligne par ligne qui est la base du raycasting. De plus, faut pas oublier que la fonction Java2d utilise indirectement l'accélération graphique derrière.
Sur ta remarque sur la résolution et framerate, augmenter la résolution n'est pas si couteux que ça car seul la largeur de l'écran entre en compte dans le raycasting (nombre de "bande" de mur à afficher). De plus, je n'affiche pas pixel par pixel directement dans le code java mais j'utilise des fonction accélérées qui vont afficher par "groupe de pixel" (comme le plafond et le sol où c'est juste un fillRect tout bête, les murs un simple drawImage etc...), c'est la puce graphique derrière qui fait la plus grosse partie du boulot.
Pour ton problème de clavier sur l'applet, en général se problème se produit si on a pas cliqué une fois sur l'applet pour gagner le focus.
Pour l'autocentrage, je viens de le rajouter dans mon code, je republierai ce week end quand j'aurai un peu plus de temps...
Merci

Bonjour,
lol pour les fautes d'orthographes !! en général en codant, quand je suis un peu fatigué, j'ai tendance en faire encore plus ! :) désolé pour les fautes!
Pour ANT, oui tout a fait mais en général, Eclipse est le plus répandu dans le domaine java... si tu es motivé pour écrire le script, le l'inclurai avec plaisir :)
Pour l'OpenGL, le but de mon projet n'était pas d'utiliser des librairies annexes mais de prouver que Java n'est pas si lent que ça... Sur mes bécanes (minimum 1Ghz tout de même), le jeu tourne sans problème à 60 images par secondes sans avoir particulièrement optimisé mon code (l'optimisation n'a pas été ma priorité d'ailleurs ça se confirme car j'ai utilisé que des double à la place de float bien plus rapides!), quand on pense que Wolfenstein tournait sur des machines n'allant même pas à 100 Mhz... :)
Licence ? en gros mon projet est libre sauf qu'on doit laisser mon nom dans les sources ;)
Pour WebStart, je sais pas faire donc il faut que je me renseigne, j'ai pas trop le temps pour le moment. Une version applet est tout de même dispo à l'adresse suivante :
http://gbouchon1.free.fr/jwolfenstein.php

Merci pour tes remarques!

Bonne continuation

Salut!
Pas mal, c'est soigné en apparence (pas regardé le code), juste les touches un poil trop nerveuses (il est difficile de choisir avec précision sa rotation).
Bonne continuation

Bonjour,
suite a votre remarque j'ai modifié les déplacement : on peut désormais utiliser la souris. C'est pas encore terrible mais c'est beaucoup mieux!
Merci
A+

Bonjour,
oui effectivement il y avait un prb au démarrage de l'appli... c'est désormais corrigé. Merci

Je prends note...
j'ai modifié la source :
-test des bornes dans getCellule
-le nombre de voisines n'est plus stocké dans la cellule (n'a rien à faire là car on s'en sert que pour la mise a jour des cellules)

Lol ça c'est de l'analyse précise et pointue :)

En prenant dans l'ordre :
1) Pour les override, mon ami Eclipse me les a mis automatiquement (puis des fois en faisant des copier coller, on les embarques!), l'erreur de compilation dépends apparemment du compilateur : chez moi ça compile! Pour éviter toute erreur : je les ai supprimés!

2) Pour l'implémentation de ComponentListener sur MainFrame : oui en effet on pourrait... mais j'aime bien avoir un listener par composant

3) Pour l'exception possible ligne 107 : il peut en effet y avoir une exception si les index ne sont pas bons. Néanmoins, c'est au code client de tester cette exception pour la gérer (que je n'ai pas fait d'ailleurs!).

4) Pour la mise a jour du nombre de voisines, la valeur nombre de voisines n'est utile que dans la mise a jour des cellules. (Si je déplace le traitement a la fin de la méthode, il faudrait mettre a jour le nombre de voisines lorsqu'on clic sur la grille)

5) Pour finir, l'idée de mettre deux textbox, j'y avais pensé mais par manque de temps je ne l'ai pas fait... (j'ai codé cette appli en 2h...)

Merci

TucoBouch

Pour le scrolling game,
j'ai pas de site en tête, j'ai appris le principe il y a fort longtemps quand je codais sur mon Amiga avec AMOS ou BLITZ BASIC (la belle époque :) )...
La technique d'affichage du décor est trés classique (même la Game Boy l'implémente en hardware), elle devrait se trouver facilement avec Google.
En cherchant rapidement j'ai trouvé ce site en anglais certes pour le langage C mais tu devrais voir certaines bases :
http://www.gamedev.net/reference/list.asp?categoryid=44