Reprise du message précédent :
un principe oui, sur un LCD, le flux des pixels à travers le TMDS doit être comparable à celui du RAMDAC (ligne par ligne puis pixel par pixel), donc au niveau logique ça devrait être pareil

Ben le problème est que je me base sur la position horizontale du faisceau d'électrons pour détecter le changement de ligne et faire mon changement de palette. Et en LCD, y'a pas de faisceau d'électrons...
De toute façon, si mes effets précédents fonctionnent, ça devrait marcher aussi, vu qu'ils sont temporisés sur la position verticale. A vérifier quand même

oui le CRTC ne sais pas qu'il n'y a pas de faisceau d'électron...
 
quand tu est en vga le retour balayage horizontal, c'est une impulsion sur la broche qui correspond à la chose.
 
pour un LCD, c'est quand le TMDS a fini de transmettre une ligne, qu'il passe ou passe pas une info de synchro, on s'en fout, le CRTC doit être actualisé en fonction....
 
de plus certains LCD sont attaqués en VGA (donc la carte vidéo ne sais même pas que c'est un LCD), et en DVI c'est ce que j'ai dit avant...

Coming soon avant le plasma : les mathématiques à virgule fixe

ça se compile sous linux ce bordel?

malheureusement non
les interruptions que j'utilise n'existent que sous DOS, pas sous Linux

zurte.
est-ce que le code qui est dos-specifique est bien séparé, et si oui, est-ce que c'est adaptable à linux ou bien c'est des concepts qui n'y existe meme pas?

 
Bin le code C/C++/Asm utlisant DOS4G avec Watcom, c'est du code ciblé pour un modèle mémoire "flat" (pas de notions de segements, dumoins de multiples segments de code/donnée), donc le code de traitement serait presque portable tel quel, hormis les accès au bios/registre du hardware dont:
 
1) appels bios mode VGA/mode texte
2) l'accès au framebuffer VGA (segment 0x0A000)
3) l'accès au registres de contrôle du CRTC VGA  
et ptet:
4) l'accès aux services de la souris (mais y'a pas là je pense)

 
ça serait sympa si y'avait moyen d'abstraire ça dans un layer system-specific et faire des demos portables

la démo n'est pas portable, par définition

prff, ça pourrait

 
dans les simples effets ici oui mais en principe une demo est sensée demontrer les possibilité de la machine et la maitrise de celui qui programme  

 
mouais
moi chui de l'avis de --, perso j'aurais attaqué ca via une lib bien portable a la openptc

blablabla, une démo ça attaque le hardware directement, ça exploite la machine et l'OS à donf sinon ça vaut peanuts
 
edit: rien vous empêche de faire une version Linux/BSD hein, d'ailleurs ça vous ferait les pieds

à titre édicatif oui, mais fo voir que Harko veux se caller sur des états du CRTC....

 
je crois qu'il est un brin trop oldschool pour moi

que je sache, un pc sous dos ou linux, ça reste la meme machine
et la maitrise de celui qui programme serait d'autant mieux demontrée s'il était capable de faire un truc portable plutot qu'un truc de porcin qui ne tourne que sur son os

oui bon jvoulais dire les possibilités disponibles a ce moment la (un peu comme ya 10 ans sous dos cetait mode 13h, palette,...)
 
 
en tout cas une demo reste tres proche du materiel....
 
 
sauf que maintenant avec tout les possibilite des os ya moyen de refaire ca de facon logicielle

