Bonjour !
 
Juste une petite question : est-il possible de contôler la carte graphique via les drivers directement, sans autre étape ?
Sinon, quels sont les autres manières d'afficher quelque chose à l'écran ?
 
J'ai vu qu'il était possible d'utiliser le mode VGA (bof bof !) et le mode VESA. Je ne suis pas trop intéressé par DirectX ou Open GL car c'est trop automatisé : j'aimerais apprendre comment tout cela fonctionne !
 
Quelqu'un aurait des tutoriaux bien faits (français/anglais) sur ce thème ?
 
Merci pour votre aide  

Faut choisir, si c'est via les drivers c'est pas du tout directement, si tu veux afficher quelque chose à l'écran tu peux t'amuser en ASM c'est un fait mais pour faire de la vraie 3D ou un truc similaire t'as qd même intérêt à passer par DirectX ou OpenGL.
 
Et pour bien faire, même si y a moyen de faire de l'ASM sous Windows rien de tel qu'un bon vieux Dos (une machine virtuelle sous Bochs qui est gratos fera l'affaire). Ensuite suffit de reprendre la liste des interruptions, 13h si je me rapelle bien (?) pour afficher un pixel (non 13h c autre chose je sais plus ), et plus simple que ca tu moeurs, tu as 3 registres, un pour la couleur, un pour le X et un pour le Y    
 
Sinon je doute que tu puisses avoir la doc pour ta carte graphique pour en faire quoi que ce soit sous DOS autre que ca, quand j'ai vu les difficultés rien que pour avoir les infos sur une matrox que les gens avaient pour en faire un driver pour Linux, tu peux oublier  

zion : de memoire
 
passage en 320x200x8
 
mov eax,13h
int 10;
 
la base de la mem video est 0xA00000 (??? je sais pu )
fodrait aller refouiller dans des vielles doc(google + mode 13h)

Merci pour vos réponses ^^
 
Alors j'avais trouvé pour le mode VGA et l'int 10h. Mais au mieux, je peux aller en 320*240 avec 256 couleurs. C'est assez restrictif ! De plus, je ne suis même pas certain que l'adresse de base de la mémoire vidéo pointe réellement sur la mémoire vidéo : on dirait plus un emplacement dans la ram.
 
J'aimerais bien pouvoir afficher des résolutions honnêtes (640*480 au min !) avec une profondeur de couleurs correcte (min 16 bits !). Pour cela, il semble exister le VESA ... Mais je me dis que si j'aimerais exploiter au mieux ma carte graphique, le mieux serait quand même de passer par les drivers de celle-ci !
Je suppose qu'entre Windows et les drivers, il y a une sorte d'interface standard, non ? Est-il possible de connaître les détails de cette interface afin d'envoyer mes commandes à la carte graphique non plus par l'intermédiaire de Windows (qui enverra ensuite aux drivers), mais bien aux drivers directement ?
 
Pour Zion : je sais bien que Direct X et Open GL sont largement plus simples et avec un résultat meilleur ! Mais mon but n'est pas d'avoir rapidement de jolies images sur l'écran, c'est plus d'apprendre ce qu'il faut faire pour les avoir ces images ...

Ben oui, c'est le VGA.
Tu peux pas aller plus loin que ca en 256 couleur, et 640*480 en 16 couleurs (ce qu'utilise Windows9x en mode sans echec)
 

 
Le PC possede 2 espages d'adressage : les ports d'E/S (0-65535) et la mémoire vive (0-4Go)
Pour communiquer avec un périphérique, celui-ci utilise un de ces 2 espaces, ou les 2.
Donc le RAM de ta carte est manipulée comme si c'était de la RAM du PC.
Le VGA utilise un fenetre de A0000 à BFFFF (128 Ko) qu'elle utilise d'une certaine maniere pour que l'on puisse manipuler ses 256Ko de RAM (y'a des bascules qui permettent de choisir quelle plan de 64Ko parmis les 4 possibles est affecte quand on ecrit à A0000-AFFFF)
 

 
Le VGA a un avantage : c'est le seul denominateur commun au niveau hardware entre toutes les cartes (enfin toutes celles compatibles VGA, soit le plupart)
Mais il est limité ...
Chaque nouvelle carte SVGA etant radicalement differente des autres, on s'est resigné à un standard logiciel commun : le VESA.
Le VESA permet de monter en 1600*1200 et 32 bits, si la carte le permet, tout ca au moyen d'un BIOS VESA, qui vient s'ajouter au BIOS VGA.
Les constructeurs ne sont pas obligés, ils font ce qu'ils veulent. Ils peuvent supporter une version VESA partiellement.
Le BIOS VESA a lui aussi un gros defaut : c'est du code 16 bits.
Et c'est la que ca devient chiant.
Effacer un ecran de 1600*1200*32 a coup de plages de 64Ko, c'est chiadique et lent.
Pour bien l'utiliser, il faut etre en mode protegé. Mais appeler de code 16 bits reel en mode protege, c'est galere ...
Alors y'a VESA 3 qui offre une interface mode protege. C'est toujours du code 16 bits, mais il est ecrit pour ne pas merder en mode protege.
Mais c'est galere a utiliser.
Faut bien connaitre l'OS car il faut allouer un page de code executable en mode reel, mais sur 16 bits. Et y'a des magouilles a faire, et faut avoir le droit d'utiliser les ports ... bref, faut se coder un vrai driver, et je m'y suis jamais risqué, meme si ca reste dans les cartons (j'attend d'avoir les compétences)
Alors je me suis recemment rabatu sur Linux.
Linux magouille un peu : il utilise le VESA alors qu'il est encore en mode reel (lors du boot) et passe les infos au kernel en mode protege pour qu'il puisse ecrire dans la RAM video ensuite.
Si ca te tente, tu peux jeter un coup d'oeil au sources du driver vesa, dans /drivers/video.
Mais tu peux pas en faire grand chose, il est utilisé pour créer une console et donc juste manipuler du text (par /drivers/video/fbcon.c).
Autant que je sache, le meilleur truc que j'ai vu qui utilise le VESA pour faire de la prog graphique, c'est Allegro.
Pareil, ca part de DOS, mais ca bifurque en mode protege ensuite.
 

 
Je me suis aussi posé la question. Mais je te l'ai dit, c'est dans les cartons.
La seule doc que j'ai croisé la dessus (je l'ai tout juste survolée), c'est les explication (avec exemple je crois) du DDK pour développer ton pilote de carte graphique.
J'avais téléchargé le kit de nvidia aussi (ils ont sorti un langage qui permet d'utiliser directement leur cartes graphiques, ca serait une sorte de synthese DirectX - OpenGL) mais le zip etait fouarreux rien pu savoir de plus
Donc si c'est manipuler ta carte graphique qui t'interresse, je pense qu'il faut s'orienter vers les drivers.
Tu peux farfouiller dans les sources des drivers d'XFree aussi, mais sans aucune doc, perso, j'ai pas pigé qui fait quoi. (j'ai pas trop bataillé non plus)
Sinon y'a les sources de VBeaf, utilisé par Allegro (http://www.talula.demon.co.uk/freebe/). Mais y'a pas beaucoup de cartes. Mais c'est assez simple à lire.
Good luck !

Ca m'a l'air bien compliqué tout ça /
 
J'ai pu voir la page d'un type qui explique comment fonctionne le VESA 1.2 et supérieur. Ca n'avait pas l'air si compliqué que cela mais bon, je n'ai pas encore regardé en détails (en fait, j'aurais regardé en détails si c'était du VESA 3 et pas du 1.2)(autant être à jour ;o) ...
 
Je crois que je n'ai pas le choix : c'est VESA ou rien !
 
Ce qui est énervant, c'est que je n'ai besoin que d'écrire dans la mémoire vidéo, et rien d'autre ! J'aimerais simplement travailler en mémoire vidéo sur un tableau de 800*600 emplacements, y créer mon image, et une fois que c'est fait, j'envoie tout d'un coup dans la mémoire vidéo ! Donc bon, même si le VESA est un peu compliqué, peut-être que c'est quand même faisable : ça restera dans une fonction de toute manière et je ne le programmerai qu'une fois ...
 
Sinon, pourrais-tu m'expliquer ce que sont les modes protégés et les modes réels ?
On en a parlé aux cours, mais on a pas précisé ce que c'était /
C'était un truc du genre que la mémoire conventionnelle du DOS était accessible en mode réel tandis que la mémoire étendue ne l'était qu'en mode protégé ... Quelle est la différence ? Et que faut-il faire au niveau programmation pour utiliser le mode protégé, ou bien le mode réel ?
 
Merci pour ton aide hein ^^

Yodelaï
 
Un p'tit coup de pousse ?

Personne pour répondre à mes pitites questions ?

au fait, pourquoi ces restrictions ? tu veux absolument etre en DOS ?
 
Si jamais tout ce que tu veux c'est barbouillé a l'ecran (sans passer par des fonctions de tracage de primitive ala DX/OGL) alors openPTC pourra te convenir (sous windows, pe il y a de vieille version dos, je ne sais pas). Du tps ou je faisais de la 2D c elle que j'utilisais avec un bonheur non feint (par contre elle se base sur DX, je ne sais pas si c'est ce que tu souhaites)
 
 

 
 
