camelot-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Camelot-discuss] Bindings librsvg


From: Sven Luther
Subject: Re: [Camelot-discuss] Bindings librsvg
Date: Tue, 11 Feb 2003 15:43:32 +0100
User-agent: Mutt/1.5.3i

On Tue, Feb 11, 2003 at 03:07:32PM +0100, Jérôme Marant wrote:
> En réponse à Sven Luther <address@hidden>:
> 
> 
> > > OK. Je suis un peu dépassé en ce moment (je n'ai pas eu le temps
> > > de voir ce qui a été fait.) Je peux peut-être m'occuper
> > > de d'autres aspects.
> > 
> > Tu t'etait porte volontaire pour faire des images SVG que l'on
> > pourrait
> > tester.
> 
> Je parlais de code, mais enfin, si tu veux des images, je peux
> continuer le sketch ou sodipodi :-)

Cela poura venir par la suite, mais je crois que Luc et Olivier sont
plus expert en SDL que nous. Enfin, maintenant on a la librairie rsvg et
un exemple de comment l'utiliser en SDL, et on peut commencer a
developper avec cela. Moi par contre je n'aurais pas le temps avant le
WE.

Pour le tetris, on peut imagine un jeu avec 3 couches de surfaces SDL.
Une premiere pour l'interface utilisateur, les scores etc. Une deuxieme
qui correspond a l'etat du tableau de jeu courrant, et une troisieme qui
correspond a la tuile en train de descendre. Lorsque la tuile ne peut
plus descendre plus bas, on l'integre alors au tableau du jeu, et si des
lignes disparaissent du tableau de jeu, on fait un blit de la partie
haute du tableau de jeu vers le bas, et on remplit le haut par des
lignes vides. Bien sur, les tests de se feront sur une structure de
donnee entierement a part, peut-etre une liste de lignes, ou quelque
chose comme, ou les ligne serait des tableaux de booleens par exemple.

On peut donc decouper la suite du developpement en plusieurs parties :

  o realiser le mecanisme du jeu, qui manipule la liste de lignes, et
  renvoie les informations correspondantes a l'interface, ou meme qui
  initie les callbacks de synchronisation du tableau de jeu directement
  (deplacement vers le bas, vers les cote ou rotation d'une tuile,
  inclusion de la tuile dans le fond, suppression d'une ou plusieurs
  lignes).

  o realiser la partie graphique, soit directement soit grace a une
  librairie, qui permettrait de realiser les differentes operations
  ci-dessus.

  o realiser la partie annexe qui correspond a l'interface utilisateur.

  o realiser la partie interaction avec le joueur.

  o realiser la partie qui correspond a la lecture des images svg, a la
  sauvegarde du score, etc. Eventuellement on peut meme prevoir une
  sauvegarde de la partie en cours pour pouvoir la reprendre plus tard.

  o realiser differentes sortes de tuiles et de caches.

Ceci dis, la realisation d'images permettant de tester l'utilisation de
SVG avec different sprites et voir comment cela rend, c'est important
aussi, surtout si on remarque que finalement SVG ne permet pas de faire
de petit sprites; Je remarque que tu dis 'continuer' sodipodi ou sketch
, est-ce que cela veut dire que tu a deja des images qu'on pourrait
tester.

Et comme dis, on pourrait ajouter un outils de visualisation d'images
SVG a ocamlrsvg. De maniere a pouvoir plus simplment tester et comparer
les differentes images.

Amicalement,

Sven Luther




reply via email to

[Prev in Thread] Current Thread [Next in Thread]