Forum Graph100

Azor · 12 Jun 2003 15:26:52

Voila, ce que je vais dire pourrait être un tuto, cependant ca m' emballe pas de faire un tuto pour expliquer ceci lol

Bon voila votre problème(comme moi):
Vous avez plus de place en ram, votre programme souffre d' overflow successif, enfin bref c la merde !

Alors l' astuce, c de mettre toutes vos données non-initialisées dans un fichiers basic!

Pour ceci, vous en créer un, ensuite voyez ceci :

{signe} {type} far *memory;

memory=MK_FP(RAM.b_segment,RAM.b_inner_offset);

Lorsque RAM est une structure du type memoryzone ( voir lib de 2072 memzone)

Ceci marche très bien lorsque c' est en langage C, en c++ g pas essayé (autant vous prévenir !)

MK_FP est une macro de dos.h, mais pas besoin d' inclure celui ci, il est inclus dans les libs de 2072 !

Enfin, memory ( dans mon future cas) est un pointeur, il peu etre lu comme un tableau !

Autre chose, si vous voulez par exemple une varialbes de type int, fo savoir que sans short et long ca prend 2 octets !

Enfin, voici un exemple :

unsigned char far *temporaire;
signed int far *baballe;
long far * lol;

void main(void)
{
temporaire = MK_FP(memory.b_segment,memory.b_inner_offset);
baballe= MK_FP(memory.b_segment,memory.b_inner_offset+1);
lol= MK_FP(memory.b_segment,memory.b_inner_offset+1+2);
(...)
*temporaire = 2* fonction(*baballe,*lol);
(...)
exit(0)
}

Voila !
2-3 conseils :
1- Pensez surtout à vérifier qu' il existe, sans ca ca va couiller a mort !
2- Je pense qu' un fichier commun 'EXT_RAM'(ou un autre nom) de 16Ko (ou moins, bien sur) ca pourrait etre utile smile dans certains cas ca résolverai pas mal de pb meme !
3- Attention, ca ne marche que pour les données NON INITIALISEES !!!
4- Bin faites un shéma avec des cases pour voir ou vos données iront smile
5- ATTENTION surtout quand vous créer un fichier mémoire il est possible que l' adresse mémoire de ces pointeurs doivent changer alors remettez les a chaque Création, Effacement et Redimenssionement !!!

Pour ma part, un fichier mémoire (zone 12) nommé 'RAM_XTNS' de 16Ko me conviendrai parfaitement, d' ailleur je crois que la plupart des données non initialisées peuvent largement tenir dans un tel fichier !

