Reprise du message précédent :

 
y'a un stub a lier qui peut intégrer le dos-extender.
 
sous Dosbox, j'ai peur que ça ne puisse pas marcher.
Doom ou DN3D ça marche sous dosbox ?
 
regarde PMODE, c'était mon dos-extender préféré. (déjà il s'initialisait plus vite que dos4g)

En 16bit il faut utiliser si, si, bx ou bp pour adresser. Si tu n'écris pas le registre de segment que tu veux utiliser ce sera ss pour bp et ds pour les autres.

si si, et Doom, DN3D et autres Redneck Rampage fonctionnent parfaitement avec une fluidité remarquable

bon bah c'est farpait alors (t'as pas cité Blood caymale)

Bon, ça fait 3 heures que je cherche, sans trouver.
 
Est-ce que quelqu'un a quelque chose permettant de profiler mon truc ? Y'a une énorme différence de perfs entre la version normalle, et la version double-bufferisée (ça va du simple au double)...

Bon c'est bon, c'est à peu près résolu.

Pour copier le buffer dans la mémoire vidéo, j'utilisais ça :

mov cx, 64000
rep movs byte [di], [si]

Avec es: di qui pointe sur la mémoire vidéo, et ds:si sur le buffer. C'est évidemment totalement naze, parce que je copie octet par octet... alors qu'on peut copier dword par dword direct :

mov cx, 16000
rep movsd

Et ça marche tout de suite mieux

et avec du mmx, tu peux même copier 8 octets à la fois

Ouais j'ai vu sur le forum de fasm, on peut doubler voire tripler les perfs

le top, c'est d'utiliser la FPU pour effacer l'écran

 
Sinon, t'aurais pas un chouette profiler, là ?

Pour optimiser du code natif : http://smallcode.weblogs.us/2007/1 [...] ith-rdtsc/
Mais en 16 bits ça ne donnera rien.
 
Je viens de refaire le starfield en 241 octets : http://pastie.caboo.se/131935
Ca ne marcherait pas d'augmenter l'abscisse de l'étoile même quand ça la fait sauter à la ligne suivante et de rajouter des étoiles en à gauche régulièrement ?
J'ai fait une version où à la place de l'ordonnée je stocke directement l'adresse de la ligne, ça marche aussi bien.

Salut,
 
Je me passionne depuis quelques jours pour ce topic d'Harkonnen sur les demos assembleur et j'ai donc entrepris d'ecrire quelques lignes en suivant quelque peu la progression du topic.
J'ai d'ailleurs pas mal suivi dans un premier temps les posts de la page precedente car je ne fais que de l'asm (avec FASM) sans C. Pour le fun ! Et c'est fun !
 
J'ai fait mon point a l'ecran, ensuite je l'ai fait se deplacer, ensuite en synchro avec le VBL pas de souci ! Me voila rendu au double buffering et c'est la que j'ai un souci.
 
Voici le code tout simple pour ecrire un point dans le buffer et switch ensuite tout le buffer dans la memoire video (A000h).
 
 

 
Le probleme est le suivant : le "blit" buffer -> ecran se passe mal, je suis quasiment sur que c'est la source du blit qui est erronee (le resultat est presque correct sauf tout en haut (=au debut du tampon) une ligne de couleurs incoherente).
 
A mon avis c'est parce que pour faire le movsd, la source requise est de la forme ds:si, si est bon je pense, mais ds ne semble pas pointer au bon endroit (d'ou le resultat pas tout a fait correct)
ds est cense pointe sur le segment des donnees, et donc ds:[memB] est cense pointe sur mon buffer.
 
Avez-vous une idee du probleme ?
Si qqn peut "corriger" et me donner des ameliorations sur mon code il est le bienvenu aussi.
Est-ce la bonne facon de declarer un buffer pour double buffering ?
 
merci

il te manque un: (en début de code)
push cs
pop ds
 
ou
 
mov ax,cs
mov ds,ax
 
