des debuts sans pretention

je debute et suis parfois surpris de ce que j'obtiens
presque 3d
[/code]
dim x,y, a
width 0,1950
height 0,1400
color 0,34,231,228
wait 10
a=(-20)
for x=1 to 2000 step 0.3
a=a+0.2
2d_fill_color rnd( 255),0,0

y=500+sin((x*1.2)/57.297)*400
2d_circle x,y,a
2d_circle x+100,y+80,a
2d_fill_color 0,0,rnd(255)
2d_circle x+200,y+85,a
2d_circle x+100,y+100,a
2d_circle x+200,y+25,a

a=20/A


2d_circle x,y,a
2d_circle x+100,y+80,a
2d_fill_color 0,0,rnd(255)
2d_circle x+200,y+185,a
2d_circle x+100,y+200,a
2d_circle x+200,y+125,a
a=a*5
next x
end

parfois des effets visuels
[code]
width 0,1000
height 0,1000
dim a,x,y,q
a=2
2d_poly_from 800,600
for q=1 to 1000 step 0.1


2d_poly_to 900,600-a
2d_poly_to 100+a,600+a
2d_poly_to 300-a,900+a
a=a+2
next q


bizarre ,non?

Eh, pas mal, surtout si c'est obtenu un peu par hasard !
Superbe !

Ah oui, très joli ces effets visuels ! Il y aurait là de quoi faire un économiseur d'écran, en laissant le programme continuer à l'infinie...

Bravo pour cet essai !

Pas mal du tout en effet !

Klaus,

Prend ce code et fais un exécutable...

Code:

dim x,y, a:label debut,suit
debut:
border_hide 0
full_space 0
on_key_up 0,suit
color 0,34,231,228
wait 10
a=(-20)
for x=1 to 2000 step 0.3
a=a+0.2
2d_fill_color rnd( 255),0,0

y=500+sin((x*1.2)/57.297)*400
2d_circle x,y,a
2d_circle x+100,y+80,a
2d_fill_color 0,0,rnd(255)
2d_circle x+200,y+85,a
2d_circle x+100,y+100,a
2d_circle x+200,y+25,a

a=20/A


2d_circle x,y,a
2d_circle x+100,y+80,a
2d_fill_color 0,0,rnd(255)
2d_circle x+200,y+185,a
2d_circle x+100,y+200,a
2d_circle x+200,y+125,a
a=a*5
next x
goto debut
end
suit:
terminate
return

Après renomme l'exécutable Screen.scr
Et met-le dans c:\windows\system32\
Et vas dans les propriétés de l'écran veille...
Chez moi ça marche et je vais bien le prendre comme écran de veille !

Oui, très joli. Seul b-mol: pour quitter le programme, il faut frapper une touche - normal pour un économiseur d'écran. Mais, d'abord, il ne s'arrête pas immédiatement et je n'arrive pas à savoir pourquoi le on_key_up n'est pas exécuté immédiatement. Ensuite, lorsqu'il le prend enfin en compte, il termine par "access violation at address 000...0048; read access at address 000...0048".

