salut
 
voila mon code (mon premier vrais programme graphique depuis que j'ai découvert TurboC ilya quelques jours), c'ets un effet plasma sous VGA, comme en qbasic
Code : C
Code:
 

 
mais voila, il me plante windows avec une opération non conforme.
 
voyez vous une erreur ?
 
 
[EDIT] voila, ce programme fonctionne maintenant, la source a étée modifiée.[/edit]
merci, ++ Tix.
__________________

On est en 2006 cammarade

certe, et en 2006, mon 386 tourne toujours, et 386 != windows != sdl/glu ... donc VGA inside seulement
 
si vous avez des idées quant a mon probleme , je serai ravis, je le serai aussi en cosant air du temps mais bon ,ca aidera pas mon darxhigher d'amuuuuuur ^3^
 
enfin voila, ++ Tix.

Le mode 13h fonctionne en 8 bit non? Dans drawpx, la couleur est un int, du coup ça ne se comporte pas comme il faut, et à la fin de la mémoire vidéo, crash, il écrit ailleurs.
Enfin, je crois
 
Edit: je viens de relire, et en fait tu l'appelles nul part
Ceci dit c'est peut-être lié; plutôt que peek et poke, tu devrais utiliser peekb et pokeb. Ou alors, modifier ton code de façon à écrire 2 pixels à la fois (mais je sais pas si c'est trop possible avec cet effet).

tout est sous quoi comme Windows ?
pourquoi ne pas rester sous DOS ? (c'est bien un binaire DOS que tu fais au moins ? )
 
j'ai jamais aimé les peek/poke (ça sert à rien avec un langage comme le C, c'était bon pour le basic ça)
 
par contre si tu veux aller vite, il vaux mieux actualiser le plasma dans un buffer en mémoire système et copier ce buffer vers la ram vidéo ensuite. (rester en cache tout ça, adressage non continu rendement PCI/AGP merdique tout ça)

oui, c'est pour un PC sous dos, un 386 exactement j'essay peekb t pokeb, mais quelle est la différence avec peek et poke ?
 
merci, ++ Tix.

Le b à la fin laisse à penser qu'il agit en byte
 
Par contre, si tu veux travailler ton effet suis les conseils de bjone (et d'harko s'il passe par là)

haha, j'azi pensé a l'histoire du buffer, mais je m'y suis pas encor attelé, je prévois une fonction qui affiche le contenu de 5 buffers avec leurs mask 1/0 , si quelq'un a une idée pour la transparence partielle ...
 
je teste, ++ Tix.

 
on est en C, en C y'a pas besoin de peek et poke pour écrire un octet laisse ça au basic.

sous quel Windows est-tu ?

C'est vrai que ce n'est pas clair. Je suppose qu'il essaye de développer son bazar sur un PC Windows récent, genre XP et évidemment, ça banane dur...
 
L'objectif étant de le faire tourner sur son 386/DOS, probablement pour un musée de l'informatique...

 
vu le code qu'il nous balance et l'age de sa becanne je dirais Windows 95/98 ....  
je le vois mal compiler sous win puis rebooter sous dos a chaque fois, et ce genre de fantaisies sous XP => :S

rhoo;lala, excusez moi
 
j edévellope sur un PC 233Mhz, windows 98, un programme destiné a un 386. voila pour l'environnement
 
mon programme tourne désormais, il suffisait de remplacer poke et peek par pokeb et peekb ^^ mais j ene comprend pas la différence entre les deux.
 
ensuite, je vois mal comment faire mon truc sans poke et peek, je sui snovice en C
 
voila, merci a vous, ++ Tix.

C'est dans la doc de Turbo C (F1):  
 
poke()/peek() : accès en mémoire 16-bit sur x86 mode réel
pokeb()/peekb() : accès en mémoire 8-bit sur x86 mode réel

ASM roulaize
Des tutoriaux sur le sujet, il y en a des tas; google sur mode 13h. Comme celui-ci par exemple.
Ceci dit, si tu ne comprends pas encore la différence entre un int et un byte, continue d'apprendre le C, et les pointeurs avant de t'attaquer à ça (ça = prog graphique, surtout en asm)...

 
unsigned char far *ptr=0xA0000000;
 
