Image aléatoire - Page 2

microbug >> ben tu effaces tout avec clrscr();, puis tu affiches tout ton level en BASIC, (ça prend un peu de temps), et ensuite tu fais une copy du LCD sur un écran virtuel grace à une fonction en C : memcpy()

void *buffer;
buffer=malloc(3840); //allocation dynamique pour pas encombrer la pile
memcpy(buffer, LCD_MEM, 3840); // copy du l'écran de la calcu

et ensuite tu peux le rappeler quand tu veux grace à

memcpy( LCD_MEM , buffer, 3840);

donc tu peux effacer tout ton écran de RPG puis tout réafficher à chaque fois sans perdre de temps !!!

oki...
bob il faut que tu nous implémente cette fonction là.
Et à la fin du programme, pour libérer les 3840 octet ?

pour liberer les 3840 o ?
il faut utiliser la fonction free();

par exemple pour liberer le buffer de Pima89 il faut faire :

free(buffer);

tout simplement

microbug > je peux pas, il faut faire free() a la fin du prgm sinon la mémoire est perdue, donc pour vertel c impossible...

non, tu peux le faire ds n'importe quelle fonction.
Mais remarque si tu en utilises un ou 2, pas besoin d'allouer. Mais pas plus, sinon ça craint un peu. Ensuite :

tu stocke le buffer ds un fichier externe présent ds le TIOS, et à la fin du prog BASIC, tu demande de virer par une fonction. Le fait de le mettre ds un fichier ext permettra de le rappeler à tout moment par du C. Mais faudra assurer pour que les temps de chargement (d'ouverture du fichier externe) soit pas trop long.

Pim > J'ai déjà essayé de calloc-er 2 buffers (j'en ai besoin pour les zooms et les masques), mais ça ralenti trop. Il ne faut pas oublier que vertel est un programme fait pour être appellé plusieurs fois de suite très rapidement. Le fait d'utiliser malloc ou calloc rend le prog inutilisable malheureusement...

Et puis bon... Pour du basic en général on ne s'amuse pas à tout effacer pour tout réafficher, donc les écrans virtuels ne sont pas très utiles...

erf oué ... c'est pas la lbi qui serait lente mais le trop grand nbre de rappel qui ramerait. en tout cas ça aurait été cool les écrans virtuels.

je vois pas pkoi... le basic c trop lent pour avoir reccours à des écrans virtuels..

Il faudrait plutot optimiser le system d'appel pour que vertel puisse prendre plusieurs commandes en une fois. Masi c'est deja implemente non ? Sinon c'est idiot

oui, une fois que la lib est lancée ça roule, mais par exemple pour tracer plein de lignes dans une boucle de type for, ça oblige à entrer/quitter la lib et si y'a des malloc à chaque appel c encore plus lent que la fonction 'line' de base

heureusement que oui

heureusement.

Tu pourrais pas exemple utiliser seq pour crrer une liste des lignes a afficher.
Puis faire un appel a vertel pour ene afficher plein.

ya quand même une différence entre setbyte (même sur plusieurs ocvtets comme bob64 propose) et mempcy:
setbyte met des octets que tu rentres en argument, memcpy copie des octets à partir d'une variable connue.
De plus il y a pas mal d'argument.
Faire une pic aléatoire avec setbyte obligerait à créer une chaine pour mettre en argument dans setbyte, alors qu'avec memcpy, ta chaine est dirrectement créée dans les arguments, avec une variable, un début et un nombre d'octets

Pour memcopy :
tu prend n octet d'un fichier déjas existant, et tu les copis dans un autre fichier à partir du x-ième octet (ette fonction peut être completer par mkvar).
Pour setbyte :
tu remplace le n-ième octet d'un fichier par un valeur de ton choix.

Donc, voilà, Bob64