Enfin, fo faire gaffe car un pointeur far c 'est pas un pointeur normal !
suffit d' éssaye de mettre un pointeur far a la place d' une chaine de caractere ( par exemple pour une fonction d'affichage de texte graphique) pour voir une erreur apparaitre !

Voila, c 'était mon idée que je voulais partager, espérant que ca va aider certains! Je trouve que cette téchnique est assez évolué pour l' utilisation d' un fichier mémoire, cependant elle permet de lire et écrire dans un beaucoup plus facilement ( a mon gout) qu' avec les fonctions de 2072 , enfin ca ce sont mes gouts lol

Au fait : Il s' agit de l' idée de lark ( enfin je crois vu ce qu il disait a propos de ces cartes), donc c lui qu' il faut remercier !

2072 · 14 Jun 2003 07:11:17

peut-être plus facilement dans certains cas mais surtout moins vite...

Enfin bon pour ce qui est des pointeurs far en fait ce sont des unsigned long, les 16 octets de poid fort contiennent le segment et les 16 octets de poids faible l'offset.

Mais attention l'utilisation des pointeurs far implique des calcules supplémentaires alors c'est souvent plus lent qu'un accès mémoire normale rien que le fait que le segment du pointeur far n'est pas stocké dans un registre ralenti...

Enfin c'est une bonne idée, je pensais le faire pour touche 4.0 sauf que j'imaginais un fichier temporaire (une zone) qui serait créée et supprimée à chaque exécution...

Azor · 14 Jun 2003 07:38:05

bin justement, est-ce qu' un pointeur far va moins vite que tes fonction de lecture et d' écriture, fodrai voir !
cependant je préfere cette méthode car je trouve que c la plus simple pour lire un fichier basic uniquement en octet par exemple!

Et puis ya -t-il moyen de modifier un pointeur normal pour lire les fichiers zone mémoire? je pense pas trop, mais bon!

Tes fonction d' autres part, semblent utiliser aussi des pointeurs far.
Pê qu' il faudrai faire un calcul de vitesse genre ca:
1- on écrit une valeur dans l' offset X d'une zonemem
2- on passe a l' octet suivant
3- on va a la ligne 1 jusqu' a avoir fini le fichier

Et si c est trop rapide(ca le sera je pense), on recommence ceci suffisemment de fois jusqu' a obtenir un temps en secondes !

Pour ce faire on utilserai un char far *testzonemem; pointant sur le debut de la zone et ta fonction !

PS : Trouvant la méthode du pointeur far plus pratique et - lourd, suis-je autorisée a faire une version lite pour moi-meme (tu sera quand meme dans les crédits de ma futur création car elle est ENTIEREMENT basée sur un fichiers zone mémoire ) de tes libs avec seulement ces fonctions :
1- créer,redimensionner, supprimer une zone mémoire
2- effacer ( mettre des 0) le contenu d'une zone mémoire
?
parce que ta lib est quand meme lourde apres compilation(3ko je crois), alors que je ne me sert pas de toute les fonctions sad car je me sert maintenant que des pointeurs far !

2072 · 14 Jun 2003 07:47:20

non mes fontion d'écriture et de lecteur sont infiniment plus rapide que les pointeur far, j'utilise le préfix rep assembleur et je lis/copie mot par mot dans la mémoire... on peut pas faire plus rapide.

(cela ne compte pas si tu lis octet par octet en utilisant mes fonctions car la ça n'ira pas plus vite)

Toute les fonctions sont interdépendantes dans memzones tu ne peux rien enlever... regarde les sources, les fonctions de lecture et d'ériture ne font que quelques lignes...

Je n'utilise les pointeurs far que pour modifier la MAT ou d'autre petites éditions, tout les gros mouvements de mémoire sont optimisé à fond.

Azor · 14 Jun 2003 10:55:45

non mes fontion d'écriture et de lecteur sont infiniment plus rapide que les pointeur far, j'utilise le préfix rep assembleur et je lis/copie mot par mot dans la mémoire... on peut pas faire plus rapide.
>C clair qu' avec rep on ne peut faire + rapide!

(cela ne compte pas si tu lis octet par octet en utilisant mes fonctions car la ça n'ira pas plus vite)
> vi, la c sur !

Toute les fonctions sont interdépendantes dans memzones tu ne peux rien enlever... regarde les sources, les fonctions de lecture et d'ériture ne font que quelques lignes...
> g vu ca !

Je n'utilise les pointeurs far que pour modifier la MAT ou d'autre petites éditions, tout les gros mouvements de mémoire sont optimisé à fond.
> ouais c vrai !

Cependant la taille que ces fonctions prennent risque de m' handicaper sad enfin en utilisant un system de zone mémoire pour "rajouter" de la RAM je devrai y arriver quand meme !

dada66 · 14 Jun 2003 12:04:11

moi je ne me sers pas des fonctions read et write de 2072 dans GComm uniquement, car un appel de fonction fait perdre du tps de transfert. Je mémorise le segment et l'offset puis j'y accede en asm avec es:[si], par exemple. (X-thunder28, tu comprendras certainement pourkoi dans les fonctions receive et send ya 'segment' et 'offset' comme paramètres).
Sinon ton idée X-thunder28 est pas mal, ca permet d'accéder assez facilement à un octet. Pour faire une affectation sur plusieurs octets, je pense que les méthodes read et write de 2072 seront plus rapide.
Je pense que pour stocker une map ca peut être très pratique.
Mnt reste à voir si on décide de créer un fichier en zone 1 (basic) ou zone 12 commun à tout le monde qui reste dans la caltos tout le temps ou que chaque développeur le créer et le détruit à chaque lancement/fermeture du prog.
C un choix.

2072 · 14 Jun 2003 15:41:19

oui c'est comme je l'ai dit pour copier octet par octet ça ne vaut pas le coup mais dès qu'il s'agit de plusieurs octets ça change tout... mais bon si j'ai créer la structure "memzone" c'est bien pour ça, je n'oblige personne à utiliser mes fonctions de lectures/écriture.

Puis pour la taille c'est sûr que y'a des fonctions pas simples du tout quand même, donc ça n'est pas exagéré vu la compléxité des tâches à effectuer mais ce qui prend le plus de place c'est justement l'utilisation des pointeurs far qui prennent chacun 4 octets et qui oblige le compilateur à faire plein de calcules à chaque affectation...

Azor · 15 Jun 2003 04:55:02

Pour moi j' utilise la zone 12 sauf parfois j' utilise la zone 1 pour permettre l' échange facile de données ( par exemple les cartes dans stour)
Dada66 tu devrais fair un format de fichier pour les fichiers basic a ce propos !

dada66 · 15 Jun 2003 08:46:27

comprend pas ? Koi comme format et pour qui ?

mastermage · 15 Jun 2003 14:37:41

pourquoi un format si c'est juste un tampon memoire ??

C@siomax · 16 Jun 2003 07:58:07

chais pas, pê pour être réutilisé par d'autres appz après ?

Azor · 16 Jun 2003 09:11:41

Non je parlais de format de fichier sur PC/MAC pour pouvoir échanger des données plus facilement car FXI V3 pro ( Casioworld si tu le veu pour ton site, tu me le di et je le metterai sur mon ftp, il est vraiment bien le pb étant que le format de fichier est fxd bien que ca lit les fxi soit un peu chi*nt !) ca bugge parfois !

Et puis comme ca ton Flash100 sera presque complet comme ca wink

dada66 · 16 Jun 2003 12:18:21

ah oki......
théoriquement c prévu que Flash100 puisse recevoir des fichiers BASIC, picture, ..., mais seulement avec GComm. De plus je ne sais pas encore comment je vais intégrer tout ca !!!

Azor · 16 Jun 2003 12:20:36

bin tu fais des format de fichiers et tu recopie betement le contenu recu par Flash100 !

C@siomax · 17 Jun 2003 02:32:35

bin tu fais des format de fichiers

...des extensions :mrgreen: lol

L@rk · 19 Jun 2003 04:21:34

J'utilise en effet cette technique pour loader mes maps dans KarioKart, mais elle est beaucoup moins poussée que celle qu'explique X-Thunder.
En fait, déja je n'utilise pas les libs de 2072 (mais je vais my mettre ;-) ) donc il faut créer le fichier manuellement avant de lancer le jeu.
Ensuite, g codé une routine que cherche le fichier basic nécessaire (MKMAP, size = 10 1024), et copie la MAP dedans, à partir du fichier .map présent dans la flash.
Et ensuite, je me sert de cette zone mémoire comme un tableau, avec des pointeurs indexés ;-)

2072 · 19 Jun 2003 14:07:57

Oui sauf que ma lib va ajouter ~4 kilos à ton programme or tu as des problèmes de taille je crois...

Peut Être que je pourrais faire un programmes tout simple par ligne de commande pour créer une zone d'un certains type et d'une certaine taille...

Ça interresserait des gens ?

Azor · 20 Jun 2003 08:09:10

non, pas besoin, c déjà inclus dans mon future projet!!!
Mais si tu veu le faire, te gene pas ! wink
(hein casiomax wink )

Forum Graph100

Annonce

#1 12 Jun 2003 15:26:52

Petite technique qui m' a été inspiré par lark !

#2 14 Jun 2003 07:11:17

Re: Petite technique qui m' a été inspiré par lark !

#3 14 Jun 2003 07:38:05

Re: Petite technique qui m' a été inspiré par lark !

#4 14 Jun 2003 07:47:20

Re: Petite technique qui m' a été inspiré par lark !

#5 14 Jun 2003 10:55:45

Re: Petite technique qui m' a été inspiré par lark !

#6 14 Jun 2003 12:04:11

Re: Petite technique qui m' a été inspiré par lark !

#7 14 Jun 2003 15:41:19

Re: Petite technique qui m' a été inspiré par lark !

#8 15 Jun 2003 04:55:02

Re: Petite technique qui m' a été inspiré par lark !

#9 15 Jun 2003 08:46:27

Re: Petite technique qui m' a été inspiré par lark !

#10 15 Jun 2003 14:37:41

Re: Petite technique qui m' a été inspiré par lark !

#11 16 Jun 2003 07:58:07

Re: Petite technique qui m' a été inspiré par lark !

#12 16 Jun 2003 09:11:41

Re: Petite technique qui m' a été inspiré par lark !

#13 16 Jun 2003 12:18:21

Re: Petite technique qui m' a été inspiré par lark !

#14 16 Jun 2003 12:20:36

Re: Petite technique qui m' a été inspiré par lark !

#15 17 Jun 2003 02:32:35

Re: Petite technique qui m' a été inspiré par lark !

#16 19 Jun 2003 04:21:34

Re: Petite technique qui m' a été inspiré par lark !

#17 19 Jun 2003 14:07:57

Re: Petite technique qui m' a été inspiré par lark !

#18 20 Jun 2003 08:09:10

Re: Petite technique qui m' a été inspiré par lark !

Pied de page des forums