Reprise du message précédent :
Ah les demos pc.Je vais pouvoir commencer a en coder !Chouette !
 
Cela dit je code en assembleur sur Amstrad CpC(+),et je code des demos.Je fait aussi des test de gfa basic sur atari et d'ici 1 semaine ,je vais voir ce qu'il est possible de faire avec un thomson(oui,ca existe encore)
revivalcpc.free.fr

lol
 
j'avais un pote de mon frangin qui avait un tetris en GFA basic avec un player de mod et la possibilitée de jouer en null-modem avec deux ST

Le topic des démos, le retour.
 
Bon, il est temps de ressuciter ce topic ! Il n'a jamais été question de l'abandonner, juste de le mettre en sommeil quelques temps, le temps pour moi de résoudre divers problèmes d'ordre personnel
 
Ces problèmes étant en passe d'être soldés, the show must go on
 
Je souhaitais au départ continuer sur ma lancée, et travailler plus en profondeur sur le starfield en 3D. J'avais en effet délibérément "sous-optimisé" l'effet précédent, pour pouvoir ensuite montrer les différentes étapes de l'optimisation d'un tel effet, voire de le recoder entièrement en assembleur. Ceci est toujours d'actualité, et sera fait dans un prochain article. Néanmoins, je préfère donner la possibilité à ceux qui s'en sentent capable de l'optimiser eux-mêmes. Il suffira ainsi de :
 
- "plotter" les étoiles dans un buffer, puis de copier ce buffer dans le VRAM (souvenez vous, lors des 1ers articles, j'ai stipulé que l'écriture directe en mémoire vidéo était très lente, et qu'il valait mieux écrire d'abord dans un buffer, avant de le balancer en mémoire vidéo)
- ajouter un effet de profondeur : les étoiles situées le plus loin sur l'axe Z devront être sombres, puis s'éclaircir au fur et à mesure qu'elles se rapprochent de nous. Il est possible de réaliser cet effet de diverses manières, d'un test de la coordonnée Z, au précalcul d'une palette.
 
Ceci sera réalisé dans un prochain article. Pour le moment, il est temps de passer aux
 
Bases de la 3D
Que ce soit sur les cartes graphiques les plus puissantes, ou en software, tous les objets 3D sont codés exactement de la même façon, et selon le même cheminement (simplifié) ci dessous :
 
- chaque objet est en fait un assemblage de triangles
- les coordonnées x, y et z de ces triangles, nommées vertices (singulier : un vertex) sont placées dans un tableau
- la boucle de dessin va lire ces coordonnées puis placer un point à l'endroit correspondant de la mémoire vidéo. A ce stade, l'objet est mis en place
- puis cette boucle va relier ces points par des lignes pour tracer l'objet. On obtient ainsi un rendu en "fil de fer" (ou wireframe)
- optionnellement, cette boucle va "remplir" chaque face avec une couleur (rendu "faces pleines" ), ou une texture 2D (rendu "mapping" ), appliquer divers effets d'ombrages et d'éclairage (gouraud, phong, etc...)
- puis, la boucle va appliquer une formule à chacun de ces points et les stocker dans le tableau. cette formule pourra servir à appliquer une rotation à l'objet, ou une translation, etc...
- et retour à l'envoyeur : la boucle va lire les nouvelles coordonnées, etc...
 
Ce schéma est toujours le même, quelle que soit la complexité de l'objet.
 
Ceux qui ont lancé la sublimissime Second Reality mentionnée dans l'article précédent, auront surement remarqué qu'elle est truffée de nombreux effets 3D :
- rotation et zoom d'objets (comme le vaisseau du début)
- application de divers effets de remplissage (comme la transparence des 2 objets au début, appelée "rendu glenz" )
- rotation d'une image 2D ("rotozoom" )
- tunnels,  
- etc...
 
Comment réaliser ces différents effets ? Très simple, il suffit de ne jamais oublier LE principe essentiel de la 3D informatique :
 
Animer un objet 3D revient à manipuler l'ensemble de ses vertices
 
Attention, je parle ici d'animation, et pas de remplissage de surface, qui fait appel à d'autres principes, tout aussi simples.
Une fois que ce principe est acquis, il est possible de réaliser n'importe quelle animation d'objet 3D :
 
- zoom, qui consiste simplement à modifier la coordonnée Z des vertices de l'objet,
- translation, qui consiste à ajouter ou soustraire une valeur à la coordonnée X des vertices (l'objet bouge horizontalement), ou à la coordonnée Y (l'objet bouge verticalement), ou les 2.
- rotation, opération un peu plus complexe, car nécessite quelques connaissances très basiques en trigonométrie.
 
