Reprise du message précédent :
Bon, je vais me remettre à l'asm x86, je ferais bien le starfield (je l'avais fais y'a 5 ans). Je suis en train de revoir toute l'architecture x86 là.

\o/
par contre fais moi plaisir : fais de l'assembleur 32 bits, du vrai, pas de seizebiterie des années 90

Euh ouais, j'étais parti là-dessus

et comme assembleur, je te conseille RosAsm. il se suffit à lui même, n'a pas besoin de linker, et truc sympa, il permet de sauvegarder le source du programme directement dans l'exécutable.
c'est du clé en mains

Ah, parce que je viens de chopper nasm, et il lui faut justement un linker à part (sauf pour des .exe 16bits, mais nan)... Je vais opter pour RosAsm alors

Je te conseille FASM, il est multiplateforme, innovant et le projet évolue encore beaucoup, pas comme NASM. http://flatassembler.net/docs.php?article=design

Maintenant j'ai commencé à donf' sur rosasm, j'étudierais un peu plus tard les différents assembleurs. Là faut que je souvienne de tout, ça fait 5 ans que j'en ai pas fait

+1 avec dap++, Fasm est le meilleur assembleur, que tu pourras utiliser quand tu auras récupéré les bases avec Rosasm, qui est également excellent mais surtout qui se suffit à lui même (entêtes Win32 compris)
Par la suite, tu pourras faire mumuse avec Fasm, couplé à un super IDE : RadAsm
Par contre, fuis HLA comme la peste (c'est un assembleur à base de macros, qui finit par ressembler à un langage de haut niveau. ou est l'interet ? autant faire du VB)

Ouais, en examinant les différents assembleurs dispos, je suis tombé sur HLA, et ça m'a direct moins interressé

Bon, j'ai parcouru toute la doc de rosasm, j'me suis remis dans le cerveau un peut toutes les notions de registre, d'adressage, etc.
 
Maintenant, rosasm ne sort que des PE win32, et pour utiliser les bonnes-vieilles interuptions DOS, forcément ça marche pas Je crois que je vais bouger sous FASM pour pouvoir refaire du bon vieux mode 10h, à moins que çe ne soit la forme de 16bits que tu ne voulais pas que je fasse...

bah initialise un contexte directdraw

Ouais mais voilà quoi... J'veux faire du vieux en 13h, alors si je dois me taper du directX, ça va pas trop l'faire
 
Et là j'ai bien avancé, j'arrive à afficher un pixel blanc au milieu Voilà le code :

org 100h
 
    mov ax, 13h
    int 10h
 
 
    mov al, 30
    mov bx, 160
    mov cx, 100
    call outPix
 
waitloop:
 
    mov ah, 01h
    int 21h
    test al, al
    jz waitloop
 
 
    mov ax, 4C00h
    int 21h
 
outPix:  ; al => couleur, bx => x, cx => y
 
    push ax
    mov ax, 0A000h
    mov es, ax
 
    mov ax, 320
    mul cx
    add ax, bx
    mov di, ax
 
    pop ax
    stosb
 
    ret

J'ai tout pigé à 100% et tout refais moi-même

maintenant, tu me fais la même, mais avec le pixel qui se déplace de gauche à droite, synchronisé avec l'écran

AYééééééé !

org 100h
 
    mov ax, 13h
    int 10h
 
mainloop:
 
    mov edx, 0
 
    renderloop:
 
        ; Récupération de la position de l'étoile
        mov bx, WORD [starsX+edx*2]
        mov cx, WORD [starsY+edx*2]
 
        ; On efface la position actuelle
        push edx
            mov al, 0
            call outPix
        pop edx
 
        ; On soustrait la vitesse
        push ax
            movsx ax, [starsV+edx] ; conversion byte -> word
            sub bx, ax
        pop ax
 
        ; Si x < 0, on remet à 319
        cmp bx, 0
        jg assignX
 
        mov bx, 319
 
        assignX:
            mov [starsX+edx*2], bx
 
        ; Affichage de l'étoile
        push edx
 
            ; On addition la vitesse à 22 (histoire du dégradé qui va de 22 à 30)
            mov al, 22
            add al, [starsV+edx]
            call outPix
        pop edx
 
        ; Itération sur les 10 étoiles
        inc edx
        cmp edx, 19
        jle renderloop
 
 
    ; vérif si pas de touche pressée
    push ax
        mov ah, 06h
        mov dl, 0FFh
        int 21h
        test al, al
    pop ax
    jz mainloop
 
 
    mov ax, 4C00h
    int 21h
 
