Prob Genlib avec HW2 - Page 1

Je suis en train de créer un moteur 3d pour pouvoir ensuite faire un jeux du style CS

J'ai un probleme avec Gen lib, sur la Hw2, quand je lance mon prog ca me met un truc du genre memory protected violation.

Est ce que quelqu'un aurait une bonne methode pour l'initialisation, car je pense que ca vient de la, avec la Hw2.

Merci d'avance..

Je ne peux pas t'aider sans que tu m'aides plus.
Et perso, Genlib marche depuis tres longtemps avec la HW2. Donc c pas la le pb.

balance des morceaux de sources, la version de ton chien, l'age de genlib etc ... !

Voici plus d'info : version hw2 2.05, genlib V0.99.20

Un petit morceau de source , l'initialisation :

DSCREEN *DScr[2] = {NULL, NULL };
int ts = 0;


void SwapBuffer()
{
gl_set_dscreen_int(DScr[ts]);
ts ^= 1;
gl_set_dscreen_function(DScr[ts]);
}

// Constant speed 30Hz function


// Constant speed 15Hz function


// Ready to print ?
void Ready()
{
while (gl_timer == 0);
}







void _main()
{
short keya=0;

HANDLE hd;

gl_init(); // Init genlib

gl_init_dscreen(&DScr[0], &hd); // Alloc 1 DScreen
if (hd == H_NULL) goto exit; // Quit if error
gl_push_hd(hd); // Save the handle

gl_init_dscreen(&DScr[1], &hd); // Alloc the 2nd DScreen
if (hd == 0) goto exit; // Quit if error
gl_push_hd(hd); // Save the handle

gl_set_dscreen_int(DScr[0]); // Define the printed DScreen
gl_set_dscreen_function(DScr[0]); // Define the working DScreen
gl_cls(); // Clear the working DScreen


pointeur=&mur;
transforminit();
pointeur=&mur2;
transforminit();


centrcam[0]=0;
centrcam[1]=0;
centrcam[2]=0;


pointeur=&mur;
transformation();
pointeur=&mur2;
transformation();



do
{
ClrScr();
keya=ngetchx();
switch(keya)
{

case 338:
centrcam[2]=centrcam[2]+20;
case 344:
centrcam[2]=centrcam[2]-20;

case 340:
centrcam[0]=centrcam[0]+10;

case 337:
centrcam[0]=centrcam[0]-10;


}
pointeur=&mur;
transformation();
pointeur=&mur2;
transformation();



}while(keya !=264);
goto exit;

exit:
PortRestore(); // If we have called PortSet
gl_free_hd(); // Free all the allocated handles
gl_quit();
}

Peut-être que c'est encore le problème de GenLib qui ne marche pas sous certaines calculettes...
En plus, tu n'utilises pas la dernière version, donc ceci explique peut-être cela...

Ne melanges pas ClrScr() et gl_cls() !!!!
Tu fonctionnes sur un DScreen ! Et les routines de tios, a moins d'utiliser portset ne fonctionne pas dessus.

n'utilise pas clrscr() mais gl_cls(), n'utilise pas ngetchx() mais utilise les fonctions joypad pour faire gl_wait_a_key(), n'utilise pas de goto mais fais des sous fonctions sauf si vraiment c le plus efficace...

Heu pour le goto, en plus il est plus que inutile (dans la source tel qu'il la explosé) !!!


{
[...]
goto exit;

exit:
}

C'est pas franchement de l'optimisation sa !

C comme si tu faisait (en asm) :

[...]
   jmp exit
exit: [...]

En faisant sa tu risque d'avoir du code encore "mieux" que celui de l'AMS 2.07 (Sisi c possible )

mdr !

pkoi utiliser genlib pour un moteur 3D ?!!!!!!

Moui, pour tracer des lignes ect, je ne suis pas sur que genlib soit indispensable, tu peux utiliser des fonctions static plus rapide que celle du TIOS dispo un peu partout

Mais celle de gen sont clairement les + rapides.
Ext/X : 400 lignes /s
Gen: 1200 lignes /s

godzil a écrit :
Heu pour le goto, en plus il est plus que inutile (dans la source tel qu'il la explosé) !!!


{
[...]
goto exit;

exit:
}

C'est pas franchement de l'optimisation sa !

C comme si tu faisait (en asm) :

[...]
   jmp exit
exit: [...]

En faisant sa tu risque d'avoir du code encore "mieux" que celui de l'AMS 2.07 (Sisi c possible )

Non, n'importe quel compilo C optimise ça (même ontic ou CC )

PpHd a écrit :
Mais celle de gen sont clairement les + rapides.
Ext/X : 400 lignes /s Gen: 1200 lignes /s

quelle longeur ?
quelle pente ?
faudait faire un bench sur 360° ac un petit pas.

Erf.. Neuroo est en train de les passer en asm pour que le bench soit un peu plus séré...
Parce qu'en c, ca chie pas mal... meme si on utilise un algo différent de celui de bresenhma (il me semble.. faut que neuroo confirme).

Pen² > il ne faut jamais croir un bench quand on ne l'a pas compilé soit meme ou dasm.. surtout que en plus c'est benché avec Gen en kernel, ce qui est plus rapide qu'en nostub (la différence se voit que dans les bench, mais il y en a une ...)
D'ailleur pourquoi la source n'est pas dispo...

un de ces jours je v me recoder ma fonction de segment de bresenham..
je me demande combien de segment/s je peux atteindre