[Logiciel] µDev++ - Version 1.3 disponible

La je suis en pleine refonte de tout le système de base donc ça risque de mettre un moment a arriver :/
Enfin si j'y arrive ça auras le mérite d'être très simple a rendre multiplateforme (genre SDL et SFML like quoi).

On peut voir les Sprite Sheet comme des tableaux de int où chaque case correspond à une couleur ? Parce que si c'est le cas on peut s'en servir comme définition de niveaux en tileset, au lieu de bourriner un fichier texte. Exemple:

Code:

uint spr = sprite_sheet_add("level.bmp");
if (spr[20][20] == c_blue)
{
    //etc...
}

Faut avouer que ça serait super pratique.

Non on ne peut pas car un sprite sheet contient une texture opengl.
Ce que tu peut faire par contre c'est utiliser la fonction image_load_bmp qui te retourne quand a elle un tableau qui contient toutes les couleurs d'affilées.
Par contre le tableau n'a qu'une dimension donc faut récupérer la couleur avec tabpixels[x + largeur*y]
Tu peut aussi les utiliser comme pixmap (je créerais des fonctions pour leur gestion).

Mon but était de les utiliser comme pixmap ^^

Par contre j'ai l'impression que quelque chose ne va pas bien.

Lorsque je tape :

µDev : Create a écrit:

uint img = image_load_bmp("test.bmp",8,8);

Test.bmp étant une petite image de 8*8 pixels, évidemment.

Le compilateur me dit :

Superbe fenetre popup a écrit:

main:create:1: error: invalid initialization of non-const reference of type 'uint&' from a temporary of type 'int'
udev_bitmap.h:8: error: in passing argument 2 of `uint* image_load_bmp(const char*, uint&, uint&, uint)'

C'est normal, ai-je fait une erreur ou il y a un problème ? (J'ai bien pensé à mettre "Image Bitmap Loader" dans 'Build Options')

Faut passer des variable (c'est des references les paramètres).

Par exemple :

uint largeur, hauteur;
uint *pixmap = image_load_bmp("test.bmp",largeur, hauteur);

Pas besoin de connaitre la taille de l'image en plus :p

Yép en effet, j'ai pas beaucoup réfléchi ^^
C'est vrai que dans le prototype de la fonction width et height passent par référence, donc c'était assez évident que ce soit des variables qui seraient modifiées par la suite...

Mais bon ça marche, c'est l'essentiel !

EDIT : Par contre ça fait une rotation de 90° en sens direct...
C'est étrange mais on doit juste changer deux lettres pour l'initialisation ^^
(au lieu de [x*largeur + y] c'est [y*largeur + x])

onilink_ a écrit:

Non on ne peut pas car un sprite sheet contient une texture opengl.
Ce que tu peut faire par contre c'est utiliser la fonction image_load_bmp qui te retourne quand a elle un tableau qui contient toutes les couleurs d'affilées.
Par contre le tableau n'a qu'une dimension donc faut récupérer la couleur avec tabpixels[x + largeur*y]
Tu peut aussi les utiliser comme pixmap (je créerais des fonctions pour leur gestion).

:3

Je devrais aller dormir un peu moi...

Allez, ça y est, c'est parti !

Pacman le retour

Entièrement programmé grâce à µDev++ 1.4 (le système de gestion des erreurs marche nickel, ça roxx du ponay!).

Si vous avez suivi ce topic, vous avez certainement vu mon premier Pacman.
J'ai décidé de l'améliorer, et devant le système merdique que j'avais mis en place, j'ai donc recommencé le programme à zéro (ou presque.)

Screen:

Spoiler:

Et donc le lien de téléchargement (source + exe + ressources)

Qu'a-t-il de mieux par rapport au précédent ?

• Le labyrinthe est vachement plus joli
  
• Les fantômes bénéficient d'un véritable algorithme de déplacement (ce qui rend le jeu plus dur et donc un peu plus captivant)
  
• La gestion de la mort des fantômes est plus semblable aux vrai pacman (grâce à l'algo de dép)
  
• utilisation d'une jolie Pixmap au lieu d'un fichier texte tout moche
  

Il reste bien sûr d'autre choses à améliorer mais je suis assez content du résultat ^^

Ahah vraiment excellent
Par contre ça se corse avec les ghost qui suivent Pacman :p
En tout cas bravo.

Une idée d'amélioration : mettre tes ressource en un seul fichier comme les jeux pros. Au moins tu a l'exe et un fichier de données.
Pourquoi pas faire un level editor aussi :p

Les ressources ne sont que dans un fichier normalement (le fichier rec.)

Par contre cette fois j'ai utilisé une image pour le niveau, et pas de primitives comme l'ancien, ce qui restreint les modifications. (donc probablement pas de level editor)
Par contre, j'essaie de faire un espèce de Mario, et là j'inclurai un level editor.
(Je suppose qu'il n'est pas possible de sauvegarder des .bmp, alors j'utiliserai des fichiers texte : Moins classe mais ça marche)

@-Coco- : ah un bon vieux Pacman !

@onilink_ : dans le titre du sujet, il est indiqué "version 1.3 disponible" .

Si tu veux de la performance le code source d'Allegro est une bonne lecture.
Par contre c'est du C.

Ben parce que la 1.4 n'est pas encore officielle :p

Sinon ouai je connais allegro c'est vraiment pas mal du tout.

Ah ok, c'est un secret alors x). (Chuuut !)

Je pense quand-même que tu auras plus de monde avec µDev, les noobs ont peur d'Allegro.
Ils font même... des cauchemars.

Ben, Allegro m'a l'air plus complet car plus abouti, mais µDev++ est bien plus simple à prendre en main, et puis bon niveau aboutissement on a µDev 1.4 contre Allegro 5.X, donc attendons un peu ^^

Ça, c'est sur qu'Allegro, que la SDL, que la SFML, etc. sont toutes "terminées".
µDev n'en est qu'à ses débuts, et s'il obtient des performances approchantes de celles d'Allegro...

Il est quand même déjà assez performant et simple (je ne me serai jamais attaqué à un pacman avec un autre langage, le seul truc que j'ai réussi à faire en SDL c'est un vieux pong tout pourri avec une IA invincible (coordonnées de la raquette adverse = coordonnées de la balle)).

µDev est presque ce qui m'a redonné goût à la programmation en C++, car lorsque j'ai appris la programmation c'était à la base pour faire des jeux (c'est vrai que Game Maker c'est bien mais beaucoup moins intéressant, la programmation directe est plus tripante, plus "épique" ^^).

Au fait, tu t'en sors dans la refonte de µDev ?

Ahah je galère un peu a vrai dire :p
Le problème est que je doit coder un système de fenêtrage multiplateforme. J'essaye donc de me baser sur SDL et SFML, mais c'est chaud quand même de récupérer le stricte nécessaire ^^

En plus je travail en parallèle sur la version GM. J'ai finis la base du système d'instances d'ailleurs. Voici les fonctions disponibles :

Code:

int instance_create(float x, float y, uint object)
int instance_find(uint obj, uint n);
int instance_exists(uint obj);
int instance_number(uint obj);
void instance_destroy();
void instance_destroy(uint instance);
int place_meeting(float xx, float yy, uint object);
(système de collision uniquement par aabb pour l'instant)

De plus il est possible d'accéder au attributs et méthodes de chaque instance d'un objet depuis l'instance de n'importe quel objet. (avec l'utilisation de cast)

par exemple il est possible de faire :

Code:

uint player = instance_create(16, 16, 0);
uint ins = instance_create(160, 80, 1);
// 0 et 1 sont les object_index. Je générerais des constantes dans le programme

adresses[player]->y = 64;
// adresses et le tableau qui contient toutes les adresses. Je lui donnerais certainement un autre nom dans le programme. Vous remarquerez qu'il n'y a pas de cast ici car y est un attribut de la classe mère Object

// Ici on appelle la méthode create(string str) de l'object1
static_cast<object1*>(adresses[ins])->create("test");
//obligé de faire un cast

Bon c'est un peu plus compliqué qu'avec les with(id) de GM mais ça fonctionne exactement pareil
De plus on a un contrôle totale sur vraiment tout la, car accès directement aux adresses mémoire des instances.

Qu'est ce que tu appelles un système de fenetrage multi-plateforme ?
C'est pour des fenêtres ingame ou c'est pour l'interface général ?

Pour la(les) fenêtre(s) ingame.

Bien sur je pourrais utiliser un truc tout prêt comme la SDL mais je souhaite créer le mien.
Déjà parce qu'il seras forcément beaucoup plus léger (vu qu'il ne gèreras que les fenêtres), et j'ai vraiment envie de tout faire de A à Z.

Pour l'interface vu que j'utilise Qt c'est déjà multiplateforme :p

Pour les fonctions GM, c'est dans un programme à part du genre µGM.exe ou c'est une lib à inclure dans µDev++ comme par exemple "udev_bitmap.h" (avec "udev_gm.h" dans ce cas)

Je crois que le GM-like se basera sur les librairies de µDev, en offrant "juste" une structure toute prête, avec gestion des ressources etc.

C'est a peut près ça oui. Et il s'occuperas de générer les fichiers h et cpp ainsi que les binaire (pour pas recompiler ce qui n'as pas été modifié)
Bref pas mal de trucs en perspective, et donc de boulot.

Les fichiers .cpp et .hpp seront sauvegardés séparément, où ton projet les contient ?

Je pense les sauvegarder en fichiers temporaires. Ce seras les binaires qui resterons dans le projet.

Question à part et pas trop hors sujet...

Plus de Box2D avec la 1.4 ?
Je peux me débrouiller sinon en déplaçant le fichier include etc... Mais bon...

Non je l'ai pas mis étant donné que je n'avais aucun exemple a fournir avec ...
Si quelqu'un me fournis un exemple je pourrais toujours le mettre en tant que module.

Bah c'est un peu compliqué à utiliser...
Mais on peut trouver des exemples tout prêts sur le net ^^

Et c'est dommage que l'on ne puisse pas utiliser Extremephysics en C++, du moins avec µDev vu que c'est pas super pratique d'inclure des fichiers...

Oui pour l'instant.
La je stoppe un peu le développement de µDev pour me pencher sur le GM like, qui a ses débuts seras une espèce de µDev mais avec des fonctionnalités supplémentaires (comme l'inclusion de fichiers sources, et la possibilité de ne pas avoir sans arrêt a les recompiler) et une interface complètement différente mais plus attrayante :p

Donc bon suffit d'espérer que j'arriverais a me dé***** le plus rapidement possible ><
(sinon il risque de pas avoir de nouvelle version avant un moment lol)

Bon courage, le GM like a l'air assez puissant lui aussi ^^