Ces derniers temps, il y a une idée qui traine dans un recoin de ma cervelle et j'aimerais la tester. Cependant, pour cela, je dois pouvoir écrire en mémoire vidéo : je ne peux utiliser ni DX, ni OpenGl. Du moins, je ne pense pas.
 
Et puis même : j'aimerais autant que possible me servir des DX/OpenGl pour ce qu'ils sont : des outils qui facilitent la vie. Mais ils ne sont pas la base de tout ! Je n'aimerais pas être un programmeur qui ne sait rien afficher sur un écran juste parce qu'il ne se trouve pas sur son petit Windows avec ses outils qui prémachent son travail etc ...
Si un jour je passe à Linux (ce qui ne saurait tarder) etc, je n'ai pas envie d'être totalement perdu sans mon DX ! Bon, ok, y a OpenGl, mais t'as compris le principe quoi ! Lorsque je m'attaquerai au controle de la carte son, ce sera pareil ! Et sur Linux, y a pas Direct Sound et je ne pense pas qu'OpenGl pourra faire quelque chose pour moi.
Seule solution : dépendre des autres et attendre que quelqu'un crée une librairie de fonctions ? Tss tss ! J'aimerais être capable de la programmer tout seul
 
Voila, beaucoup de blabla ^^
 
 
Toujours personne pour mes deux-trois petites questions sur les modes protégés/réels ?? Z'êtes des grands timides, hein !?

tu as pense a sdl, c'est portable sur bcp de chose(linux et windows et leur amis) et ca controle le son, la video, les entree clavier, les joystick, bref c'est un direct x portalbe de partout

Ben je n'ai pas un succès dingue
 
On ne me répond pas : pourquoi ? Parce qu'on trouve que je n'ai pas fait assez de recherches ? Ou c'est une bête question ? Ou bien vou savez pas ? Z'avez pas envie ?
 
 
>>> Kick : non, je ne tiens pas à utiliser Direct X, Open GL ou quoi que ce soit d'autre ...

parce que a mon avis peu de gens s'interesse a ca (j'entends par la qu'a priori ceux qui veulent faire du graphique utilisent les libs et ne soucis pas d'avoir un acces aussi direct au matos que tu le souhaite)

 
Surtout parce que l'argument de "si je passe sur un autre OS je serai perdu" est d'un nonsens total dans ce cas-ci, que ce soit sous linux ou windows tu n'as plus accès directement au matos ce qui me parait une très bonne chose et donc ce qu'il doit apprendre ce sont les APIs et non la manière d'utiliser son écran en VESA vu que ca ne l'aidera vraiment pas le jour ou il aura envie de faire un projet réel...
 
Voila peut être pourquoi à part le mec qui réécrit un mini OS (y en a plusieurs qui viennent ici) personne ne s'intéresse à ce sujet et donc ca vole en bide... Et encore, les réponses qu'il a déjà eues sont excellentes (cfr HelloWorld)

Ok les gars, je plaisante plus
 
Posons la question différemment !
 
 
Existe-t-il un moyen de contrôle l'affichage de l'écran facilement ?
 
J'aimerais pouvoir assigner une couleur à chaque point selon un procédé qui m'est propre (--> sans obligatoirement utiliser de la 3D polygonale par exemple).
Vraiment un contrôle pixel par pixel.
 
Un moyen qui soit évidemment très rapide pour que mon programme dispose d'un maximum de ressources.
 
Est-ce possible avec des api Windows ? Voire Open GL ? Pas Direct X (je sais pas pourquoi je ne l'aime pas celui-là ...).
 
Alors ?
 
Vais-je avoir plus de succès ? ^^
 
 
Euuh oui : svp, si vous me proposez une solution, pourriez-vous également m'indiquer sous quelle forme cette solution se présente (librairies, appels systèmes etc ...). Merchi ^^

openPTC te dis-je (maintenant que tu t'es décidé a utiliser des librairies )
 
Portée un peu partout, en plus
 
(pis dx c bien )

 
C'est que le VESA, ça a l'air finalement vachement costaud avec les adressages réels et protégés sur lesquels je ne trouve pas des masses d'infos
 
Donc, Open PTC ne fait que ce que j'avais envie de faire, c'est bien ça ? C'est dommage que ça passe par Direct X (ça fait un intermédiaire de plus) mais bon, c'est déjà pas mal
Ca se présente sous quelle forme ? Une librairie ?
 
Et Open GL, ça le fait ? Tu sais pas ?
Parce que quitte à apprendre à utiliser une librairie, autant en choisir une belle

c'est une librairie, tu peux definir la couleur de n'importe quel pixel de facon toute concon. Ca doit se baser pour sur ddraw pour la version windows. (www.gaffer.org/openptc, de tete, ptet que ca marche pu)
 
OpenGL doit aussi te le permettre mais a mon avis ce n'est pas la meilleure libraire pour ce genre de plaisanterie. (a la base elle est quand meme + orienté polygonale que 2d pixel par pixel)

Merci pour ton aide, Chrisbk, je crois que j'ai trouvé mon bonheur C'est un bon compromis entre ce que je voulais et ce que je ne peux pas encore avoir ^^

Ben j'ai l'impression que sous Windows toute lib graphique est basee sur DirectDraw.
Quand on regarde les dépendances des dll OpenGL, on voit que ca utilise (mais je sais pas a quel niveau) direct draw.
Alors, pour le VESA, je reformule :
le VESA en soit est simple : il te renvoit un pointeur vers la VRAM.
Mais ce qui se complique, c'est ecrire dans cette VRAM.
800*600*16 = 1Mo
Or, en mode réel, tu es limité à des acces par plages de 64Ko
Alors y'a 2 solutions :
- utiliser le VESA en mode protege => VESA 3, jamais réussi, car tres cho
- utiliser en flat real mode
le mode reel flat est une sorte de croisement entre mode reel et protege. T'es toujours en mode réel, mais apres une magouille (passage en mode protege puis come back) tu peux adresser les 4Go de ram, et donc facilement jouer avec le VESA
Donc c'est nickel, sauf que ... t'es toujours en code 16 bits et donc limité à un adressage de 1Mo.
T'as le droit d'aller à + de 1Mo, mais t'es limité (les compilos ne savent pas).
La seule solution : ecrire une routine assemleur qui utilise les préfixes pour atteindre en mode reel 4 Go.
Faut connaitre l'asm, le codage des instructions ... sans compter le code pour passer en flat real mode (asm aussi).
C'est comme ca que j'y suis arrivé à utiliser VESA 3 moi.
Il m'a fallu plusieurs jours pour juste dessiner un point a l'ecran ... pas d'acceleration hardware (c'est chiant de se coder une routine qui dessine un trait...), la souris c'est galere a gérer aussi (tout en software aussi), et tout ca au moyen de ta routine asm qui est la seule a pouvoir ecrire en VRAM ...
En uilisant DirectDraw, tu peux obtenir facilement un ecran ou tu dessines ou tu veux, la couleur que tu veux...
Pareil que VESA, sauf que c'est bcp moins chiant.
Si t'es pas famillier avec le prog Windows, tu peux opter pour otre chose, genre OpenGL, la SDL (qui elle aussi est basee sur DX), Allegro ...
mais tu fais erreur en croyant qu'en jouant avec les registres tu pourras programmer n'importe ou.
Se lier au hardware est le meilleur moyen pour ne pas etre portable.
Avec OpenGL, ton code, il marche sur PC Win/Linux, sur MacOS, sur SGI ...
 
Sinon j'ai farfouillé dans le SDK / DDK pour avoir des infos sur l'interface des drivers videos sous windows.
J'ai été surpris par les exemples et la doc (y'a des drivers complets avec acceleration materielle directX)
Les drivers possèdent une fonction destinee a DX pour qu'il puisse interroger sur les capacites de la carte et les fonctions possibles. Ca doit etre pour ca que OpenGL en a besoin (=> interroger le driver).
On peut ainsi demander directement au driver d'effectuer un blit. C'est ce que fait SetPixel : un blit de 1 pixel.
Pour ca que c'est pas top SetPixel.
Mais c'est debile de passer par le driver : windows le fait pour toi, et y'a rien a gagner.
Nan, franchement, utilises une lib faite pour ca.
Ou alors c'est possible en Win32.
Dans une fenetre, tu peux dessiner ou tu veux ...