Une fois les nouvelles coordonnées 3D calculées, il suffit d'appliquer sur chaque vertex la formule de projection décrite dans l'article traitant du Starfield 3D pour convertir les coordonnées 3D en coordonnées 2D
 
Pour que l'animation soit fluide, chaque vertex de l'objet doit se voir appliquer la formule souhaitée pendant le retour de balayage. Si de nos jours, les machines sont largement assez puissantes, ce n'était pas le cas à l'époque des 286-386, et il fallait donc optimiser à fond ces calculs. En effet, il est possible d'appliquer simultanément plusieurs formules (si on souhaite par exemple tourner un cube, et le zommer en même temps), et ces formules, notamment les multiplications, prennent énormément de cycles machines. Il fallait donc tout faire pour optimiser au maximum.
 
Je décrirai les différentes formules de transformation 3D dans les articles suivants, d'ici là, j'invite tous ceux d'entre vous qui ne l'ont pas encore fait à télécharger Dosbox et la merveilleuse Second Reality (cf article précédent)

yeah, on va avoir 2/3 topic 3D en tête de la cat

rah !!!!!!!!!!!!!!!

oui, il est temps de rendre cette cat à l'élite

merci

1ere page updated, j'ai rajouté un sommaire

y'a de moins en moins de monde sur ce topic, j'essaye pourtant de vulgariser au maximum

ça va mieux ta libido ?

oui
 
ben alors, pas de volontaires pour optimiser le starfield en 3D ?

C'est pas mal car Céline commençait à se plaindre ici !

 
 
spa grave il ne reste que les meilleurs    
 

 
mouais faut voir, ca peut etre faisable, une foi que j'aurais lu tout les chapitre d'avant

euh pour la 3D je serais bien volontaire mais en ce moment c'est un peu gavé de manque de temps... d'ici Noël ça te va???

l'article sera rédigé bien avant

ya besoin de maîtriser les maths pour faire de la 3D de nos jours?

tant que tu te contentes de faire des translations/zoom, il te suffit de connaitre l'addition/soustraction
par contre, pour la rotation, notions de trigo obligatoires (sinus et cosinus)
si tu veux optimiser tout ce bouzin, faut connaitre les matrices

La 3d!

