Forum Graph100

WAOOOOWWW !!!!!!

Bien sure que ça nous intéresse 2072…. (Avec une petite doc quand méme)

Bonne nouvelle Deather.
Ton travail vas être simplifié : ne t’occupe plus des structures
Je ferais une fonction qui enverra tout vers une mem zone.
Ça va m’arranger pour pleins de trucks notamment pour faire un rafraîchissement de la RAM, et en plus ta lib pourra servir pour pleins de progeursG100.

//========== dans ta lib ============

int compress_Huffman (char name_no_compreced_fill [8] , char name_ compreced_fill[8])
{int error ;
………
//compression de “name_no_compreced_fill [8] » vers « name_ compreced_fill [8] » en économisant au maximum la RAM
…..….
return (error) ; //type d’erreur rencontrée
}


int decompres_Huffman (char name_compreced_fill[8], char name_decompreced_fill[8] )
{int error ;
……..
//chercher le fichier spécifié par « name_compreced_fill[8] » dans la mem zone
//le décompresser, tu peut utiliser toute la RAM que tu veut a condition qu’elle soit libérée a la fin de la routine de décompression.
//création de la mem zone spécifié par name_decompressed_fill[8]
//écriture dans cette dernière du tableau décompressé
............
return (error); //type d’erreur rencontrée
}

PS : Si j’arrive a finir ce projet sur G100, j’en aurai peut-être un autre encor plus gros.

oui bien sur que tu peux reprendre mon code
je t'autorise même à l'utiliser à des fins commerciales si t'arrive à le vendre
mouarf

hmmmm, ok, je la met à disposition, mais tu devras te passer de doc... Je ne me souviens plus moi même, donc en lisant le .h tu devrais t'en sortir je pense

http://www.casiocalc.org/?to=fsdisplay. … nes-librar

Ok, merci 2072, je vais étudier tout ça.

Si seulement t'avais sorti ça 2 ans plus tôt 

C'est pas grave Julien : tu peut toujours faire Sonic 2

Salut ,

Bon voila, j’ai presque finit mes routines de base (il m’en reste deux ou trois…), donc maintenant ça vas devenir du lego.

Alors je vais commencer à faire des allocations de mémoires, le problème est combien…

Mes questions sont les suivantes :
-    lorsque on déclare des variables en locale est qu’elles se mettent dans la RAM ou la Pile ? qu’en est il pour les variables statique et automatique ? (j’ai utilisé aucune variable globale)
-    La pile n’est elle pas comprise dans la RAM (Pile + RAM = 64Ko   ou bien RAM seul =64Ko) ?
-    Est il possible d’évaluer l’espace libre dans la RAM lors de l’exécution en faisan :
64Ko - Taille de l’EXE = espace libre = Constante


Si non j’ai eu une idée qui va me simplifier le boulot pour les dessins.
Je ferais un autre EXE (en float pour les cercles, les droites obliques…) du méme genre que Paint.
Ce prog créera des fichiers dans la mem zone, ainsi il sera possible d’exécuter un EXE à partir de l’autre et donc de faire des liens Hiper-texte ou Hiper-graph en utilisant une mem zone (ou zone 12, j’ai vu ça quelque part, je crois) comme Pile (un peu comme en ASM lorsque on appelle un sous prog).
Ma question est la suivante : La zone 12 fait elle parti de mon imagination ou existe elle vraiment ? est elle mieux qu’une mem zone pour faire une pile ? Pourquoi ?

Merci pour vos réponses.

Cèdèrom cèdèrom cèdèrom cèdèrom       

Bon d'accord, c'est désert, on va répondre 
Faut dire que c'est le week-end de la finale de Prologin aussi (mais ça m'excuse pas, c'est vrai).

Bon, la pile est en RAM (je vois pas où elle pourrait être d'autre).

Pour déterminer la quantité de mémoire libre, il y avait une fonction utilisable dont j'ai oublié le nom... Sinon effectivement les allocations de mémoire échouent s'il n'en reste plus assez (mais ça t'oblige à tester toutes tes allocations, ce qui est assez pénible).

La zone 12... Ca me dit quelque chose.
...
*fouille ses sources*
...
*verse une larme nostalgique*
...
Ah, enfin:

#define DEFAULT_ID   12

Donc oui c'est bien les zones de type "12" qu'il vaut mieux utiliser par défaut.

Mais alors ton histoire de "pile" en memzone...  :confus:
Je comprends bien l'idée d'enregistrer les images en memzone, quitte à les charger grâce à un autre programme (je doute que ça soit nécessaire mais bon), mais je vois pas le rapport avec une structure de pile (une "pile" pour moi c'est une structure LIFO, Last In First Out).
Une remarque quand même: si un programme A démarre un programme B, et que B s'exécute jusqu'à la fin, A ne reprend pas le contrôle. Il n'y a jamais qu'un seul programme chargé en mémoire à la fois, donc si tu veux revenir au programme A à la fin de B, tu dois le rappeler explicitement et A devra recommencer au début, pas depuis l'appel de B.
Il y a moyen de s'en tirer (Sonic le fait), mais ça pose des problèmes, notamment à cause d'une certaine perte de mémoire liée aux appels successifs (je n'ai jamais pu déterminer la cause exacte).

Autre chose: on peut se passer sans problème des floats pour dessiner des cercles et des droites obliques.

Ok, merci pour tes infos, je vais investiguer sur cette zone 12 maintenant que je sais qu’elle existe.

Attention que "12" ne désigne pas une zone en particulier, mais plutôt un type de zone, tout comme il y a un le numéro 10 pour désigner les programmes basic, un autre numéro pour les matrices etc. Il me semble que le type 12 est un type prévu au départ pour que des applications puissent y placer des données qui leur sont propres et les récupérer (ce qui correspond bien à ce que nous faisons).

En fait ce que je voulait dire ç’est que dans cette mem zone (ou zone 12) je mémorise le nom du fichier appelant (et la ligne pour les fichiers de texte).

Par exemple, on ouvre un fichier de texte A et dans ce fichiers à la ligne N on clic sur un lien hyper-graph B et pour finir dans ce fichier B on clic sur un lien de text C.
Avant chaque voyage entre TEX.EXE et DES.EXE (et oui ç’est le nom d’mes 2) le prog écrira dans la mem zone les informations qui permettent d’exécuter l’autre .EXE en ouvrant le fichier appelant.

OK je comprends mieux... Mais je doute vraiment que tu aies besoin de créer deux programmes pour ça, à mon avis tu peux sans problème te contenter d'un seul. Gérer une pile au sein de ton programme n'a rien de compliqué, ça sera à mon avis bien plus simple que de travailler avec une memzone  (par contre stocker le texte en memzone peut être intéressant si tu crains de manquer de RAM)

Autre chose: on peut se passer sans problème des floats pour dessiner des cercles et des droites obliques.

??? comment ???

Simplement en multipliant tous tes entiers par un coefficient (une puissance de 2 de préférence) pour simuler des nombres décimaux... Pour tracer un cercle par exemple il suffit que tu crées (ou récupères) une table des sinus et cosinus enregistrés dans un format entier (par exemple sur un octet) et que tu utilises ça dans tes calculs, pour finalement rediviser le résultat final par ton coefficient. Comme au final ce sont souvent des résultats entiers qui t'intéressent (comme la position d'un pixel), la perte de précision est sans conséquences

Pourquoi il n’y a plus trop de développement sur la G100 les progeurs HP ou Ti ils en font tout le temps et ils s’arrêtent méme pas pour chier ?
Je trouve ça dommage pour cette pauvre petite G100 abandonnée…

Les programmeurs g100 ne se sont pas renouvelés... et tous les anciens ont d'autres priorités maintenant
Les Casio souffrent aussi du prestige de HP et TI justement, pour lesquels il existe des communautés énormes et bien plus d'outils à la disposition des amateurs, ce qui fait que plus grand monde n'a envie de se lancer dans la prog sur g100... Comme tu le constates toi-même il n'ya a plus grand chose comme soutien pour démarrer 
Au départ c'est une conséquence de la politique de Casio qui n'a pas désiré offrir la possibilité de développer des add-ins; du coup l'évolution des applications Casio a été beaucoup plus lente que sur les autres machines et ce sont principalement des programmeurs déjà assez expérimentés qui ont du s'attaquer à la g100 pour arriver à en tirer quelque chose.
Les autres modèles de Casio (comme la ClassPad) souffrent énormément de ce retard malheureusement; il y a bien un SDK pour la CP, mais toujours très peu de volontaires :?

Wech, mais… :?
Si la zone 12 ne désigne pas une zone en particulier alors elle n’a pas d’adresse physique. Donc pour y accéder à  cette zone  il faut  la déclarer du type 12, ou bien faire un truck du genre non ?

D'abord lire la doc de la lib "memzone" de 2072 (pas la 2.0, la version précédente).
Ensuite passer 12 comme parametre aux fonctions de la lib sans se poser trop de questions 

Le type 12 correspond à un type d'entrée dans la Table d'Allocation de Mémoire, c'est dans cette table que se trouvent les adresses grâce auxquelles on peut délimiter une nouvelle zone du type voulu. La lib le fait pour toi, donc pas de souci 

oui la memzone de type 12 est celle utilisée par les add-ins officiels de casio pour stocker leurs info et de ce fait la consommation des memzones de ce type est affichés dans l'utilisation de la mémoire.

j'ai beaucoup de sprites qui me prennent de la place.

J'aimerai les mettre ailleur mais je vois pas comment faire (j'utilise des pointeurs sur tableau comme le code géneré par sprite maker)

comment je peu faire ?

J'ai presque fini une demos...

En théorie, les pilotes compatibles Windows 2000 marchent sous Windows XP, en tout cas dans la plupart des cas.
Autrement pour ton éditeur, je le testerai dès que j'aurai un moment !

Comment je dois faire pour créer  des fichiers RFI  de sprites comme FONT.RFI sachant que j’ai créer mes sprites avec spritemaker ?
Il faut que je les compile a part et que je mette l’extension .RFI ?
Dans ce cas est que je pourrais utiliser les fonctions d’affichage de sprites de gxlib de la méme façon mais avec les pointeurs far ?
Tu pourait me montrer un petit exemple de code pour l’affichage d’un sprite qui aurait été mis en RAM a partir d’un fichier RFI ?

Si non, je peu pas télécharger RFL de Julien sur son site ou je peu le trouver ?

Merci pour tes indications.

Les sprites que je veux mettre en mem zone n'ont pas tous la méme taille donc il faut que je connaisse leurs taille pour connaître leurs positions.

Dans Sonic t’a fait ça :

uint t = m_largeur*m_hauteur;
search_mem_zone(DEFAULT_ZONE_ID,(uchar*)NAME_ZONE_MAPS,&memz);
m_ptrTabObj  = (uchar far*) MK_FP(memz.b_segment,memz.b_inner_offset);
m_ptrTabText = m_ptrTabObj + t;

Voila comment je le comprends :

La 2nd ligne et la 3em ligne permet d’initialiser le pointeur far « m_ptrTabObj »  sur la mem zone souhaitée

La 4em ligne permet d’initialiser le pointeur far « m_ptrTabText» pour pointer sur une autre donnée qui est après les données de taille « t » pointé par  m_ptrTabObj.

Mais voila, je vois pas où est  la fonction MK_FP, quel #include il faut que je fasse ?
Et comment « t = m_largeur*m_hauteur » permet d’obtenir la taille ed la 1er donnée qui est dans une mem zone, que représentent  m_largeur et m_hauteur ?

Si non pour créer un fichier RFI qui servira a installer les spritre il faut que je les compilent et que je remplace l’extention .c pas .rfi ?

Par ailleur j’ai rendu la vitesse de defilement beaucoup plus rapide et lorsque on appui sur F6 le curseur bouge vers le droite et vers le bas en tenant compte des hypess-liens.

http://www.freazer.com/perso/transferdatavic/


Quand j’aurai fini les curseur et l’ecriture de texte je commencerai peut être a voir le bout du tunnel. En ce moment j’ai l’impression que plus j’en fait, plus il m’en reste a faire et il fait chaud  :boire2:  :rocket: