Skip to main content

Pleins de nouvelles classes

La semaine dernière il y a eu tout pleins de nouvelles classes qui ont été créé.

TextureManager Comme son nom l’indique, cette classe contiendra un vector des textures qui sont présentements loader en mémoire pour le level en cours.
Tile Cette classe s’occupe des tile qui provienne des tilesets loader en mémoire avec le texture manager
Level S’occupe de gérer le fichier xml du level
Texture Représente une texture. Une fois loader, elle est placé dans le textureManager

Comme je suis présentement en vancance, il se peut que les mises à jours seront plus espacer jusqu’au 15 août.
Bonne semaine 🙂

OnLostDevice

J’ai enfin réglé un bug qui trainait depuis très longtemps. Lorsqu’on déplaçait la fenêtre ou si on la redimensionnait, il y avait un crash qui disait ceci :

Direct3D9: (ERROR) :All user created D3DPOOL_DEFAULT surfaces must be freed before ResetEx can succeed. ResetEx Fails.
Direct3D9: (ERROR) :ResetEx failed and ResetEx/TestCooperativeLevel/Release are the only legal APIs to be called subsequently
D3D9 Helper: IDirect3DDevice9::Reset failed: D3DERR_INVALIDCALL

J’ai chercher longtemps avant de trouver c’était quoi. En fait, tout était correct exepter une chose. J’appelais 2 fois de suite cette série de code :

OnLostDevice();
HR(mpDevice->Reset(&mD3dPresentParam));
OnResetDevice();

J’ai enlever le doublon et mon crash a été réglé comme par magie. J’ai trouvé l’indice qui me fallait en allant faire des recherches sur http://www.gamedev.net/  😛

Début des collisions

La semaine dernière j’ai commencé à travailler sur la gestion des collisions. Je me suis concentré davantage sur la collision par bounding box pour le moment. Je me suis créé une petite fonction dans ma classe sprite qui vérifie si celui-ci collisionne avec un autre sprite passé en paramètre. Pour le moment, la détection fonctionne assez bien mais il me reste plusieurs test à faire et un petit bug lorsque le sprite collisionne avec le coin d’un autre sprite. Parfois il ne le détecte tout simplement pas et le sprite passe au travers de l’autre.

J’ai aussi commencer à travailler sur mon éditeurs de niveaux. Je ne savais pas trop comment l’appeller alors j’ai pigé dans la mythologie grecque et j’ai choisi comme nom : Cyclope. Cet éditeur de niveau permettra de créé nos cartes rapidement et simplement. Il sauvegardera les map dans un format  crypter (*.map) pour ne pas que les joueurs les modifie pour tricher et les informations des tilesets utilisé seront sauvegardé en xml et seront général au projet.

À venir cette semaine:

  • Regard sur le bug qui concerne la détection de collision lorsque ça arrive dans un coins du bounding box
  • Affichage d’un tilemap
  • Poursuite de l’éditeur de niveau
  • Screenshots pour le blog

Classe des sprites

Cette semaine j’ai donné un grand coup pour ma nouvelle classe pour gérer les sprites. Je n’ai pas eu de problème majeur mais fait tout pleins de découvertes intéressante sur la gestions des sprites. Pour le moment la classe permet de loader une image et de l’afficher. On peut lui définir sa position ainsi que son point de pivot. Ce n’est pas beaucoup pour le moment mais il faut savoir que cette classe dérive de la classe gameobject et que celle ci contient d’autre attributs intéressant. Lorsque ma classe sera pas mal terminé, je vous détaillerai d’avantage son utilisation et je vous posterai une image. La semaine prochaine je vais m’attaquer à la gestion des collisions entre les sprites. Pour le moment je vais me concentrer sur la détection par bounding box et par le rayon tout dépendant de la forme du sprite. 🙂

D3DXVector3

J’étais entrain de me faire une belle classe pour gérer mes vecteurs mais en regardant pour un autre problème dans la doc de directX , je suis tombé sur D3DXVECTOR3. J’ai donc effacer ma classe de vecteurs et commencer à utiliser celle-ci. C’est beaucoup plus simple et ça évite de réinventer la roue. Bref, avant de ré-inventer la roue, vérifier dans la doc du sdk de directX (Si vous utilisez DirectX) pour voir si quelque chose existe déjà. Grace à cette découverte, ma classe pour les sprites a grandement avancé et devrait être complétée d’ici la fin de la semaine. 🙂

Petit retard

Aujourd’hui est seulement un petit message pour vous dire qu’il y a un petit retard dans l’avancement de space ball. Mais ne vous inquiètez pas, ce que j’avais prévue de faire pour cette semaine sera tout simplement reporter pour la semaine prochaine. 🙂

Fix bug d’affichage

La semaine dernière, j’ai pratiquement réalisé les objectifs que je m’étais donnés. J’ai donné un gros coup dans le refactoring des classes de bases. Je me suis retrouvé à n’avoir plus rien d’affiché à l’écran. J’ai donc du travailler fort pour réussir à ré-afficher quelque chose. J’ai réussi et du coup, mon refactoring m’a permis de régler plusieurs petits bug d’affichage qu’il y avait.  Il n’y a pas beaucoup de choses à dire cette semaine. Je vous laisse donc sur ce qui sera fait d’ici 2 semaines.

