Reprise du message précédent :
chuis toujours là moi
je lirai ce soir car pas le temps en journée

vi vi, je suis un peu en retard, sorry, le temps de régler quelques problèmes à mon futur ex-boulot et je suis à vous

C vrai, le starfield 3D c un des plus beaux effets!! 8)

comment on appelle encore leffet ou en 3d on a deux plans parallales dans lequel on progresse
 

free directionnal plane

jme suis amuse a en faire cet aprem
mario kart finalement c vraiment tres simple    
 
 
sinon ca fait un petit temps que je developpe une intro en 4k
jaimerai y ajouter du son mais les seuls trucs que jarrive a genere c des betes sinewaves, jai deja pas mal cherche pour trouver des infos la dessus mais sen vraiment trouve ce que je voulais vraiment
ne serait que generer un basse je serais deja bien content

update en cours, j'ai des soucis avec le debugger distant VDMSERV de watcom

Le principe de la synthese analogique d'antan  
c'etait d'avoir des oscillateurs simples et de combiner pour avoir des sons plus complexes.
 
Le genre de choses que tu peux faire:
- addition des amplitudes. Pour à partir d'une note simple faire des sons plus riches. (cf théorie de Fourier)
- modulation de frequence. Tu as une porteuse dont la frequence varie en fonction d'une autre fonction oscillante.  
- ajout de bruit, saturation, etc.. La saturation consiste à couper les cretes de tes fonctions oscillantes.
- modification de l'enveloppe. Avec une rampe linéaire en entrée et en sortie pour simuler l'attaque des notes. Tu peux egalement moduler l'amplitude par une énième fonction oscillante.
- varier les types de fonctions oscillantes (creneaux, sinusoides, triangulaires, dents de scie etc..)
 
LeGreg

les echnatillons que jai pour linstant me font penser a certains morceaux de daft punk  
 
en tout cas ca claque  

 
Fourier a dit que tout son périodique était décomposable en une somme de sa série de Fourier (composants sinusoidales dont les fréquences croissent selon n). Évidemment plus tu rajoutes de fréquences plus tu as un son qui ressemble à l'original.
Comme le son est périodique et que tu utilises des fréquences multiples de la fréquence de base la phase d'origine est importante.  
 
Le téléphone utilise deux fréquences il me semble (dual tone). Mais ce ne sont pas des éléments d'une série de Fourier parce qu'elles sont conçues pour n'avoir pas de relation harmonique entre elles.
 

 
C'est ce qu'utilisait Yamaha dans ses synthés à succès des années 80 (avant j'étais presque pas né donc je sais pas).  
Par exemple pour eux un son de piano c'était une source sinusoidale modulé en fréquence par une autre source sinusoidale. la fréquence du modulateur était un multiple ou un diviseur (je ne me souviens plus) de la fréquence d'origine. L'amplitude était modifiée par une enveloppe d'attaque caractéristique (croissante rapide, plateau petit et decroissance lente). Évidemment selon les standards actuels c'est soit "Cheezy" soit "vintage", selon le biais initial pour les vieilles technologies.
 

 
La saturation rajoute des harmoniques dans ton son d'origine
(si la source de départ est sinusoidale par exemple), certains musiciens ne peuvent plus jouer qu'avec des guitares amplifiées, saturées et avec un feedback important (mixage par le son de sortie décalé dans le temps) .

LE STARFIELD 3D
 
Télécharger l'éxécutable
Télécharger le source
Télécharger le dos4gw.exe (à mettre dans le meme répertoire que l'éxécutable).
 
Me revoici, après une petite absence ! Rassurez vous, le topic est loin d'être mort, c'est juste qu'en ce moment j'ai pas une minute à moi. En plus, j'ai eu des soucis avec le débugger de Watcom (pour ceux qui souhaiteraient débugger des programmes en mode dos4g, envoyez moi un MP, je vous expliquerais certains trucs )
 
Voici donc le Starfield en 3D. Fondamentalement, il est très semblable au Starfield en 2D. La seule différence provient du fait qu'il existe maintenant une notion de projection.
 
La projection
 
Qu'est ce que la projection ? Tout simplement la base de la 3D telle que nous la voyons tous les jours. La projection permet de transformer des coordonnées 3D (donc avec 3 coordonnées : x, y et z pour la profondeur) en coordonnées 2D (x et y). En effet, il est impossible avec les écrans actuels de générer des graphismes en relief. Une conversion 3D->2D doit être réalisée avant affichage à l'écran.
 
La formule utilisée pour la projection est très simple. Soit un point 3D de coordonées (x,y,z). Si on veut transformer ces coordonnées en coordonnées 2D (x',y') pour un affichage à l'écran, la formule sera :
 

 
Tout simplement.
 
La constante FOCALE représente la distance se trouvant entre le regard de l'utilisateur et la scène 3D. Plus cette constante sera proche de 0, plus le regard sera loin de la scène.
 
L'origine du système de coordonées 3D se trouve en (0,0,0). Ce point se trouve en haut à gauche de l'écran. Plus la coordonnée z augmente, plus la profondeur augmente, plus le point rentre virtuellement dans l'écran. Plus la coordonnée z diminue, plus le point sort de l'écran. En d'autres termes, l'axe Z est positif du regard de l'utilisateur vers l'écran et négatif de la "vitre" de l'écran vers le regard de l'utilisateur.
 
Ces principes sont donc la base fondamentale de la 3D contemporaine. Tous les logiciels actuels sont représentés à l'écran de cette manière.
 
Revenons au Starfield 3D. Par rapport au Starfield 2D, j'ai rajouté une composante Z dans la structure de l'étoile, ainsi qu'une couleur. Dans le 1er article, j'ai indiqué que les couleurs 21 à 31 de la palette système contenaient un dégradé de gris. On réutilise cette palette en calculant une couleur comprise entre ces index. De même, j'ai conservé la sauvegarde de la position pour effacement de l'étoile. Je vous invite à consulter l'article sur le Starfield 2D pour plus d'infos à ce sujet.
 
La procédure moveStars s'occupe de bouger les étoiles. Elle est commentée et ne devrait pas poser de difficulté. L'algo utilisé est très simple :
 
Pour chaque étoile :
- on efface l'étoile de son ancienne position
- on décrémente sa coordonnée Z pour faire défiler le starfield vers nous
- si Z <= 0, alors on réinitialise les valeurs de cette étoile
- on calcule ensuite les coordonnées projetées selon la formule donnée plus haut
- on clippe ces coordonnées pour pas qu'elles sortent de l'écran. Si c'est le cas, on réinitialise les valeurs de l'étoile
- à partir des coordonnées projetées, on calcule l'offset de la mémoire vidéo correspondant au point
- on sauvegarde cet offset pour effacement de l'étoile lors de la prochaine itération
- on affiche l'étoile dans sa couleur
 
Voilà, c'est enfantin. Evidemment, n'hésitez pas à poser des questions si quelque chose vous parait pas clair.
 
Pour le prochain article, on restera sur cet effet, on verra ainsi comment l'améliorer (comme par exemple changer la couleur de l'étoile au fur et à mesure qu'elle se rapproche de nous, pour simuler un relief, ou alors comment optimiser le code pour afficher plus d'étoiles, etc...). D'ici là, amusez vous à l'optimiser par vous mêmes avec le test de temps machine décrit dans le second article

prems!
 
sympa, je dévore

j'ai une question hyper con
si on enleve le waitVBL dans la boucle principale, ispasskoi?

 
tu vire la vsynch, donc tu va parfois faire une copie de ton ecran virtuel a la ram graphique alors que le faisceau est justement en train de barbouiller a l'ecran (le vrai)
resultat : effet de dechirure (pour shematiser, t'as une moitié de l'image precedente et une moitié de la nouvelle)

bon, alors y'a un truc qui m'echappe qd meme:
- l'ecran est redesinné au moment du "waitVBL": oui?
- tu calcules les pos. des etoiles apres. qu'est-ce qui garantit que ce calcul va pas se terminer apres une vsynch ?  
 

 
tu calcules pendant que l'ecran trace l'image precedente. tu attends la fin remplissage (waitvbl), et quand le faisceau remonte tu balance ton image  
 

 
absolument rien du tout, par contre tu t'en apercevras paske tes FPS feront une sale gueule
 
 

euh la partie "tu balances ton image", c'est ou ds le code?
(désolé si ça fait redite hein)

j'avais pas regardé le code
 
harko vieux porcho, c koi ces acces direct a la ram video ??

bon ben c'est la meme chose il attends juste que le faisceau remonte pour faire ses calculs. quand le faisceau est en haut, avec un peu de chance il a fini ses calculs et le faisceau dessine bien la nouvelle image

(moi j'avais meme pas pigé ce que c'était ce *(truc+machin)=pouet )

ben ui ok mais il calcule qd le faisceau est en haut, mais le tps que ça calcule le faisceau il a deja bougé nan

ouais, c'est fin naze cette notation en plus
 
 
harko fodra qu'on parle

 
nope il calcul quand le faisceau commence a remonter

 waitVBL(); // attente du début du balayage vertical.
  moveStars(); // déplacement des étoiles    
 
moi ce que je lis avec juste ça c'est que moveStars commence une fois que le faisceau commence à descendre

Merci Harko
Par contre petite précision
Tu parles ici de projection perspective. Je précise car des types de projections il en existe un paquet (orthogonale, parallèle etc.). En fait la projection se fait sur le plan de vision de la caméra.
C'est juste une précision tout bête, pour le reste tes explications sont très claires.
Bravo

c'était pour préparer mon article suivant sur l'optimisation de ce source, pour démontrer par a+b que l'écriture dans un buffer est beaucoup plus rapide que l'écriture directe en VRAM

elle a quoi ma notation ?

 
sde la daube qui surcomplique inutilement le code

non, regarde mon article sur le Starfield 2D en page 2 : la fonction waitVBL() attend que le faisceau soit en bas de l'écran, et non en haut. donc je fais mes calculs pendant que le faisceau commence à remonter vers le haut, vu la simplicité des calculs, j'ai largement le temps de tout calculer avant qu'une nouvelle image soit redessinée
 
par contre, dans les prochains articles en 3D, je ferais mes calculs pendant que l'image précédente sera dessinée, et je profiterais de la remontée du faisceau pour copier l'écran virtuel (le buffer) dans la ram vidéo. ici ça va, les calculs sont très simples et ont largement le temps de se faire dans l'intervalle d'un retour de balayage. ça risque de plus être le cas quand il faudra calculer des matrices de rotation et tout le bordel.

Tu as raison, merci de le préciser
 

Merci

ben expliques toi bordel

 
je ne vois pas le gain qu'il y a ecrire
 
 

 
en lieu et place de :
 

qui est quand meme franchement plus lisible
Bon ca fait moins w4rr1Or mais bon.. Quand on fais des tutos on se doit de faire le code le plus clair possible
 
 
 

Ouais mais ce sont des tutos pour w4rr10rs justement

ben j'ai toujours fait comme ça, les habitudes sont dures à perdre
mais bon, je tacherais de faire un effort la prochaine fois
 
edit: ceci dit, je préfère cette notation car elle a le mérite de bien mettre en évidence qu'on ajoute un offset à l'adresse de base de la vram pour trouver l'adresse du point

 

 
j'avais un pote qui refusait religieusement d'utiliser la notation tableau. On avait droit a eds :
 
 

 
la blessure est encore vive
 

cf mon edit précédent

bah c'est pareil

 
et

 

Quand on touche aux tableaux on connait les pointeurs, donc on comprend que c'est pareil... Chais pas, je vois même pas ce qui pose problème en fait...

 
oué ben comme tous les acces a un tableau hein ?
 
 
Regardez ce pauvre javaeux de moins moins il en a ete tout tourneboulé, pensez donc un peu a vos frere codeux qui vivent dans la noirceur de langage d'universitaire sans avenir, cette notation ne leur est pe pas familiere