Reprise du message précédent :
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é)

 
Win9x aussi ? pas toujours il me semble

pas encore tout lu mais je plante mon drapo ici c ahcment interessant

 
en principe y devrait

 
non, c'est pas censé être un OS ça, tout juste une plateforme de lancement de jeux  

De toute façon, savoir si l'OS ou non fait le ménage
n'est pas le problème.
Si tu as une fuite de mémoire rien ne garantit qu'elle ne va gonfler dans des proportions énormes, si ton programme
fait plus qu'un hello world (ce qui est vrai pour 99.9999% des programmes).
Faire ramer un ordi surpuissant par négligence -> c'est la peine de mort dans certains pays.
 
LeGreg
 

 
on raconte ds trucs horribles, des types deportés dans d'infames codoirs ou ils font du VB 22h par jour sur un 486dx d'epoque, coude a coude avec le voisin tellement les box sont serrés, et le tout pendant qu'un groupe ecossais joue de la cornemuse plein pot non stop pour les tenirs eveillés.
 
Affreux, vraiment, pensez a faire des free() !
 

 
putain t'as bossé dans la meme boite que moi ??
 
LeGreg

Voilà, c'est fait

Désolé pour le retard, mais j'ai pas mal de sommeil en retard en ce moment, et je débauche tard...
Mais bientot mon boulot ne sera plus un problème et j'aurais tout mon temps

 
serait-ce:
 
"fous zavez deuze zheures pour libérer fotre buro"
 
  ?

Il est viré mais heureux, son boulot le faisait chier depuis des mois.

l'effet de feu
l'effet de feu
l'effet de feu
l'effet de feu

vu au rythme que ca va c pas demain la veille qu'on aura des metaballs  

et des rasters      
bon je retourne au boulot moi...

Oui, oui, oui !
Rasters et metaballs sont prévus !
Et les rasters à l'ancienne hein, avec surveillance du faisceau horizontal et tout !

avec un PC ?

ben oui, t'imagines pas tout ce que peut faire une carte VGA

tu polles les registres CRTC alors, passke sur amiga/atari st c'était par interruption non ?

ça pour les polluer, je les pollue
sur ST je sais pas comment ça se passait (surement une interruption effectivement), mais sur Amiga on utilisait le Copper qui permettait d'attribuer une palette différente pour chaque ligne écran

 
A les demos Amiga...  

J'suis en retard, mais j'ai un pb moi:
quand j'essaye d'initialiser le mode d'affichage en 13h, comme ça :

Ben, ça plante sur le "int 10h"
ça, c'est uniquement quand je compile avec VC++ 6. Avec la version compilée par Hako de starfield.exe, c ok.

je crois que c'était dû au compilateur lui-même, il faudrait que tu downloades et installes Watcom pour réaliser sans problème une telle opération. VC n'a pas l'air d'apprécier les appels aux interruptions.

bah surtout qu'avec VC++ 6, t'es censé faire du Win32, pas du DOS en mode réel.

VC++ ne permet pas d'utiliser les interruptions DOS, tu ne peux que faire du Win 32.
C'est pour ça que j'ai utilisé Open Watcom

L'EFFET DE FEU
 
Télécharger le source
Télécharger l'éxécutable
N'oubliez pas de télécharger aussi le dos4gw.exe (le lien est présent dans l'article précédent)
 
L'effet de feu est un effet dont le principe est enfantin. Il repose uniquement sur un jeu de palette.
 
Avant toute chose, il faut définir une palette en adéquation avec la structure de la flamme elle même.
On part du principe qu'une flamme est quasi blanche à sa base, puis jaune et enfin rouge à son sommet. On crééra donc une palette respectant cette logique.
 