À venir dans 2 semaines :

  • Création de la classe de base des games objects
  • Création d’une classe qui dérive de la classe gameObject pour gérer les sprites.
  • Fix de crash s’il y en a
  • Fix de l’affichage du texte qui est assez étrange.

Refactoring

Cette semaine j’ai travaillé à faire bouger la balle. En faisant ça, j’ai vue plusieurs erreurs de conceptions au niveau des classes. J’ai donc décidé de faire un petit refactoring histoire que ce soit plus facile pour créer le jeu. J’ai commencer par créé un surface pour le background au lieu d’utiliser des sprites, ensuite j’ai créé des fonctions pour afficher une surface. On peut y spécifié sa taille, sa destination et finalement on peut spécifier si on veut que la surface prenne tout l’écran.

À venir la semaine prochaine:

  • Continuation du refactoring, il n’y aura probablement pas de nouveau éléments du coté visuel.
  • Fix des warning lors de la compilation.
  • Fix de crash s’il y en a
  • Fix de la balle qui fonctionne bizzare coté logique.

Premier bug majeur

Je recherchais la cause d’un de mes bugs lorsque je switchais du mode fenêtre vers le mode plein écran. J’ai cherché, cherché et cherché la cause de mon erreur. Il y a quelque minute je me suis rapeller un petit truc que j’avais apris lors de mon travail. J’ai donc essayé et j’ai pu trouver le bug en moins de 30 secondes. Mais quel est ce truc dites-vous ? Et bien c’est simple, lorsque vous travaillez avec le sdk de directX, je vous suggère de mettre directX en mode debug. Pour le faire, vous aller dans le dossier où vous avez installer le sdk de direct X et vous ouvrez le control panel de direct X. Rendu là vous choisissez ce que vous voyez dans l’image ci-bas :

*image non disponible

Vous pouvez essayer les autres options aussi. Mais si vous utilisez seulement l’option que j’ai entouré en rouge, s’il y a une erreur, celle-ci sera loggué dans le output de visual studio et c’est souvent un message très claire. C’est grâce à ça que j’ai découvert que mon erreur était une erreur d’inatention. J’avais mis un mauvais format de couleur au backbuffer. J’avais mis : D3DFMT_X8B8G8R8 au lieu de D3DFMT_X8R8G8B8. Bref, j’avais mis le format BGR au lieu de RGB pour la couleur. Cette erreur a du se faire avec l’auto-completion du code. lol. Donc pour conclure, n’oubliez pas le petit truc, ça vous évitera de la perte de temps.   Dernière petite chose, n’oubliez pas de remettre vos setting par defaut si vous voulez jouer à d’autre jeux par après, sinon vous allez trouver que votre FPS est pas trop haut et vous ne saurez pas trop pourquoi.

Premier screenshot

Voici ce qui a été fait il y a quelque temps déjà

– Création de la classe principal
– Création de la classe GraphicStats qui s’occupera d’afficher des statistiques à l’écran tel que le fps, le mpf (milliseconde par frame), le nombre de triangles, nombre de vertex.
– Création de la classe DirectInput qui s’occupera, comme son nom l’indique, des inputs. Pour le moment je gère que le clavier et la souris.
– Finalement, création de la class d3dApp qui s’occupe de l’initialisation de la fenêtre principale et de directX.

Avec tout ça, j’ai pu créer la fenêtre et initialiser DirectX. J’ai aussi fait en sorte d’afficher un background à l’écran. En fait c’est une texture 512 x 512 qui est Tiler. Il y a aussi l’affichage des statistiques. Voici un petit screenshot pour vous montrer ce qu’il y a de fait.

 

C’est le debut

Le but de ce projet est pour simplement m’amuser et améliorer mon c++. Donc voici mon petit projet. En fait, ce n’est pas compliqué, c’est seulement un petit clone d’arcanoïd. Malgré que ce soit un jeu à l’allure simple, ça implique quand même beaucoup de choses à faire.

  • Création d’un éditeur de carte car faire des map en écrivant à la main ce serait long et ardu.
  • Création des power up et des … power down. J’ai décidé de mettre des power down pour personnaliser mon jeu.
  • Équilibrage des power up et des power down pour s’assurer que le jeu ne soit ni trop simple ni trop difficile.
  • Gestions des sprites à l’écran
  • Création d’une bonne gestion de colision.
  • Création de la fenêtre et utilisation de DirectX

C’est mon petit projet en gros. Dans la liste de choses à faire il y en a plus mais ce sont ceux qui me sont venu à l’esprit pour le moment. Je vais vous tenir au courant des progrès que je ferai au fil du temps. Je dirais qu’il devrait y avoir des nouvelles à chaque semaines selon mon emploi du temps bien entendu et si le changement vaut la peine d’être mentionné.