petite précision de ma part:
zoom = translation (c'est une translation sur Z)
les translations peuvent aussi être représentées par un calcul matriciel (de la même manière que les rotations)
chaque matrice (pour chaque transformation) est une application linéaire, on peut donc les multiplier afin d'executer plusieurs transformations en un seul calcul.
La représentation à l'écran correspond à la projection de l'objet sur un des plans de l'espace.
Cette projection permet de résoudre le problème de la gestion des faces cachées (méthode complémentaire au Z-buffering)

je sens que je vais reprendre la lecture de mon vieux bouquin sur la programmation 3D

certains concepts t'échappent?

bin les maths avancées, ça a jamais été trop mes copines, déjà  pour faire une intégrale, je suis dans les choux
'fin dès que j'ai un peu de temps, je m'y remets

bah du zoom tu le fait sans faire de considération 3D. un rotozoom, c'est juste des vecteurs 2D qui tournent pour la rotation avec leur longueur qui change pour le zoom.

magne toi de t'y remettre, parce que la rotation c'est rien du tout en comparaison de ce qui t'attend quand j'aborderai l'éclairage
sommaire :
- produit scalaire,
- normale,
- et plein d'autres invités surprises

et après on abordera la transformée de Fourier

et tu comptes aborder aussi le maillage?
 
edit: et les marching polyhedrons?
et le ray-tracing?

pour le ray tracing, y'a qu'à lire le topic de LeGreg, il explique bien mieux que je pourrais le faire
pour le reste : c'est quoi ?

bah le maillage c'est du maillage quoi... application d'un maillage pour le rendu de formes complexes... on en trouve divers types (carré, hexagonal), et des super marrants genre maillage multi-résolution à base d'ondelettes
 
Les marching-trucs c'est des systèmes de rendu à partir de formes géométriques de base (cubes, tetrahèdres, sphères etc.). C'est un tracé par interpolation des voxels.
 
Et dans la lignée synthèse d'image tu peux attaquer bezier et splines.
 
Puis finir dans la 4D avec la dynamique, dynamique inverse, cinématique et cinématique inverse

Bezier & Splines, j'avais prévu de le faire
Par contre, pour le reste, je te le dis franchement : je n'y connais rien du tout
Ceci dit, si tu veux apporter ta contribution à ce topic en éclairant le pauvre ignare que je suis dans ce domaine (et bien d'autres surement), y'a aucun problème

faudrait que je retrouve mes cours de maîtrise et de DEA, mais pourquoi pas faire une synthèse de 2,3 trucs oui...
(quand je pense que j'avais promis aussi de faire un topic dédié IA, classifieurs etc. )
comme je disais tout à l'heure, d'ici Noël peut-être

ca ve en faire des truc à lire

 
rapide

  ce topic est mort je crois  

non il est pas mort
je manque de temps en ce moment, mais j'y pense

Salut !
 
C'est super ces effets oldskool mais pourquoi ne pas les avoir fais sous DirectX / OpenGL ? C'est plus propre, plus rapide, plus in en fait. Y a pas d'intérêt ? Bein si, y en a un : c'est plus simple et plus rapide tout en étant plus léger et en utilisant le matos de nos jours.
 
Je voulais savoir pourquoi les démos dos et tes effets donc, saccadent sous XP Pro : ils sont fluides pendant disont 20 frames puis y a une saccade puis ça repart et ainsi de suite en boucle.
 
J'aimerai bien savoir pourquoi sur PC pendant des années il y a eu des saccades et encore aujourd'hui. Oui, pourquoi sur cette machine y a plus de saccades qu'ailleur (sur Amiga ou ST par exemple).
 
Pour ce qui est de la synchro vbl, j'ai pas compris pourquoi y a 2 fois le test. De plus pourquoi est ce qu'on est obligé de bloquer le CPU sur une attente alors qu'on pourrais l'occuper à d'autres choses. Il y a pas d'interrupt VBL comme sur Amiga ou ST sur PC ? Et en DirectX ça se fait comment ?
 
Et puis pourquoi copier brutalement un buffer complet pendant la VBL, alors que sur Amiga y avait moyen de juste changer les pointeurs bitplanes pour faire le switch (5 words à écrire au lieu de 32000 (64000 pixels) à copier ? Faut m'expliquer si c'est possible d'optimiser.
 
Tu parles de masque plus haut, explique complétement la notion stp (avec les opérateurs logiques et à quoi ça sert dans tous les cas possible).
 
En tous cas ces sources c'est super.
Merci.

 
c'est expliqué au début, question de nostalgie (retour aux sources powa)
 
 

 
win XP émule le DOS, sous un OS en mode protégé acceder a la mémoire causerait un simple refus du systeme "memory can't be 'written'".
donc avec une telle couche d'abstraction tu rajoutes 1000 OPCODE pour une lol
 
 

 
question d'architecture.
PC: centrée sur CPU
amiga: parrallèle (multi proc)
 
de nos jours si il y a des saccades c'est parce que les développeurs utilisent des dynamic occlusion culling et 85000 textures en 2048*2048 pour un seul niveau (voir far cry) enfin que des gouffres a performances et de plus tout ceci a un niveau assez elevé prog->compilo_HighLevel->lib->OS->driver->HAL->µcode->bus->CG->etc...
 
 

 
DX demande aux pilotes vidéos quand il faut balancer le backbuffer dans le front. (par swaping de pointeurs ou par copy en fonction de ce qu'on a mis a l'initialisation D3DSWAPEFFECT_DISCARD etc...)
 
le reste qqun d'autre répondra
 

 
copymem utilise les + grand mots possible pour la copie c déja ca.
en AMD64 ca doit etre encore mieux
question de choix, comme marqué + haut le pointers swaping est possible en DX maintenant en 13h chui pas expert: pas a moi de répondre.
 

 
on parle de bitmask.
tres souvent utilisé avec les flags.
genre CST | CST2
ou encore, peut etre plus ciblé, si on veut tenir compte d'un quartet dans une variable short:
short var;
var &= BITMASK;
 
avec BITMASK = 0x0F
 
ce qui va se passer c'est que bit a bit (& = bitwise AND) tout ce qui est x & 0 passe a 0 et x & 1 reste a x donc on garde le quartet de poind faible dans ce cas la.
(enfin je pense, parce que avec ces histoires d'indiens on pige pas tout)
 

C'est clair, ils pourraient avoir la même taille

 
Pour la plupard ces effets sont difficile a reecrire en Dx/OGL, parce qu'il necessite un acces direct au framebuffer, ce qui est pas franchement possible (ni meme conseillé) pour un affichage rapide sur les CG modernes
 

 
because en 13h on vu qu'on peut pas modifier l'adresse de ce qui va etre affiché, fo tout recopier a cette adresse.
 

voé mais ya 4 pages non ?
doit bien y avoir moyen de swaper les pages (double buffering ?)
 
lol
edit: il faut que je sorte ?

 
double buffer = deux buffer, ca implique pas que tu swap au lieu de blitter
 
sous 13h on blit
sous DX windowed on blit
sous DX fullscreen on swap (ou on blit, au choix, mais bon, swap roulaise)