Bonjour
Je programme en mode 13h et j'aimerais bien passer à une résolution supérieur. j'ai regardé un peu partout à propos des modes VESA et j'ai pas trouvé grand chose (en plus j'ai un peu de mal avec l'anglais dès que les termes deviennent compliqués).
J'ai essayé de faire un prog simple (juste pour essayer) qui se contente de remplir la mémoire ecran pour afficher un ecran bleu uni:
(le mode 800*600*8 a été initialisé avant)
         
        push es
 mov ax,0a000h
 mov es,ax
 xor dx,dx
 
 boucle:
 mov ax,4f05h
 xor bx,bx
 int 10h
 
 xor di,di
 mov al,1
 mov cx,0ffffh
 rep stosb
 inc dx
 cmp dx,8
 jb boucle
        pop es
 
Je n'ai pas réussi à le réduire plus et pourtant lorsque je l'execute en boucle et que je comptabilise les images par seconde (en ajoutant un peu de c++) je me retrouve avec environ 10 images par seconde. c'est un peu faible non?
Si quelqu'un a une solution...
Merci
Chep

tu est sûr que c'est pas ta mesure temporelle qui est foireuse ?
 
avec quoi tu mesures ?

où alors y'a un perte de perf à l'appel du bios vidéo
 

Merci pour les reponses
En fait j'utilisais la fonction time pour obtenir l'heure je crois (j'avais deja été obligé de compter les images dans un autre prog et j'ai fait un copier coller). j'ai essayer en enlevant le décompte des secondes et en remplaçant :
 
mov al,1  
 
par:
 
mov al,couleur
 
et en augmentant couleur à chaque boucle
C'est peut-etre un peu plus rapide mais j'ai (presque, il ne faut pas exagérer) le temps de compter les 256 ecrans qui s'affichent...

bah moi ce que je te propose, c'est de faire 1000 remplissage du buffer vidéo, et de diviser ce qui a été mesuré par 1000, parceque ton aproche par time elle bancale.

je vais essayer...

Le prog met environ 1 min 17 sec pour afficher 1000 images
ca fait environ 13 images/sec. C'est pas très précis comme mesure mais ca suffit pour voir la lenteur. Il n'y avait que la fonction qui tournait en boucle, j'ai chronométré à la main...
Calculer avec time me faisait surement perdre un peu de tps...

non, mais c'est très très bizarre.
 
que l'affichage "banked" soit très sensiblement plus lent que le "linear", je veux bien, mais aussi lent y'a une couille dans le potage
 
t'es sûr que tu attends pas le retour balayage ou autre glissade ?

t'as fait des tests avec les outils fournis avec univbe de SciTech ? (merde la version gratos est pu dispo )

non je cherche ce que c...

bah c'était un soft qui permettait d'obtenir les extensions bios vesa 2.0 pour les cartes qui n'en avaient pas. (soft très interressant lors de l'age d'or des jeux dos svga)
 
si tu veux je t'envoyes les parties gratuites...
 
accessoirement Scitech participe au dev d'OpenWatcom... (la version OpenSource du compilateur utilisé lors de l'age d'or des jeux dos ceci expliquant cela)

J'ai trouvé la version 6.53 (sdd653.exe) si tu peux m'eclairer sur le fonctionnement ça serait cool  
Merci
 
Chep

Tu es sous quel OS ?
Tu es sous le vrai DOS ou dans une boite d'émulation sous un OS 32 bits ?

 
t'as un truc dedans qui s'appelles VBETEST.
 
si en 800x600x8, il débite plus d'images que toi en "banked" c'est qu'il y a un beans dans ton code (je dirai ptet à l'extérieur du code asm), sinon bah y'a un blem ailleurs.

Ok j'ai fait le test, il m'affiche 60 fps. j'en suis loin...
Je suis sous windows 98 j'ai essayer de démarrer le pc sous dos et... c'est encore plus lent! J'y comprend rien!

bah pause un arrêt sur le 'jb', et  regarde si DX est pas corrompu par l'appel du bios.

...
ça se tente...

