PControl beta 3 - Page 1

PControl est un petit outil (4 ko) qui permet de configurer graphiquement les flags et les variables globales de PedroM.

On peut faire basculer les 4 flags et modifier le répertoire 'Home', 'Temp', l'apd, et définir un script à exécuter au démarrage.

A noter une légère limitation de certains ROM calls de PedroM par rapport à AMS (SymFindPrev/Next) et un léger bug non fatal (SymFindPrev) qui rendent le comportement un peu moins aisé que ce que je voudrais lorsqu'on parcours la liste des répertoires, mais rien de grave, ni même peut-être de visible pour certains. Au pire, pour les courageux qui voudraient recompiler PedroM avec des versions correctes de ces ROM calls, j'ai proposé des patches qui marchent ( topics/108701-question-sur-les-repertoires-de-pedrom-et-autres-questions-comme-dhab )

Le programme a cette particularité qu'il est exécuté en flash, son loader seul résidant en RAM, ce qui fait que le programme ne consomme que 270 octets au run-time.
Il y a plus d'infos sur mon blog ( blogs/blog.php?id=400 pour ceux qui n'affichent pas les signatures).

Téléchargement ici : http://www.mirari.fr/n57v

J'attends votre feedback intense et fourni #illusions#

Quelques screens quand même, pour vous donner une idée :

Bah, comme dit sur ton blog, c'est du bon boulot !

Sorry this version of pcontrol can be used only with PedroM 0.81

