[Guigui]

Envoyé par berka

Merci pour la reponse.
En gros je voudrais éviter de devoir mettre tous mes objets graphiques dans la def draw et ne pas bloquer mon programme par la boucle show.

Mais j'ai regardé un peu le code source, et je crois que je vais modifier un peu la def show

Je te tiens au courant,
berka

Tout ce qui compte :
- c'est de stocker tes objets graphiques quelque part
- de garder une référence à la fenêtre
- que la méthode update de la fenêtre appelle une méthode équivalente d'une autre classe

Si la fenêtre appelle par exemple la méthode update de ton objet Engine lorsqu'elle est mise à jour par sa propre méthode update, ton objet Gosu::Window ne bloque pas ton programme. Il travaille de son côté, et toi tu peux faire ce que tu veux dans la méthode update de ta classe Engine, par exemple.

Et tu peux finalement créer tes objets graphiques, sonores ou autres Fonts où bon te semble, tant que lors de leur création tu as un objet de type Gosu::Window à leur fournir. Une fois cette référence "en poche", ton objet graphique peut être dessiné de n'importe où dans ton code de par l'appel à sa méthode draw, ce qui fait qu'en mon sens modifier le code source de Gosu, en plus d'être une mauvaise idée, est totalement dispensable.

Imagine que Julian ajoute une fonctionnalité géniale dans sa prochaine version, rien ne dit que tes modifications seront opportunes en termes de compatibilité, sans parler des soucis de compilation, etc.

En se creusant un peu le crâne, on peut vraiment faire ce qu'on souhaite de Gosu

Envoyé par maeln

Pour faire bouger un sprite il vas en fait falloir que quand telle touche est presser on modifie la variable de position mais quelle est telle ? il y a sa :

Class Gosu ::Image def initialize(window, filename_or_rmagick_image, hard_borders, [srcX, srcY, srcWidth, srcHeight])

Donc c'est srcX et srcY qu'il faut modifier ?
Ou alors il faut modifier les valeurs qui se situe ici ? :

 def draw
	  @sprite.draw(320, 240, 1) #affichage du sprite 
  end

Et la c'est la même quéstion : quelle est le nom des variables qui sont ici (320, 240, 1) ?

Les variables srcX et srcY correspondent au rectangle de découpe dans ton image de personnage, elles ne servent donc qu'à changer de tile dans ta planche de sprite (pour animation).

La méthode draw prend pour paramètres : x, y et z où x et y correspondent aux coordonnées 2D de dessin et Z l'empilement de profondeur (plus Z est grand, plus le dessin est au-dessus de la pile).

En effet, la classe Gosu::Image ne possède pas de variables propres aux coordonnées, et c'est donc dans la méthode draw qu'on va les spécifier. En revanche, rien n'empêche de dériver une classe Sprite de la classe Gosu::Image.

require "gosu.so"

class Sprite < Gosu::Image
  def initialize(window_parent, filename, x, y, z)
    super(window_parent, filename, true)
    @x, @y, @z = x, y, z
  end

  def draw
    super(@x, @y, @z)
  end
end

class Window < Gosu::Window
  def initialize
    super(320, 240, false)
    @sprite = Sprite.new(self, "character.png", 10, 10, 0)
  end

  def draw
    @sprite.draw
  end
end

Window.new.show

Je n'ai pas testé ce code, mais il doit fonctionner. En gros, l'intérêt est ici de retenir dans l'objet Sprite même les coordonnées. Ainsi tu peux gérer en interne tous les déplacements, etc.

class Sprite
  def move(direction)
    case direction
      when "left" : @x -= 1
      when "right" : @x += 1
      when "up" : @y -= 1
      when "down" : @y += 1
    end
  end
end

class Window
  def update
    @sprite.move("right") if button_down?(Gosu::KbRight)
    @sprite.move("left") if button_down?(Gosu::KbLeft)
    @sprite.move("up") if button_down?(Gosu::KbUp)
    @sprite.move("down") if button_down?(Gosu::KbDown)
  end
end

Et c'est dans la même classe Sprite, voire dans la même méthode move que tu pourras gérer l'animation, le changement de frame bouclé, etc.

Note bien sûr que ce n'est qu'une façon de faire. Étant donné que Gosu ne fournit RIEN de toute cette gestion, c'est bien au programmeur de le faire à sa façon. Il en existe pratiquement autant de possibles qu'il y a de programmeurs

[glutox]

Bonsoir,

Ça fait maintenant 2-3 jours que j'ai commencé à utiliser gosu, le tutoriel à l'origine du post est vraiment très instructif !
Si j'ai envie de créer des jeux vidéo, c'est parce que j'ai un projet de mmorpg qui m'emballe particulièrement.
Pour faire bref, c'est un mmo en 3D isométrique dans le même style que Dofus.

