PureBasic

aujourd'hui pour dessiner sur l'ecran on fait

StartDrawing ( ScreenOutput ())
For X=1 To Largeur
     For Y=1 To Hauteur
         Plot (X,Y,couleur)
     Next Y
Next X
StopDrawing ()

pour dessiner sur une image on fait

StartDrawing ( imageOutput ())
For X=1 To Largeur
     For Y=1 To Hauteur
         Plot (X,Y,couleur)
     Next Y
Next X
StopDrawing ()

pourquoi ne pas se debarrasser de "StartDrawing()" et de "StopDrawing()"

car comment faire si l'on veux lire un point sur une image puis l'ecrire sur l'ecran

on est obligé de faire un truc du genre :

Dim tableau(X,Y)
StartDrawing ( ImageOutput ())
For X=1 To Largeur
     For Y=1 To Hauteur
        tableau(X,Y)= Point (X,Y)
     Next Y
Next X
StopDrawing ()

StartDrawing ( ScreenOutput ())
For X=1 To Largeur
     For Y=1 To Hauteur
         Plot (X,Y,tableau(X,Y))
     Next Y
Next X
StopDrawing ()

c'est plutot ringard n'est -ce pas ??

si l'on pouvait mettre la direction des commande dans le nom de la commande genre :

screen_plot (x,y,couleur)
image_point(x,y,numero d'image)
ect ..
cela permetrai des codes beaucoup plus court

ont pourrai mettre dans une seul boucle et 6 lignes ce qu'il faut actuellement faire en 2 boucle et 15 ligne !!!

For X=1 To Largeur
     For Y=1 To Hauteur
        couleur=image_Point(X,Y)
        screen_plot(X,Y,couleur)
     Next Y
Next X

personne ne reagit la dessus ?

Le probleme, c'est que ça apellerais un StartDrawing() caché a chaque boucle de ton For Next et ça ralentit vachement aussi...
Imagine qu'en plus tu mette un Image_Plot, Texture_Plot et Sprite_Plot : StartDrawing() * 4

En plus, StartDrawing() renvoit le DC de la surface de dessin, ce qui peut quand même être utile.

cederavic a écrit :Le probleme, c'est que ça apellerais un StartDrawing() caché a chaque boucle de ton For Next et ça ralentit vachement aussi...
Imagine qu'en plus tu mette un Image_Plot, Texture_Plot et Sprite_Plot : StartDrawing() * 4

ça c'est parceque tu imagine que derriere ma suggestion il y a toujours
startdrawing , avec la gestion actuel du stardrawing ....

si je demande des nouvelles commandes , c'est bien pour virer le stardrawing et la gestion lente qui va avec !!

le but c'est bien d'acceder a une zone (graphique ) memoire
dans plein de language cet acces est beaucoup plus rapide qu'en PureBasic

en plus , non content d'etre lente , le system actuel empeche d'avoir plusieurs ecrans, et meme par exemple un programme
qui lit une image a l'ecran et qui plot () (avec un traitement) dans une autre image (affiche a l'ecran) , et que l'on voie les plots() se dessiner
est impossible dans une seul boucle , je trouve ça tres limite !!

avec le system actuel , car il sagit bien du system utilisé par Fred qui amene ces limitations,
il est inconcevable de faire un prg de traitement d'image (retouche photo, anaglyphe , video, ect ...)

d'autres language (meme basic) propose une facilité , on a pas a s'emmerd** la vie avec des contraintes imposé par le langage !!

je ne critique pas purebasic , je voudrai qu'il soit pris en compte une autre façon de gerer le graphisme , car je suis sur que les concurents (Basic)
utilise une autre façon de resoudre ce problem

il est mon avis , que Fred n'a pas choisi la bonne voie !!

-Lenteur << plusieurs secondes pour remplir une image ou un ecran
en regardant le remplissage se faire sur un ecran 1024x768 !!
en Stos basic , ça pédalait nettement plus vite avec 8Mhz !!!
aujourd'hui , avec mon3.8 Ghz je suis loin du compte !!!....

-complication du code pour l'utilisateur (plusieurs boucles obligatoires)
-impossibilité de simplifier le code (a cause du startdrawing non-imbriquable...)

pour reference , je n'ai connu AUCUN autre basics utilisant cette commande ou ce genre de gestion....

