RSC couleurs en GFA - Page 1

J'ouvre un nouveau sujet ici pour ne pas polluer l'autre Topic !

Playmobil (./28) :
Merci Rajah !

Bha mon code sans tes conseils et sans le décortiquement de tes sources, il en serait pas ou il en serait !

Pour le moment je suis bloqué sur la gestion des RSC avec icônes couleurs... Je sait les charger, les afficher, mais certaines instructions comme :

CHAR{{OB_SPEC(adr%(arbre&),objet&)}}=texte$+chr$(0)

me font planter le programme !


J'ai cerné le problème, c'est que mon adresse d'arbre change selon que je soit au début de mes initialisations (juste après avoir chargé le RSC) ou plus loin dans le programme... (l'adresse change bizareement de quelques octets vers le haut ! )

Bref, encore une erreur de ma part, j'en suis sur, mais où ?


Sinon, quel est le rapport entre Mintnet/Gluestick/Sting ???

Je suis une brêle en réseau, j'ai juste suivi le tuto de ProTos pour faire la passerelle entre Windows et Aranym, et ça a fonctionné du premier coup...


Ca me fait penser à ouvrir un nouveau topic d'ailleur ! NetSurf = OK, Highwire, Cab, Wensuite = NADA !

Rajah (./31) :
CHAR{{OB_SPEC(adr%(arbre&),objet&)}}=texte$+chr$(0)

Déjà, tu peux virer le chr$(0), c'est en trop. Quand on fait un CHAR{}, un nullbyte est toujours écrit à la fin implicitement. Et secondo, la longueur du texte$ ne doit pas dépasser ce que tu as mis dans le RSC. Si l'adr%(arbre&) change, effectivement, ça va planter (OB_SPEC ne pointera pas sur une structure TEDINFO). Attention aussi à la nature de l'objet : vu comme ça, il ne doit pas être un STRING, mais un TEXT, FTEXT, BOXTEXT ou FBOXTEXT.

Gluestick est à lancer dans MiNT si tu veux émuler la couche STinG sous MiNTNet. NetSurf utilise d'emblée MiNTNet. Pour CAB et HighWire, il faut utiliser le module adéquat pour la couche TCP/IP. Pareil pour Wen.Suite dont la couche est propriétaire.

Comme je n'ai jamais réussis à ouvrir un RSC contenant des icônes couleurs avec un simple RSRC_LOAD, j'ai donc décortiqué ce que FaceValue faisait, car en l'utilisant, il ouvre sans sourciller un RSC couleurs...

FUNCTION get_rsc $F% RETURN RSRC_LOAD(rsc_path_name$) ENDFUNC

c'est pourtant un simple RSRC_LOAD ! Il faut dire aussi qu'il y a un INLINE a merger donc celà vient surement de là ?

A quoi correspond le $F% ?


de même, j'ai un mal de chien à récupérer dans mon code l'adresse d'un arbre avec RSRC_GADDR, il me retourne toujours 0 !!! Je regarde le code de FaceValue et il fait appel a xrsrc_gaddr :
FUNCTION xrsrc_gaddr(type&,tree&) $F% LOCAL tree% ~RSRC_GADDR(type&,tree&,tree%) RETURN tree% ENDFUNC

IDEM, un simple RSRC_GADDR précédé de $F% !

Moi être perdu !


Pour le moment j'utilise donc un mix de code FaceValue (pour charger le RSC couleurs) + code GFAFLY4.9 (pour utiliser les objets étendus) et tout fonctionne jusqu'a ce que je veux changer un TEXT avec le fameux CHAR{{OB_SPEC(adr%(arbre&),objet&)}}=texte$

celà ne vient pas de la longueur, c'est bien un objet TEXT et pas STRING...

Je peux le changer sans faire planter le programme JUSTE après les initialisations de FaceValue, mais une fois passé les initialisations de GFAFLY, plus possible, plantage direct ! Et ce que ce soit que j'utilise le pointeur que je récupère avec un RSRC_GADDR, ou en utilisant le pointeur sauvegardé juste après les inittialisations de FaceValue...

Pourtant l'affichage fonctionne, le changement d'état de boutons, hide et autre changement d'état fonctionne sans broncher...

$F% c'est pour retourner un entier et non un float, le GFA fait des casts en pagaille, ça évite d'utiliser un flottant dans la variable retournée. N'utilise que le $F%, car les $F& $F! $F| ne sont pas des commandes de compilation reconnues.

Les librairies, faut les maîtriser. FaceValue et autres comme GFAFLY : je connais pas, et ne veut pas prendre le temps pour les connaître. En général, elles comportent leurs propres erreurs (BIG est bourée de cancrelats). Les utiliser, c'est aussi prendre le risque d'une incompatibilité avec les AES plus récents et les résolutions étendues. Déjà que l'affichage est moche pour certaines (comme windom).
Elles sont censées faciliter la vie, mais ça rend paresseux et surtout ça bloque le débogage : on ne sait pas si un bug vient de son propre code ou de la librairie.

Je suis entièrement d'accord avec toi Rajah, mais si j'utilise les routines de FaceValue, c'est juste parce que je n'arrive pas à charger un RSC couleurs par moi même... J'ai une belle erreur du GFABasic qui me dit que la taille ne correspond pas au fichier RSC !

As-tu déjà travaillé avec des RSC comprenant ne serait-ce qu'un seul icône couleur ? Malgrès mes recherches je n'ai trouvé aucun article qui parle de ce sujet... Hormis que des routines en C et en Omikron sont fournit avec Interface, mais malheureusement tout les Interface glané sur le Net, justement il manque ses routines...

Je sait maintenant, en ayant vu que FaceValue les chargent avec un simple RSRC_LOAD, que celà se passe en amont, lors des initialisations programme, mais où ? Je met ma main a couper qu'il utilise du code machine contenu dans le INLINE pour initialiser un truc, mais ça dépasse mes compétences là !

Quioqu'il en soit, si j'utilise uniquement les routines FaceValue, je ne rencontre aucuns bug dans mon programme, idem si je n'utilise que que les routines GFAFLY, mais donc j'ai un cruel dilemme ! Soit j'utilise de joli RSC couleurs, soit j'utilise les objets USERDEF, mais pas les 2 ! J'aimerai pourtant tellement et aussi comprendre !

Il n'y a pas besoin de librairie en plus pour gérer les icônes couleurs : leur affichage ne dépend que de l'OS et l'AES (version >= 3.99). En dessous, tu as un Atari ST/TT/STE avec peu de RAM. La couleur est consommatrice de RAM, donc peu d'intérêt sur ces machines.

De plus, il est préférable de faire les icônes couleurs avec les 16 premières couleurs. Si tu en fais avec 256c, il faudra te soucier de la palette système (Atari ? NVDI ? autre ?), en général, on préconise celle NVDI, et on la précise dans les fichiers de configuration de l'OS employé : colors.cpx ou fvdi.sys ou xaaes.cnf.

Attention aussi au format de l'icône couleur, il y en a plusieurs que tu peux choisir dans l'éditeur de RSC.
Les icônes couleurs sont fournies avec plusieurs bitplanes, que tu gères (ou pas) : 1, 2, 4, 8 bitplanes, avec leur masque (ou pas).

Les icônes couleurs, c'est joli, mais ça bouffe en mémoire et en affichage ; cela ne doit pas se faire aux dépends des fonctionnalités du programme. Si c'est juste pour faire le kakou, pas trop la peine. Je te conseille de faire 2 versions du RSC, une avec icônes N&B, l'autre avec icônes couleurs. L'utilisateur pourra choisir, selon son AES. (Voir dans le Joé HTML Editor).

Si le RSC dépasse les 64 Ko (les graphes, ça bouffe), la fonction pour déterminer les adresses des trees sera perturbée. Il faut alors utiliser un overlay XRSRCLOADMACHIN.OVL pour palier ça (Voir dans le Tramiel Quizz).

Merci pour ses explications, me reste plus qu'a plancher dessus encore et encore !

Pourtant je suis soit au choix sous Tos4.04 ou EmuTos... C'est là que je pige pas l'erreur lors du chargement du RSC !

Bref, je vais de ce pas prendre une aspirine et décortiquer une fois de plus Joe... Et aussi en profiter pour jeter un oeuil a Tramiel Quizz, bien que mon RSC ne fait pas encore 64ko !

Merci encore une fois Rajah !


Edit : Haaa, une autre question que j'avais oublié de poser :

Icônes couleurs, c'est bien, mais en faite j'en ai besoin de 8 seulement dans mon RSC, et environ autant mais plus en habillement, donc une simple image... Malheureusement, ni Interface, ni Ressource Master ne semble connaitre ceci ! Ca diviserait pas mal le poid du RSC, vu qu'il n'y a pas de Mask pour les images... C'est possible ça ? USERDEF je suppose, mais pareil je vois pas comment mettre ça en place !