pour mettre le segment de donné sur le segment de code. (.com)

 
Je l'ai mis juste apres le org 100h et ca ne change malheureusement rien.
J'ai bien compris l'idee mais ca ne marche pas!  

mov si, WORD [memB]
 
plustôt en:
mov si, offset memB  
ou
lea si, memB
 
là si je suis pas fatigué, mov si, WORD [memB]
charge le word à l'adresse memB (et non l'adresse) dans si: soit 0 (dû à la déclaration de memB)
 
tu blit donc ton code en ram vidéo.
 
---
sinon DS est automatiquement a CS dans un .com, donc ma première réponse est à coté de la plaque.

 
 
Voila c'etait exactement ca (lea si, [memB] pour etre exact) ! Grand merci  

Ou bien mov si, memB. LEA est surtout utile pour les adresses qui doivent être calculées à l'exécution comme celles des variables locales.

Merci pour la precision, je debute alors ca clarifie tres bien l'utilisation de mov.  

Ce qui peut paraître bizarre au début c'est qu'avec FASM/NASM on utilise toujours [] pour accéder à la mémoire, y compris pour les variables globales (le nom de la variable est juste un label typé sur une certaine taille en fait, avec FASM en tout cas).
Avec MASM/TASM on accède aux variables globales sans [] (en fait MASM accepte aussi [] mais on ne l'utilise jamais, TASM je ne sais pas), si on veut l'adresse on ajoute OFFSET devant. En fait TASM avait un "ideal mode" avec une syntaxe du style de FASM mais c'est surtout le mode de compatibilité avec MASM qui est connu.

Je n'arrive pas a comprendre ce qu'il se passe avec la bande bleue (cf debut du topic, tstarfield.c) nous indiquant le temps machine restant / consomme.
Ce que je comprends:
- on est au debut du VBL, on passe en background bleu
- fin des calculs, on passe en fond noir jusqu'a ce que le VBL se termine
- phase de tracage sur l'ecran
 
je ne comprends pas pourquoi ce qui est trace a l'ecran n'est pas tout simplement noir ? Puisque la derniere couleur de fond specifiee est noire justement. Pourquoi le bleu reste la ?
Pour moi au debut du tracage le systeme regarde quelle couleur est specifiee pour le background est c parti, tout en noir dans cas. A posteriori je me trompe !
 
merci pour vos lumieres~

ne pouvant plus tester le binaire (vista 64 proute sur le dos)
je peux pas trop te dire.

 
Virtual PC
VMWare
DosBOX
etc...
 

j'ai vmware d'installé, mais en fait j'avais la flemme

je le suit avec beaucoup d'intérêt depuis à peu près un ans, sans héla, avoir le temps de coder les exemples.
 
et je me demandais :
 
ce post est il mort ?
ou juste en 'sommeil' ?
 
merci, bonne journée

il est pas mort, je reçois régulièrement des MP pour le continuer, mais je manque de temps en ce moment
mais il reprendra, j'en fais la promesse à tous mes nombreux fans, promis juré

chouette !
 
merci encore pour tout ce temps passé à faire connaitre aux plus jeunes, la (douce) folie d'antan de la programmation de démo !

Ben disons que contrairement à la rumeur, la demoscene est LOIN d'être morte :
http://www.pouet.net/
http://www.pouet.net/prodlist.php
 
D'ailleurs je te conseille de mater "Edge of disgrace", une démo sur C64 (oui, LE commodore 64) sortie ya qq semaines et qui prouve que niveau programmation d'effets, certains en connaissent un gros rayon (il te faut Vice, l'émulateur C64).
Tu peux aussi choper des démos en 256 octets, avec le code source (en ASM).
 
Donc non, "d'antan" n'est pas vraiement le terme approprié

Ho c'était une tournure de phrase.
 
Je ne sais pas si , aujourd'hui, on fait encore des démos techniques pour les machines actuelles...
 
En tout cas, "Edge of disgrace" est une vraie tuerie O_O
Je pensait pas un Comodore64 capable de faire ça !
 
C'est du génie à l'état pur, la musique est énorme, les graphismes magnifiques, elle est Géniale !

Hi,
je pense que ce sujet est le plus approrié pour ma question, enfin je l'espère.
Est-ce qu'il est possible de faire du double-buffering en se limitant à la norme VBE2, ie, dans le but d'avoir du code portable.
J'étais parti en pensant exploiter

 
... mais en continuant ma lecture aujourd'hui, ces windows ne semblent qu'etre présent pour pallier à une limitation du Video Bios (16 bit pointer). Et donc, elles ne peuvent pas etre utilisées comme je le pensais pour faire du double-buffering (mais juste pour accéder en lecture/écriture à un buffer plus grand). Donc ma solution initiale tombe à l'eau
 
... Toujours dans ma lecture, je tombe sur "NumberOfImagePages" :

Ces extra-images n'ont-elles comme utilité d'etre seulement des back-buffers et ne peuvent jamais etre swappé pour etre affichées en front buffer (sans copie préalable) ?
 
Bref en conclusion, c'est pas possible ?  
 
Reference: VBE 2.0 - http://docs.ruudkoot.nl/vbe20.txt

Si, mais en mode protégé.
C'est quoi ton OS ?
 
Sous DOS, il faut un dos-extender style DOS/4G, PMODE, par le bios vbe 2 tu obtiens l'adresse physique de la mémoire vidéo, tu mappes l'espace par le DPMI et ensuite y'a qu'à écrire et fixer le début du scan comme tu veux pour faire le page flipping.
 

Veux-tu dire que fixer le debut du scan est une option disponible seulement avec un dos-extender. Je pensais que les dos-extenders n'etait qu'une interface/extension en mode protege des fonctions disponibles en real mode ?
 
Dans mon cas, mon application tourne encore en real mode.
 
Si c'est pas possible en real mode, est-ce que ca voudrait dire que le dos-extender va simuler le flip en copiant les buffer a chaque swap dans la memoire video ?

le dos-extender te permet de juste de tourner en protégé (simplifié, adressage flat), et ce mode protégé permet de projeter toute la mémoire vidéo dans l'adressage flat, et ensuite tu fais ton double buffering comme tu le sens et tu as juste à replacer le début de scan comme ça te plait.
 
Le début de scan est bien entendu en mode réel, par contre là tu retombe en adressage banké, et tu dois remplir le backbuffer par passes de 32/64K.
 
Maintenant si tu veux t'amuser passe par un dos-extender t'as quand même plus de ressource sous la main.

+1 pour le mode protégé, faut quand même être maso pour faire du double buffering en mode réel
d'ailleurs, tous les sources que j'ai posté ici sont codés en mode protégé

Oky, oky, j'essaye de resumer :

On peut avoir deux modes pour le frame buffer :
- Banked Frame Buffer : accessible en real mode. Besoin d'utiliser les banks pour remplir la memoire.
- Flat Frame Buffer : accessible en protected mode. Bankage transparent.

Pour etre sur qu'on a un Flat Frame Buffer mode, on verifie que le mode verifie cette condition ((modeInfo.ucNumberOfPlanes == 1 && modeInfo.dwPhysBasePtr != 0).

Pour changer l'adresse de depart du display :

... Et l'adresse de depart doit etre dans l'interval [PhysBasePtr;PhysBasePtr+TotalMemory*64KB]
avec :
 - PhysBasePtr : physical address for flat frame buffer
 - The TotalMemory field indicates the maximum amount of memory physically installed and available to the frame buffer in 64KB units.

On parle plustôt de Linear FrameBuffer (LFB).
Mais de mémoire oui c'est ça.

 
 
Si j'ai des choses intéressantes/difficultés à raconter par rapport à ce double-buffering, je mettrais à jour ce fil.

faudrait que je le mette à jour aussi
mais pour ça, faudrait que j'arrive à me décoller de Flight Simulator

 
HarkoG

J'adore ces tutos.
J'ai eu enfin le temps de télécharger un compilateur C pour DOS, et j'adore tout ce que l'on peut faire!
 
je dois être fou XD