+ Répondre à la discussion
Affichage des résultats 1 à 10 sur 10
  1. #1
    Candidat au titre de Membre du Club
    Inscrit en
    mars 2006
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 14
    Points : 13
    Points
    13

    Par défaut Demo style "old-school"

    Bonsoir à tous

    tout d'abord je suis agréablement surpris de voir qu'il existe encore des gens utilisant l'environnement Borland pour programmer en Pascal.

    Même si évidemment ça ne sert plus à grand chose d'utiliser cet environnement, je ne peux l'oublier car il m'a fait connaître un vrai langage ... à l'époque j'avais commencé avec Turbo-Pascal 5.0 ...

    Donc je me propose de vous faire partager une petite démo que j'ai récemment fini, en Turbo-Pascal 7.0 ... n'utilisant pas la biblitothéque GRAPH.TPU car j'avais besoins de routines ciblées et rapides.

    Donc tous les calculs, sont faits en Pascal, j'utilise juste une routine assembleur pour la synchro. écran et pour allumer l'écran graphique ...

    juste l'unit CRT pour lire le clavier, sinon le reste c'est du Pascal pure puisque j'accéde directement à la mémoire vidéo.

    Voilà ... bon visionnage et bonne nostalgie

    http://membres.multimania.fr/powel/DOS_16_bits/NOST.EXE

  2. #2
    Rédacteur/Modérateur
    Avatar de M.Dlb
    Inscrit en
    avril 2002
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : avril 2002
    Messages : 2 346
    Points : 3 862
    Points
    3 862

    Par défaut

    Super sympa, ca rappelle des très bons souvenirs !!

    Si tu en as envie, tu peux partager la source des ton (tes) programme(s) sur ce site

    M.Dlb - Modérateur z/OS - Rédacteur et Modérateur Pascal

  3. #3
    Candidat au titre de Membre du Club
    Inscrit en
    mars 2006
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 14
    Points : 13
    Points
    13

    Par défaut

    Salut et merci pour ta réponse

    j'espère que ça a fait revivre de vieux souvenirs.

    Si ce topic suscite plus d'intérêt ça me fera plaisir de poster le source et de le partager avec vous histoire qu'on discute sur la manière plus optimale de faire telle ou telle chose.

  4. #4
    Membre Expert
    Avatar de Dr.Who
    Inscrit en
    septembre 2009
    Messages
    980
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : septembre 2009
    Messages : 980
    Points : 1 299
    Points
    1 299

    Par défaut

    HAAAA MY EYES!

    bien joué, une petite dentro bien sympa, dommage il manque un petit mod en fond histoire de.

    attention par contre, le texte semble défilé plus ou moins vite sur certaines machine ce qui donne mal au yeux au bout d'un moment ... trop de texte.

    faut la poster sur Pouet.net

    si tu veux y ajouter un petit mp3 style chiptune fait moi signe.
    [ Sources et programmes de Dr.Who | FAQ Delphi | FAQ Pascal | Règlement | Contactez l'équipe ]
    Ma messagerie n'est pas la succursale du forum... merci!

  5. #5
    Responsable Pascal, Delphi et Assembleur

    Avatar de Alcatîz
    Homme Profil pro Jean-Luc Gofflot
    Ressources humaines
    Inscrit en
    mars 2003
    Messages
    6 214
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Luc Gofflot
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ressources humaines
    Secteur : Service public

    Informations forums :
    Inscription : mars 2003
    Messages : 6 214
    Points : 40 974
    Points
    40 974

    Par défaut

    Citation Envoyé par powel Voir le message
    Si ce topic suscite plus d'intérêt ça me fera plaisir de poster le source et de le partager avec vous histoire qu'on discute sur la manière plus optimale de faire telle ou telle chose.
    Oh oui !
    Règles du forum
    Tutoriels, exercices, FAQ, sources, compilateurs, outils, livres Pascal
    Mes tutoriels et sources Pascal
    FAQ Assembleur

    Le problème en ce bas monde est que les imbéciles sont sûrs d'eux et fiers comme des coqs de basse cour, alors que les gens intelligents sont emplis de doute. [Bertrand Russell]

  6. #6
    Candidat au titre de Membre du Club
    Inscrit en
    mars 2006
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 14
    Points : 13
    Points
    13

    Par défaut

    Citation Envoyé par Dr.Who Voir le message
    HAAAA MY EYES!

    bien joué, une petite dentro bien sympa, dommage il manque un petit mod en fond histoire de.

    attention par contre, le texte semble défilé plus ou moins vite sur certaines machine ce qui donne mal au yeux au bout d'un moment ... trop de texte.

    faut la poster sur Pouet.net

    si tu veux y ajouter un petit mp3 style chiptune fait moi signe.
    Merci pour le qualificatif "Dentro", car il me semble qu'une Intro ne doit pas dépasser 64 K
    Merci bien d'avoir essayé sur plusieurs machines peux-tu me dire lesquelles étaient-ce ?

    Normalement le scroll text ainsi que tous les autres déplacement sont synchronisés avec la fin du balayage vertical, ce qui veut dire que les déplacements doivent être parfaits !... et ne doivent pas faire mal aux yeux. Mais ça veut dire que j'ai pas pris en compte toutes les différences des matériels existant

    Je viens de jeter un oeil sur Pouet.net, je vais la poster aussi la bas ... merci

    J'avais pensé à une musique en utilisant "sound" de Pascal ... mais tu me surprends, donc il est tout à fait facile d'implementer une musique en mp3 ou mod avec Turbo-Pascal Borland ? si t'as des bouts de codes utilisant le MP3 ou MOD je veux bien y jeter un oeil. Curieux de voir ça. Car je ne connais pas l'utilisation des ports concernant la carte son ... pour l'instant j'ai pas vraiment la foi pour revenir en arrière et améliorer la demo mais pourquoi pas dans une prochaine .... et l'algo. pour décompresser le MP3, s'il existe en Pascal, ça m'intéresse.

    Citation Envoyé par Alcatîz Voir le message
    Oh oui !
    Sinon pour discutailler bouts de ... code ... voici une des parties essentielles, l'affichage des "sprites" ...
    L'affichage d'une image sur l'écran consiste à copier les octets de l'image à partir d'une zone mémoire vers la mémoire de la carte graphique.
    Ensuite on affiche l'image sur l'endroit d'à côté et ainsi de suite on voit une image se déplacer, ce qui est je crois un Sprite.

    Je ne voulais pas de GRAPH.TPU pour l'affichage des images, pour plusieurs raisons :
    - beaucoup trop lent PutImage, ça aurai été impossible de réaliser cette DEMO.
    - le PutImage de GRAPH.TPU n'affiche pas du tout l'image, lorsque celle-ci ne déborde que d'un pixel en dehors de l'écran, et c'était pas acceptable pour ce que j'avais à faire
    - je voulais pas de fichier externe (GRAPH.TPU), et j'avais pas besoin de toutes ses fonctionnalités
    - je voulais un code éventuellement adaptable en Assembleur pour rester dans le ton d'une DEMO et l'utilisation des bibliothéques ne me plaisait pas

    Ils ont pourtant pensé à tout avec PutImage et GetImage, même l'utilisation de XOR, OR, etc ... mais l'explication de la lenteur vient probablement du fait qu'ils doivent appeler leur routine PutPixel ... ce qui est naturel, mais pas optimal. Voilà la structure d'une Image EGA qu'ils ont utilisé.

    Sans entrer dans les détails, une image EGA (16 couleurs) fonctionne en "BitPlan". Par exemple pour afficher une image de 640 x 350 x 16 couleurs, il faut fournir à la mémoire video de la carte graphique, 4 images monochromes d'une résolution de 640 x 350 pixels. J'entends par monochrome qu'un pixel ne peut prendre que deux états (Blanc ou Noir par exemple).
    La carte graphique va en interne "superposer" ces 4 images monochromes pour afficher à l'écran une image de 16 couleurs. Principe qu'utilise par exemple l'AMIGA.

    Le premier pixel de l'image monochrome BitPlan0, BitPlan1, BitPlan2 & BitPlan3 peuvent prendre 0 ou 1 donc en les associant on a par exemple :
    0101 ce qui donnera pour le premier pixel visible sur l'écran une couleur de valeur 5 en décimale. Donc 4 bits on a bien 16 couleurs possibles. Il en va de même pour tous les autres pixels.

    Voilà comment GRAPH.TPU stock ça dans la mémoire dynamique :
    la première rangée d'octets, c'est la première ligne du bitplan3 (exemple : une image de 640 pixels de large = 80 octets puisque 8 points monochromes par octet)
    la deuxième rangée d'octets, c'est la première ligne du bitplan2
    la troisieme rangée d'octets, c'est la première ligne de bitplan1
    la quatrieme rangée d'octets, c'est la première ligne du bitplan0

    la cinquieme rangée d'octers, c'est la deuxième ligne du bitplan3
    la sixieme rangée d'octers, c'est la deuxième ligne du bitplan2
    la septieme rangée d'octers, c'est la deuxième ligne du bitplan1
    la huitieme rangée d'octers, c'est la deuxième ligne du bitplan0

    etc ...

    Ce qui veut dire qu'ils fusionnent dans la mémoire de stockage de l'image, les 4 bits plans. Et comme GetImage requiert un pointeur, vous savez comme moi qu'on ne peut pas allouer plus de 65528 octets en un seul bloc.
    Donc cela limite une image 16 couleurs à environ 640 x 200 (64000 octets).

    Pour pouvoir utiliser le maximum de mémoire dynamique tout en restant compatible avec les fonctions de gestion mémoire fournis par l'UNIT SYSTEM, j'ai décidé de faire autrement.

    C'est simple, chaque BitPlan (de 0 à 3) se réserve son bloc mémoire dynamique. Autrement dit un BitPlan (donc une image monochrome), de 60 000 octets pourrai être de 800 x 600 x 2 couleurs. Et donc les 4 bitplans forment une image de 800 x 600 x 16 couleurs, stockable en mémoire dynamique.

    Donc sans être obligé de me refaire une gestion mémoire pour dépasser la limitation 64K, j'arrive en utilisant la spécificité du BitPlan à stocker par exemple un paysage de 800 x 600 x 16 couleurs.

    J'utilise aussi le côté objet de Pascal ; j'instancie une classe "Image16" ce qui me donne un objet dans lequel je stock l'image. Quand je veux afficher cet objet, j'écris simplement :
    Code :
    1
    2
    3
    4
    5
     
    paysage.disp (0, 0);				 
    arbre.disp (30, 30); 
    montagne.disp (-50, 200);
    etc ...
    Voici donc la classe "Image16" :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    const planMaxSize = 60000;
    var screenH, screenV : word;
     
    type
     Plan = array [0..planMaxSize-1] of byte;	
     
     Image16 = object			   	
      h, v : word;	
      bitmap : array [0..3] of ^Plan;       
      procedure disp (x, y : integer);	
     end;
    Les variables "screenH", "screenV" contiennent les dimensions actuelles de l'écran, car en EGA on peut passer aussi en 320 x 200.
    Le type "Plan" est comme je l'explique plus haut, un tableau de 60000 octets contenant un des 4 BitPlan d'une image 16 couleurs.
    "bitmap" est un tableau de 4 pointeurs. Chaque pointeur indique des données structurées façon "Plan".
    "Disp" affiche l'image en copiant depuis les données "Plan" vers la mémoire de la carte graphique EGA.

    Définition de la méthode "disp" :
    Code :
    1
    2
    3
    4
    5
     
    procedure Image16.disp (x, y : integer);		
     
    var x2, y2, h2, v2, source, target, srcStep, tarStep, i : word;
    begin
    x & y -> coordonnées de l'image. Type Integer volontairement choisi à la place de Word permettant à l'utilisateur de faire déborder l'image exemple : -30, -100
    x2 & y2 -> coordonnées de la zone mémoire qui différent de x et y lorsque l'image à afficher déborde de l'écran ; il est inutile de lire les octets qu'on affiche pas !
    h2 & v2 -> dimensions de la zone mémoire qui différent de h et v lorsque l'image à afficher déborde de l'écran ; il est inutile de lire les octets qu'on affiche pas !
    autrement dit x2, y2, h2, v2 existent en plus de x, y, h, v car il y a découpage de l'image en cas de débordement ... et oui c'est jamais simple la programmation bas niveau
    h2 contiendra le nombre d'octets d'une ligne découpée à copier
    v2 contiendra le nombre de lignes à copier en écartant les lignes invisibles

    source -> dans la zone mémoire où est stockée l'image, numéro du premier octet à lire
    target -> dans la zone mémoire de la carte graphique, numéro du premier octet à écrire
    srcStep -> lorsque l'on a fini de copier la première ligne de l'image, source est incrementée avec "srcStep"
    tarStep -> lorsque l'on a fini de copier la première ligne de l'image, target est incrementée avec "tarStep"
    n'oublions pas que srcStep et tarStep sont évidemmenent différents, car dans la zone source après une longueur de ligne, l'autre ligne se trouve juste après, alors que dans la zone graphique la ligne suivante se trouve (ScreenH / 8) octets après. Tout ça évite d'effectuer les mêmes multiplications entre chaque copie de ligne de l'image pour gratter du temps CPU.

    Code :
    if (x >= screenH) or (y >= screenV) or (x + h < 1) or (y + v < 1) then exit;
    si l'image déborde totalement de l'écran, pas la peine de continuer plus loin puisqu'on affiche rien.



    Code :
    h2 := screenH - x; if h2 > h then h2 := h;
    calcul de h2 : si screenH - x > largeur initiale de l'image alors pas de débordement et h2 = h sinon h2 prendra une plus petite valeure puisque découpage



    Code :
     v2 := screenV - y; if v2 > v then v2 := v;
    calcul de v2 : même principe que pour h2



    Code :
    x2 := 0; if x < 0 then begin x := -((abs(x + 1) shr 3 + 1) shl 3); dec (x2, x); inc (h2, x); x := 0; end;
    Calcul de x2. En cas de débordement horizontal gauche ; x := -((abs(x + 1) shr 3 + 1) shl 3); dec (x2, x); inc (h2, x); x := 0;
    il n'est donc utile de lire l'image dans la zone de stockage qu'à PARTIR DE l'ENDROIT VISIBLE d'où le x := - abs (x) <-- si x = - 30, on lit à partir du 30 ème pixel.
    dec (x2, x); comme x est négatif la decrementation se transforme en incrementation et x2 se trouve incrementé de 30. x = 0 car si l'image déborde à gauche, on commence par écrire les pixels à partir de 0.
    shr 3 est équivalent à div / 8 ... traduit en assembleur par un pur shr 3, donc gain de temps
    shl 3 est équivalent à mul * 8 ... traduit en assembleur par un pur shl 3, donc gain de temps


    Code :
    y2 := 0; if y < 0 then begin dec (y2, y); inc (v2, y); y := 0; end;
    calcul de y2. En cas de débordement vertical haut ; même procédé que pour x2.


    conversion pixels en octets exemple : 640 -> 80
    par exemple si l'utilisateur veut afficher une image à partir de la position -8 horizontale. Et bien inutile de lire le premier octet, puisqu'il est invisible
    1 octet = 8 points . D'où l'utilité de garder x2 et x et tous ces calculs ! il en va de même pour le vertical
    Code :
    1
    2
    3
     
    srcStep := h       shr 3; source := x2 shr 3 + y2 * srcStep; 
    tarStep := screenH shr 3; target := x  shr 3 + y  * tarStep;
    OUF !... toutes les valeurs sont prêtes, il n'y a plus qu'à lancer la boucle qui copie les lignes. Cette boucle sera répété 4 fois pour les bitplans de 0 à 3 ...
    Code :
    1
    2
    3
    4
    5
    6
     
     for i := 0 to 3 do begin
      port [$3C5] := 1 shl i;
      rowsCopy (bitmap[i]^[source], mem[40960:target], srcStep, tarStep, h2, v2);
     end;
    end;
    port [$3C5] := 1 shl i;
    indique à la carte EGA quel BitPlan attaquer : 1, 2, 4, 8 pour dire 0, 1, 2, d'où le shl.


    "disp" utilise une procedure "rowsCopy" qui copie des rangées d'octets, directement utile pour l'affichage d'une image on remarque l'utilisation de "move" et aucune multiplication à l'intérieur de la boucle, afin de gratter du temps CPU
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    procedure rowsCopy (var source, target : array of byte; srcStep, tarStep, rowSize, rowNumber : word);
    var s, t : word;
    begin
     s := 0;
     t := 0;
     while (rowNumber > 0) do begin
      move (source[s], target[t], rowSize);
      inc (s, srcStep);
      inc (t, tarStep);
      dec (rowNumber);
     end;
    end;
    Il est clair qu'à le relecture de mon code, tout me parait compliqué et pourtant pour gérer les cas de débordement de l'image, ne copier que les octets utiles et qu'aucun calcul ne soit fait à l'intérieur des boucles pour un temps d'execution optimal ... il faut ce qu'il faut.

    En tous cas bravo si vous avez eu le courage de tout lire et si vous avez tout compris
    Fichiers attachés Fichiers attachés

  7. #7
    Rédacteur/Modérateur
    Avatar de M.Dlb
    Inscrit en
    avril 2002
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : avril 2002
    Messages : 2 346
    Points : 3 862
    Points
    3 862

    Par défaut

    Très intéressant, je connaissais pas l'histoire du port [$3C5]... Vais jeter un oeil ce soir...
    M.Dlb - Modérateur z/OS - Rédacteur et Modérateur Pascal

  8. #8
    Membre Expert
    Avatar de Dr.Who
    Inscrit en
    septembre 2009
    Messages
    980
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : septembre 2009
    Messages : 980
    Points : 1 299
    Points
    1 299

    Par défaut

    ah oui c'est du TP haha
    alors a moins d'utiliser la lib Ogg ou lameMp3 ou même bass. pas moyen de faire autrement.
    ce qui du coups est moins simple.
    aprés y'a des petites lib pour lire les MOD et XM, sur torry's je crois.
    mais j'ai pas la motivation pour retourner sur ModPlug

    pour le PC : c'est un HP pavilion zv6000 en 60hz rR. pas une bete de course quoi.
    ou alors ce sont mes yeux qui n'ont pas supporter ... tout simplement.
    [ Sources et programmes de Dr.Who | FAQ Delphi | FAQ Pascal | Règlement | Contactez l'équipe ]
    Ma messagerie n'est pas la succursale du forum... merci!

  9. #9
    Candidat au titre de Membre du Club
    Inscrit en
    mars 2006
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 14
    Points : 13
    Points
    13

    Par défaut

    Citation Envoyé par wormful_sickfoot Voir le message
    Très intéressant, je connaissais pas l'histoire du port [$3C5]... Vais jeter un oeil ce soir...
    oui mais attention il faut d'abord lui dire de passer en mode "X"
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
     
    asm
     mov ax, 16     { choix du mode EGA 640 x 350 x 16 }
     int 16
     port [$3C4] := 2; { passage en mode "X" pour pouvoir accéder aux bitplans }
     
     port [$3C5] := 1;
     
     { modification du bitplan 0 }
     
     port [$3C5] := 2;
     
     { modification du bitplan 1 }
     
     port [$3C5] := 4;
     
     { modification du bitplan 2 }
     
     port [$3C5] := 8;
     { modification du bitplan 3 }
     
     port [$3C5] := 15;
     { modification simultanément des bitplans 0, 1, 2 et 3 }
     { autrement dit les octets qu'on écrira ici apparaitront en blanc clair }
     { qui correspond à la couleur 15 de la couleur IBM PC ou EGA par défaut }
    end;

  10. #10
    Candidat au titre de Membre du Club
    Inscrit en
    mars 2006
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 14
    Points : 13
    Points
    13

    Par défaut Changement URL

    Bonjour à tous,

    un an après je reviens avec un prétexte pour remonter le topic
    L'URL de la démo a changé :
    http://caltronik.pagesperso-orange.f...80286/NOST.EXE


Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •