Startdrawing -- StopDrawing

[Backup]

je sais pas si vous avez deja codé des applications graphique
mais pour ma part j e trouve tres tres lourd le System Purebasic avec ses

Startdrawing(ImageOutput(image))
plot(element(i)\x,element(i)\y,element(i)\coul.l)
StopDrawing()

deja , on ne peut pas les imbriquer !

si dans une boucle on veut Ecrire des points dans une image
et en meme temps changer la couleur d'un Sprite
je ne vous dis pas le cirque ...

si en plus vous intégrez ça dans une procedure Recursive , c'est tirage de balle in the Head
pour gerer les StopDrawing au bons endroits ..


sans parler de la LEEEEENNTTTEEEEUUUUR ..dans une boucle .ça oblige a les metres en dehors des boucles
mais alors , il ne faut pas avoir a dessiner plusieurs choses dans plusieurs destinations (Sprite,Screen ,etc.. )
ces histoires de Startdrawing- StopDrawing c'est archaïque !

comment font les autres langages ?
je suis a 2 doigts de me chercher un autre langage rien que pour évitez ces fonctions !

pourquoi ne pas désigner l'endroit ou l'on dessine, par un paramètre dans la fonction de dessin

gentre Plot(Screen(),X,Y,Couleur)


je trouve que la base du langage, demanderai a etre Amélioré ... qu'en pensez vous ?

[SPH]

qu'en pensez vous ?

Moi qui ai fait un jeu entierement en mode graphique, je n'ai pas rencontré de difficultés et de problemes avec les Start et Stop Drawing. Ca coule naturellement.

[MetalOS]

J'utilise beaucoup la lib Darwing pour mon logiciel d'impacts de foudre.



Sous Mac et Linux le chargement et le dessin des impacts ce fait instantanément mais sous windows le chargement ce fait au fur et à mesure du chargement du fichier de données alors que le code et le même sur les trois platformes.

[Backup]

joli le soft

[MetalOS]

Merci

[blendman]

J'utilise très souvent la lib graphique 2D que ce soit pour des outils ou des petits prototypes de jeux, et je suis assez d'accord avec dobro, je trouve qu'il a énoncé les points problématiques de ce système.

En général, sur mes projets 2D, je dessine d'abord sur une image (le calque sélectionné), puis, je dessine sur une copie de cette image (pour effctuer si besoin des opérations comme resize ou blendmode), puis, je dessine le résultat sur le canvas. Et bien ça me fait déjà 3 startdrawing/stopdrawing enchainés.
Et si on plot() ou qu'on point() et bien, ça devient vraiment compliqué à gérer et je ne parle même pas du fait que ça rame assez rapidement sur des images relativement moyennes (1024*768 par exemple).

Dessiner sur le canvas est super rapide, mais hélas il n'est pas transparent. S'il était transparent, ça changerait beaucoup de choses à mon avis, ça permet d'éviter des opérations sur les images qui sont très lentes.

Par exemple, sur un des outils sur lesquels je bosse en ce moment, pour mes jeux, j'utilise la méthode énoncée plus haut (au moins 3 enchaînements de start/stop) :

[Backup]

haaa!! Merci de confirmer ...

si on fait un jeux, c'est le plus simple a traiter .. car les dessins,affichages, peuvent etre sequentiel ...

mais des qu'on aborde la creation graphique, avec gadgets, Sprites, images (plusieurs images), (Couche),etc ...
que l'on ai besoin de rafraichir plusieurs choses en meme temps ...
(seul ceux qui ont deja essayé de coder un soft graphique peuvent savoir de quoi on parle )


ça deviens l'enfer !

je ne dis pas que c'est impossible , je dis que c'est loin d'etre evident
et que peut etre certaines chose deviennent impossibles a cause de la limitation de vitesse que cette gestion impose

hors de question de faire du temps Reel , on est forcement dans le Pre-calculé ... pour que ça ne rame pas .

