Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Par contre , toto me fait remarquer que sur l'opérateur << , le décalage est indiqué par l"opérande de droite , donc je corrige effectivement mon code :
ld A,L ; (1 << (var & 7))) and 7
srl H ;var>>3 rr L srl H rr L srl H rr L
ld BC,_bitvars ;_bitVars[] add HL,BC ld C,(HL)
or A
ld B,A ld A,1
jr z,mul_done
.loop_mul add A djnz loop_mul
.mul_done
and C ;&
or A ;? 1 : 0 jr z,null_val
ld HL,1 ret
.null_val ld HL,0 ret
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
merci fano !
Sinon, ca y est, les opcodes s'exécutent -> y'a plus qu'à les écrire tous ou presque et prévoir l'affichage (texte, costumes, etc.)
par contre, y'en a un qui est un peu particulier...o5_stringOps il alloue des strings pour le futur affichage des textes... Du coup, j'aurai besoin de deux fonctions :
à partir d'un morceau de mémoire donné j'ai fait une fonction qui alloue la ressource (genre calloc())... par contre, ce qui est plus embattant c'est qu'il va falloir quelques fois désalloué des espaces de mémoire et donc prévoir une gestion intelligente pour reconnecter les morceaux qu'en on aura plus de place mémoire dispo !!! (et une fonction qui réordonne et concatène tout cela (avec move etc...) )
je vous mets les morceaux de code à traduire (plus le calloc() et free() ) :
j'ai supprimé les trucs inutiles
Code :
;;byte *ResourceManager::createResource(int type, int idx, uint32 size) { ;; ;; nukeResource(type, idx); ;; ;; void *ptr = calloc(size + sizeof(MemBlkHeader) + SAFETY_AREA, 1); ;; if (ptr == NULL) { cela veut dire qu'on a plus de place mémoire dispo c'est là qu'il faudrait tenter le concat pour voir si on libère de la place !!! ;; } ;; ;; _allocatedSize += size; ;; ;; address[type][idx] = (byte *)ptr; ;; ((MemBlkHeader *)ptr)->size = size; ;; return (byte *)ptr + sizeof(MemBlkHeader); /* skip header */ ;;} ;;
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Megachur a écrit :
sinon pour l'utilitaire découpe fichier, ça intéresse quelqu'un (fano ?) également ?
Pas de souci, comme je t'ai dit plus haut , si tu peux poster quelques .LEC histoire que je commence à regarder ça car avec un fichier cible sous les yeux, ça me semblera plus concret.
Au fait , pour tes allocs , c'est quoi la durée de vie des strings (si c'est la salle , pourquoi ne pas utliser un tas qu'on réinitialise à chaque salle ?)
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
fano a écrit :
Megachur a écrit :
sinon pour l'utilitaire découpe fichier, ça intéresse quelqu'un (fano ?) également ?
Pas de souci, comme je t'ai dit plus haut , si tu peux poster quelques .LEC histoire que je commence à regarder ça car avec un fichier cible sous les yeux, ça me semblera plus concret.
Au fait , pour tes allocs , c'est quoi la durée de vie des strings (si c'est la salle , pourquoi ne pas utliser un tas qu'on réinitialise à chaque salle ?)
euh... je n'ai pas encore vu cela...mais c'est une idée... au moins pour la fonction de concat !
pour les sources de fichiers, je te fais un mp avec un lien !
merci de ton aide -> je me sens bcp moins seul d'un coup
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Pas de souci , ce projet m'interesse beaucoup alors si je peux apporter ma pierre à l'édifice
Megachur a écrit :
euh... je n'ai pas encore vu cela...mais c'est une idée... au moins pour la fonction de concat !
Je pensais que ça serait plus simple car avec le système d'alloc que tu semble vouloir , ça suppose de travailler avec des références et d'avoir un ramasse miette , ce qui est assez lourd à mettre en place et lent.
Sinon tu as la définition du type custom MemBlkHeader et le type de address[][] ?
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
dans le code ensuite cp type1 jr nz,pas_type1 ld ix,flags_type_1 jr ok_type
pas_type1 etc.. ok_type ; ix = ptr on flag type tab
si y'a beaucoup de type : flags_type_index dw flags_type_1, flags_type_2, etc...
et un code équivalent à add a,a ; si a <&80 ld h,0 ld l,a ld bc,flags_type_index add hl,bc ld a,(hl) inc hl db &dd:ld h,(hl) ; je sais pas si c'est bon ça...pour initialiser ix db &dd:ld l,a
puis sinon si on imagine qu'on a (a = idx) ; on commence à zero ld bc,length_flags find_flags_type_idx cp (ix+idx) jr z,find_idx add ix,bc jr z,find_flags_type_idx
find_idx
une autre idée plus optimisée pour gérer ces tableaux à simple ou double entrée de la façon la plus optimisée possible (soit en gain de place mémoire, soit en code, soit en durée d'exécution, soit ? ) ???
Glups, il te faudrait un 80386 oui ! Je suis une turne en asm, surtout sur un processeur 8/16 bits, mais je me rends bien compte de l'ampleur de la tâche. Je crois savoir que l'utilisation des registres d'index est lente mais puissante sur le Z80. Ce n'est pas un jeu d'arcade donc je suppose que c'est bon. Argh, je m'en veux d'être si faible !
Un peu HS mais je te réponds quand même Hermol. Impossible de rattraper ces lacunes. Je sais faire une routine potable de sprite, de scroll sur le CPC en Z80, mais pas tout un jeu. J'ai trop été habitué aux langages évolués et à des processeurs 16/32, même si je m'amusais à un moment avec la limite des segments 64 ko du mode réel sur PC. Je mixais Pascal et ASM intel, ou C et ASM... Donc je "pense" trop langages évolués et à leurs facilités (struct, fonctions, tableaux à n dimensions etc...) pour pouvoir revenir à de l'asm intégral. Surtout pour un jeu comme Monkey.
Pour te dire, quand Longshot m'a montré comment faire une rupture, j'ai failli mourir !
Et puis je suis trop vieux !
Sinon j'ai dit une connerie sur IX et IY ? Ou c'était une façon de me dire de ne pas intervenir sur ce fil si je peux pas aider (chose que je peux comprendre) ?
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Xifos a écrit :
Et puis je suis trop vieux !
Sinon j'ai dit une connerie sur IX et IY ? Ou c'était une façon de me dire de ne pas intervenir sur ce fil si je peux pas aider (chose que je peux comprendre) ?
mais non !!! on est jamais trop vieux pour s'éclater !
sinon oui, ix peut être utile pour se balader facilement dans une structure...
ld iy,vm_slot on se positionne au bonne endroit avec des add iy,bc ou bc = ScriptSlot_length par exemple puis directement ld a,(iy+ScriptSlot_didexec) ou ld (iy+ScriptSlot_cycle),&00
mais ce que je cherche à optimiser c'est les accès au tableau à double entrée pour éviter les boucles de positionnement au bon endroit...
Bon sinon le code avance...doucement mais surement -> j'en suis au script 145 qui lance l'affichage de la montagne -> on arrive bientôt au premier texte !!! va falloir que j'écrive quelques routines d'affichage des graphismes et textes maintenant !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 31 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
ou presque et prévoir l'affichage (texte, costumes, etc.) 