quand la demoscene a fait la conquête du PC, Linux était encore a l'état embryonnaire, et le topic présente des trucs d'époque donc rien à battre de Linux (et ce n'est pas un troll, merci de ne pas feeder).

c'est sur que unix c'est tout recent comme os
 
là n'est pas la question.
j'espere que c'est pas QUE un topic de vieux cons... je vois pas ce qui empecherait de refaire ces effets de maniere à ce que ça soit portable *maintenant*.

 
il te parle de Linux
 
et je pense pas qu'à l'époque Unix était très répandu sur les machines perso

Je parle de Linux depuis le début -> Linux Is Not UniX. Cesse donc de mélanger tout. (et merde grillé )
 

Sisi absolument et perso j'espère que ça va rester tel quel
 
Harko si t'as envie d'effacer ces salades qui polluent, te gêne surtout pas hein

moins moins, jusqu'a maintenant y'a rien qui soit pas portable, tout ce dont tu as beson c'est une lib graphique supportant le monde 256 couleurs (openptc )

Comme je l'ai dit plus haut, rien ne t'empêche de le faire toi même, t'as le code source, pas mal d'explications, et en plus t'apprendrais quelque chose à le faire toi-même, bref que des avantages.

ben j'ai jamais dit le contraire, keski me fait lui? j'ai juste posé des questions sur la faisabilité de la chose.
 
 
ps: c'est pas parce que l'accronyme dit que linux n'est pas unix que c'est pas le cas...

Ca m'étonnait encore que personne ne m'ait reproché de faire du code pas portable
Pourtant j'avais annoncé la couleur dés le 1er article :

La raison d'être d'une démo est effectivement de pousser la machine dans ses derniers retranchements, en attaquant directement le hardware et les interruptions les plus profondes du système pour obtenir un maximum de vitesse d'éxécution. Une démo n'est donc pas portable d'un système à l'autre par simple recompilation.
Et ce n'est pas un "topic de vieux cons", mais juste une explication des astuces et ficelles utilisées par ceux qui à l'époque n'avaient aucune librairie graphique sous la main, mais uniquement leur imagination et un doc technique en béton. Sans la créativité de ces pionniers, les librairies portables si chères au coeur des linuxiens n'auraient jamais vu le jour !
 
Ces articles continueront à être en DOS + hardware pur, je n'ai pas l'intention d'utiliser une quelconque librairie graphique, ça n'aurait plus aucun intérêt.
 
Pour ceux qui veulent absolument compiler sous un autre système, je leur ai pondu cette nuit une version du feu en SDL, et une autre en Open PTC, certainement les 2 librairies graphiques les plus portables. A vous de vous inspirer de ces exemples pour adaptet les articles suivants, je ne vais pas m'amuser à compiler 36 versions par article.
 
Pour info, les exe sont compilés sous Windows, mais le source est fourni et je n'utilise aucune extension spécifique à Windows.
 
Version Open PTC de l'effet de feu
Version SDL de l'effet de feu

n'écoute pas les râleurs, il y a toujours des gens qui ne sont pas content

surtout qu'ils font mine de pas lire le premier topic
 

LES MATHEMATIQUES A VIRGULE FIXE
 
Bon, maintenant que les intaigristes sont satisfaits (ils le seront beaucoup moins quand on arrivera aux articles ultra bourrins avec le CRTC comme les rasters ), et avant d'aborder les plasmas, il est bon de faire un petit topo sur les mathématiques à virgule fixe.
 
La démo, et la programmation graphique en général, requiert la réalisation de calculs de précision : les calculs de trajectoires, la retouche d'image, etc... nécessitent souvent l'utilisation de fonctions transcendantes (cosinus, sinus, tangente, etc...). Or, pour la plupart, ces fonctions retournent des résultats compris entre 0 et 1. Il n'est donc pas concevable de travailler avec des entiers, les décimaux s'imposent.
 
Un ordinateur ne sait compter qu'avec des entiers, il a donc fallu trouver un format apte à représenter les nombres décimaux.
Le format le plus utilisé aujourd'hui, est le format à virgule floattante (ou format IEEE), qui se compose d'une mantisse et d'un exposant. C'est ce format qui est utilisé par les unités de calcul flottant (FPU).
 
Bien sur, actuellement, tous les processeurs disposent d'une unité de calcul flottant (FPU), mais ce n'était pas le cas au début des années 90. Pour représenter un nombre décimal, il était nécessaire de coder soi même les routines de conversion entier-IEEE.
Evidemment, dans une démo ou la vitesse est primordiale, ce type de routine était exclu car bien trop gourmande. Il fallait trouver une alternative au format IEEE : c'est ainsi qu'est né le format en virgule fixe.
 
Ce format part du constat suivant : un nombre n'est qu'un moyen, et non une fin. Il permet de faire divers calculs, mais sa représentation, finalement, importe peu, à partir du moment ou le résultat escompté est obtenu.
Le principe de la virgule fixe est simple : on décide qu'une virgule existe quelque part dans le format entier. La partie à sa gauche représente la partie entière, la partie à sa droite représente la partie décimale (on raisonne en binaire, et non en décimal).
 
Exemple : représentation binaire en virgule fixe du nombre 413.56 sur 32 bits, en décidant d'accorder 8 bits à la partie décimale (ce qui donne 24 bits pour la partie entière) :
 
000000000000000110011101,10001111 (bien évidemment, la virgule est fictive et permet de distinguer la partie entière et décimale).
 
On distingue en partie entière le nombre 413 (110011101). Etant donné qu'on a choisi 8 bits de virgule, ce nombre a été décalé de 8 bits vers la gauche. Le principe de conversion entre décimal et nombre à virgule fixe apparait ici clairement : pour convertir un décimal en virgule fixe, on le décale vers la gauche du nombre de bits nécessaires à sa partie décimale, ici 8. Ceci revient donc à faire une multiplication du nombre décimal par 256 (2^8) pour obtenir son équivalent en virgule fixe.
 
Le choix de 8 bits pour la partie décimale est tout à fait arbitraire, il est parfaitement possible de choisir 10, 12, 15, etc... bits de virgule. Ceci augmentera la précision de la partie décimale, mais réduira la plage de valeurs pour la partie entière. Une précision de 8 bits est généralement suffisante pour les effets en 2D, la 3D et les fractales peuvent nécessiter plus de précision.
 
La déclaration d'un nombre en virgule fixe est très simple : il s'agit d'une variable sur 32 bits (un long, ou un int selon le processeur employé).
 
Addition et soustraction
L'addition et la soustraction de nombres à virgule fixe se fait sans difficulté :

Aucune difficulté. Les choses se corsent avec la multiplication et la division.
 
Multiplication
Cette opération est la plus difficile et si on n'y prend pas garde, on peut dans le pire des cas planter la machine.
Il faut d'abord prendre garde à la grandeur des nombres qu'on multiplie : la multiplication de 2 nombres sur 32 bits produit un résultat sur 64 bits. Il faut donc faire gaffe à la grandeur des nombres qu'on manipule, sous peine d'overflow.
 
Un autre problème se pose : en effet, considérons le cas suivant.
 

Résultat souhaité pour p : 793.1028 * 256
Résultat obtenu pour p : 51 976 785.1008, soit 793.1028 * 256 * 256
 
On constate donc que la multiplication provoque un décalage de 8 bits vers la gauche, en plus du décalage initial. Ce décalage doit être neutralisé, sinon tous les résultats seront faussés. On divise donc le résultat final par 256 (en le décalant de 8 bits vers la droite) :
 

 
Division
La division de nombres à virgule fixe est également un problème. Soit le cas suivant :

Résultat souhaité pour q : (36.82/21.54) * 256
Résultat obtenu pour q : 36.82/21.54
 
Il faut donc multiplier le résultat par 256.
Pour éviter toute perte de précision, on préferera multiplier le dividende une nouvelle fois par 256 plutot que le résultat final, à l'inverse de la multiplication ou c'est le résultat qui doit être décalé vers la droite, et non le multiplicande ou le multiplicateur. Ce qui donne :

 
Valeurs maximum et débordement
Si on utilise 8 bits pour la partie décimale, alors il nous reste 24 bits pour la partie entière.
En théorie, la partie entière peut donc contenir une valeur comprise entre 0 et 16 777 215 en non signé, et une valeur comprise entre -8 388 608 et +8 388 607 en signé. Ceci est vrai si on veut juste additionner ou soustraire, mais n'est pas valable pour la multiplication.
 
En effet, il faut garder à l'esprit que le résultat est contenu dans une variable de 32 bits, donc la plage de valeurs possible pour celui ci en signé va de -2 147 483 648 à +2 147 483 647.
Exemple : on veut faire l'opération suivante en virgule fixe : 5000 * 5000, ce qui donne 25 000 000.
En théorie, ça tient largement dans 32 bits, mais c'est oublier les 8 bits de la partie décimale.
Le produit vaut donc (5000*256) * (5000*256) = 1 638 400 000 000, il est donc impossible de le stocker dans 32 bits.
La valeur maximum pour un produit en virgule fixe est donc de 32761. Pourquoi ce nombre ? Car 32761 * 256 * 256 = 2 147 024 896.
La multiplication la plus grande possible en virgule fixe est donc 181 * 181 (32761)
C'est le dernier nombre dont le carré converti en virgule fixe tienne dans l'intervalle [-2 147 483 648; +2 147 483 647]

c'est bete, t'aurais fait cet article 3mois plus tot j'aurais pu le copier/coller dans mon rapport de stage

 
 
mais quel roots-bourrin ce harko quand meme  

j'ai viré le début de baston, des sources portables sont dispo, l'incident est clos !
 
Greg >> si tu as des questions, des trucs que tu comprends pas, poste les ici ou en MP et je te répondrais

ya un post de antp qui a disparu la!

notez que dans le cas d'un cpu full 32 bits comme le 386, la multiplication 32bits x 32bits donne un 64 bits, ce qui permet de contourner la restriction de plage décrite par Harko.
 
dans le cas du 68000 ( qui a tout d'un 32 bits ) sauf qu'il est n'est pas capable de faire 32bits x 32bits => 64 bits ou 64 bits / 32 bits => 32 bits de quotien et 32 bits pour le reste, alors que le 386 le peut.
 
a titre indicatif cela à permis au 386 (donc le PC) d'offrir de la 3D mappée plus rapidement que les machines en 68000 premier du nom comme les Atari ST et les Amiga 500 ainsi que les premiers Mac. (les évolutions du 68k ont en suite ainsi évolués)
 
l'avantage calculatoire et fréquenciel du 386 ont donc sonné le glas des ST & Amiga qui n'on pu suivre l'évolution 2D blittée => 3D software.

ben j'en ai posé, j'ai eu des bouts de réponses et des râleries

euh, je lis pas tout, mais le dernier message d'Harko, c'est bien une pseudo-notation mise dans un bloc cpp pour faire joli ?

À mon avis oui, dans le code il le mettra en assembleur

 
mais nan il fait du decalage de bit sur des doubles, comme de bien entendu, d'autant plus que le but est de se passer des virgules flottantes

t'en connais bpc des compilos qui te laisse faire un decalage de bit sur des doubles ?

non, mais c'est pas exclus que certains fassent la conversion implicitement flottant -> int