Reprise du message précédent :

 
Y'a un bat a lancer (setvars je crois, dans le rep de openwatcom) qui regle le pb

Bon j'ai regardé mes vieilles docs, apparemment y'a certaines cartes svga qui ont des registres 8 bits, et d'autres qui ont des registres 6 bits. Donc effectivement, dans le doute, j'utiliserais 6 bits pour la couleur.

Dans le répertoire d'install de watcom, tu as un setvars.bat à lancer (à noter que tu peux choisir lors de l'install si tu souhaites le lancer manuellement ou l'inclure dans tes variables d'environnement).
Et je l'ai dit à la fin de mon article en plus
 
edit:

J'avais choisi l'install auto, et j'avais déjà essayé avec setvars.bat

drapo pour quand jaurai le temp de tout lire ^^

Ok, pb watcom réglé. J'avais installé que le support pour windows 32bits

Allez, juste pour le plaisir :
 
Dans waitVBL, pas la peine de faire mov dx,03dah à chaque passage dans la boucle start, il suffit de l'initialiser 1 fois avant
 
Sinon, comment faire pour intercepter un Ctrl+C ? Parce-que sinon, y'a pas d'appel à resetVideo()...

Une dernière pour la route :
 

 
au lieu de

 
Bon, je pinaille, je sais...

clair, mais bon, j'ai codé ça la nuit hein, j'ai le droit de loucher non ?
 

la fonction kbhit() n'intercepte que l'appui sur une touche unique. tu sors de la boucle en pressant n'importe quelle touche

A mon tour de pinailler : ta solution est plus lente car elle oblige à faire une soustraction, plus lente que le xor nécesaire pour mettre le registre contenant x à 0    
 
Mais bon, sur un P4, on s'en fout un peu

Je vois bien que c'est plus lent, mais çà décale les étoiles les unes par rapport aux autres

 
Bon sinon, l'histoire de la multiplication par 2 pour accéder aux données de la table, c'est bon pour toi ?  

 
Chez moi ça marchait pas; j'ai dû tuer le process

En fait non, parce-ce que je croyait qu'en C, l'arithmétique des pointeur en tenais compte
 
Si tu déclares unsigned int *yTable et bien *(yTable + 1) pointe bien sur le 2éme unsigned int !
 
Tu peux le vérifier,
Dans precalcOffs(), enlève le *2, et dans le main, virre la ligne ypos = ypos+ypos et çà marche très bien.
 
Ben oui, on est plus en ASM là  
 
C'est à se demander pourquoi çà plantait pas avant (dépassement du tableau)
 
Ou alors j'ai rien compris. De toute façon, c'est pas normal que çà marche en faisant *2 ou en ne le faisant pas

je testerais ce soir, c'est space ce truc

La notion de temps machine
 
En regardant défiler les étoiles du Starfield, on peut s'interroger : combien d'étoiles peut on mettre en l'espace d'un balayage vertical ?
 
Tout le challenge de la création de démo consiste à faire le maximum de choses en une VBL, ceci pour préserver la sacro-sainte fluidité de l'animation.
 
Ainsi, il est plus que problable que le nombre arbitraire de 500 étoiles que j'ai fixé soit largement inférieur à la capacité du processeur central. Dés lors, comment connaitre le nombre d'étoiles idéal, celui qui, si on lui rajoute une étoile supplémentaire, fera franchir le cap fatidique de la VBL à la capacité de calcul du processeur ?
 
Oubliez les GetTickCount() et autres fonctions réservées à la programmation Windows. Nous faisons tout à la main.
 
Nous pourrions utiliser l'instruction assembleur RDTSC, qui compte les cycles. Seulement, ce nombre n'est pas très parlant, et surtout ne veut strictement rien dire d'une machine à l'autre.
 
Ce qui serait pratique, c'est un moyen de visualiser à l'écran le temps qu'il me reste avant que le faisceau n'arrive en bas de l'écran. Ceci est possible par une petite bidouille en assembleur.
 
Le principe est très simple : avant que le faisceau ne soit en bas de l'écran, on définit la couleur de fond en noir. Une fois que le faisceau commence à tracer une nouvelle image, on la passe en bleu (par exemple).
Ainsi, le temps machine utilisé avant le VBL suivant sera matérialisé par une bande bleue en haut de l'écran. Plus cette bande sera près du bas de l'écran, moins il restera de temps avant que le faisceau n'arrive en bas de l'écran.
 
Le challenge consiste donc à trouver le nombre d'étoiles maximum, celui qui recouvrira la totalité de l'écran en bleu sauf le point de coordonnées (319,199) qui devra rester noir
 
La définition de la palette utilise la fonction assembleur décrite dans l'article sur le Starfield et ne présente aucune difficulté.
 
Modification du source
Dans le source, j'ai modifié la fonction WaitVBL().
Juste avant l'attente du VBL, j'ai rajouté des instructions qui passent la couleur de fond en noir, et juste après, je colorie le fond en bleu.
Ces modifications sont activées en compilant le source de la manière suivante :
 
wcl386 -dDEBUG /l=dos4g tstarfield.c
 
Le symbole DEBUG encadre la coloration du fond dans le source tstarfield.c. Pour ne pas visualiser le temps machine, il suffit de compiler selon la ligne de commande décrite dans l'article sur le Starfield, sans le "-dDEBUG".
 
