Télécharger le zip
#include <dos.h>[...amis linuxois s'abstennir...]enfin voila c'est pas portable
Fallait publier cela 10 ans en arriere, aucune utilite maintenant, le 16 bits est totalement depasse et ne reviendra jamais plus. En info, il faut aller de l'avant et pas en marche arriere.
exact, ça sert pas a grand chose...Si tu veux faire des trucs cortects dans le graphismes et pourquois pas avoir une ligne de plus sur un CV tu peux chercher à contribuer pour the gimp... Je sais pas si ils recherchent des dévelopeurs, mais en général, ils sont sympas et ne crachent pas sur de l'aide.
1- En ce qui conserne DOS.H j epeux arranger le problème je l'ai inclut pour l'appel des interruption il suffira pour les amis de linux de remplacer l'unité souris.h ex de fonction: remplacer la définition de la fonction showmouse() initiale parvoid showmouse(){ asm{ mov ax,1 int 0x33}2- En ce qui concerne la question de l'antiquité de mon programme j'en suis conscient mais ce n'est pas un prog pour des utilisateur qui veulent faire du super disigne mais plutôt pour les débutant qui veulent comprendre comment fonctionnait un programme de ce type merci tout de même pour votre aprèciation.
Je ne doute pas de qualité de ton "paint" mais si tu veux en faire un, fais-le avec l'API Windows ou même(bcp bcp mieux) avec la SDL(plus dur car il faut gérer les menus et l'affichage de texte mais portable) . Mais alors le DOS, il faut pas y penser, çà te renda les choses plus dur à mon avis dès que ton "paint" sera un peut plus complet . Et en plus, le 16-bit sera bientôt(quelques années à mon avis) délaissé à mon avis au profit du 32-bits et du 64-bits .
le 16 bits sera "bientôt" délaissé? vous parlez en quelle année?
Les processeurs 64 bits arrivent sur le marche grand public, le passage devrait se faire a la meme cadence qu'a l'arrivee du pentium.
64 - 32 bits, ayant cherhcé de la doc sur la stéganographie, je peux dier que la diférence se verra plus au niveau du temps de téléchargement que du résultat...
de quoi tu parles?
à mon avis avec le passage au 64-bits on gagne plus que du temps de téléchargement . Rien que la mémoire adressable, avec 64-bits on adresse bcp plus qu'avec 32-bits : 2^32 fois plus de méoire : çà dépasse de très loin de To . ne m'y connais pas super bien mais il doit y avoir encore plein d'autre avantages pour que des processeurs soient développés . Seul problèmes : les logiciels(certains processeur ne sont pas compatibles 32-bits je crois) .
Les processeurs 64 sont une avancée (j'ai un pote qui a un g5, et il marche super) mais si ils se mettent a faire des couleurs 64 bits sur les cartes, alors c'ets la que je ne vois pa l'interet... les images seront plus grosses, et on verra pas vraimlent la diférence...
mais coucou, je comprends pas le rapport que tu vois entre l'architecture du proecesseur et la stéganographie, puis les images mtnt (???). il s'agit seulement de traiter plus d'infos plus vite, après ce que tu fais avec le processeur (afficher des images, faire de la stégano, puisque tu insistes, lol), ben ça dépend que de toi!
le titre de cette source c'ets paint, 16 bit vous parlez pas des couleurs ???
non, la remarque était à propos du mode vidéo du programme, qui est un affichage 16 bits à l'écran, alors que tous nos processeurs peuvent gérer du 32 bits, et très prochainement du 64, avec la même efficacité, alors faut pas s'en priver. mais ça ne nuit en rien à la pédagogie de la source.
Le sujet est surtout la compatibilte des progs 16 bits sur la generation des processeurs 64 bits qui arrivent, et de compatibilite il n'y en a aucune, c'est desesperement foutu pour le 16 bits.
oki j'étais hors sujet dsl
je ne doute pas de votre bonne volonté et je suis conscient de la mort plusque prochaine du 16 bit mais je le redis cette source est comme l'a mentionné Kirua est à titre pedagogique.Il vous suffit d'observer et vous comprendrer que les languages telque Vc++ C# pour quelqu'un qui commence par là ne lui permettront jamais de savoir ce qui se trame derière.si vous vouleez je vous poste en quelques heures la meme source en 32bit développer sous VC++ 6.0 (aucun interêt) ce travail sera effectué tout a plus en qq heures hors avec le bon vieux dos on apprend les rudiment de la programmation à l'ancienne .je conclus en disant : cette source n'a pas pour but la beauté mais le plaisir de programmer et pour plus débutants que moi de jouir de son aspect pédagogique.
je suis désolé mais en 32-bits on peut parfaitement faire un paint tout en apprenant ses rudiment : soit en gérant soit même tout les évênement windows(la galère) ou alors en faisant un PAINT sous la sdl avec ou sans OpenGL par exemple .
désolé moi aussi de te le dire mais sous win32 on a aucune gestion de memoire à faire t'es variable tu les déclares tant que t'as suffisement de RAM.tu peux donner des tailles gigentesques à tes pointeurs windows gére gentillement le tout pour toi essais d'allouer un pointer sous dos de 64000*3*sizeof(float) sans passer en mode proteger (on vas rigoler un peu).de plus tu signals toi mêmequ'on peu gérer les évènement windows alors là tu dis justement ce que je veux: gérer les évènements window<> gérer les évènements windows! windows se charge d'envoyer des messages vers ton programme sur tout les évènement qui se produisent au cour du temps c'est donc à toi de les interpreter. ce qui est différent avec la machine qui ne t'informe de rien si tu veux un renseignement tu dois 1-savoire où il se trouve 2-savoire comment le récuperer 3-et enfin l'interpréter.conclusion ne pas confondre rudiments de la programmation tout cour et rudiment de la programmation windows.
une erreur: gérer les évènements windows <> de gerer les évènements machine
évènements windows: c'est en partie vrai, dans un prog windows on ne reçoit pas que des evenements materiels.
certe, pour la mémoire, c'est un problème mais cela est directement et intimmement lié au 16-bit . De plus, pour les évènement en 16-bits, il est vrai que pour les 90% du temps on est obligé de faire une batterie de test(avec utilisation des registre ax,bx... et les interruptions) . Cette programmation n'est pas très pratique mais bon . Néanmois, je tempère car on peut créer un gestionaire d'évènement avec les interruption mais encore faut-il savoir quels sont les arguments retournés .
On est enfin d'accord !c'est justement la difficulter à trouver les valeurs retournées qui donne un interêt à ce type de programmation pour l'heure je suis entrain de commencer un petit jeu 2D avant de me lancer sur OpenGL.tu connais sans doute castelvania ? c'est probablement ma dernière source 16bit juste le temp de poster une version de tetris comme avant dernière source. en attendant jettes un coup d'oeil sur ma source calcul numerique fais le tour de son execution et tu vera que je m'amuse à réinventer la roue(tant bien que mal).
en effet, c'est bien de réinventer la roue mais le pb, c'est que le 16-bit c'est bientôt fini et en plus, gérer cette mléoire vidéo(surtout quand on arrive au memory pages), là ca devient vraiment galère . On perd énormement de temps à créer un système stable pour afficher des pxiels alors que le but du code c'est tout l'intéraction derrière . C'est là le problème qui m'a vite fait abandonner le 16-bit .Sinon, bonne chance pour ton jeu .après, uu verra OpenGL c'est très bien
probleme c'est que je pige pas grand chose en lisant les sources opengl.j'aimerai juste un petit programme qui deplace un point à gauche ou à droite selon que la touche appuyé.tu peux me le filer?
ce que tu fait c'est envoie moi un message privé avec ton e-mail et je t'envoie quelques codes commentés . Par contre il faut que je sache une chose : OpenGL ne peut pas marcher tout seul, il lui faut un support et il en existe trois bien : SDL(très bien), Glut(moyen), Windows(ahh horrible, je connait pas le code) . Donc dis moi lequel tu préfère et je te fais le code(Glut et SDL sont portables et faciles ) .
euhm, je dirais que Glut est très bien pour les débuts, parce que justement il est très simple. SDL est plus puissant, donc forcément plus compliqué (sans être monstrueux). si tu veux commencer OpenGL avec pas trop de code en plus du code OpenGL, opte pour la GLUT, au moins au début.note que... elle n'est plus supportée de puis 1997 (sauf erreur). ça n'en fait pas un choix d'avenir!
reçu je prndreait bien juste pour commencer une source sdl (pour voir) et glut (pour débuter).de préférence 2 sources qui font la même chose sans execption merci
ok je te fais ca pour ce soir je pense
Merci cool.
Se souvenir du profil
Mot de passe oublié ? / Activation de compteCréer un compte