J'ai vraiment perdu la main en assembleur, c'est quoi ces lignes : ( je parrie que c'est ça qui prend le plus de temps )
 
 mov ax,4f05h  
 xor bx,bx  
 int 10h  

Ca appelle la fonction du BIOS qui réalise le bankswitching, qui prend en argument :
bx = 0 (toujours)
dx = n° de la banque

Bah voila le problème, il vaut largement mieux passer en mode protegé et utiliser un framebuffer complet mappé en mémoire que de passer par le bankswitching

Oui, mais il y aura forcément du bankswitching à faire, que ce soit par le BIOS ou à la main, vu que la VRAM en 13h fait 64000 octets, alors qu'il a besoin de 480000 octets.

Il faut voir que depuis le 386, on peut faire du mode 32bits ce qui a l'énorme avantage de ne plus nécessité de faire du bankswitching et par la même améliore énormément les perfs.
 

Effectivement, j'avais oublié que VESA 2.0 permettait de faire du flat

ptitchep >> essaie de réécrire ton programme avec VBE 2.0 pour voir si tu gagnes en perfs :
 
http://www.geocities.com/SiliconVa [...] /vesa.html

vi mais fo qu'il passe à DJGPP ou au Watcom.

J'ai récupéré masm32 et j'ai remplacé stosb par stosd et je gagne un peu de temps. Expliquez moi comment passer en mode protégé pour avoir un buffer de 480000 octets parce que même en compilant en 32 bits mes segments sont limités à 64Ko
Merci bcp
Chep

tu télécharges DJGPP ou OpenWatcom, et tu compiles avec un Dos Extender comme DOS4G(W), PMODE(/W), ou CWSDPMI. y'en a d'autres mais c'est les plus connus/stables. (petite préférence pour PMODE)

J'ai l'impression que l'installation de djgpp n'est pas très simple... je vais voir pour openwatcom...

open watcom est 100 fois plus simple à installer
pour compiler un programme DOS avec le dos4gw : wcl386 /l=dos4g tonprog.c

Je suis en train de chercher open watcom mais j'ai l'impression qu'il est long a télécharger avec un 56k...

Pouvez vous me dire ou le télécharger  gratuitement?

euh, hein !
c'est un projet Open Source

ok j'ai rien dit c'est que je suis tombé sur open watcom donnation 25$ et quelque... j'ai téléchargé la source depuis le site, 43 Mo... J'en ai pour un bon mois...

Les sources d'Open Watcom, ça se compile pas avec... Open Watcom ?

Le problème de faire des appels de puis le mode réel aux fonctions VBE2, c'est que le proc doit passer en mode protégé, faire le traîtement VBE2 puis repasser en mode réel.
 
Donc l'idéal, tout le monde l'a dit, programmer directement en  mode protégé.

+1
L'idéal c'est d'utiliser OpenGL ou DirectX ou tout autre lib moderne sur un OS moderne.
C'est très simple :
- mode réel = segments de 64Ko max. Faut se prendre la tête pour manipuler des buffers plus gros, tout ça avec des performances médiocres (adressage 16 bits).
- 800*600 = 480 000. Si tu es en 16 bits, ça fait pas loin de 1Mo de mémoire à adresser depuis un OS qui en offre...640Ko. En 32 bits, tu as plus de mémoire à adresser que le processeur (en mode réel) ne te le permet.
 
Et tout ça sans bénéficier de la moindre capacité d'accélération des cartes graphiques. Rien que dessiner une ligne c'est la merde.

+1
Réel = prise de tête sauf pour faire du boot
Protégé = royal !

J'ai (enfin) téléchargé open watcom mais je n'arrive pas a integrer de l'assembleur dans mon code c++:
asm
 {
  mov ax,12
 }
Il me trouve une erreur sur la ligne de l'accolade ouvrante...
Error!E121:col(4) syntax error
.......
 
Chep

L'assebmeur inline dans du code C ou C++ ne fait parti d'aucune norme existante. Chaque compilateur fait comme il veut. Il faudra donc que tu cherches dans la doc de open watcom pour ça.
 
PS : en mode protege 32bit, il est de bon ton d'utiliser EAX à la place de AX

avec OpenWatcom, l'asm il vaux mieux l'utiliser comme ça: