UrWorld, le retour du retour

A mon avis, il faudrait que tu fasse des petits carrées pour tes ombres, genre 1/10 des cubes normaux, et que tu fasses ton dégradé, ça rendrait mieux.

Ensuite je penses que tu as intérêt à avoir deux calques (je sais pas si c'est possible) : un pour le monde, l'autre pour tes ombres.

Et niveau algo, je verrais bien :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Classe Ombre
   Direction // droite, gauche, haut, bas
   Intensité // Un nombre de 0 a 100
Fin de la classe

Pour chaque bloc de la map :
  Regarder si il y a un bloc a côté (d'abord à droite, puis en haut, puis ...) :
    Si oui :
      Ajouter une Ombre de X%, avec un dégradé
    Si non :
      Ajouter un Ombre de : Moyenne ombres à côté - Y%

Bon alors là j'ai simplifié au max et je sais pas si c'est vraiment efficace, mais tu vois l'idée.

Edit : Au pire, demandes à HexaBeast comment il a fait dans son jeu.

Je crois qu'il a utilisé les shaders de LibGDX.

Ah oui, ça risque d'être compliqué en effet …

D'après ce message il utilise une solution maison

—> Java

Je sais, je répondait juste à ta question

Bonjour, je ne pense pas que l'utilisation de Java change tant que ça les performances - d'ailleurs, Java n'est pas connu pour être rapide :P. 20x75 tiles, c'est vraiment très peu à traiter pour nos machines modernes, il faut que tu trouves un algorithme qui corresponde à ce que tu veux faire, mais que veux-tu exactement ? - quelles sources de lumière et de quel type ? - statique ou dynamique ? - seulement en intensité, ou aussi en couleur ?

Ensuite, comment comptes-tu faire le rendu ? Je ne sais pas comment fonctionne ta bibliothèque graphique, si elle est basée sur les "vieilles" surfaces à la SDL1.2 ou sur OpenGL.

(Java n'est plus connu pour être lent. C'est une vieille rumeur qui traîne encore, mais qui persiste surtout en tant que joke de programmeur. Et le Python, si je ne me trompe pas, n'est pas compilé à la volée, ce qui est moins rapide, bien que toutes les machines virtuelles Java ne fonctionnent pas forcément sur ce principe-là.)

Et bien, lorsque je développais en Java, c'était pas une rumeur mais j'avoue que ça a bien changé tout ça ! Sinon, je ne voulais pas troller, j'intervenais par rapport au dernier échange, et je pense qu'il peut essayer d'avoir un système (trivial) d'éclairage sans plomber les perfs. Puis Java ou Python… de toute façon, ils utilisent des bibliothèques C (SDL, OpenGL) pour le rendu.

Folaefolc, tu comptes t'y prendre comment ? Tu affiches tes tiles et sprites normalement, puis tu appliques une couche d'ombres par dessus ? As-tu la possibilité de faire du blending avec ta bibliothèque ? En hardware ?

"Je crois qu'il a utilisé les shaders de LibGDX."

C'est du shading en GLSL classique, pas propre à LibGDX, mais je suis pas sûr que pygame puisse gérer ça (J'ai trouvé ça après une rapide recherche, mais je suis pas sûr à 100% que ça le fasse http://www.pygame.org/wiki/GLSLExample )

Sinon avant le shading j'utilisais une autre méthode, qu'on peut toujours activer si le shader fonctionne mal. La flemme d'expliquer celle qui permet de faire des ombres un peu "adoucies", comme sur ce vieux screen : https://www.dropbox.com/s/7zrjpc1ahdfkxop/Screen25.png?dl=0 , par contre celle-ci est relativement simple : https://www.dropbox.com/s/1ewcf150jdgrwqg/Screen24LowShadow.png?dl=0

En gros, j'avais un tableau de floats de la taille de la map, chaque float = la luminosité du bloc qui lui est associé, avec 0 pour dire que la case doit être toute noire, 1 pour dire qu'il n'y a aucune ombre, et les nombres entre 0 et 1 pour les nuances d'ombre. De base tous les floats sont mis à 0. Ensuite, à chaque frame: - Je donne une valeur de 1 à tous les blocs touchant l'extérieur - Je propage la valeur de chaque float à ses 4 voisins en la diminuant légèrement - Quand je draw chaque bloc, je l'assombrit selon la valeur du float Bon, c'est très théorique tout ça, j'ai pas vraiment détaillé, mais c'est pas trop compliqué à appliquer normalement.