Version imprimable
Salut,
J'utilise djgpp sous windows 2000. Je tente de faire de la prog graphique avec ce compilo sans succes. J'ai fait un bete programme qui affiche un pixel. Ca compile avec 50 warnings de redeclarations diverses que je ne sais pas d'ou ils sortent et quand j'execute j'ai un general protection fault.
J'ai desactive les protections memoires avec __djgpp_enable_nearptr() ;
Quelqu un peut il m'aider paske la je desespere.
Montre un peu l'allure des warnings.
Mefie toi des pointeurs far, surtout en programmation graphique.
Un pointeur far a un segment et un offset comme tout pointeur, seulement quans l 'offset deborde, le segment n'est pas modifie en consequences ce qui te donne une adresse memoire inexistante, non alloue ou bien pas celle que tu desires.
En programmation graphique, on utilise souvent un tableau representant l'ecran. donc pour du 320*200; on aurait besoin de 64000 case de tableau, donc de 64000 pointeurs. En mode Far, tu peux allouer sans risque jusqu'a 64000 pointeur (la limite theorique est 65535 ie FFFF : FFFF).
Si effectivement tu utilises une resolution de plus de 320*200, et que tu utilises un buffer pour stocker l'ecran, tu dois faire des changements :
- passer en mode huge (ici le segment est modifie en consequence d'eventuels debordement de l offset), la c bon, tu auras assez de pointeurs :) . A noter que les acces memoires sont un peu plus lents (problematiques pour un moteur 3D). Tu dois declarer comme ca tes pointeurs
unsigned char huge *Buffer_Ecran;
if ((Buffer_Ecran = (unsigned char huge *) malloc ("taille voulue")) == NULL)
Error;
- Sinon utilises une bibliotheques graphiques qui gerera ca pour toi de facon transparente
- Passe a l assembleur :)
- Passe en Mode13H (320*200) :))
Voila, a plus ;-)
Ah oui j'oubliais, n'oublie pas d'activer dans les options de ton compilo le mode FAR ou HUGE, sinon ca va pas aller !!!!
Moi j'utilises gcc ou Borland, donc pour DJGPP je sais pas ou c'est, mais un truc est sur et certain ces options existent et sont primordiales.
D'ailleurs reteste ton programme en mode Far deja et dis m en des nouvelles.
je suis dsl, le titre du post est erone
je n ai plus de pb de pointeur far. puiske djgpp est un compilo 32 bits il n y a plus de pointeurs far. je l'ai appris d un post precedent.
J ai aussi resolu le pb des warnings. ils etaient dues a la declaration de djgpp.env en variable d environnemnt. Il fallait la declarer dans autoexec.bat a la place de le declarer dans les variables d environnement de windows 2000.
Par contre malgre 0 warnings et 0 erreurs, je ne peux pas afficher mon point et le programme plante en affichant general protection fault. J ai regarde le site de djgpp et j y ai lu que la version 2.03 que j ai est cense etre totalement compatible avec windows 2000, pourtant le pb persiste.
Qq peut il m'aider paske la je desespere.
Je comprends pas. Tu essaie de l'afficher comment ton pixel ?
via le bios, une lib ?
avec le bios
a l adresse 0xa0000000
Euh...
C'est pas comme un pointeur NULL, ça ?
Ou alors il y a une hisoire de segment et d'offset ?
L'adresses A000 : 0000 est bien le debut de l'adresse video (en mode 13h en tout cas).
Est ce que tu as initialiser ton mode video avant?
Sinon ce serait bien si tu pouvait montrer la partie de ton code supposée affichée ton pixel, ca sera plus simple.
Liusting de rain.c:
#include <stdio.h>
#include "./video.h"
int main()
{
set_video_mode(0x0013);
init_realscreen();
printf("hello djgpp world");
set_pixel(100, 100, 15);
getchar();
close_realscreen();
set_video_mode(0x0003) ;
return 0;
}
Listing de video.h:
#include <dos.h>
#include <string.h>
#include <sys/nearptr.h>
// Type definition --------------------------------------------------------------------------------------------
typedef unsigned char BYTE ;
// Global variable declaration --------------------------------------------------------------------------------
BYTE* realscreen ;//= (BYTE*) 0xA0000000L ;
BYTE* fakescreen ;
// Function code ----------------------------------------------------------------------------------------------
void init_realscreen()
{
__djgpp_nearptr_enable() ;
realscreen = (char *) (0xa0000 + __djgpp_conventional_base);
}
void close_realscreen()
{
__djgpp_nearptr_disable() ;
}
void set_video_mode(int mode)
{
union REGS regs;
regs.x.ax = mode;
int86(0x10, ®s, ®s);
}
void set_pixel(int x, int y, BYTE color)
{
realscreen[(y << 8) + (y << 6) + x] = color ;
}
Petites remarques:
FFFF:FFFF = 0xFFFF<<4 + 0xFFFF = 0xFFFF0 + 0xFFFF = 0x10FFEF = 1114095Citation:
Envoyé par funkeejeffou
Attention pour le calcul reel d'adresse. La notation segment/offset est un peu trompeuse.
Le calcul de l'adresse se fait de la maniere suivante (ou precedente si l'on regarde le calcul precedent) :
si l'adresse se donne de la maniere suivante : segment:offset, alors l'adresse reelle est: segment<<4+offset. (ceci est du au fait que le bus etait au depart sur 20 bits).
D'autre part, je ne sais pas pourquoi [elvio] tu rajoutes __djgpp_conventional_base a l'adresse de l'ecran reel (c'est une adresse absolue).
Pour moi FFFF:FFFF = 0xFFFF<<16 + offset (FFFF ie 16 bits a un, donc c est un decalage 16 bits que l'on doit effectuer).
Sinon dans ton code, y a plusieurs choses que je ne comprends pas.
Quand tu initialise ton mode essaye de mettre 19 et non 0x0013, il te demande un int, si ca se trouve, le cast n'est pas effectue implicitement (13h = 19 en decimal).
Le printf en mode graphique c'est moyen, vire le :)
Dans ta fonction init_realscreen, l'adresse pointe sur byte en theorie et toi tu cast en char, ce qui ne va pas du tout, cast en BYTE ou en unsigned char a la limite.
Sinon pour fakescreen, je suppose que tu veux que ca soit un buffer ecran. Je te signale que ca doit etre de la taille de la resolution de l'ecran(320*200), donc faut faire un malloc de 64000 de unsigned char ou byte.
C'est tout a fait normal que ca se plante si tu alloues pas tes pointeurs.
Dernier truc, je connais rien a djgpp, mais le near_ptr me fait croire que c'est des pointeurs nears et ca pourrait tres bien etre une cause de plantage(passe en mode far au moins).
Pour DreadLock, le Y<<8 + y<<6(je suppose que le smiley c est 8), c'est juste en faite pour faire faire y*320. En fait le fakescreen est un buffer ecran que l 'on peut voir comme un tableau [320][200], donc son calcul est juste une representation d'un tableau bidimensionnel en un tableau unidimensionnel.
A plus
Au fait Dreadlock, desole pour l'erreur de la derniere fois, je voulais dire que FFFF est egal 65535, et que je justement en mode huge on utilisait plus de pointeurs grace a la prise en charge des segments, c'est a dire qu'on adresse plus en 16 bits mais en 32.
Voila et encore desole de cette enormite(ca devait etre la fatigue :))
Normal que ca ne marche pas :
en 32 bits tu ne peux pas adresser de la mémoire physique.
Il faut passer par un driver.
oui je sais que ca marche plus directement mais bon je sais pas faire un driver. t'aurais pas des docs la dessus (memoire en mode protege et driver pour l utiliser ) ??
Il me semblait que pour la memoire en dessous de 1Mega, tu pouvais continuer de pouvoir l'adresser. Par contre pour adresser le reste de la memoire, il faut passer par des dos-extender sous Dos : Dos4gw,dpmi: http://www.tenberry.com/dpmi/index.html
Merci.
Je vais etudier ca.