Edit 2 : Pfffff ! Sous Tos 4.04, un simple RSRC_LOAD fonctionne effectivement, mais pas sous Emutos, vu que c'est basé sur un Tos 2.06... Ce qui est bien avec le code de FaceValue, c'est que ça fonctionne sur STE avec un TOS 2.06 (j'ai pas osé testé sous tos 1.62 ! ) et donc sous Emutos aussi... Bon je continue à explorer les méandres du GEM en GFA !

La prochaine fois j'attendrais 4 mois avant de poser une question, j'ai tellement honte de moi sur ce coup là !

1 mois que je cherchait, et la solution je l'avais devant le nez... Soit j'ai alzeihmer qui commence, soit j'ai vraiment tout perdu de mes bases Atari !

Tu peux utiliser les icônes couleurs pour stocker des images couleurs, si elle sont assez petites. Suffit de pas créer la version "sélectionnée/animée". Pour le masque, c'est en général 1 bitplane, donc ça prend peau de zob. C'est en effet pratique, si tu veux les dessiner avec objc_draw au lieu de vro_cpyfm.
Un truc, tu vas avoir des difficultés à obtenir les bonnes couleurs de ton icône-image 256c en TC, ça dépend de l'AES, je fais la conversion moi-même dans les images de Sylféline dans la fenêtre info de Rosemary's Racoon Strip Game.

Le mieux étant de gérer tes images dans des fichiers séparés, chargés à part ou placées en INLINE (voir DEDITOR.PRG, l'éditeur de donjon de DGEM), et affichés en vro_cpyfm.

Merci de me décourager si près du but !

Les icônes 256col, j'y ai pensé, mais je galère tellement que je croit en rester au bon vieux 16col !

Bon j'ai fait un test avec icônes 256 couleurs, et sa passe comme un gant !

Juste 2 screens avant d'aller me coucher...

1 sous Mint+Xaees et 1 sous Magic 6.20... Les 2 sous Tos 4.04 :

MinT+XaaeS



Magic 6.20



Vous voyez la différence ?

La barre de menu apparait sous Xaaes, mais pas sous Magic...
Un truc que l'on voit pas sur le screen, j'ai parfois des problèmes de REDRAW sur la barre de menu en fenêtre uniquement sous MinT (mais pas tout le temps... )

Sous Magic il me dit que j'ai un 68020 et Tos 4.00... Sous Mint, il me dit 68040 et Tos 4.04 !

Je suis sur qu'il y'en a d'autre !



Bon en tout cas merci Rajah de me mettre toujours sur la voie, et de ne jamais me donner une solution clé en main, et de me laisser galérer comme un cochon pour que j'y arrive de moi même !



EDIT : J'ai abandonné les routines FaceValue, Rajah ! Un truc en moins !

Comme dirait Mémé Ciredutemps, ça rentre mieux dans la caboche quand le coup de marteau est plus dur.

XaAES a envie d'utiliser les gradients de teinte dans la barre de menu, d'où les problèmes de redessins des titres... J'ai pas trouvé d'autre solution que redessiner totalement la barre (cf Joé et ses modules, Iphigénie, Meg...). Depuis, je préfère utiliser le menu classique et ne pas en faire en fenêtre (il faudrait utiliser les fonctions spéciales pour des derniers AES, genre wind_set avec WF_MENU).

Pour la ligne pas dessinée sous MagiC, faut retoucher manuellement la hauteur d'un des objets de l'arbre menu (voir encore dans mes sources, au niveau de l'init RSC après son LOAD).

Playmobil (./5) :


Edit 2 : Pfffff ! Sous Tos 4.04, un simple RSRC_LOAD fonctionne effectivement, mais pas sous Emutos, vu que c'est basé sur un Tos 2.06... Ce qui est bien avec le code de FaceValue, c'est que ça fonctionne sur STE avec un TOS 2.06 (j'ai pas osé testé sous tos 1.62 ! ) et donc sous Emutos aussi... Bon je continue à explorer les méandres du GEM en GFA !

Emutos supporte les icones couleurs que depuis quelques mois seulement, donc mets à jours cela vaut le coups.

Olivier

Effectivement sous Emutos 0.9.0 ça fonctionne aussi !