🚀 go-pugleaf

Tristan. a ecrit:
> 
> Dive, EnDive, FsDive :
> 
> - What are the differences ?
> Thanks for your lights.
> 
> - Quelles sont les differences ?
> Merci de votre eclairage.
> 
> --
> Tristan.

Bon, alors allons-y pour une petite explication :)

Si tu n'as pas envie de tout lire, dis toi que Dive est l'equivalent de
DirectDraw pour OS/2.. encore que .. Une facon simple et souvent rapide
d'afficher rapidement des images de grande taille dans tout un tas de
modes videos..


Certaines applications ont besoin d'afficher rapidement un grand nombre
de pixels a l'ecran ( c'est le cas notamment des jeux et des "videos"
numeriques ). Dans ces cas-la, la methode classique qui consiste a
faire appel au Presentation Manager et au GPI ( bref le gestionnaire de
fenetres ) s'avere particulierement desastreuse, car PM est une sur-
couche logicielle consequente entre l'application et la memoire video.

L'alternative a PM est l'acces direct a la memoire video. Ceci ne pose
pas trop de probleme en plein ecran ou tu peux choisir ton mode
graphique assez facilement ( encore que le SVGA, dur dur ! ).

En revanche, le mode fenetre peut etre un cauchemar : il faut gerer
pas mal de modes videos possibles ( 8 bits palettes, RGB 15 bits, RGB
16 bits (3 variantes), RGB 24 bits, etc .. ) tout en faisant attention
de ne pas bouffer sur les fenetres des autres, sans parler des memoires
videos 'banquees' de cartes assez anciennes. Bref.. le delire.. de plus
tu n'as le droit d'ecrire en memoire que si ton application est bien
a l'ecran ( et pas dans la memoire video d'une appli plein ecran mise
en avant !! )

C'est pour cela que les petits gars d'IBM ont developpe DIVE, afin
d'ecrire un MMPM pas trop trop complique ( encore que .. ). DIVE est
une 'interface' qui permet plusieurs choses :

- Si tu le desires, si tu y tiens absolument, tu peux acceder
  directement a la memoire video en mode fenetre, et recueillir
  des informations sur les zones de TA fenetre qui sont visibles
  ( et oui, c'est important ). Mais tu devras gerer les modes graphiques
  toi meme.

- Si tu ne veux pas trop te fouler, tu peux travailler avec un buffer
  ecran plus ou moins 'virtuel' ( en fait il est alloue dans le memoire
  video jusqu'ici inutilisee ). L'avantage est que tu peux definir le
  format des pixels du buffer DIVE ( comme par exemple RGB 15 bits ),
  et demander son 'affichage' ( le terme technique est 'blitting',
  auquel je prefere 'blittage', plus Francais ) dans ta fenetre courante
  et dans le mode courant. Cela signifie que si necessaire, la fonction
  DIVE de blittage que tu appelles va realiser la conversion RGB15 ->
  8Bits si ton affichage courant est en 256 couleurs !!

  Ca signifie que tu n'as plus besoin de te preoccuper du mode courant,
  simplement de celui que tu veux manipuler.

  L'avantage peut etre double ( je dis bien 'peut' ) : d'abord la
  routine de 'blittage' est de fait generee en fonction de la surface
  visible de ton application. Cela signifie qu'a chaque fois que la
  partie visible de ta fenetre change ( si tu fais passer une fenetre
  devant une autre par exemple ), une nouvelle routine sera
  automatiquement generee ( oui, c'est du code-gen !! ). Cette routine
  est optimisee afin de ne traiter que les pixels qui sont necessaires,
  sans faire de tests a chaque appel, de plus elle realise toute seule
  la conversion de couleurs !

  A j'oubliais !! Ta fenetre peut changer de taille au cours du temps
  ( il suffit de la retailler ). Ton buffer DIVE lui ne bouge pas et la
  routine generee permet egalement d'agrandir ou de reduire l'image
  automatiquement afin de la 'caser' dans la fenetre !! ( la, c'est
  souvent beaucoup plus lent que la simple recopie )

  Attention, c'est que ca ne marche qu'en mode fenetre !

  Il y a mieux !! Certaines cartes videos peuvent assurer en hard
  certaines focntionnalites ( agrandissement/reduction, conversion des
  couleurs, etc .. ). EnDIVE est l'interface utilisee entre DIVE et ces
  cartes pour faire appel a ces fonctions en dur ( d'ou gain de temps )
  A ma connaissance, jusqu'a tres recemment, il n'y avait qu'une seule
  carte supportant EnDIVE ( une ELSA ). Je crois que Matrox ou
  Diamond s'y sont mis il y a peu de temps.. c'est a verifier par
  toi-meme aupres de ton revendeur ( desole.. ).

- Quant a FsDIVE ( pour Full-Screen-Dive ), c'est une extension de
  DIVE censee nous permettre d'utiliser les memes fonctionnalites en
  mode plein ecran ( du vrai SVGA en plein ecran !? ), voire de passer
  dynamiquement du mode plein ecran au fenetre ( comme Alt-Ins en
  Session DOS, mais pour une appli OS/2 ). Malheureusement, c'est pour
  l'instant completement bugge, et le seul mode reconnu est le 320x200
  en 8 bits ( horreur !! Autant faire l'application en plein ecran seul)

  Et j'avoue que je doute fort que FsDIVE soit un jour termine, vu qu'
  IBM vient de declarer que les jeux etait un trop petit marche pour eux
  ( ben voyons.. ). Sans desesperer toutefois, notons que les problemes
  actuels de FsDIVE sont sans doute du a la conception ahurissante des
  drivers video sous OS/2 ( un driver DOS, un driver Windows et un
  driver OS/2 pour la meme carte !! ). L'introduction des drivers 32
  bits de type GRADD dans Merlin devrait sans doute regler pas mal de
  problemes..

  M'enfin, quand je pense que DirectX en est a sa troisieme version
  ( je l'avais dans les doigts hier encore.. ).


Voila, j'espere que tu as pu comprendre ces explications tout de
meme tres techniques. Je voudrai en profiter pour lancer un appel a
tous les hommes de bonnes volontes : qui parmi vous a deja reussi a
fair du SVGA plein-ecran ( ne serait-ce que 640*480 en 8 bits ) avec
un access lineaire ! A l'aide, l'IOCTL $0B de SCREEN$ ne fonctionne pas
correctement chez moi ??

Merci d'avance..

- DAvid