Dans mon exemple, j'utilise 128 couleurs sur les 256 possibles en mode 13h :
- La couleur 0 est noire (fond d'écran)
- Les couleurs 1 à 32 contiennent un dégradé qui va du noir au rouge,
- Les couleurs 33 à 64 contiennent un dégradé qui va du rouge au jaune,
- Les couleurs 65 à 96 contiennent un dégradé qui va du jaune au blanc;
- Les couleurs 97 à 128 ne contiennent que du blanc.
 
Pour créer la palette, on a le choix :
- Soit on utilise un éditeur de palette dans lequel on créé le dégradé à la souris, et on sauvegarde ensuite la palette sous forme de fichier include,
- Soit on la calcule directement dans le programme.
 
J'applique cette seconde méthode, en sachant que chaque nuance de rouge, vert ou bleu est codée sur 6 bits, soit 64 nuances possibles par composante.
 
Une fois qu'on a créé notre palette, il faut créer une ou plusieurs lignes en bas de l'écran, qui représenteront le foyer du feu.
Ces lignes sont remplies de pixels choisis aléatoirement.
 
Une fois les lignes du foyer créées (dans mon exemple, j'en créé 3), il va falloir procéder à un petit traitement d'image.
 
En effet, vous aurez remarqué que la structure d'une flamme est douce, qu'on ne distingue aucune transition entre les différentes couleurs.
Pour simuler ceci sur l'écran du PC, on utilise un effet de blur, dont l'explication est donnée ci après :
 
L'effet de floutage, ou blur
Le blur consiste à atténuer la transition entre les différentes couleurs d'une image, afin de la rendre plus douce à l'oeil.
Il existe plusieurs sortes de blur, mais celui que j'utilise est très simple :
 
- on initialise une variable qui représentera la moyenne des couleurs environnantes,
- on se positionne sur un pixel,  
- on ajoute à cette couleur la couleur des pixels environnants,
- on fait la moyenne de la somme de ces couleurs.
 
Ceci est résumé par le shéma suivant : le pixel "1" représente le pixel de référence, celui sur lequel est positionné le pointeur de lecture de l'écran. Pour les autres pixels, chaque nombre représente une couleur :
 

 
On calcule la moyenne des pixels environnants :
 
(4 + 4 + 5 + 3 + 3 + 2 + 2 + 2) = 25
25 / 8 = 3
 
Notre feu sera donc lissé selon cet algorithme en calculant la moyenne de tous les points le représentant. Ceci, ajouté au dégradé créé dans la palette, donnera une transition des plus douces.
 
Il reste à savoir ou positionner la couleur correspondant à la moyenne, ceci est très simple : puisqu'on veut que notre feu monte, on écrit cette valeur sur la ligne au dessus du pixel courant (y-320).
 
Il reste une dernière petite chose. Plus le feu monte, plus il doit foncer, donc plus la couleur doit décroitre (souvenez vous que les couleurs les plus basses dans la palette sont les plus sombres). Ceci est très simple : une fois la moyenne calculée, si cette dernière n'est pas nulle, on lui retranche 1. Ainsi, l'écran donnera l'illusion d'un feu très clair à son foyer, et très sombre à son sommet.
 
En résumé, voici l'algo complet de l'effet de feu :
 
1 - On créé un dégradé adapté aux couleurs naturelles du feu,
2 - On créé en bas de l'écran une ou plusieurs lignes qui représenteront le foyer
3 - Pour chaque point de l'écran à partir du bas, on calcule la moyenne des points environnants
4 - Si cette moyenne n'est pas nulle, on la baisse d'une unité
5 - On écrit la couleur ainsi obtenue une ligne au dessus du pixel courant.
 
La technique
Contrairement à l'effet précédent, l'écriture des points ne sera pas faite directement sur l'écran, mais dans un buffer hors écran. Ceci permet d'augmenter la vitesse du programme, car l'écriture dans la mémoire VGA est bien plus lente que l'écriture en mémoire centrale.
On calculera donc l'effet de feu dans un buffer de même taille que la mémoire vidéo (320 x 200 octets), puis on attend le début du balayage écran. Dés ce balayage entamé, on recopie l'ensemble du buffer dans la mémoire vidéo avec une fonction en assembleur.
Pour éviter d'observer le crépitement en bas de l'écran, assez disgracieux du fait de sa nature aléatoire, on ne recopiera pas les 3 dernières lignes.
 
Un mot sur le source
Le source est largement commenté, et ne devrait pas poser de difficultés.
A noter l'apparition de nouvelles fonctions en assembleur :
 

Comme son nom l'indique, cette fonction se charge de copier le contenu du buffer dans la mémoire vidéo. La variante que je propose ici permet d'indiquer le nombre de double words (=4 octets) qu'on désire copier.  
L'instruction movsd permet de copier le contenu de la zone mémoire pointée par le registre esi (source) dans la zone mémoire pointée par le registre edi (screen). Le registre ecx contient le nombre de double words à copier. Il est nécessaire si on préfixe l'instruction movsd par le préfixe rep
Pourquoi recopier des double words et non des octets ? Car on recopie ainsi 4 pixels à la fois dans la mémoire vidéo.
Le buffer étant constitué d'octets, il faudra penser à diviser ce nombre d'octets par 4 avant de le recopier dans la mémoire vidéo.
 
Autre fonction :

Cette fonction initialise la palette. Les registres 3c8h et 3c9h ont été expliqués dans un article précédent.
Ici, on commence par indiquer dans le registre 3c8h le premier index de couleur qu'on veut modifier (le 0), puis on envoie au registre 3c9h, les 768 octets de la palette (256 x 3) par l'instruction rep outsb, qui suit le même principe que l'instruction rep movsd de la fonction précédente.
 
C'est tout pour cette fois. N'hésitez pas à poser des questions si vous en avez.
 
Prochain article : le Sine Plasma ou plasma sinusoidal. Préparez les aspirines, nous allons rentrer dans le merveilleux monde de la trigonométrie
 

C'est plus simple que je ne le pensais le truc du feu

 
pas mal d'effet sont archis simples
harko fait du compliqué, la je dirais
 
tu prevois de faire du feedback harko ?
pis les metaballs 2D/3D ?

 
Dans ton exe y a cet effet bizarre en bas de l'écran justement, non ?

bah, j'ai toujours fait comme ça
 

c'est à dire
 

vi, c'est prévu

non, ça vient pas du foyer, je sais pas d'ou ça vient ce truc
sinon, ça disparait si tu met à 3 la hauteur du feu dans le #define du début
 
edit: si tu veux voir le foyer, remplace cette ligne à la fin du source :
 
copyToVGA(buffer,(320*197)>>2);  
 
par  
 
copyToVGA(buffer,(320*200)>>2);

J'ai pas encore d/l le compilo en fait  

 
je veux dire en terme de complexité d'algo
 
le premier effet que j'ai fait c'etait
 

 
et ca tuait tout
 
 

 
quand tu bricole avec l'image precedente
exemple
 
dessin :
dessiner oscillo de la musique courante
 
feedback :
etirer le centre de cette image sur tout l'ecran
appliquer blur
goto dessin  
 
(on notera l'absence de clear)
 
resultat : geiss for winamp (ouais, enfin, en gros hein ? )
 
 
(35 edits pour un post )

ok, je vois le truc, c'est une sorte de motion blur avec trainées

 
tu peux faire des trucs sympa, tout depend de comment tu fais ton feedback (au lieu d'etirer tu tords par exemple ....)

Chuis en train de coder des copperbarres au boulot, et mon écran est en train d'émettre un drôle de sifflement quand je teste
Les registres du CRTC c'est bon, mangez en
Par contre, je suis en train de me demander si cet effet fonctionnera sur les écrans LCD

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