/* ptr[y*360+x]=.... */
 
unsigned char far *wptr=ptr;
unsigned char far *rptr=ptr;
 
for( int i=0 ; i < 200 ; ++i )
{
    for( int x=1 ; x < 319 ; ++x )
    {
       unsigned int sum=rptr[x-1];
       sum+=rptr[x+1];
       wptr[x]=sum>>1;  
    }          
 
    rptr+=320;
    wptr+=320;
}
 
par exemple je dirais (si je ne m'abuse).
 

et prends pas TurboC, prends OpenWatcom ou DJGPP si tu veux un vrai compilateur DOS.

@bjone, je n'ai jamais testé en C; il n'y a pas de différence de perf entre une routine C et une asm pour faire ça?

ça dépends du compilo, mais dans l'absolu en asm tu produira la boucle la plus imbriquée la plus efficace. (mais bon il faut bien connaitre les règles d'optimisations vis à vis des cpu cibles, moi je me suis arrêté au Pentium 1).
 
de toutes manières, avant l'asm, l'aspect algo et cache-friendly est de loin le plus important.

ha oui et en VGA, les composantes RVB de la palette ne sont pas sur 8 bits.

c bizarre comme borland n'a jamais eu la cote, c la mm chose avec Delphi, pourtant je trouve leurs produit tres bien  

salut
 
merci pour vos réponses, je vais cependant m'en tenir a ca pour l'instant.
 
cependant, voila un nouveau dileme
 
est il possible de stoquer une pseudo image de l'écran pour la restituer ? si oui, comment faire cela ?
 
merci, ++ Tix.

Merci bjone
J'ai jamais testé sur autre chose qu'un P2, et c'était  que des tests destinés à tourner sur ma machine pour apprendre un peu tout ça. Donc j'étais loin de l'optimisation dont tu parles
 

C'est un double buffer. Il faut que tu alloues une zone mémoire de la taille de ton écran et que tu "dessines", c-a-d, la modifie, au lieu de la mémoire VGA que tu utilises actuellement. Après, il ne reste plus quà copier le bloc de ton double buffer vers la mémoire VGA, avec memcpy.

 
TurboC date de 1989 ou un truc du genre et fait que du mode réel
 
c'était bien TurboC, moi j'ai commençé a faire le con avec au tout début, mais pour du dev DOS, Watcom & DJGPP restent les maitres incontestés pour l'éternité (vu que y'aura plus jamais de nouveau compilo de quelque chose pour le DOS).
 
sinon perso j'avais adoré C++ Builder.

C'est exactement de que fait le P.O. avec ses int 13h

pas compris.
 
mais Watcom et DJGPP, d'une part optimisent le code plus que correctement, et permettent du faire du mode protégé avec un dos-extender fourni.

INT 13h, c'est du mode réel 16-bit (AX, et non EAX, pas de GDT etc.). Je ne vois pas ce qu'un compilateur pour DOS en mode protégé va apporter..
 

bin le dos-extender wrappe de manière transparente les interruptions du dos et bios (tant qu'il y a pas d'adresse segment: offset en paramètre/retour), permet un adressage linéaire jusqu'à 64Mo (il te libère de la construction segment: offset, les pointeurs far...), et permet d'utiliser un cpu moderne a pleine efficacité en 32bits.  
 
ndlr puisque que par exemple un pentium 1 ne peux pairer que des instructions 16bits en mode réel, et que des instructions 32bits en mode protégé (dû à l'octet de préfixe), et que sur tous les cpus modernes c'est pareil ou pire (un P2 est encore plus boeuf si tu fais du 32bits en mode réel ou du 16 en pm).
 
même si il compte cibler du 386, c'est toujours ça de pris.

... j'ai pas tout compris  
 
bon bha j evais déja bosser un peu ma technique, pi on verra apres.
 
merci tous, ++ Tix.