Annonces Google
Serveur IRC
Serveur : irc.portlane.se
Canal : #AmigaNG
Activité du Site

Pages vues depuis 25/07/2007 : 25 286 365

  • Nb. de membres 187
  • Nb. d'articles 1 270
  • Nb. de forums 19
  • Nb. de sujets 20
  • Nb. de critiques 24

Top 10  Statistiques

Index du forum »»  Création-Développement »» Développement ralenti de l'AmiDARK Engine

Développement ralenti de l'AmiDARK Engine#1022

7Contributeur(s)
AmiDARKphardfrSharynnElwoodTarzinartblinkCentaurZ
3 Modérateur(s)
K-LElwoodcorto
artblink artblinkicon_post
Sa c'est bon...
AmiDARK AmiDARKicon_post
Bon, le Back buffer fonctionne à 90%
En fait je saisis bien l'image de fond dessous le sprite ... mais quand je la rétabli après la synchro et l'affichage ... elle est 1 fois /2 décalée de 1 pixel vers la gauche ... Faut que je trouve pkoi j'ai ce ch'tit soucis la ...

Par contre le backbuffer ... ça rame .. vu que le backbuffer n'est pas stoqué en mémoire vidéo ... faudrait que je trouve une solution pour qu'il soit en mémoire vidéo mais rien dans l'AllocMem / AllocVec qui dise de façon claire qu'il le fasse ...

Une fois le BackBuffer fixé, je pourrais bosser le reste des commandes liées aux sprites :p

@ +
AmiDARK
artblink artblinkicon_post
C'est koi le plus rapide pour traiter les images, tout faire en mémoire graphique ou calculer en ram et déplacer le traitement en mémoire GFX pour affichage?

J'ai mes prgs qui sont trop lent, et j'essai de trouver des combines pour y remédier
CentaurZ CentaurZicon_post
@AmiDark

Ton backbuffer n'est pas une BitMap standard ? Sinon normalement s'il y a de la place elle est placée en mémoire vidéo.
AmiDARK AmiDARKicon_post
@Artblink :
Bonne question ... faudrat aussi que je fasse des tests pour ...

@CentaurZ :
Non ce n'est pas un bitmap ... je ne veux pas m'encombrer à gérer 50.000 structures ... je fais au moins complêxe...

J'allocationne une zone mémoire ... je fais un glReadPixels ... pour stoquer la partie vidéo dans ce tampon mémoire ..
J'applique ensuite le sprite.
Je rafraichit l'écran (on voit le sprite dessus l'image de fond)
je restaure le tampon mémoire dans la mémoire vidéo avec un glDrawPixels .

Ca s'affiche bien ... mais 1 frame sur 2 ça se décale vers la gauche ...
EDIT : En fait, c'est même pire que ça ... sur 2 frames consécutives ça shift de 1 pixel vers la gauche ... puis de 3 frames ça bouge pas ... et ainsi de suite ...


Message édité par : AmiDARK / 19-03-2011 15:43
CentaurZ CentaurZicon_post
@AmiDark

J'y connais rien à OpenGL mais pour ce que tu veux faire tu gagnerais peut-être à allouer une vraie Bitmap en guise de backbuffer, puis à accéder aux données ARGB en la verrouillant par un p96LockBitMap(). C'est comme si tu allouais un pixel buffer avec AllocVec(), sauf qu'il faut la verrouiller avant pour savoir exactement où se trouvent les données (c'est à dire en principe, en mémoire vidéo). Après, il y a peut-être un risque que ta fonction glDrawPixels n'apprécie pas de lire les données pendant que c'est verrouillé, selon comment c'est implémenté.
Ceci dit, sur les autres plateformes les données sont aussi lues depuis la RAM à priori avec glDrawBuffers ?
AmiDARK AmiDARKicon_post
@CentaurZ :
Non pas besoin de fait toute cela ..
Je que je fais fonctionne très bien ... j'ai seulement un pbe de projection de flottant vers int qui merdouille quelque part ... et les copies résultat se font pas exactement au bon endroit ...
Je vais fixer cela rapidement ;)
artblink artblinkicon_post
Et si tu utiliser la valeur arrondie pour ta donnée a virgule flottante si tu n'arrive pas a isoler l'entier?

Par contre sa m'était déjà arriver se genre d'erreur, mais c'est parceque le point chaud (de contrôle) de mes sprites bougé car j'utilisé le centre du sprite en pourcentage, mais comme les dimensions du sprite était un nombre pair, le milieu évolué entre 2 chiffre le centre d'un objet sur 3 pixel c'est 2, sur 4, sa évolue entre 2 et 3 car 2.5 n'existe pas


XXX : le 2ème X est le centre de l'objet

XXXX : Il n'y a pas de centre, donc sa évolue entre le deuxième et le troisième X

AmiDARK AmiDARKicon_post
non en fait j'ai utilisé un printf() pour faire du débug et les coordonnées de saisie, de rendu, et de restauration du fond sont identiques.
En fait le pbe réside dans un fait apparement.

1. Je saisis en opération pixels (glReadPixels)
2. J'affiche le sprite en polygones (1 Quad)
3. Je restaure en opération pixels (glDrawPixels)

C'est la 2nde opération qui est pas gérée de la même façon par MiniGL et même si les coordonnées sont identiques ... le résultat est pas le même

J'ai réussi à fixer ce pbe en forçant le back buffer à être de 4 pixels plus large que le sprite et en saisissant avec X multiple de 4 ( avec un && 65532 pour isoles les bits 0 & 1 ) .... Résultat ... ça fonctionne ...

Bon j'ai quelques petits glitches ... je vais fixer ça maintenant :)
EDIT : C'est bon ça fonctionne :)
EDIT #2 : Je viens de voir que pour une autre fonction j'avais forcé l'alignement de saisie sur 4 octet (int) .. Je pense que le pbe venait de la ;)

Je pourrai bientôt mettre une chetite démo en ligne :)

Message édité par : AmiDARK / 19-03-2011 18:30
artblink artblinkicon_post
Tu va mettre une démo pour coder ou le résultat compiler?
Petites Annonces

0 annonce(s) publiée(s)

Consulter

AmigaOS 4.1

Laissez-vous tenter par
AmigaOS 4.1
AmiTheme

AmiTheme