RPG ALLENDE // JEUX EN OPENGL (VERSION BETA 4)
kenjimax
Messages postés
82
Date d'inscription
dimanche 3 août 2003
Statut
Membre
Dernière intervention
10 août 2007
-
6 juil. 2004 à 01:32
Heakons Messages postés 8 Date d'inscription samedi 15 janvier 2005 Statut Membre Dernière intervention 14 juin 2005 - 13 juin 2005 à 02:32
Heakons Messages postés 8 Date d'inscription samedi 15 janvier 2005 Statut Membre Dernière intervention 14 juin 2005 - 13 juin 2005 à 02:32
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/24304-rpg-allende-jeux-en-opengl-version-beta-4
https://codes-sources.commentcamarche.net/source/24304-rpg-allende-jeux-en-opengl-version-beta-4
13 juin 2005 à 02:32
12 août 2004 à 18:37
12 août 2004 à 18:27
10 août 2004 à 16:38
Je crois qu'il manque un fichier sources dans le fichier zip.
Il manquerait pas un fichier appelé timer.cpp dans le zip ?
8 août 2004 à 23:52
sinon c'est clair que bêtement pour des fonctions super courantes du style Min, Max, Abs, ... si tu veux pas te tapper 15 000 surcharges, t'as tout intérêt à coder ça en template.
8 août 2004 à 23:25
Elles sont super puissantes et super inutilisées des amateurs car elles sont assez difficiles à maitriser (regarde par exemple le calcul d'une valeur par le précompilo, et non in game).
En fait, elles ne sont pas si difficiles, mais bon faut déjà en avoir l'utilité. Dans notre jeu waterball (www.waterball.fr.st) on s'en est servi uniquement pour CDXList et le registre.
cordialement
8 août 2004 à 23:18
Les changements de map sont plutot hardcore :D
Mais tous ces problemes s'expliquent par le fait que au debut j'ai commencé a coder pour tester deux ou trois ptits trucs et c'est seulement plus tard, alors que le ode avait deja pas mal avancé que j'ai decidé de pousser le projet un peu plus loin.
Au fait, j'ai une question :
Le C++ propose une onction super puissante : les templates, et pourtant je ne les vois jamais utilisés, il y a une raison ? C'est pourtant bien pratique quand meme !
10 juil. 2004 à 16:11
jai lu aucun comment, je vais probablement repeter des choses, je suis presse, voila pq.
je te conseil de faire du multi-layer pour tes cartes, renseigne-toi, mais ca na rien de sorcier, il sagit juste de dessiner plusieurs couches de la carte par transparence.
pas vu de scrolling
tu devrais mettre la zone de collisions de ton perso (et des arbres) a la base du sprite, et pas sur tout le sprite, cest pas realiste :/
a ce propos, gere le ainsi nomme Z-index, pour que passer derriere un arbre fasse bien apparaitre larbre devant toi, et tu devras faire pareil avec les PNJ. ca cest ds le cas ou tu changerais justement la zone de collision (franchement, il faut ;))
est-ce que tu as un script engine? cest a propos des changements de map, ils sont scripte, ou cest "hardcode"? si cest hardcode, faut repenser larchitecture je pense, parce que tu vas avoir des problemes pour levolutivite, et, accessoirement mais on sen fiche, un exe dune taille barbare.
vala, jai ete que negatif, dsl :p bah pr la route alors: garde la musique ;)
8 juil. 2004 à 01:37
Mais le vrai probleme de l'heritage, c'est que c'est bien pour les vieux qui programment des tableurs, mais, pour les jeux, niveau espace memoire et rapidité, c'est miserable !
quand tu crés un objet a partir d'une classe fille, ca créé un objet de chaques classes parentes ! (sauf classes virtuelles pures). Imagine que tu utilises un multiheritage, ca devient n'importe quoi, il y a un appel à 15 constructeurs...C'est nul ! ;)
8 juil. 2004 à 01:31
J'ai une fonction qui s'appelle collision et une autre collision_pnj
la premiere est de la forme:
(en gros) :
for(int i =0, i< map->nbr_element; i++)
{
if(hero->pos_x==map->element[i]->pos_x - hero->taille_x && blabla)
{ return 1 } //je sais pas besoin d'accolades....
}
et dans une autre fonction j'ai un appel, qui fait :
if(collision(map_courante, hero)==1) blabla....
Ca revien a peu pres au meme.
Au fait, je te vois jamais sur MSN... :(
Pour te faire plaisir, j'ai fait un joli programme tout propre, mais qui marche pas lol, dans une source un peu plus recente.
8 juil. 2004 à 00:47
Le truc c'est de penser objet avant de coder : quelles seront tes classes, quand est-ce qu'elles seront instanciées, et pourquoi.
Sinon si tu crées un objet juste pour avoir la syntaxe objet->collision(), effectivement c'est con.
Non, moi je verrais plutôt, par exemple, chaque "element" qui aurait un pointeur vers la "map_courante" en membre, par exemple, et là tu ferais :
if(mon_element->collision())
// blabla...
ou sinon, sans pointeur membre vers la map courante tu ferais :
if(mon_element->collision(ma_map))
// blabla...
Enfin moi je dis ça mais j'ai pas vraiment étudié le code source donc je sais pas du tout si je dis des conneries ou pas ^^
7 juil. 2004 à 19:09
C'est trop de probleme, pour un resultat equivalent sauf un code moins propre, mais pas forcement mois rapide !
J'avais fait un jeu en mode texte METEROID III, qui etait tres "propre", avec surcharge d'operateur, polymorphisme, encapsulage et heritage, mais...pour ce programme la, ca me donne pas grand chose....enfin je trouve....
7 juil. 2004 à 16:56
7 juil. 2004 à 12:40
Mais c'est surtout dans un soucis de clarification des choses, les fonctions friend, sont des fonctions qui ont un rapport direct avec la classe dans la quelle elles sont declarées.
En gros pour l'instant ca sert a rien, mais si jamais je modifie quelquechose, ca servira.
7 juil. 2004 à 12:40
Mais c'est surtout dans un soucis de clarification des choses, les fonctions friend, sont des fonctions qui ont un rapport direct avec la classe dans la quelle elles sont declarées.
En gros pour l'instant ca sert a rien, mais si jamais je modifie quelquechose, ca servira.
7 juil. 2004 à 12:36
Va falloir que je revois ca...
Pour le scrolling, ca complique enormement les choses ! Mais c'est rai que ce sera mieu. Je peux pas le faire pour ce projet, dans un prochain peut etre.
Oui achoum, surement, mais si je te dis que pour faire tes programmes, tu ferais bien mieux de programmer en Q-basic ! Tu me repondrais quoi ? que tu ne sais faire que du C++ et que tu n'as pas le temps de te mettre au Q-basic ! J'ai prevu de me mettre a directX en rentrant des vacances (dans 5 semaines en fait) apres avoir fini ce programme.(Faut que je le distribue au lycee...)
PS --> Ok, je suis quasiement connecté en permanence...mais parfois...ce n'est pas moi ! ;) Mais t'en fait pas, mon petit frere est cool :D
7 juil. 2004 à 10:11
Aussi bien au niveau optimisation qu'au niveau fonction....
Voila ....
6 juil. 2004 à 22:26
Je viens de tester et ça a l'air pas mal bravo :) Mais j'ai le même problème qu'AmK avec la vitesse du perso.
Attends je regarde le code voir si je peux trouver d'où vient ce problème (au fait t'as oublié de fournir timer.cpp dans le zip ^^)...bon ben non j'ai pas trouvé (si je pouvais compiler ça aiderait mais bon de toutes façons j'ai la flemme lol).
Sinon faudrait que tu rajoutes un scrolling, pour ça faut considérer une nouvelle origine, celle du monde, et afficher les persos et les objets selon cette origine.
Et pour finir, pourquoi est-ce que tu mets tous ces friend??? ça sert à quelque chose??
En te souhaitant bonne prog...
@++
PS : je t'ai rajouté dans mes contacts MSN, si jamais tu te connectes...;)
6 juil. 2004 à 19:29
La prochaine fois je les met, c'est promis !
D'ailleur quand je pense a la fonction afficher_element(), ca me fait plutot penser a la blague de momo...
Je mets a jour des que ca aura un peu avancer dans la gestion des PNJ et des ennemis.
6 juil. 2004 à 18:58
6 juil. 2004 à 18:55
6 juil. 2004 à 18:52
6 juil. 2004 à 18:50
Ca me permet de ne pas faire gaffe aux histoires de classes amis et consorts, cependant je les mets quand meme, au cas ou j'aurai besoin d'utiliser ces mots clefs...
6 juil. 2004 à 16:41
class carte
{
public :
element * objet[30];
int numero;
int nombre_element;
friend void charger_carte(carte *map);
friend void changement_carte(carte *map);
friend void afficher_carte(carte *map);
};
je suis pas un prince en poo mais les membres de données comme element * objet[30];
int numero;
int nombre_element;
on feraut pas mieux de les mettre sous le label private ? c'est le principe meme d'une clase non ?
6 juil. 2004 à 15:17
sinon j'ai decouvert dans ton zip le .h le plus court que je n'ai jamais vu :
//OBJECT.H
#include "element.h"
voila que dire d'autres à part que j'aime bien lire ton code , il me permet de penser à un monde meilleur !!!!! ( bon j'arrette de delirer :))
6 juil. 2004 à 12:43
Je pensais à faire une surcharge des operateurs >> et << avec :
>> : on ecrit l'objet map
<< : on lit l'objet map et on charge les elements
le jeu le permet, il suffit donc de créer l'editeur (suffire....)
6 juil. 2004 à 11:48
Un peu plus long certes mais tellement plus compréhensible et facile d utilisation =D
6 juil. 2004 à 11:21
Pour les layers, je suppose que tu parles de la gestion des collisions avec des calques ? Donc une collision pixel perfect ?
Je ne maitrise pas encore ce point, je vais me documenter.
Une petite anecdote :
Je peux pas avancer dans la programmation sans avoir des sprites a mettre, or puisque ceci sont pas mal pris dans secret of mana et que je n'ai pas le tileset, je suis obligé de jouer a l'emulateur..(j'ai le jeu original en plus..) et de faire des impressions ecrans...et en ce moment j'arrive pas a tuer TIGROR un boss...alors je peux plus programmer...
6 juil. 2004 à 09:28
Pour les collisions, utilise le systeme des layers : aussi simple mais il permet beaucoups plus de choses !
Et pour les maps.... j'avoue que la c'est un peu primitif comme tu dis :D.
Mais je repete : la production globale est sympa, meme excellente !
8/10
6 juil. 2004 à 01:32
http://kenjimax.free.fr/rpgbeta4.zip
(j'essaye une balise BBcode :)
[URL]http://kenjimax.free.fr/rpgbeta4.zip/URL
une html :