Comme je débute et que je ne sais pas trop où poser la question/me renseigner (j'ai déjà chercher sur google, mais je vois pas où elle est la communauté)
Pour les questions :
- Comment faire pour faire une action lorsqu'on clique sur un image ? (avec la gestion de la transparence pour les gif et les png).
- Lorsque je crée mes losange pour réaliser un effet de 3d isométrique, comment savoir dans quel losange je suis lorsque un utilisateur clique dessus ? (j'ai chercher la formule mathématique des heures sans succès)

[Guigui]

Hmmm... pas facile tout ça ! Ce n'est pas spécialement spécifique à Gosu d'ailleurs, mais bien à toutes les librairies 2D !

J'aurais néanmoins quelques solutions. Il existe des algorithmes pour calculer la position d'un tile hexagonal ou losange, qu'on peut assez facilement trouver sur google.

Pour savoir si on clique sur une image, il y aurait éventuellement un simple calcul de coordonnées à faire, mais le problème, c'est que ce picking ne tiendrait pas compte de la profondeur d'affichage, en ce sens que plusieurs objets peuvent se trouver aux mêmes coordonnées...

Donc :
- soit tu fais une recherche sur tes éléments graphiques pour savoir lesquels sont sous le curseur de la souris, puis tu sélectionnes celui dont le Z est le plus grand, mais ceci risque de poser des soucis si tes images ne sont pas pleines
- soit tu fais un color keying via le color buffer en OpenGL, ce qui me semble être le plus simple, et de loin.

Tu peux très bien calculer la position d'un tile de la même manière.

C'est très simple en fait :
- tu attribues une couleur pour chaque objet
- tu dessines ton image avec cette couleur (via opengl ou fichier spécialement dédié, genre chaque sprite en version couleur unique + version propre)
- tu lis le buffer opengl :

pixel = GL.ReadPixels(self.mouse_x, self.height() - self.mouse_y, 1, 1, GL::RGB, GL::UNSIGNED_BYTE)
  GL.Clear(GL::COLOR_BUFFER_BIT)

la variable pixel contiendra alors un tableau de trois entiers de 0 à 255. Tu effaces ton écran via GL.Clear, puis tu dessines normalement et tu laisses l'affichage se mettre à jour. Tu pourras donc facilement savoir ce que tu survoles

[glutox]

Merci de ta réponse si rapide !

Pour les algos, j'ai aussi cherché sur google, mais je ne sais pas quel mot clé utilisé ^^'

Pour ce qui est de la solution des images, j'ai compris le principe, seulement, je n'ai encore jamais fait de l'openGL. Est-ce que tu pourrais me donner des ressources pour apprendre à l'utiliser (avec ruby) parce que je ne comprend rien aux tutos prévus à la base pour c/c++ ^^'

Pour déjà tester ta solution (qui me semble vraiment génial), est-ce que tu pourrais me dire comment faire le "color keying" sur mes images ?

[Guigui]

http://wiki.jeuweb.net/tutoprog/3d_i...es_hexagonales

surement le plus clair que j'ai jamais lu à ce sujet

Le truc, c'est qu'il existe très peu de bons liens pour Ruby OpenGL. La plupart des fonctions des versions C existent en Ruby et s'utilisent pratiquement de la même manière.

Le fichier openglIntegration.rb dans les samples Gosu est un bon exemple.
http://gosu.googlecode.com/svn/trunk...Integration.rb

Bien sûr, il te faudra installer ruby-opengl pour pouvoir réaliser ce qui suit.

En fait, concrètement, on ne peut pas le faire directement sur les images (contrairement à SDL, par exemple). On est obligés de ruser, et de passer par l'écran-même, ce qui revient à dessiner en deux fois, ce qui a priori ne pose pas de problème de performances dans un moteur 100% 3D que j'ai codé avec un pote.

Ce que tu dois faire, c'est de te créer deux fichiers pour tes images :
- 1 qui sera celui avec les bons pixels, représentant par exemple un personnage
- 1 qui sera celui avec une couleur pleine par-dessus les pixels de ton image

Quand tu crées un sprite, tu charges les deux comme des Gosu::Image.

Dans un premier temps, tu ne dessines que tes images à couleur pleine, puis tu lis le pixel survolé dans le tampon couleur par ta souris via :

pixel = GL.ReadPixels(self.mouse_x, self.height() - self.mouse_y, 1, 1, GL::RGB, GL::UNSIGNED_BYTE)
GL.Clear(GL::COLOR_BUFFER_BIT)

La variable pixel contiendra alors un tableau de trois Integer, de 0 à 255, représentant la couleur actuellement survolée par la souris (le self.height - self.mouse sert à inverser l'axe Y car OpenGL et Gosu fonctionnent opposés).

Ensuite, via la dernière ligne, on vide le buffer. On peut alors dessiner normalement la scène via les images normales. Cette étape peut être facultative en soi, puisqu'en principe les images nouvelles écraseront leur "copie couleur", à essayer et voir si ça fait gagner de la perf. A proscrire d'office je suppose si tu utilises des transparences partielles par contre (effet de feuillage laissant ressortir un vert colorkey monstrueux derrière...) sauf à bien sûr ne pas inclure les transparences partielles dans la zone cliquable, et donc dans l'image faisant office de colokey.

Maintenant que tu as le code couleur, tu n'as plus qu'à en déduire l'image survolée, puisque tu auras pris le soin bien sûr d'ajouter ce paramètre dans le constructeur de ton sprite, dans une classe comme celle-ci, par exemple :

class Sprite
  def initialize(window, filename, colorkey, x = 0, y = 0, z = 0)
    @gfx = Gosu::Image.new(window, filename + ".png", true)
    @gfx_color = Gosu::Image.new(window, filename + "_color.png", true)
    @colorkey = colorkey
    @x, @y, @z = x, y, z
  end

  def draw
    @gfx.draw(@x, @y, @z)
  end

  def drawColor
    @gfx_color(@x, @y, @z)
  end

  def has_colorkey?(color)
    @colorkey == color
  end
end

Et donc dans ta classe Window, quand tu auras obtenu le pixel, tu n'auras plus qu'à balayer tous tes sprites et tester la dernière méthode, ainsi :

@sprites.each {|sprite| selected = sprite if sprite.has_colorkey?(@pixel)}

ce n'est qu'un exemple, mais au moins tu auras une référence vers l'image actuellement survolée, et vu que Gosu utilise le Z-Buffer, il ne peut pas y avoir deux images au même endroit de la souris, au même niveau de profondeur tout du moins.

Note au passage que ce procédé fonctionne parfaitement sur de la full 3D Nous utilisons ce procédé notamment pour notre éditeur de niveau, où les objets 3D sont d'abord dessinés en mode couleur, puis dessinés en mode texture.

[glutox]

Merci encore pour ta rapidité !
J'ai tester ta solution OpenGL et elle marche à merveille.

En ce qui concerne la conception et l'emplacement des tiles, ce n'est pas un soucis. (c'était une formule style "mouse_x/mouse_y = tile 5/6")
J'ai déjà testé le fichier "OpenGLIntegration" mais je ne comprend pas les fonctions OpenGL, j'aurais aimé de la doc que je puisse aisément comprendre ( je ne connais pas du tout la syntaxe C même si ça me tente de m'y mettre un jour ).

Je ne sais pas où j'avais la tête mais pour donner une couleur à l'image, je n'ai qu'à utiliser une fonction d'ImageMagick (colorize) et charger via la variable d'ImageMagick.
Ce qui m'inquiette, ce sont les perfs. Les graphismes seront similaire à Dofus, il y aura beaucoup d'image différentes à afficher, doubler les images pour savoir si on est sur une zone cliquable, ça ne consommera pas trop ?

[Guigui]

Si tu utilises Rmagick c'est en effet bien plus simple ! J'avais laissé tomber cette librairie du fait que "compiler" un "exécutable" via rubyscript2exe posait beaucoup de soucis avec.

Mais si tu comptes l'utiliser, tu peux en effet coloriser une image et en garder une référence. C'est exactement ce que je faisais quand je bossais avec, et je n'avais aucune perte de performances.

Créer ces images est un pré-traitement, avant même que ta scène ne s'affiche. Et garder deux fois plus de références aux images affichées, ça reste très peu par rapport à ce qu'un PC peut endurer.

Concrètement, Rmagick ne te servira qu'à ça, en revanche. A voir si utiliser cette lourde librairie est vraiment nécessaire, sauf si bien entendu tu en utilises d'autres méthodes.

Par ce que créer un doublon coloré d'une image, sous Photoshop, c'est quand même ultra rapide :
- tu choisis une couleur
- tu control + clic sur ton calque, ce qui te sélectionneras les pixels non vides
- tu remplis
- tu enregistres avec même nom + "_color" par exemple
tu peux même automatiser tout ça via une macro, ce qui est super facile à concevoir sous Photoshop.

Au passage, pour quelqu'un qui affirme ne pas comprendre ni connaitre OpenGL, je n'en reviens pas que tu sois arrivé à créer cette méthode de lecture de pixels aussi rapidement