outPix:  ; al => couleur, bx => x, cx => y
 
    push ax
    mov ax, 0A000h
    mov es, ax
 
    mov ax, 320
    mul cx
    add ax, bx
    mov di, ax
 
    pop ax
    stosb
 
    ret
 
 
starsX dw 200, 120, 50, 20, 180, 310, 280, 10, 140, 190, 300, 40, 130, 80, 20, 170, 290, 95, 25, 170
starsY dw 2, 10, 24, 35, 40, 52, 58, 62, 75, 82, 98, 110, 120, 122, 133, 148, 159, 182, 195
starsV db 2, 1, 1, 8, 4, 5, 7, 3, 1, 4, 2, 1, 2, 2, 4, 5, 4, 1, 2, 6

Alors évidemment c'est pas très élégant, mais ça fonctionne :

• 20 étoiles
• Les plus "éloignées" vont moins vites et sont plus sombres
• Trois tableaux pour position X, Y et vitesse (un peu moche, mais facile à implémenter
• Les position et vitesses sont aléatoires, mais entrées à la main
• Y'a pas de synchro verticale pour l'instant, sous DOSBox faut réduire le nombre de cycles CPU à 15 (c'est 3000 par défaut) pour que ça soit pas trop rapide

Y'aurait un moyen simple de débugger en mode 13h ? Possible, pas possible ? Parce que là je suis en train de refactoriser, en utilisant mieux les registres, en utilisant la stack pour la méthode outPix, mais ça marche plus

outPix ne doit pas être callé, mais inliné.

Uniquement pour des questions de performance, nan ? Là je veux le caller juste pour la science. Je verrais après pour les perfs

Bon sinon pour le debug j'ai trouvé : Une version debug de dosbox

 
certes    
mais la philosophie de l'asm c'est les perfs

Effectivement Mais comme j'apprends, je tests quelques trucs. Là j'ai réussi, on push sur la stack la coordonnée x, la y et la couleur. On call la fonction outPix, et ça roule, tout est récupérer dans la stack frame.
 
Maintenant c'est sûr, ça à un coût. La permière version avec registres est normalement plus speed. J'ai vu ça en cherchant justement les conventions de calling, un __stdcall va faire en pushant les paramètres sur la stack, alors que __fastcall utilise des registres (mais est forcément plus limité). Enfin y'a l'inlining de la fonction, qui se passe de commentaires, c'est évidemment la plus rapide.

Alors j'ai modifié plein de trucs, notamment les étoiles sous formes de carrés.

Au lieu d'utiliser une fonction qui affiche un pixel tout seul, j'ai fait une
fonction qui affiche une ligne horizontale. Un carré est alors simplement une
succession de lignes horizontales.

On peut dessiner une ligne horizontale très facilement : on calcule l'adresse
du premier point, il suffit alors d'afficher un pixel en incrémentant l'adresse,
jusqu'à ce qu'on atteint la longueur de la ligne. Avec l'opérande rep stostb,
on peut faire justement ça. Suffit de stocker dans DI l'adresse de base, dans AX
la couleur, et dans CX la longueur de la ligne :

;
; Draws an horizontal line
;
; @param word x
; @param word y
; @param word length
; @param color
drawHLine:
 
    push ebp
    mov  ebp, esp
 
    push ax
    push cx
    push dx
    push di
 
        mov ax, 320
        mul WORD [ebp + 8]
        add ax, WORD [ebp + 6]
        mov di, ax
 
        mov ax, WORD [ebp + 12]
        mov cx, WORD [ebp + 10]
 
        rep stosb
 
    pop di
    pop dx
    pop cx
    pop ax
 
    pop ebp
 
    ret 8

J'ai utilisé la convention __stdcall, comme en C, pour les appels de fonction.
On push sur la stack les paramètres de droite à gauche, et on appelle la
fonction. Elle se charge de nettoyer la stack des paramètres ensuite.

Pour dessiner un carré, on appelle cette fonction de lignes horizontales. On
spécifie les coordonnées du coint supérieur gauche, et la longueur du côté.
On dessigne par lignes horizontales de la fin au début : on précalcule la dernière
ligne, et on dessine jusqu'à ce qu'on arrive à la coordonnée y spécifiée en
paramètres :

;
; Draws a square
;
; x & y are top left coords
;
; @param word x
; @param word y
; @param word size
; @param word color
drawSquare:
 
    push ebp
    mov  ebp, esp
 
    push ax
    push di
    push cx
    push dx
 
        mov ax, WORD [ebp + 8]  ; y
        add ax, WORD [ebp + 10] ; y + size (square is drawn bottom to top)
 
        squareLoop:
 
           push WORD [ebp + 12]
           push WORD [ebp + 10]
           push ax
           push WORD [ebp + 6]
           call drawHLine
 
           dec ax
           cmp ax, WORD [ebp + 8]
           jnz squareLoop
 
    pop dx
    pop cx
    pop di
    pop ax
    pop ebp
 
    ret 8

 
Il y a matière à optimisation, au lieu d'appeller drawHLine, on pourrait
précalculer l'adresse du pixel supérieur gauche, puis dessiner cash la ligne.
Pour passer à la ligne suivante, suffirait d'ajouter 320 à di, pas besoin
de recalculer l'adresse du point suivant. Je ferais ça plus tard.

J'ai aussi fait deux fonctions pour basculer en mode 13h, et une fonction pour
attendre la synchro verticale :

;
; Init mode 13h and init ES at base video address
;
initScreen:
 
    push ax
 
        mov ax, 13h
        int 10h
 
    pop ax
 
    push 0A000h
    pop es
 
    ret
 
 
;
; Wait for VBL
;
; © Harko
;
waitVbl:
 
    vblStart:
 
        mov  dx, 03DAh
        in   al, dx
        test al, 8
        jnz vblStart
 
    vblEnd:
 
        in   al,  dx
        test al, 8
        jz   vblEnd
 
    ret

Avec tout ça, remplacer les étoiles sous forme de pixels par des étoiles sous
forme de carrés est trivial. Suffit de spécifier la taille de chaque étoile.

Faut juste encore modifier la réinitialisation des étoiles. On ne les remets pas
à 319 pixels, mais à 319 - taille, sinon les étoiles débordent, et un morceau
apparaît de l'autre côté de l'écran (on risque même d'écrire dans des adresses
pas trop autorisée)

Voilà le programme final. Les fonctions sus-mentionnées sont dans un fichier à
part, "draw.inc" :

org 100h
 
call initScreen
 
mainloop:
 
    mov ecx, 19 ; Star counter
 
    call waitVbl
 
    renderloop:
 
        mov ax, WORD [starsX + ecx * 2]
        mov bx, WORD [starsY + ecx * 2]
 
        push 0                          ; Clear current pos
        push WORD [starsS + ecx * 2]
        push bx
        push ax
        call drawSquare
 
 
        sub ax, WORD [starsV + ecx * 2] ; x -= speed
        cmp ax, 0                       ; If x < 0
        jg assignX
        mov ax, 319
        sub ax, WORD [starsS + ecx * 2] ; x = 319 - size
        assignX:
            mov [starsX + ecx * 2], ax
 
        mov dx, 22                      ; 22 = base color
        add dx, [starsV + ecx * 2]
 
        push dx
        push WORD [starsS + ecx * 2]
        push bx
        push ax
        call drawSquare
 
 
        dec ecx
        jnz renderloop
 
 
    mov ah, 06h
    mov dl, 0FFh
    int 21h
    test al, al
    jz mainloop
 
 
    mov ax, 4C00h
    int 21h
 
 
    include 'draw.inc'
 
 
; Stars X position
starsX du 200, 120, 50, 20, 180, 310, 280, 10, 140, 190, 300, 40, 130, 80, 20, 170, 290, 95, 25, 170
 
; Stars Y position
starsY du 2, 10, 24, 35, 40, 52, 58, 62, 75, 82, 98, 110, 120, 122, 133, 148, 159, 182, 195
 
; Stars Speed
starsV du 2, 1, 1, 8, 4, 5, 7, 3, 1, 4, 2, 1, 2, 2, 4, 5, 4, 1, 2, 6
 
; Stars Size
starsS du 1, 4, 2, 5, 1 , 2, 2, 1, 1, 5, 8, 1, 4, 2, 2, 1, 6, 2, 1, 3

Ce qui manque maintenant, outre les différentes optimisations, c'est un
générateur de nombres (pseudo) aléatoires, pour générer les étoiles. Mais faut
le faire à la patte, il me reste encore à étudier tout ça...

bravo, maintenant tu optimises ce bordel : tu réalises toutes les opérations de tracé dans un buffer, et tu copies ce buffer dans la mémoire écran à chaque VBL

et la zik en interuption

Je vais voir tout ça ce soir
 
Pour la musique par contre on attendra

Quand tu connais à peu près l'asm 16, c'est beaucoup dur de passer au 32

non, tu as mêmes moins de restrictions (adressage et instructions/opérandes).
 
maintenant ça dépends comment tu y passes, la difficulté c'est l'os sous-jacent.
 
y'a deux choses: le mode réel et le mode protégé/flat.
 
si tu passes en mode-protégé sous dos avec un dos-extender faut se bouffer les contraintes du dos-extender pour communiquer avec certains services du dos.
 

Le mode réel, c'est uniquement 16 bits, nan

Apparemment oui !
Le mode réel est un mode 16 bits, c'est-à-dire que les registres occupent 2 octets (16 bits)

Mon double-buffering foire    
 

C'est bien, à la place t'as fait un stéréogramme

Héhé, en plus en regardant bien, ça à l'air périodique

 
en fait en mode réel tu peux utiliser des instructions 32bits, la preuve t'en a mis dans ton code.

C'est clair, faut être maso pour encore utiliser l'adressage 16 bits.
 

Au fait je viens de remarquer qu'en utilisant l'adressage 32 bits dans DOSBox avec des adresses qui dépassent 1 Mo ça a l'air de fonctionner correctement, ça passait aussi sous DOS ça ? En fait ça m'étonnerait pas que le processeur tronque l'adresse.
Et le Plasma plante chez moi, toujours sous DOSBox.
 

Les processeurs 32 bit sont toujours capables d'émuler le mode réel, par contre les 64 bit il m'avait semblé entendre dire que non.

Ok. Mais j'avais l'impression d'être schyzo en mixant des ECX et des AX

 
bin c'est du bricolage mais ça peut être pratique.
attention aussi au fait d'utiliser des instructions à opérandes 32bits en mode réel: tu as un octet de préfixe qui peu faire plus de mal de bien
et symétriquement la même chose en mode protégé, les instructions 16bits ont l'octet de préfixe.
 
maintenant parler perfs avec du code en mode réel avec des routines pas complètement inlinées, c'est pas pertinent.

[/quotemsg]

normalement, si le binaire que tu lances est un binaire en mode réel, pour faire court, ça doit être tronqué.

C'est dès lors qu'il faut faire de l'adressage style [machin + eax]. Si je met juste ax, fasm veut pas compiler.

marche très bien chez moi, aussi bien le plasma en 13h qu'en mode X
voici mon fichier de config dosbox  

J'aurais bien essayé de recompiler mais mon disque dur a décider de lâcher hier. Sinon il y un moyen simple pour utiliser un DOS extender en assembleur ?

bizarrerie    
(sinon assembler, pas compiler )

 
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)