petites petites, c'est vite dit. Elles sont pas faciles tes questions  
 
A ma connaissance, dans le mode réel, on accède aux vraies adresses. Alors qu'en mode protégé, chaque processus a son propre espace d'adressage.
Donc l'adresse 0xA00000 en mode protégé ne correspond pas à un vrai 0xA00000, ce que tu y écrit ne pourra pas être intercepté par la carte graphique.

 
D'ailleurs, avec DJGPP sous dos (et surtout son dos extented go32),  l'addresse de la mémoire vidéo était remappée en 0xD0000000

humpf, du temps ou j'etais sous dos, ce bon vieux watcom me sortait du code protégé et j'ecrivais directement a la 0xA00000

Heu juste pour dire qu'on peut très bien créer un moteur de rendu 3D pour des jeux sans utiliser directx ni opengl, simplement en utilisant windows et en faisant de l'affichage pixel par pixel, j'ai moi même créé un moteur de ce type. Si vous le voulez demandez moi !

Surement pas. Autant il était de bon ton de taper directement dans le framebuffer sur un C64 ou une vielle carte vga toute moisie, autant c'est completement ignorer que l'architecture des cartes (et des bus) à qque peu évolué entre temps. C'est contre productif et idiot.
 
Si vous voulez peindre un 'framebuffer' à la main, il faudra soit mapper un bout de mémoire video dans l'espace d'adressage soit demander un transfert DMA (mais c'est à la discretion du driver qui lui sait comment fonctionne le hardware contrairement à vous). OpenGL, par exemple, expose ce genre de méchanisme au travers d'une légere abstraction avec les PBO, Pixel Buffer Object.
http://oss.sgi.com/projects/ogl-sa [...] object.txt
 
Je transfère plusieur giga par seconde de scene raytracé comme celà, merci de me poser la question.