problème d'acces à des fichiers - Page 2

pour en revenir à ton pb, c'est curieux qu'il ne connaisse pas new et delete... t'es sûr que c'est du C++ en fin de compte ?

tu ne peux pas utiliser malloc et free, du moins pas uniquement eux, puisqu'ils ne vont pas initialiser/libérer l'objet ni appeler son constructeur/destructeur correctement. mais t'es sûr que C_keyboard est une classe, et non pas un simple enregistrement ?

Spipu (./9) :
vi tout à fait, c'est du C

Cest parceque sauver citer foire sur les "+"ok

C_keyboard est une classe que j'ai fait moi meme donc oui c'est bien une classe

en fait, avant, il reconnaisait new et delete, avant que j'enlève la directive indiquée ici (./24)

cette directive sert à ca :

It tells the compiler to link against PSPSDKs own implementation of libc. By default it will use the newlib port, which is more compatible and preferred, at the cost of making your executable bigger. The other alternative is to use the kernels inbuilt small libc (which is very stripped down) by defining USE_KERNEL_LIBC = 1 in the makefile, which will not add any extra code to your executable for libc (other than the import table).

comment changer une lib statique peut faire en sorte que new et delete soient plus reconnus ?

c'est quoi le message d'erreur exact que tu obtiens ?

idem....

main.cpp: (.text+0x500): undefined reference to `operator new(unsigned int)'
main.cpp: (.text+0x618): undefined reference to `operator delete(void*)'

ah attends, ça voudrait dire que la lib que t'utilises maintenant est une lib C et non pas une lib C++ ? (et que donc si tu comptes coder en C++, tu n'as pas le choix)

tu compiles avec gcc ou g++ ?

si c'est avec gcc il aurait même pas pu avoir ce msg d'erreur non ? (ça aurait pas reconnu "new blabla" en tant que operator new (unsigned int)" j'imagine ?)

ben j'utilise DEv-C++ (sous windows) couplé à un pspsdk sous cygwin pour compiler. et quand je vais dans le repertoire d'install sous cygwin de ce sdk, il y a ca : gcc-4.0.2.tar.bz2

donc je suppose que c'est GCC qui est utilisé...

Non, ça veut dire juste qu'il installe la GNU Compiler Collection. La question, c'est s'il linke en utilisant gcc.exe ou g++.exe, parce que c'est le deuxième qu'il faut.

Zephyr (./38) :
si c'est avec gcc il aurait même pas pu avoir ce msg d'erreur non ? (ça aurait pas reconnu "new blabla" en tant que operator new (unsigned int)" j'imagine ?)

si si, gcc compile les .cpp en .o exactement comme g++, la seule différence est dans le linker : g++ linke aussi avec la lib C++

ah ok

bon, ben sur un forum de prog PSP, on me conseille d'ajouter une option dans le make file : l'option -lstdc++ dans la variable LIBS

j'espere que ca va marcher avec ca....

bon, ben ca marche il arrive à me charger des textures et autre donc mon code etait bon, le pb venait juste du make file (ce qui me rassure...)


pour plus d'infos, voici le topic que j'avais créé sur le forum de PSP-Programming : http://www.psp-programming.com/forums/index.php?topic=2833.0

spa ça qu'il faut que tu postes, c'est les screenshots une fois que ça sera fini

vi, mais déjà, c'est pour ceux qui auraient le meme pb plus tard : ils sauront commment le résoudre

et ces screenshot ?

lol, j'en suis pas encore à faire des screenshoot... pour l'instant j'en suis à créer mes class afin de réussir à faire ce que je faisais il y a quelques années en opengl sur pc

y'a déjà des libs pour faire de la 3D ou faut tout se taper soi même ?

Spipu (./43) :
bon, ben sur un forum de prog PSP, on me conseille d'ajouter une option dans le make file : l'option -lstdc++ dans la variable LIBS

g++ linke ça automatiquement.
Bref, c'est ton makefile qui est foireux. Une fois de plus: il faut linker avec g++, pas gcc.

Zephyr (./49) :
y'a déjà des libs pour faire de la 3D ou faut tout se taper soi même ?

il y a des fonctions proches de celles de l'opengl

bon, ben c'est bon, j'arrive à charger des images bnp et à les utiliser comme texture par contre, le fait de passer de 1 texture à 2 textures me divise le fps par 2

30 fps pour trois cube qui tournent ? y'a une synchronisation avec l'écran qui est effectuée, ou bien il y a effectivement un petit problème de vitesse avec ton programme ? ^^

Spipu (./52) :
le fait de passer de 1 texture à 2 textures me divise le fps par 2

avec une seule texture => 60fps, avec plus d'une texture => divisé par 2 => 30 fps

=> y à la fois une synchro avec l'écran *et* un pb de vitesse

tout à fait

alors, petit test : à chaque fois la meme scene avec les 3 cubes, mais avec 1, 2 ou 3 textures d'utilisées : avec une ou 2 textures, il est à 60fps, avec 3 textures, il passe à 30fps ?! du coup, j'ai regardé les dimensions de mes textures : la 1 et la 2 sont en 128x128x24bit, la 3eme etait en 256x256x24bit => j'ai essayé en la passant à 128x128x24bit => op, 60fps donc la psp a du mal avec les grosses textures !

Spipu (./57) :
alors, petit test : à chaque fois la meme scene avec les 3 cubes, mais avec 1, 2 ou 3 textures d'utilisées : avec une ou 2 textures, il est à 60fps, avec 3 textures, il passe à 30fps ?!

note que en soi, c'est pas surprenant : sachant que la synchro verticale arrondit au diviseur de 60fps inférieur, il suffit que sans synchro verticale avec 1 texture ça fasse 65 fps, 2 textures 61 fps et 1 texture 57 fps pour que tu observes ce genre de chose... si tu peux désactiver la synchro c'est mieux pour faire des mesures de fps

Pollux (./58) :
si tu peux désactiver la synchro c'est mieux pour faire des mesures de fps

ah vi lol, c'est pas bete du tout ca !!!!

bon, ben en desactivant la synchro, c un peu mieu

et en fait la psp gere très bien les textures en 256x256 (heureusement d'ailleur, pour les textures des fontes de texte)

et à propos des fonts de texte, j'ai des petits pbs moi ^^