entre nous soit dit, je ne comprends pas que le fait de changer de contexte (StartDrawing() dans une boucle ; prenne autant de temps !
ce n'est qu'un changement d'adresse non ?

le fait de mettre ce changement de context dans les fonctions de dessin, permettrai de pouvoir dessiner dans une boucle, et dans plusieurs destination


ce serai plutôt sympath de pouvoir faire :

For x= 1 to 100 step 10
    For y= 1 to 100 step 10
       Box(x,y, 10, 10,couleur,imageoutput( #image1 ))
       Box(x,y, 10, 10,couleur,imageoutput( #image2 ))
       Box(x,y, 10, 10,couleur,SPriteoutput( #Sprite1 ))
       Box(x,y, 10, 10,couleur,Screenoutput())
    Next Y
Next x
; Epb

si ça n'est pas qu'un changement d'addresse , alors il faudrait des fonction de Creation de contexte
de façon a séparer la creation de context graphique, ... on creerai le context en debut de code
et ensuite on pourrai dessiner dessus dans une boucle comme mon exemple ci dessus ..


Fred , si tu lis ça ...

[blendman]

Oui, ce serait vraiment plus simple de faire ça et peut-être même beaucoup plus rapide.

Mais le problème est bien celui-là :

seul ceux qui ont deja essayé de coder un soft graphique peuvent savoir de quoi on parle

[Backup]

je vais essayer de faire traduire ça par internet, et poster une demande sur le forum des gens qui mangent de la gelée a la menthe

[Fred]

Ca n'est pas qu'un changement d'adresse, quand tu crées un contexte tu vérouilles ton buffer, tu le convertis en 24-bit ou 32-bit avec les bons paramètres (up/down, etc) et ca prends du temps et de la memoire. L'avantage de StartDrawing(), c'est que le contexte est implicite, donc tu gagnes un paramètre à passer à chaque appel fonctions (sans compter les optimisations qu'on peut faire du fait que l'on sait quel contexte est actif). Pour une commande comme Plot() ou Point(), ça fait une grosse différence au niveau des performances. J'ai fait pas mal de graphique aussi, et je ne trouve pas que ce soit si compliqué que ça. Comme quoi, on peut avoir un avis différent sur la question .

[Backup]

que j'essaie de bien comprendre ...

Ca n'est pas qu'un changement d'adresse, quand tu crées un contexte tu vérouilles ton buffer, tu le convertis en 24-bit ou 32-bit avec les bons paramètres (up/down, etc) et ca prends du temps et de la memoire.

car cela n'est pas effectué lors de la creation ??
au moment de OpenWindow() , OpenScreen() , CanvasGadget() , CreateImage() etc ...
tu ne le creer pas le context ?

ne peux t'on pas creer plusieurs device context en meme temps ?

si cela etait le cas ... alors tu me confirme qu'un Plot(x,y,Context) serait possible non ?
car une fois le context connu ,a la creation , un plot n'est qu'une écriture dans un context deja Crée , donc pas de perte de temp ... enfin , je ne suis pas assez bon programmeur pour savoir de quoi je parle , mais ... ça me semble logique
de reserver ce qui prends le plus de temps au moment de la création de l'objet (du context )

ainsi de pouvoir disposer de l'espace des Devicecontexts créés , a notre guise ...
certes en ajoutant un parametre de destination a chaque fonctions de dessin .. mais franchement, ça ouvrirai
des possibilités bien plus confortables ...

on peut ecrire dans le Graphique context d'une autre Application , voir dans son espace Ram , alors, pourquoi pas pouvoir le faire
dans la notre .. ?
en quelques sorte cela reviendrai a ouvrir plusieurs StartDrawing de nos objets au moment de leur creations , pour pouvoir ecrire dans celui qu'on veux dans le prg en cours de fonctionnement SANS AVOIR a LES REFERMER ... (seulement en fin de prg )

le principe actuel , donne l'impression qu'on ne peut ecrire que dans un context a la fois .. c'est rageant

(Excuse ma naïveté , je suis un radis concernant la programmation )

[Fred]

Créer un contexte pour chaque image lors de sa creation n'est pas possible car ca monopoliserait le double de mémoire et un "Handle" Windows (qui sont limités à 10 000 par applis, tout confondu). De plus on n'a pas forcement envie de faire un StartDrawing() sur une image. Pour finir, si tu utilises l'API windows sur ton image, les changements ne seraient pas pris en compte dans le contexte préalablement créé, ce qui poserait aussi probleme à certains.

Ce serait possible de creer plusieurs contextes à la volée et de passer ca en parametre des fonctions. Malheureusement les fonctions PB n'ont pas été pensées comme ca au depart, et utiliser le dernier parametre pour ca, c'est syntaxiquement incorrect. Tu es le premier en 12 ans à voir un "probleme majeur" là dedans, et objectivement je ne pense pas que ce soit le cas (tu peux utiliser un tableau à 2 dimensions temporaire pour faire rapidement du transfert de données par exemple). Il faut agencer son code pour tirer meilleur profit des fonctions actuelles, qui sont alors tres optimisées .

[Backup]

je comprends ...

et utiliser le dernier parametre pour ca, c'est syntaxiquement incorrect.

c'etait pour l'exemple ... peut importe le flacon

Tu es le premier en 12 ans à voir un "probleme majeur" là dedans,

non , je suis peut etre , le premier a en parler ... nuance... cela ne veux pas dire que je suis le seul a qui ça pose ou ça a posé un "probleme"

Merci pour tes réponses

[G-Rom]

comment font les autres langages ?

Sensiblement pareil. Les fonctions graphique sont relativement "rapide" tout de même , sans revenir sur ce qui à été dit, j'ai lu que tu voulais faire des imbrication de dessin , c'est une très mauvaise idée. le fait de swicthé entre plusieurs "contexte" de fera perdre un temps considérable.

Si tu as des besoins d'accès et de modification de manière récurrente dans ton code, l'idéal est d'utilisé le même procédé que pour l'optimisation des programmes utilisant le GPU, les méta textures , ou texture atlas. sauf qu'en RAM principal on ne parle pas de texture mais d'image. mais le principe est le même.
Tu regroupes le tout dans une seule image ( que tu fabriques en runtime au lancement du programme après le chargement du programme ) veille à ne pas dépasser une certaine taille , car lors de l'envois au GPU ( par le biais d'un sprite en PB ) ce n'est pas dit que la carte graphique supporte les grosse unité de texture. utilise une taille carré ( 4096x4096 ) max par exemple.
tu verras , tu auras un gain considérable en terme de performance.
Tu peu aussi travailler en "off screen" via des tableaux 2D , des zones mémoires que tu copie ensuite via copymemory() sur le buffer de l'image, rapidité garantie.
En ce qui concerne les autres langages, je vais parlé de la SFML que je maîtrise très bien , il n'y a aucune commande de dessin comme plot() ou point() , lineXY() , etc... tout dois ce faire en software avec des techniques que je t'ai cité plus haut.
Non, l'herbe n'est pas plus verte à coté, même avec des langages "pro"

[Backup]

Mheuuuuu !