Projet, lib rpg - Page 3

oui mais moi ce que je ne voit pas, c'est l'interet de faire ça !!!
tu m'explique quel avantage ça a ???

avec mon systeme le programmeur il a UNE seule liste à connaitre, et si il fait un monstre et que certaines stats sont inutiles, bah il les met pas (faudra que Miam se démerde) ou bien il met des zéros.

???????????? dans les listes que j'ai donné, ya des trucs inutiles à MIAM, d'apres ce que je constate, MIAM utilise n° sprite et "nom"

donc les listes sont
--hero/monstre
--equipe
--persos

???????????? dans les listes que j'ai donné, ya des trucs inutiles à MIAM, d'apres ce que je constate, MIAM utilise n° sprite et "nom"

donc les listes sont
--hero/monstre
--equipe
--persos grrrr double post

pkoi t'as fait exprès de faire un double post ?

Pkoi pas une liste "character"
{"Nom","Sprite",hp,mp,hpmax,mpmax,force,dex.............niveau,exp,exp donnée si tué......}

Et bien sur si on traite un héros on met 0 à "exp donnée si tué", si on traite on monstre on met 0 à niveau et exp.

parce que répétée 100 fois cette liste prendrait plus de mem, mais ça tu peux le faire si tu veux, MIAM ne sera pas exigent dessus, lui il prendra que les 2 ou 3 premiers elements

Bon en fait cette liste, elle est assez peu utile pour les déplacements...
(on a besoin de l'image, du nom pr l'afficher dans les dialogues, mais pas grand chose d'autre).

Ça veut dire que le reste c'est pour le moteur de combat.
Donc :
- Soit on laisse l'utilisateur se démerder avec ses propres liste, tant pis pr le moteur de combat
- Soit on trouve un système simple (je préfererais cette solution)

Mais on a qu'a commencer par le moteur de déplacements, ça regle provisoirement le problème.

de ttes façons mm si l'utilisateur ne fais pas de listes il peut tjs faire : miam({n°pic,"nom"..etc..},...etc) et c réglé !


bon attaquons au différentes fonctions !

Bientot fini Interum... v pvoir commencer à pense à Miam

aussi ! les restrictions indispensabales seront de respecter le format de maps et le format des sprites16

ah oui fo que tu me montre ton format.
il est vraiment interessant ?

bon pour les maps : size_x, size_y (et d'utres trucs que g pas le temps de preciser)

une matrice tiles
une matrice sprites
une matrice foreground
une matrice murs+persos sur la map

pour les sprites : ben une matrice de sprites 16 dans un seul fichier

une matrice tiles
une matrice sprites
une matrice foreground
une matrice murs+persos

et un module mémoire supplémentaire pour tout stocker

Ah oui o fait je te parlais de ton format de sprites

?????????? non, les matrices sont en C

Heu l'utilisateur il sera bien obligé de les mettre en basic qq part...

non ! il va les créer avec l'editeur fourni

Ah ouais... Mais ça risque de devenir limité...

n'importe quoi !!!! vu les capacites citees ci dessus, ce sera pas du tout limite !!

Fo que tu m'explique en détail les différence entre tous tes plans

Vous allez utiliser genlib en plus ?
A mon humble avis, ca sert a rien de faire comme ca.
J'aurais plutot penser a un programme basic a appeller si quelque'un touche quelqu'un d'autre ou un truc du genre.

Non on va pas utiliser Genlib pr du basic

on va utiliser extgraphlib !!

bordel !! cette lib servira juste a donner qq routines pour les programmeurs, rien d'extraodinaire mais elle permettra de faire plusieurs plans pour une map

Justement fo que tu m'explique précisement à koi correspondent les plans (j'ai tjrs utilisé un seul plan...)

moi aussi en basic g tjs utilisé un seul plan:

le background est un plan affiché en mode OR
le plan sprites est un plan ou les sprites sont masqués par un script de la lib (faudra le faire )
le foreground est un plan ou les sprites sont affichés en OR (ou bien masqués, on verra plus tard) par dessus le perso

Ouhhhh...
C compliqué tt ça

Bon... Background, le sol quoi... mode OR ? Je connais pas tous les modes par coeur, celui là c celui qui inverse les couleurs ?
Idem pr le foreground...

Sinon pr les sprites masqué ça serait vraiment + simple pr les utilisateurs si les masques sont automatiquement créés.

mode OR:
noir sur blanc donne noir
noir sur noir donne noir
blanc sur blanc donne blanc
blanc sur noir donne noir
c le mode par defaut koi :]

l'avantage du foreground c que qd tu passes avec ton perso devant et ben le foreground est superposé sur le perso :]

et pis ben oui les sprites, pas la peine de les masquer, la lib le fera, c tellement agréable

Le mode par défaut c OR ?
Ah bon bah ok je comprends mieux là

Le foreground superposé, ça fait toujours très classe, alors la pr un jeu en basic ça va tuer !

Et les masques automatique... comme tu dis...

ben oui, c un ptit plus de MiaM les foreground, on peut pas le faire sans cette lib, sinon vive la lenteur

oué... ça les foreground c pas la peine de tenter sans un petit peu de C

bref ! ce week end je te balance un descriptif du format des matrices et des sprites et on attaque le listing de ttes les fonctions qu'on voudra intégrer

##### de popup de france télécom

Ok, je c pas si je serais chez moi ce week end mais je devrais avoir un PC connecté à portée de main.