Panoramic a sûrement du mal à traiter l'interruption dans la partie initialisation d'un programme (avant de rencontrer l'instruction end), ce qui est la cas ici. L'instruction Wait ne résoud pas le problème, car elle bloque les évènements aussi.

J'ai défini un bouton "Démarrer" et j'ai placé tout le traitement dans la routine on_click de ce bouton. On peut le lancer sans problème, mais alors on ne peut plus l'arrêter du tout.

Apparemment, il y a encore un peu de boulot, mais c'est normal.

je vois en vitesse le programme, et d'après ce que j'ai déjà rencontré, c'est le goto début qui ne va pas.
Chaque fois qu'on fait une boucle de ce genre, surtout en dehors des événement, il y a ce problème.
Je n'essaye pas ces programmes pour l'instant, j'ai pas tout à fait terminer le mien, et je ne veux pas qu'il y ai des problèmes pour l'instant.
normalement pour sortir dans ce genre de boucle, je mets, mais là il faut faire l'essai, un truc de ce genre:

Code:

repeat
  sorti%=scancode
  if sorti%=27 then ' opération de sorti à définir
until sorti%=27

J'ai mis une sorti dans la boucle parce qu'après on se retrouve dans le code.
Je remarque aussi que la boucle est avant le END, ce qui fait que normalement : on_key_up n'est pas événementiel, puisque le programme ne rencontre pas le END dans son exécution.

Autre chose: il est bon de mettre un: WAIT 1, dans une boucle. Si vous faites l'essai en regardant les courbes du gestionnaire de tâche, vous remarquerez que vous prenez 100/100 du microprocesseur, alors qu'avec le rajout de wait1, celui-ci tombe à 2 - 4%.
A ne pas négliger.

Tu as raison, Cosmos70. Avec un Wait 1 dans la boucle, c'est beaucoup mieux. Et l'astuce avec

Code:

  sorti%=scancode
  if sorti%=27 then terminate

permet d'arrêter le programme immédiatement, A CONDITION de frapper Escape ! Si l'on frappe autre chose, Panoramic plante acev violation d'accès en lecture adresse 48 (comme dans mon post précédent).

Bon, ce n'est pas bien grave, tout ça....

Merci d'abord pour votre acccueil sympa,et votre attention
J'apprends pas mal de choses à votre lecture
j'ai essaye la commande WAIT dans une boucle.
Dans le code suivant si on l'enleve on passe de la vitesse d'un escargot a celle d'un tgv

[height 0,600
width 0,1690 :dim x,y
for x =1 to 1500
WAIT 1
y= 250+sin (x/57)*230
2d_circle x,y,20

next x

existe_t-il un moyen de temporiser un boucle ,sans la ralentir un max]

Effectivement, ça fait une sacrée différence entre le wait 1 et pas de wait du tout.
Le WAIT 1 étant le minimum, tu peux le remplacer par une boucle interne, à ajuster, et là on obtient des temporisations bien plus brèves:

Code:

height 0,600
width 0,1690 :dim x,y, z
print time$
for x =1 to 1500
    ' WAIT 1
    for z = 1 to 100: next z
    y= 250+sin (x/57)*230
    2d_circle x,y,20
next x
print time$

Attention ! En faisant ce genre de boucles, tu consommes exclusivement du temps CPU. Fais une boucle plus longue et regarde par le task manager: tu passes à 100 % d'utilisation d'unité centrale.

Ce n'est pas grave si ton programme est le seul qui tourne, mais normalement, XP ou Vista sont des systèmes multi-tâches, et là, tu bloques totalement le système.

Ceci me conduit à dire qu'il manque une possibilité dans Panoramic. En effet, il faut pouvoir rendre la main au système pour qu'il puisses gérer ses affaires en arrière plan (une copie de fichiers, une réception de mail, un téléchargement, ...). Panoramic le fait très bien après la phase d'initialisation, donc après l'instruction "end". Tout ce qui se passe après est géré par des évènements Windows (un click par exemple), et entretemps, windows a la main pour travailler. Or, l'instruction wait bloque les évènements totalement, ce qui est clairement indiqué dans la documentation.

Il manque une fonction du type "suspend n" avec n étant le nombre de millisecondes.

C'est vrai que le wait ne permet pas de reprendre la main avant son expiration, et c'est parfois bien embêtant.
Quant à bloquer totalement le système avec une boucle, ça ne doit pas être bien grave dans la grande majorité des cas, dans la mesure où le programme qui tourne est souvent le seul actif (pour l'utilisateur). Et je ne pense tout de même pas que ça bloque les tâches de fond de windows: gestion de l'horloge, etc., je pense qu'il doit y avoir un système de priorités d'exécution des tâches, et d'interruption des tâches moins prioritaires par les plus prioritaires.
D'ailleurs, pendant l'exécution de la boucle, le système continue bien à scruter le clavier et la souris ?

Ce n'est pas si simple que cela. Essaie de lancer l'exporateur de fchiers ou un éditeur de texte comme wordpad, puis tu lances un programme panoramic avec une boucle infinie du type

Citation :

dim i%,n%
n%=0
while n%=0
i%=1
end_while
end

Puis essaie de parcourir un répertoire avec l'exporateur ou de rentrer du texte dans l'éditeur... Où sont les priorités ? En fait, l'usage d'unité centrale prime sur presque tout, et on sait très bien pour des programmes scientifiques de calcul lourd, il faut régulièrement laisser la main au système par des moyens appropriés pour ne pas bloquer le système entier.Quelque fois, il devient même très difficile d'interrompre une telle boucle par le gestionnaire des tâches. Et que dire si tu as lancé en arrière-plan un téléchargement long ou un gravage de DVD - le DVD sera corrompu !

Tout ça pour dire que même si tu as l'impression d'être le "seul" utilisateur du système, XP ou Windows exécute en permanence des dizaines de process en multi-tâche. Normalement, tu ne t'en rends pas compte justement parceque le système reprend la main très souvent, en fait à chaque fois que ton application attend un évènement ou lance une demnde au système. Tiens, une simple instruction i%=scancode à l'itérieur de la boucle devrait résoudre le problème...

Il y a certainement des solutions plus élégantes et plus efficaces que celle de la boucle (je parlais évidemment de petites boucles de quelques millisecondes, qui existent dans tous les programmes, pas de boucles infinies = blocage général). (en fait j'ai travaillé dans un système temps réel où il y avait une tâche la plus prioritaire qui distribuait le temps de travail en fonction des disponibilités et des latences des autres programmes, et une tâche la moins prioritaire qui faisait le watchdog. Mais ce n'était pas windows... et je digresse...)

Non, tu ne digresses pas. Et je pense que ce genre d'échange au sujet de de l'utilisation du processeur peut en intéresser plus d'un.

Effectivement, dans un système temps réel, les choses fonctionnent différemment. J'en ai fait l'expérience également (il y a bien longtemps) sur les systèmes RSX11 et IAS de feu Digital Equipment.

Cependant, Windows n'est pas temps réel mais temps partagé multi-tâche, et multi-utilisateur dans une certaine limite. Il y a bien la notion de priorités, mais on n'a guère le moyen de jouer avec cela car on risque en réalité de bloquer tout le système. En effet, sous windows, toutes les interruptions ne sont pas prioritaires sur toutes les tâches; on arrive même à saturer le buffeur d'entrée du clavier et de bloquer tout le système avec cela.

Evidemment, si tu ne fais que de micro-boucles, il n'y a pas de risque (sauf erreur dans la programmation de la boucle...). Mais pour le programmeur non averti, il convient de préciser que cette technique ne doit en aucun cas être employée dans un autre contexte. Par exemple, pour afficher les secondes d'une horloge, il ne faut SURTOUT pas faire cela (ni un WAIT 1000 d'ailleurs) !

Il vaut beaucoup mieux chronométrer le temps d'exécution d'une instruction genre i%=DIR_EXISTS("temp.txt"), par exemple en faisant une boucle de 10.000 itérations, mesurer le temps global et diviser par 10.000, puis placer cette instruction dans une boucle dimensionnée par rapport à son temps d'exécution. Là, on est sûr que Windows peut travailler normalement, et avec le gestionnaire des tâches, on peut voir aisément que la charge CPU reste fable.

Une autre solution consiste à lancer un "timer" dans windows et de spécifier une routine d'évènement à appeler pour l'expiration du timer. Mais pour le moment, on ne peut pas faire cela directement dans Panoramic.

La boucle n'est certainement pas le meilleur moyen pour temporiser, c'est un pis-aller pour de petites tempos.
Je n'ai certes pas été aussi loin que toi dans les réflexions philosophiques, je constatais simplement qu'on peut toujours arrêter le programme dans une boucle par Ctl/Maj/Echap, donc Windows est toujours à l'écoute des interruptions clavier.
Toutefois le fonctionnement ne semble pas très sain, le programme panoramic reste gelé même si on quitte la boîte de dialogue windows sans rien faire (cas de la boucle que j'ai rajouté: for z = 1 to 3000...).