J'ai passé le nombre d'étoiles à 20000, afin de visualiser le temps machine. Ce nombre doit être suffisamment grand, sinon on ne verra rien (la puissance des machines actuelles permet de calculer un grand nombre d'étoiles)
 
N'hésitez pas à modifier ce nombre pour voir combien d'étoiles votre machine est capable d'afficher.
Les plus courageux peuvent même s'amuser à réécrire le source entièrement en assembleur pour voir s'il leur est possible de gagner des étoiles supplémentaires
 
Télécharger le source modifié
Télécharger l'éxécutable avec 20000 étoiles et visualisation du temps machine
 
Effet de feu in progress

ça y est, je suis largué

qu'est ce que tu comprends pas

non c'est l'histoire du truc bleu pour détecter la vitesse, j'ai lu trop vite je pense, je lirai ça plus calmement plus tard

augmente ou diminue le nombre d'étoiles, ça va te sauter aux yeux

 
 
bonne idée nempeche  
 
mais avec mon 2400+ jai le 1er 1/4 de lecran recouvert de bleu
 
faut autant de cpu pour gerer un starfield ????
 
 
jvais essayer dimplementer un blur sa doit etre vraiment beau  

ben y'a quand meme 20000 étoiles, c'est pas rien !
et puis il te reste les 3/4 de l'écran, donc tu peux placer environ 80000 étoiles !
passe le source à 100000 étoiles, tu verras les saccades

de toute façon, c'est pas un déplacement d'étoiles qui mettra le CPU à genoux !
ça commencera à se sentir quand on abordera les projections 3D, les rotations, etc...

tu compte nous faire des optimisations mmx pourla suite des evenements    
 
 
 
 
 
 

m***** c vrai pas de mmx en 16 bit c ca ?

 
non là c'est bon le cpu est mode 32bits. (DOS4G RULEZ)
 
perso j'ai un faible pour PMODE, mais bon ché pareil...

Drapal aussi ! J'avais fait un effet de feu sur un petit cube en 3D il y a quelques années, ca me rappelle des bons souvenirs de voir tout ca !

genre ça: http://site.voila.fr/bjone/files/bsplines.ace
 

 
marche pas    
 
 
 
mais jai plus aucun album mp3    
 
 

 
bin si, pi tu fais bsplines.exe cube.spl par exemple....

 
jcrois que cetait des fichiers utilise par lappli  
 
comme yavait pas de readme ou une explication du genre

 
c'était un truc fait à l'arrache en cours en bts....
 
pi après j'ai ajouté l'asc2spl qui blaireaumétriquement converti un fichier ASC issu de 3D Studio dans le format couillon que j'utilise...

forcément comme c'est du DOS en mode réel, si les ressources (vertex/lignes/splines) dépassent la fenêtre de 64Ko, c'est DTC....

et c'est du C compilé par du C++ (enfin du Borland C++ ), lol taz pourrait venir hurler... (àlàlà que de souvenirs)
 
4,6 rotation gauche droite (du pavé numérique)
8,2 rotation haut bas  
1,3 rotation Z
/,* zoom
. : bascule effet de vue/recopie simple

pas mal, le cube ! J'avais fait plus simple ... largement ... un simple cube gérés par faces triangulaires ... remplies ou non ... Mais bon ... c'était pas une gestion de splines et c'était un peu tout pourri, ce que j'avais fait ... J'abais relu le source un coup, et j'ai failli m'enfuir en courant !

 
bah tu sais je viens de re-regarder, le miens, et je me dit que la STL ou les trucs templatés c'est vraiment mieux
 
enfin surtout quand je regarde mon autre truc de rendu 3D en VESA 2.0 sous Dos, celui-là c'était mon projet d'apprentissage de A-Z de la 3D, je l'ai abandonné en 2001, et c'est vraiment un bordel

Version modifiée de starfield.c en neige.c
 

 
Plusieurs modifs :
 
1- Correction d'un bug d'harko (copier coller ) :
Dans resetVideo() les instructions :

sont en fait un appel DOS pour stopper le prog   C'est dommage de l'arrêter avant de libérer les allocations dynamiques
 
2- Pour le fun utilisation de pointeurs plutôt que d'un tableau avec indice. En plus c'est plus rapide avec des pointeurs déclaré en local dans les fonctions.

Cette manière d'écrire n'est pas forcément plus rapide ni plus lisible , mais elle montre bien l'utilisation de l'arithmétique des pointeurs en C.
 
unFlocon = Neige : On pointe sur le début de la zone mémoire de stockage des flocons ( La neige quoi ! ) .
 
unFlocon++ : On avance d'un flocon et non pas d'un octet. unFlocon est déclaré comme pointeur sur une structure, l'incrémentation tiens compte de la taille de la structure.
 
( unFlocon - Neige ) < nbFlocon : C'est pareil, on peut faire ce genre d'opération avec les pointeurs. Le résultat de la soustraction donne leur décalage en nombre de structure.
 
3- Ajout d'une vitesse verticale aléatoire pour faire tomber les étoiles d'harko et les transformer en flocons de mara
 
4- Le nombre de flocon est un paramètre du prog (500 par défaut).
 
5- Disparition du tableau d'offset précalculé. Une multiplication par 320 ne prend pas de temps en ASM.
Explication par harko:

 
J'ai laissé initPalette() même si je l'utilise pas, pour ceux qui voudrait changer la couleur de fond
 
Merci à harko, avec ses quelques lignes de code, j'ai appris plein de chose, et de vieux souvenirs sont remontés à la surface

Oui effectivement, autant pour moi, je termine le programme par cette fonction... Mais bon, toutes les machines ont au moins 512 Mo de RAM maintenant, ça se serait jamais vu
J'ai modifié les sources téléchargeables en conséquence

de toute façon Windows NT/2000/XP libère toute la mémoire allouée par le programme

Et des fois même plus

tous les OS libèrent les ressources demandées/crées par un process. (y'a des cas particuliers, comme les communications inter-process sous unix qui sont pas détruites quand y'a plus de process qui les utilisent, alors que sous windows oui )
 
mais c'est pas une excuse pour ne pas libérer ce qu'on crée...
(surtout dans des fonctions, sinon bonjour les leaks, mais bon à la fin d'un programme, (presque) tout est libéré)