Petite question comme ca : comment faire pour obtenir l´addresse du buffer vidéo d´un ordi dans le but d´écrire dedans comme une brute ?

L´adresse est :

0xA0000000

Cependant, il te faudra un vieux compilateur 16 bits pour gérer ça, car les compilateurs de windows travaillent en mode protégé, et cette pratique est devenue interdite.

De plus, les résolutions que tu auras seront faibles ( 320*200 256 couleurs)

regarde ma page sur mon site :
http://www.fvirtman.fr.st
info / progs / prog graphique en C

Merci JYY
Mais il n´y a pas un moyen pour avoir accès à mon buffer vidéo de 1280x1024x32 bits ?

hum ! tu me poses une colle mais je crois que non :

dans la mesure ou chaque carte se comporte différemment, il n´y a pas de méthode universelle pour accéder aux hauts buffers.

Donc pas moyen de se passer du pilote : l´OS t´interdira purement d´accéder a la carte autrement que par le pilote.
Je te dirais également que l´OS t´interdira aussi de faire des requetes sur la carte sans passer par lui meme...
Donc bon, si tu y arrives, dis moi comment tu fais, mais en mode protégé ( que gere tout OS actuel), ça parait difficile...

pour faire un schéma : mettons que tu fasses du SDL :

SDL -> Windows -> Pilotecarte -> carte
OpenGL -> Windows -> Pilotecarte -> carte
DirectX -> Windows -> Pilotecarte -> carte

et pareil pour Linux ou autres OS...
Un pote me dit que sur le mac on peut toujours écrire sur la mémoire vidéo, mais CT une faille, et que ça a - ou va - etre corrigé.

Dommage dommage.
C´est comme l´accès aux ports ca devient hyper protégé, c´est vraiment bête, enfin...

Tiens, je voulais ajouter : meme si tu y arrives, c´est pas sur que tu sois gagnant :

en effet, imagines que tu veuilles copier 1 Mo depuis la RAM vers la VRAM :

en direct tu es obligé de passer par le pross, et de copier ( meme si tu y fais en ASM)

mais avce le pilote, tu auras par exemple une requete de copie qui passera certes par :

OpenGL -> Windows -> Pilotecarte -> carte

mais cette requete pourra utiliser le canal DMA, optimiser avec le bus AGP, bref, jouir des accélérations matérielles que tu ne peux pas piloter en soft
et a la sortie, tu es largement gagnant

Oui les apis présentent des avantages, mais aller farfouiller dans son tableau de plus de 5 millions d´octets c´est marrant aussi
C´était pour le fun, pas pour en faire quelque chose.

Avec DirectX ( les autres je connais moins donc je m´avancerai pas) tu peux toujours passer par un Lock du BackBuffer et obtenir ainsi une adresse pour y écrire/lire. Attention tout de même c´est une source de ralentissement considérable, c´est donc à éviter autant que possible ( penser à regrouper également les écritures pour ne pas locker/unlocker plusieurs fois) . ..

OUi mais bon l´intérêt résidait dans le fait de se passer d´une API à la DirectX ou OpenGL

Je me demande ( c´est peut etre faux) si justement un lock ne ramene pas une surface en RAM pour pouvoir la lire ? ( a part bloquer le mutex bien sur)

j´arrive un peu en retard, mais voici qq complements : en mode X ( 0xA000:0000 dont parlait JY²), tu peux obtenir des resolutions supérieures en forcant les registres CRT ; la encore c´est maintenant interdit, mais avec un vieux compilo et OS, ça se fait. Autres avantages, via ces fameux registres, tu controles les paramètres du canon à électron ( sur un LCD je sais pas ce que ça donne LOL faudrait tester) : tu peux par ex faire un scrolling extremement fluide juste en changeant un registre qui est en fait un offset appliqué à la zone pointée par le blitter hardware.
Pour les résolutions supérieurs, il te faut passer par qqch telle que la norme VESA, là encore completement dépassé, mais ça permet d´écrire directement sur la carte.
A l´heure actuelle, tu procédes différements avec les nouvelles API : tu demandes la création d´une resources ( genre un backbuffer), tu le lockes ( ça assure la dispo en mem systeme et pas mem video, non adressable directement), là tu peux ecrire dedans directement via un pointeur et qq paramètres, tu unlockes, et ça update l´affichage... voilà voilà

altonfrere : pour eviter les ralentissements du au lock, tu peux creer les ressources en dynamic + pool managed, ça arrange déjà bien les choses ; ensuite le mieux est de locker une texture/surface offscreen ( vu que ça ne provoque pas de stall du pipeline si on gaule bien son truc) et d´updater comme ça
jy² : si si, les locks justement servent à assurer que la ressource est bien dispo, au sens physique ( présente dans la mem system, sinon on la rapatrie en la copiant), et logique ( mutex donc tu parles)

merci LGV il me semblait bien que le lock ramenait tout en RAM, sinon on ne pouvait pas adresser tu m´as confirmé ce que je me demandais, merci