Un RPG pour vos V200/92+ - Page 2

grâce à lamage de Filezilla, j'ai a nouveau accès à mon ftp... ouf!

au risque de passer pour un gros lourd :
topics/15832-des-gifs-de-darkhole

Arf... J'ai plus la page de cms sous la main

darkhole est surement + fluide que mo rpg, mais moi, c'est du plein écran sur 92+

en + darkhole est en 10*6 moi c'est en 15*8: plus lent, mais + bô

normal : darkhole est optimisé pour les 89 mais a ete par la suite adapté aux 92+ et je t deja dit que mm si je faisais en 15*8, ça serait aussi rapide grace à ma lib

ca resteà prouver nan je déconne, c'est vrai que si tu as une lib spécialement adapté pour ton rpg, c'est + pratique et rapide

sinon, pour en revenir au jeu, la carte du monde sera + style Zelda que Final fantaisy ou darkhole: tout sera taille réelle bref... Les environnements seront assez varés: déset montagnes, plaines, volcan, monde des ténèbres, forêts, bref les calssiques

c en taille reelle ds darkhole, enfin c comme FF : la carte du monde est taille reduite/ au perso mais les autres maps sont en taille reelle

C ce que je voulais dire: moi C plutot zelda le style: tout est taille réelle (évidemment ca prend + de mémoire, mais je peux résoudre ça)

sinon est elle une librairie spécialement consacrée à darkhole, ou plutot Rpgs en général? c'est que ca m'interresse

pour l'optimisation de la taille des matrices:
il va falloir que je stocke à la fois les évènements et les décors en même temps, sinon ca prend bcp trop de places! en ce moment j'y réflèchis... sinon il faut que je définisse des types de zones, ca m'éviterait d'avoir des nbres à 3 chiffres dans les matrices... j'essaie d'y réfléchir...

ben miam ct a la base destiné à darkhole mais apres j'ai eu envie d'en faire une lib publique qui servirait à :
-manipuler des blocs de memoire pour ne plus utiliser de matrices et dnc gagner en memoire, en vitesse et en nbre de variables
-stocker des sprites16 ds un seul fichier et pouvoir beneficier de fonctions d'affichage de sprite16 tres rapides

MAIS cette lib n'a jamais vu et ne verra peut etre jamais le jour (faute de temps) et surtt pke si je finis la lib apres faudra faire des utilitaires et avec seiken des utilitaires j'en bouffe et ça me soule

Le coup du multi-pic ct pas con... Je ferais pê ça un jour

heu ben non c copyright moi
en fait c surtt les blocs de mem qui sont les mieux ds cette lib pke t'as une liberté infinie là dessus !! tt ce que t'as a faire c stocker ds une variable string du tios le nom du fichier que tu veux manipuler et hop miam s'occupe du reste (idem pour les pics)

J'avais fait une fonction "group" pour vertel, qui pouvait extraire et ajouter des fichiers à une archive déjà créée. Ça doit être adaptable

bah c cho qd mm

Certes

(flood... J'ai rien à répondre à ça )

nan je croa que c pas adaptable de façon fine, en fait mon idée c de manipuler des variables (matrices, listes etc..) mais en C à l'interieur de miam donc tres rapide et selon la fonction appellée miam renvoie des valeurs utiles
heu ... tu me suis ?

heu... à peu près...
En fait faudrait carrément un truc entièrement en C, tu ne rentre que le PIC et les coords, la lib se charge d'aller le chercher et de l'afficher.

pour les pics c facile : tu stockes les pic en format C les unes à la suite des autres ds un fichier externe et pour afficher tu lances par exemple : miam("aff_pic",nbre_pic,num_pic,x,y[,num_pic2,x2,y2...])

pour les données diverses c pas la mm chose mais si t'as créé une "matrice" de 100*100 avec que des valeurs qui indexent une PIC tu peux faire une fonction du genre :
miam("aff_map89",x_mat,y_mat) et c réglé

et bien sur faut que l'utilisateur puisse modifier ces fichiers de données avec des fonctions du genre :
miam("update_file",nbre_val,x_val,y_val,new_val)

d'ailleurs pour simplifier le mieux est encore de raisonner en liste et non en matrice et l'utilisateur se demerde pour faire (size_x*y+x)

ça me rappelle qqchose ça
t'es en train de refaire miam telle que tu la voyais y'a... un certain temps, tu voulais qu'on s'y mette pour refaire darkhole et cms avec

c tjs comme ça que g vu miam : affichage de spr16 rapides et stockage de données ds fichiers externes+manipulation pour combler les lenteurs du ti-basic

ceci dit ya une chose certaine : si je fais fais miam un jour, je referai darkhole avec c certain (flib ou vertel avec je c pas )

Tracé d'une ligne en pixel par pixel, en utilisant le potentiel maximum de chacune des 2 libs :



Bench ?

ouais mais le truc c que flib retourne ds le prgm basic entre chaque pix et pas vertel !
le truc qui me bloque chez vertel c tes noms de fonction de merde

ouais mais le truc c que flib retourne ds le prgm basic entre chaque pix et pas vertel !

Oui, mais j'ai précisé : "en utilisant le potentiel maximum de chacune des 2 libs". Le potentiel maximum de FLib c'est ça, j'y peux rien

Les noms de fonctions je les ait changés, maintenant ils sont sous la forme "x_abcd", c un peu plus court.

j'ai optimisé mon moteur ... en gros, je prend la matrice, je sépare la partie entière et la partie décimale en 2 matrices, la partie entière indexe les graphs, la partie décimale les évènements, dialogues, etc... le problème c'est que les numéros des graphs font souvent plsr chiffres (3 généralement)...

ensuite pour vertel les noms de fonctions j'm'en fout...mais bon ayant tout mis en listes, ca fera qu'une commnde à changer

Arf tu utilise presque le même système que moi pour CMS...
Des nombres à 4 chiffres, les 3 1er indiquent le sprite et le dernier le type de case : sol, mur, bouton, évenement, poussoir, no combat, combat forcé, etc...

Si t'as de là gestions de liste, tous ces fonctions passeront a la même vitesse que du C (voir plus) grace à GT-Basic

bah d'ici 2050 il faudra bien qu'il trouve autre chose

La gestion de liste y'a déjà moyen de lui donner un petit coup de pouce