au mieux certains proposaient une fonction pour acceder a la memoire video (Le GFA basic (Xbios())) (rapide, mais bien aidé de pleins d'autre possibilités)
sinon les autres basic (Cas general) utilisent des commandes approprié

commencant par le mot Screen_****** pour des commandes concernant l'ecran

ou commencant par le mot Picture ou image_*** pour les images
sprite_**** pour les sprites
sans avoir a se soucier d'un startdrawing ..

actuellement le fait d'etre enfermé dans
startdrawing
et
stopdrawing
empeche une liberté d'utilisation, et rajoute une lenteur , que je trouve plus qu'excessive !!! ....

maintenant , c'est sur, tu n'as peut etre connu que ça ? ....


mais je pense que tout ceux qui ont connu d'autres basics , sauront de quoi je parle ...

Chris a écrit :En plus, StartDrawing() renvoit le DC de la surface de dessin, ce qui peut quand même être utile.

c'est beaucoup d'inconvegnients pour peu de choses !!!

y a qu'a laisser une fonction qui te renvois le DC
sans etre coincé par tout ce binsse !!!!

Chui d'accord avec Dobro, la lib 2DDrawing est mal foutue dans la mesure où on ne peut dessiner que sur un élément à la fois...

Par contre je proposerai plutôt quelque chose qui ressemble à ca: @Chris
C'est bien que ca renvoi le DC mais si on peut rien faire en natif je vois pas l'intérêt

Dri

Dr. Dri a écrit :Chui d'accord avec Dobro, la lib 2DDrawing est mal foutue dans la mesure où on ne peut dessiner que sur un élément à la fois...

Par contre je proposerai plutôt quelque chose qui ressemble à ca:

Code : Tout sélectionner

drawimage  = StartDrawing( ImageOutput() )
drawscreen = StartDrawing( ScreenOutput() )

For   X=1   To   Largeur
   For Y=1 To Hauteur
      couleur = Point(drawimage, X, Y)
      Plot(drawsreen, X, Y,couleur)
   Next Y
Next X

StopDrawing(drawimage)
StopDrawing(drawscreen)

Dri

si les startmachin et stopmachin sont obligatoire , je prefere nettement aussi !

Pour moi, le système idéal, c'est le système de BlitzBasic

Dr. Dri a écrit :Chui d'accord avec Dobro, la lib 2DDrawing est mal foutue dans la mesure où on ne peut dessiner que sur un élément à la fois...

Par contre je proposerai plutôt quelque chose qui ressemble à ca:

Code : Tout sélectionner

drawimage  = StartDrawing( ImageOutput() )
drawscreen = StartDrawing( ScreenOutput() )

For   X=1   To   Largeur
   For Y=1 To Hauteur
      couleur = Point(drawimage, X, Y)
      Plot(drawsreen, X, Y,couleur)
   Next Y
Next X

StopDrawing(drawimage)
StopDrawing(drawscreen)

@Chris
C'est bien que ca renvoi le DC mais si on peut rien faire en natif je vois pas l'intérêt

Dri

Ouais!
C'est vrai que quand on l'a, on n'a pas de quoi l'utiliser à moins de passer par l'Api

Polo a écrit :Pour moi, le système idéal, c'est le système de BlitzBasic

il propose quoi ?

Dobro a écrit :

Polo a écrit :Pour moi, le système idéal, c'est le système de BlitzBasic

il propose quoi ?

Déjà, il y a une commande sympa :
SetBuffer (buffer) où buffer est ImageBuffer() FrontBuffer() BackBuffer()

Tu as une fonction Plot/Point soit lente, soit accélérée, tu as le choix c'est vrai en plus !

Pas de Start/Stop, bien sûr
En tout cas, je trouve ce système carrément mieux, tu peux allez voir le manuel de blitz sur blitzbasic.com pour plus d'infos, je sais pas très bien expliquer

alors Fred ? t'en pense quoi ??

Le blitz n'a pas le probleme de polyvalence de purebasic (front/back et images sont tous le meme objet: une surface directX). En PB, tu as ScreenOutput/SpriteOutput (qui est en gros l'equivalent du blitz), ImageOutput() et PrinterOutput() qui ont chacun leurs particularités (DC sur un DIBSection ou Bitmap pour les images, ou DC sur une imprimante). A noter qu'en purebasic, quand on utilise ScreenOutput()/SpriteOutput() la commande Plot() est de toute facon accelerée (on ne passe pas par l'API mais on ecrit directement sur le buffer), donc y'a pas besoin de version lente. Quant à faire une version differente de la commande pour chaque contexte, ca va faire plus beaucoup de commandes. La solution de DrDri est pas mal, mais passer le DC pour chaque commande va la ralentir pas mal (particulierement pour les commandes Plot() et Point()). Pour la v4, chaque thread pourra utiliser un contexte different, si ca peut aider.

Dobro: le startdrawing()/stopdrawing() n'est pas le facteur de la lenteur, c'est l'API windows qui veut ca. Essaye directement avec la commande SetPixelV_() pour voir si c'est plus rapide (vu que plot, l'utilise y'a peu de chance ). L'acces direct à la memoire (en mode bourrin), dans les OS modernes est en general proscrit, donc on est obligé de respecter les regles. Il est néanmoins disponible pour ScreenOutput() et SpriteOutput(), et donc Plot() est bien plus rapide. Je vais essayer de faire un systeme similaire pour les images en recuperant d'un coup tous les pixels.

apres moult tests , pour ma part je remarque surtout un ralentissement
sur la fonction Point() !!
beaucoup plus que sur le plot !!

mais le point() ..... il rame grave !

Le blitz n'a pas le probleme de polyvalence de purebasic (front/back et images sont tous le meme objet: une surface directX).

pourquoi ne pas suivre cette exemple ? puisqu'il semble efficace ?

pourquoi a tu choisi de diferencier les images ? ya une raison particuliere ?

Pour la v4, chaque thread pourra utiliser un contexte different, si ca peut aider

c'est interressant ça

PureBasic = Blitz en terme de rapidité plot() pour les jeux (avec un leger avantage pour purebasic d'apres mes derniers tests).