Forum Graph100

les routines memzones de 2072

c'est pô extremement difficile à utilisé, je l'utilise dans mon craceur (la version instable pas distribuée...)

Dans ce cas tu me conseille quoi ? fichiers externes ?

arf c aussi ce que je fais dans chess...utiliser la lib com un barbare

Bon ben je vais faire ça... je peux mettre combien d'octets de fichier basic avant que ça bug carrément ?

plus qu'il n'en faut
Mais pour écrire ou lire dans une zone, il faut mieux utiliser ses fonctions read_mem_zone et write_mem_zone plutot que d'utiliser directement un pointeur far vers le contenu 

Lol doucement... 
DB-lib est plus complet et permet beaucoup + de choses que Drawlib, qui ne contient en fait qu'une seule fonction. Drawlib c'est bien quand tu as besoin d'afficher des sprites de dimensions assez variables, avec un masque et en gérant le clipping, ca permet de rendre la prog plus confortable... Mais bien sûr le confort a un prix, tu perds un peu en performance si jamais tu n'exploites pas drawlib à fond...
Je n'ai pas fait de tests de vitesse mais il ne me semble pas que les pertes sont énormes
Au passage, la version 1.4 plus complète devrait arriver bientôt (j'y travaille dessus maintenant): les sprites codés pour la 1.3 ne seront plus valables, mais ca vaudra le coup normalement

j'espere que tu fera un convertisseur sprite de la version 1.3 -> sprite de la version 1.4, je pense pas que je vais attendre la nouvelle version pour m'y mettre 

ben c'est pas une mauvaise idée, sauf que lire un sprite sous forme de texte "unsigned char bidule = { .. , .. , ...... };" c'est pas marrant  :? (mais pas infaisable, d'accord)
Mais bon y'a moyen de devoir juste mettre sprite maker en mode 1.4, puis de regénérer les codes et de copier-coller... 
A la limite tu peux meme t'arranger pour que le prog réécrive ton ficher source qui contient le code des sprites (a condition qu'il n'y ait que ca dedans bien sur) 

Le masque apporte une grosse différence normalement (vu que ca fait ~66% de sollicitation de la mémoire en plus  :? )

Ce serait pas mal de pouvoir générer directement le code d'un tableau de sprites.

X-th me l'avait déjà suggéré, en effet... je vais faire ça 

Oui, de toute facon si tes sprites 16*16 doivent servir pour tes maps, je t'aurais dit tout de suite de ne surtout pas utiliser drawlib pour ca

et puis c pas tres compliqué de modifier d16clip pour qu'il gere les far ; ya que quatres lignes a modifier :

// Affiche un sprite 16*16 pour mode D3 ou DB
// avec OR avec clipping, au buffer voulu.
// Fonction de DB-lib.h par Swifter - SWF Prod 2004
void d16clip_or(int x,int y,void far* spr,unsigned int segm)
{
  asm{
       push ds
       mov cx,x      // On met x dans CX.
       mov bx,cx     // Et on le met aussi dans BX.
       lds si,spr    // On place l'adresse du sprite dans SI.
       mov di,0x3FE  // On place l'offset vidéo sur le dernier mot, en haut a gauche de l'ecran.
.........
// a la fin
       pop ds

lire dans une memzone avec un pointeur far ça n'est pas grave, tu risque juste de lire des conneries si tu te plante mais écrire directement dedans c'est vraiment dangereux, la fonction write_mem_zone est BIEN PLUS RAPIDE que d'utiliser les pointeur far alors vous n'avez aucune raison de ne pas l'utiliser !

bien plus rapide qu'un rep movsw? 

Je sais bien, et la fonction que j'utilise pour écrire dans les zones utilise également le rep movsw...

pour l'écriture, il vaut mieux utiliser write_mem_zone et repérer les offsets des sprites que tu écris dans la zone.
drawsprite() s'occupe de la lecture, il faut juste que tu arrives à obtenir un pointeur far vers le début de la zone (voir post plus haut), auquel tu rajoutes l'offset du sprite que tu veux afficher

Au fait cette méthode est efficace seulement quand les sprites ne sont pas définis dans l'exe bien sûr, tu dois les placer en fichier externe et les charger dans une zone au début du prog (que tu détruis convenablement à la fin du prog hein  :twisted: )