Reprise du message précédent :
non, mais c'est pas exclus que certains fassent la conversion implicitement flottant -> int

je dois dire que ca me paraitrait completement farfelu
et avec un brin de reflexion on se rend compte qu'alors son code n'aurait strictement aucun sens

mais on ne sait jamais ... en tout cas mettre ça dans un cpp, ça peut induire en erreur les débutants

je vous rassure hein, la mise en forme des exemples était juste pour que ce soit plus clair
il est bien évident qu'un truc comme  
 
int a = 21.54 << 8;
 
est totalement absurde, mais ça permet de bien distinguer le principe des nombres en virgule fixe !

 
C'est pas un topic pour les n00b ici

LES PLASMAS EN TEMPS REEL (OU SINE PLASMA)
 
Télécharger l'éxécutable
Télécharger le source
Télécharger le dos4gw.exe (à mettre dans le meme répertoire que l'éxécutable).
 
Il existe 2 types de plasma :
 
- Le plasma statique
- Le plasma en temps réél
 
Le plasma statique n'est qu'un simple jeu de palette. On dessine une image à l'écran (généralement une fractale), puis on effectue une rotation de palette. Ceci a pour effet d'alterner des couleurs généralement choisies pour être de style psychédélique sur fond d'une image irrégulière. Joli, mais pas passionnant à programmer...
 
Le plasma en temps réél est beaucoup plus passionnant. Ce type de plasma est constitué de courbes s'entrecroisant, et en mouvement constant. Une palette de couleur adaptée, généralement à base de dégradés, donne l'illusion d'un océan de couleurs virevoltant et tournoyant selon le bon désir du codeur.
 
Qui dit courbes, dit sinus et cosinus. Pour générer notre plasma, nous aurons donc besoin de calculer des cosinus ou des sinus selon une formule totalement arbitraire. Pour ma part, j'utilise la formule la plus simple : cos(x). Mais il existe autant de formules que de programmeurs, rien ne vous empêche d'utiliser votre formule.
 
Il est bien évidemment hors de question de calculer ces cosinus en temps réél, nous utiliserons donc une table précalculée avant l'animation.
 
Cette table est calculée par la fonction precalcCosinus :

On précalcule ici 256 cosinus dans la table cosTbl, de 0 à 2*pi radians (360 degrés). Pour ceux qui sont fachés avec la trigo, je rappelle que 2*pi radians = 360 degrés, donc 1 degré = pi * (2/360) radians = pi/180 radians.
Les cosinus donnant une valeur entre -1 et 1, je multiplie le résultat par 32, ce qui me donne un intervalle entre -32 et 32. Finalement, j'ajoute 32 pour ramener le résultat dans l'intervalle [0;64], car ces cosinus seront en fait des index vers la palette de couleur. Pourquoi [0;64] et pas [0;256] ? Car le principe du plasma est d'additionner 4 cosinus, donc chaque cosinus devra être au maximum de 256/4 = 64.
 
Le principe du plasma est très simple : il s'agit, à chaque balayage vertical, de calculer la somme de 4 cosinus choisis dans la table. La somme représentera un index de couleur qu'on affichera à l'écran.
Un plasma se déplaçant horizontalement et verticalement, il faudra initialiser 4 variables, ou pointeurs, de déplacement : 2 pour le sens horizontal et 2 pour le sens vertical. Avant le tracé d'une frame, ces pointeurs devront être sauvegardés pour le mouvement décrit plus bas.
Puis, pour chaque ligne de l'écran, on met à jour nos 2 pointeurs de déplacement horizontal, et on fait de même avec les pointeurs de déplacement vertical pour chaque colonne de l'écran. On fait ensuite la somme de ces 4 pointeurs, qu'on utilise comme index pour lire la table des cosinus et en extraire l'index de couleur, qu'on "plotte" ensuite à l'écran.
 
Enfin, pour simuler le mouvement global du plasma, on met à jour les 4 pointeurs sauvegardés au début de la frame, qu'on utilisera comme base pour la frame suivante.
 
 
La technique
Aucune difficulté ici. Aucune routine assembleur supplémentaire par rapport à l'effet de feu. La boucle principale est très simple :

Ce code parle de lui même : tant qu'une touche n'est pas pressée, on dessine le plasma dans le buffer, puis on attend le retour de balayage pour copier le buffer dans la mémoire vidéo.
La routine dessinePlasma() permet de ... dessiner le plasma. Cette routine est largement commentée.
 
Variantes
Pour observer le comportement du plasma, amusez vous à modifier les valeurs des pointeurs de position p1,p2,p3,p4 et t1,t2,t3,t4, à soustraire ou à ajouter des valeurs, ou de n'utiliser que 1,2 ou 3 pointeurs. Observez l'effet ainsi obtenu.
Vous pouvez également modifier la formule utilisée pour calculer les cosinus, sans oublier de ramener les valeurs entre 0 et 64
 
Prochain article : présentation du Mode X et du mode "Chain-4', qui sont des modes vidéo bien utiles pour certaines opérations de tracé (scrolling, plasmas rapides, etc...)

j'ai le droit de dire si ça fait planter ma machine?

360/256 ça c'est par contre peut etre mieux en calcul flottant non ?

Le truc de la touche pressée ça ne fonctionne toujours pas chez moi

ha ben ça marche en fait
(jamais réussi à faire tourner la moindre démo sur mon portable, en passant..)

non, parce que les cosinus sont en fait des index de couleur, donc des entiers
aucune utilisation de la partie décimale, on peut se permettre de travailler sur des entiers

je sais pas quoi te dire, t'es sous quel OS ?

tu vois bien que je code pas comme un porc

 
WinXP

disons que t'as bien recopié le tuto
 
 
 
 
 
/o\

360/256 à fait 1 et pas 1.4....

ben moi aussi, et ça marche bien chez moi
SP1 ou pas ?

tiens, le tstarfield il ressemble à rien chez moi
(tous les effets se font en 640*qqchose apparement, mais chez moi ça fait pas du fullscreen, normal?) ben le tstarfield euh les etoiles c ptet normal, ressemblent à rien(on dirait limit du bruit télé), mais y'a un gros rectangle bleu en haut qui est pas stable
 
et le feu y'a des ptits defauts dans le fond..
 
sinon euh mes fenetres dos disparaissent qd je termine le truc..
(full screen noire, mais taille utilisable +/- 640x...)

pour le starfield, t'as du lancer le tstarfield ! le truc bleu c'est le temps machine, y'a un article dessus
tous les effets se font en 320*200 !
 
edit: et les "défauts" du feu, c'est le foyer qui est constitué de nombres aléatoires
(t'as lu les articles ? )

oui, le starfield est impec (si on considere que c'est normal que ce soit tjs les memes etoiles qui repassent au meme endroit), je parlais bien du tstarfield
 
et euh non j'ai pas lu en fait
 
(c long )

il ne faut pas raisonner comme ça
si je calcule x*360/256, pour x de 1 a 5 :
 
1*360/256 = 1
2*360/256 = 2
3*360/256 = 4
4*360/256 = 5
5*360/256 = 7
 
si je suis ton raisonnement, j'obtiens une suite de 1 à 5 toute simple.

ben oui c normal
 

 
oui

comprends pas
c'est pourtant la fonction kbhit() toute con

pour le kbhit() c'est qu'il y a qqchose dans le tampon clavier...
 
faire un:
 
while( kbhit() )
    getch();
 
avant d'entrer dans la boucle de traçage.....
 
sinon, effectivement Taz a ptet raison le "i*360/256 * PI/180" pourrait chier, mais à priori voyant que le cos() attends un flottant, Watcom doit tout faire en flottant... (bien que ça paraisse bizarre), enfin j'ai même pas essayé....

LE MODE X
 
Télécharger l'exécutable
Télécharger le source
 
Lorsque j'ai dit que la mémoire vidéo était une zone de mémoire linéaire, j'ai sous entendu que celle ci pouvait être adressée de manière linéaire, c'est à dire que les 320*200 pixels se suivaient.
 
Ceci n'est pas tout à fait vrai. La mémoire vidéo est effectivement linéaire, mais elle est en réalité découpée en 4 pages, ou plans, pouvant être adressés individuellement ou tous ensemble.
 
Le mode 13h, si pratique de par son adressage linéaire, que nous avons vu jusqu'a présent, est en fait un mode vidéo particulier qui "triche" pour faire croire au programmeur que les 64000 pixels sont disposés de manière linéaire. Je ne m'attarderai pas sur la manière dont est opérée cette "tricherie", il suffit juste de savoir qu'en mode 13h linéaire, les 4 plans de la mémoire vidéo sont en réalité "chainés" afin d'obtenir une simulation d'adressage linéaire, chaque plan étant en effet large de 80 pixels.
 
Le mode 13h linéaire est bien pratique pour adresser les pixels de manière individuelle. C'est ce mode qu'on retiendra pour les déplacements rapides de pixels comme les starfields, le calcul d'ombrage, mapping, etc... Mais dans le cas d'effets 2D nécessitant une séparation de différents plans, ce mode est très inefficace.
 
En effet, imaginons un bonhomme marchant, sur un fond représenté par une image quelconque. A chaque VBL, les opérations suivantes doivent être réalisées :
- sauvegarde de l'arrière plan
- effacement du sprite
- calcul de la nouvelle position du sprite
- affichage du sprite
- restauration de l'arrière plan de l'image précédente
 
Ceci représente une opération assez lente en mode linéaire. La solution réside dans l'utilisation du Mode X.
 
Le Mode X est un mode vidéo non documenté dans les documentations officielles des cartes VGA. Il est obtenu en "bricolant" les registres de la carte VGA.
 
Le Mode X permet un accés séparé aux 4 plans de la mémoire vidéo. La structure particulière de ce mode est ainsi faite que chaque adresse de la mémoire vidéo contient 4 pixels. Un accés en Mode X est donc 4 fois plus rapide qu'un accés en mode 13h linéaire.
 
La structure du Mode X
Le Mode X est donc constitué de 4 plans de 80 pixels de large. Contrairement au mode 13h linéaire, les pixels ne sont pas situés les uns après les autres, mais sont superposés sur les 4 plans.
 
Ainsi :
- le pixel 0 est situé à l'offset 0 du plan 0,  
- le pixel 1 est situé à l'offset 0 du plan 1,  
- le pixel 2 est situé à l'offset 0 du plan 2,  
- le pixel 3 est situé à l'offset 0 du plan 3,
- le pixel 4 est situé à l'offset 1 du plan 0,
- etc...
 
Un offset étant en réalité une adresse mémoire, nous voyons ici clairement que chaque adresse contient 4 pixels. D'ou une rapidité d'accés 4 fois plus rapide qu'en Mode 13h linéaire.
 
La contrepartie de tout ceci est évidente : l'adressage de pixels isolés est relativement lent, car pour obtenir l'adresse (offset) d'un pixel, il faut trouver le plan auquel il appartient, ainsi que son offset dans ce plan.
 
La formule utilisée est la suivante, pour un pixel (x,y) :
 
plan = x mod 4
offset = y*80 + x/4
 
Pourquoi y*80 ? Car nous avons vu qu'en Mode X, une ligne n'est pas constituée de 320 pixels, mais de 80.
 
On est donc bien loin de la simplicité du mode 13h linéaire, et on comprend mieux pourquoi le Mode X sera utilisé davantage pour le déplacement de blocs de pixels plutot que pour le déplacement de pixels isolés. C'est le mode de prédilection utilisé dans les scrollings par exemple.
 
Les registres de la carte VGA nécessaires à l'initialisation du Mode X
L'intitialisation du Mode X fait intervenir différents registres de la carte VGA, que je présente ici :
 
Le séquenceur de timing (ou TS : Timing Sequencer)
Le TS joue un rôle dans la gestion de la mémoire, et est également responsable du rafraichissement de la mémoire vidéo.
 
En 3c4, on indique le numéro de registre du TS à modifier, et en 3c5 on indique la donnée à envoyer sur ce registre.
Les numéros de registres qui nous intéresseront pour initialiser le Mode X sont :
- le registre 4 (Memory Mode) : seuls les bits 1,2 et 3 de ce registre sont utilisés.
- le registre 2 (Write Plane Mask) : seuls les bits 0,1,2,3 sont utilisés et permettent d'activer l'écriture sur les différents plans
 
Le controleur de rayons cathodique (ou CRTC : Cathod Ray Tube Controller)
Attention, ce circuit est dangereureux et, mal utilisé, peut endommager le moniteur. Il s'agit du plus gros circuit de la carte VGA et il possède beaucoup de registres sensibles. En 3d4, on indique le numéro de registre, et en 3d5, la donnée.
Les registres qui nous intéressent sont :
- le registre 14h (Underline Location), composé de 8 bits
- le registre 17h (CRTC Mode), composé de 8 bits
- le registre 09h (Maximum Row Adress), composé de 8 bits et qui sera utilisé pour modifier la résolution verticale.
 
Initialisation du Mode X
L'initialisation du Mode X se fait en plusieurs étapes :
 
- Désactivation du bit chain-4 du registre 4 du TS, afin de "déchainer" les 4 plans pour y accéder individuellement
Ceci se fait en mettant le bit 3 de ce registre à 0. Le code assembleur sera donc :

 
- Autorisation de l'accés en écriture aux 4 plans
Ceci se fait par les bits 0,1,2,3 du registre 2 du TS. Chaque bit représente un plan. S'il est à 1, on pourra écrire dans le plan.

 
- Désactivation de l'adressage de la mémoire vidéo par dword par le registre 14h du CRTC
Ceci se fait en mettant à 0 le bit 6 du registre 14h du CRTC :

 
- Activation de l'adressage de la mémoire vidéo par octet parle registre 17h du CRTC
Ceci se fait en mettant à 1 le bit 6 du registre 17h du CRTC

 
Une fois ces étapes terminées, l'écran est en Mode X.
 
A noter un bug dans Watcom : j'ai mis la valeur 227 et non 0e3 (hexa) car Watcom n'a pas l'air de vouloir compiler si j'indique en hexa des valeurs comprises entre e0 et ef (?)
 
Modification de la résolution verticale
Le Mode X supporte 4 plans. Mais la plupart du temps, on utilisera que 2 plans. On peut donc imaginer utiliser la mémoire restante pour augmenter la résolution, et parvenir ainsi à une résolution de 320x400 par exemple.
 
La résolution verticale est controlée par les bits 0-4 du registre 9h du CRTC. Pour 400 lignes, ces 5 bits sont à 0. Si on veut baisser la résolution verticale, on indique dans ces bits le nombre de fois ou les lignes seront affichées, moins une. Ainsi, pour une résolution de 200 lignes verticales (chaque ligne est donc affichée 2 fois), on aura la formule suivante :
 
fréquence = 2 lignes
2 - 1 = 1
d'ou la répartition des 5 bits : 00001
 
Pour une résolution de 50 lignes comme dans mon exemple :
fréquence = 400 / 50 = 8
8 - 1 = 7 (= 00111 en binaire)
 
Ainsi, le code pour passer en mode 50 lignes verticales sera :

 
Voilà. Tout ceci peut paraitre complexe. N'hésitez pas si vous avez des questions.
 
 
Un mot sur le source
En guise d'exemple, j'ai recodé le plasma de l'article précédent en Mode X. Afin de constater l'effet obtenu, je n'utilise qu'un plan, la résolution est donc de 80 pixels de large. Afin de ne pas déformer le plasma, j'ai créé une résolution verticales de 50 lignes, le plasma garde donc ses proportions.
 
Prochain article : on attaque la 3D doucement avec le starfield en 3D

ca me parait mal barré pour la portabilité

 
ati repompe le code a harko

C'est vrai en plus
Il contient divers registres liés au timing du balayage (entre autres), si on y poke n'importe quoi ça peut faire des dégats...
J'ai codé des copper lists qui s'appuient sur ce circuit, à un moment donné mon écran sifflait !

harko, pour le "e0", je pense qu'il faut tout simplement mettre "0e0" (avoir toujours un chiffre devant une lettre en hexa).
 
par contre pour la rapidité par rapport au mode linéaire, ça se discute, disons surtout qu'en mode linéaire tu as pas deux pages écran pour pouvoir faire du double buffering en vga, et qu'en mutli-plan tu dois pouvoir trouver des gruges pour des animations...
mais de toutes façon vive DOS4G et le VESA 2.0

ben non, j'ai testé toute valeur comprise entre 0e0h et 0efh et il compile pas car il me prend le "h" comme un symbole
 

clair, de toute façon plus personne ne code en Mode X

 
plus personne ne code en mode dos je dirais meme

putain, mon public se restreint de plus en plus après chaque article...

ben ouais.. ca blueflag a mort sur 2 pages pis apres ben pu rien

ceci dit c'est clair que le Mode X c'est un peu la mort... va falloir avancer les articles plus sympas comme les Vector Balls, les Metaballs, objets 3D, etc

... savent pas ce qu'ils ratent ...

Les écrans modernes ne sont pas protégés contre ce genre de trucs ?
Il me semble qu'ils n'accèptent pas n'importe quelle fréquence.
 
Celà dit, t'as raison, à l'époque, je me souvient qu'on disait qu'un prog ne pouvais pas endommager le matos, sauf... l'écran. On avait peur de se manger un virus qui fasse exploser le moniteur

Oui, les écrans actuels se mettent en veille si jamais on leur envoie une valeur à la con
Mais bon, pour ceux qui seraient susceptibles d'avoir des vieux écrans, autant être prévenu

chuis toujours là moi
je lirai ce soir car pas le temps en journée