Voilà pourquoi je pouvais pas tester (Si tu te demandais pourquoi j'ai pas fait de réponse).

Bon ben au moins ça ça marche.
Ceci dit, rien ne t'empêche de modifier ça (première ligne de code de pcontrol.s).
Sinon je peux t'envoyer un PedroM 0.81 patchée pour un essai sur Emu. (edit -> done)

J'aimerais vraiment avoir ton avis pour savoir dans quelle direction continuer. cas ? emulateur de term ? gestion des process ? J'aimerais que tu me dises ce qu'il y a de neuf dans la 0.82 aussi

Daniel -> Merci

Bon alors mon avis critique.

Un utilisateur normal ne va pas comprendre pourquoi tu différencie les flags, des variables. Ce n'est pas la peine de séparer.
Ce serait bien de montrer ce que valent les variables sans entrer dans le menu.
Les temporary args n'ont pas à être configurés : c'est local, et non global.

Sinon, pas mal.

Sinon quoi de neuf sur la 0.82 ? Rien du tout. Juste un build process plus user friendly qui permettra de plugguer plus de codes externes dans l'OS. Et des bugs en moins.
cas ? ==> Non. Pcontrol n'a pas à faire.
Terminal ? ==> Non plus
Gestionnaire de process => Non plus.

Ok, je vais revoir la présentation alors.

Sinon pour ça :

cas ? ==> Non. Pcontrol n'a pas à faire.
Terminal ? ==> Non plus Gestionnaire de process => Non plus.

Je parlais pas de choses à rajouter à pcontrol, mais de nouveau soft à écrire, vu que PControl est pas loin de l'aboutissement pour la 0.81.

Et ton éditeur de texte ? #siffle#

Ah oué
Je l'ai ressorti il y a une semaine pour le dépoussiérer en plus

PpHd (./5) :
Un utilisateur normal ne va pas comprendre pourquoi tu différencie les flags, des variables. Ce n'est pas la peine de séparer.

Modifié.

PpHd (./5) :
Ce serait bien de montrer ce que valent les variables sans entrer dans le menu.

Pas modifié. Le menu est facilement et rapidement modifiable, mais il est pas dynamique (encore que, je peux générer un menu en RAM sans problème à vue de nez, mais j'ai envie de finaliser ce qui est paramétrable avant).

PpHd (./5) :
Les temporary args n'ont pas à être configurés : c'est local, et non global.

Rémouveude.

Dernière question, j'ai rajouté un item pour le path, mais est-ce que l'ordre de recherche de PedroM est alphabétique, ou alors ça suit la liste ?

Ca suit la liste.

Ok. Donc ça fait chier, je dois pouvoir faire choisir l'ordre de la liste

Tiens au fait, je viens de rajouter le support d'un code de sortie dans d0.w. C'est prévu comment sous Unix ? J'ai mis 0 quand tout va bien, 1 pour un manque de RAM (quand je crérai le menu dynamique), 2 quand LibsExec retourne une erreur que je ne peux déterminer (RAM ou pack archive bidouillé).

Ca va ? Je veux dire, il y a des standards très stricts sur ça ?

Non. Pas de standard très strict du tout.

Bon, ben ça sera comme j'ai fait alors, merci ^^

PpHd (./5) :
Ce serait bien de montrer ce que valent les variables sans entrer dans le menu.

J'y repense, et ça fait chier juste pour une chose : je vais devoir créer le menu dans un handle, donc ça va prendre de la RAM, alors que le soft ne consomme que 230 octets pour le moment. Au pire, je peux faire un truc pour ça (plug-in avec fichier de conf? #v4p0r spotted# ).
Sinon, ça va m'obliger à repenser la structure du programme, pour pouvoir trouver toutes les variables avant de charger quoi que ce soit. D'un côté, ça sera un peu plus propre, de l'autre, ça prendra un peu plus de place, mais pourquoi pas.

Bon, ça va chier, je recommence en gardant la même structure de menu. Voici à quoi va ressembler le nouveau :

		.asciz	"AutoArc : %s"
		.asciz	"OffSwitch : %s"
		.asciz	"GetKeySwitch : %s"
		.asciz	"StatusError : %s"
		.asciz	"APD : %04u"
		.asciz	"Autoexec : %s"
		.asciz	"Home : %s"
		.asciz	"Temp : %s"

Ca sera donc chargé dynamiquement, ok.

Je vais faire en sorte que les flèches droite et gauche change directement le status d'un flag ou le répertoire sélectionné. Pour l'apd, on verra, défiler 1 par 1 c'est lourd, ais on verra.

PpHd -> que penses-tu d'un design de ce genre? Je préfère demander avant cette fois Parce que là, c'est une refonte de tout sauf de la gestion du menu ^^

question subsidiaire : le trap 3 pour déréférencer, c'est officiel?

Martial Demolins (./15) :
J'y repense, et ça fait chier juste pour une chose : je vais devoir créer le menu dans un handle, donc ça va prendre de la RAM, alors que le soft ne consomme que 230 octets pour le moment. Au pire, je peux faire un truc pour ça (plug-in avec fichier de conf? #v4p0r spotted# ).

Fait le dans la pile.

Martial Demolins (./16) :
PpHd -> que penses-tu d'un design de ce genre? Je préfère demander avant cette fois Parce que là, c'est une refonte de tout sauf de la gestion du menu ^^

Pas mal. Faudra prévoir le scoll pour les versions ultérieures

Martial Demolins (./16) :
question subsidiaire : le trap 3 pour déréférencer, c'est officiel?

Ca risque pas de changer.

PpHd (./17) :
Fait le dans la pile.

J'ai l'impression qu'il me manque des idées évidentes des fois

PpHd (./17) :
Pas mal. Faudra prévoir le scoll pour les versions ultérieures

Déjà implémenté depuis le début !

PpHd (./17) :
Ca risque pas de changer.

Je m'en doutais remarque.

Au fait, t'es pour la compatibilité on-calc ou pas ?

Perso, oui.

Martial, c'est si important que ça, que le soft ne consomme que 230 octets et pas 1 ko en mémoire ?

Nan, c'est juste pour le fun. Ya de l'archive à gogo, mais pas de RAM. Puis PedroM supporte plusieurs process.

Mais en soi, tu as raison, c'est pas un drame hein

C'est le concours de la plus petite.

C'est pour ça que t'as écrit CF qui tient à peine dans la RAM avoue

Chacun son concours, hein

J'ai jamais compris pourquoi CF prenait autant de RAM que ça... Parce que de la ROM, je comprend, vu tout le contenu. Mais une fois en jeu, qu'est-ce qui peut bien être si gourmand?

Gérer tous les personnages, tous les éléments dynamiques des maps.

Ok. Je pensais pas que ça prenait autant de RAM.

Toutes les maps/tiles/perso sont compressées. Au moment de l'éxécution, faut les décompresser. Et certaines maps sont très lourdes (genre la ville du départ).

D'accord.
Mais les maps, elles sont quoi exactement :
-Une matrice à laquelle est rattachée pour chaque case un sprite?
-Une sorte d'image géante?

> -Une matrice à laquelle est rattachée pour chaque case un sprite?
Une triple matrice (de word, de word, et de byte) + un gros paquet de tiles 16x16 (jusqu'à 560 sur certaines).