memoria dinámica

[artblanc]

Buenas, estoy teniendo unos pequeños problemas en la reserva dinámica de memoria y no se si el culpable es el compilador o la GP32 (o yo).

El objetivo original era el de conseguir un buffer de 32 bits del tamaño de la pantalla (lo de 32 bits es cosa mia).

El tema es que la reserva dinámica de memoria falla:

unsigned long * buffer;
buffer = new unsigned long[320*240]; // si, uso C++ :-)

pero por contra, si lo hago estáticamente si que funciona:

unsigned long buffer[320*240];

¿alguien me puede explicar la extraña causa de esto?

Gracias.

[mortimor]

prueba:

buffer = new long [320*240];

Si no me equivoco es lo mismo. (que conste que no soy un experto)

[Zheo]

¿como falla la memoria?

Lo primero que has puesto debería funcionar.

Un saludo.

[mortimor]

Seguro que te falla al asignarle algo al buffer. Estas seguro de que reservas el espacio que necesitas????

[artblanc]

sobre vuestras respuestas:

- sobre lo de long en vez de unsigned long - No lo he probado porque estoy en el trabajo pero si que probe con "int" (que al ser de 32 bits, tambien deberia ser lo mismo que long) y si que fallaba.

- Sobre el tipo de fallo - En la GP32 pantalla en blanco, en el emulador casca, error de protección y tal...

- Falla al reservar - Esta comprobado que falla al reservar, no hago nada después con el buffer

lo extraño es que con menos memoria si que va, es decir:
unsigned long * buffer;
buffer = new unsigned long[100*75];

Problema de memoria tampoco es, porque aparte de los dos buffers de la pantalla solo creo eso:

2 buffers a 16bits de 320 x 240 = 2457600 bits = 2,45 MegaBytes.
El buffer que intento crear deberia ocupar lo mismo.
2.45 + 2.45 = 4.9 Megas... me sobra memoria en la GP.

No se que puede tener la culpa... supuestamente toda la memoria es para mi apliación, no?

Problema del código en C++ no es, ¿se me escapa algo que no se sobre la memoria de la GP32?. no hay sistema operativo, luego, problemas con la pila asociada al programa o memoria para la ejecución del programa no creo que sea.

Un saludo.

[Wave]

2 buffers a 16bits de 320 x 240 = 2457600 bits = 2,45 MegaBytes.
No por dios, 2x320x240x2= 307200 bytes
= 300KB
No ocupa cada uno 8x16 bytes, sino 2x8 :D

[artblanc]

true, true, jejeje (el 16 bits = x 2 bytes)
(habia multiplicado por 16 bytes, que burrada)

mejor me lo pones... me sobra memoria por un tubo!!!

jejeje

¿alguno puede probar a reservar un buffer de 320 x 240 de 32 bits (unsigned long) y decirme si le ejecuta bien?

Gracias

[seryu]

x cierto xqe no usas un GPDRAWSURFACE?

[artblanc]

Hola, sobre lo de usar GPDRAWSURFACE si que lo hago para los buffers de pantalla, pero no para los que uso para leer TGA y otras cosillas.

Ayer en el canal de IRC #gp32dev me comentó TDP que lo que pasa es que el new de C++ no gestiona bien la memoria, que para conseguir reservar memoria de la consola tengo que usar las funciones de la api, gpmalloc, etc... que habria que hacer una adaptación del new de C++ para que usara las funciones de la API, o en su defecto usarlas yo en vez del new.

Me parece que lo más elegante es adaptar el new para que haga un gpmalloc y tal...

Parece que el hecho puntual de que no fallara con menos memoria era que daba la casualidad de que no pisaba ningún trozo de memoria que estubiera en uso.

Muchas gracias.

Un saludo.

[Aiken]

Ti vi en alguna pagina de alguien que habia implementado nuevos new y delete para c++ para gp32.

Creo que era en la pagina de darkfader o alguno de estos gurus, pero no lo encuentro, si alguien sabe a que me refiero podia colgarlo aqui, please ....

Yo uso en minigp32 para windows, yo crei que este parche del new y delete ya estaban aplicados ...

Me estoy volviendo loco con petes del tipo ahora fallo ahora no, seguro que es que a mi se me ha ido algun puntero, pero esto del new y delete, a la vez me hace ver una luz, y me desconcierta.


Por cierto yo los punteros los estoy declarando como

unsigned char *mipuntero;

mipuntero = (unsigned char *)malloc(100*100); para una imagen
de 100x100 en 256colores, vamos para luego hacer un blit.

Esta bien de esta forma, o tengo que usar punteros (int *) ??


He visto que el blit, usa multiplos de 4 en los tamaños de las imagenes (internamente), supongo que es por el tamaño de las palabras del procesador la memoria o algo, si alguien lo puede explicar ???

Aiken

[Aiken]

He hecho un sprintf a hexadecimal de un puntero y me ha
pintado cosas del tipo ....

0xC1796D0 (son 7x4 = 28 bits), deberia ser de 32bits?

Es porque me ha devuelto una direccion que no usa los 4 bits de mas peso y el sprintf lo ha quitado, o es porque lo estoy almacenando en un (unsigned char*) ??

Aiken

[Aiken]

Creo que lo he encontrado ...
pero ponia que era para gcc3.0.4 ... pero viendo el codigo yo creo que no hace nada complicado, de hecho bastante facil.

En el codigo ponia algo de Mr.Spiv.

Ahora si alguien me explica alguna forma limpia de usar esto ??

Aiken

[mortimor]

Pues es por que los primeros bits son 0, ni mas ni menos.

Jejeje, yo como todavia no me he pasado a C++ con la GP32 no tengo ese problema. :P

[artblanc]

te cuento Aiken:

-sobre los punteros
si tu haces:

unsigned char *mipuntero;
mipuntero = (unsigned char *)malloc(100*100);

es porque estarás usando imágenes con paleta (bueno, a 8 bits, otra cosa es que representen una paleta), por eso lo de usar un byte para cada pixel.

Esta bien, yo lo único que pasa es que uso modo de 16 bits de pantalla (las superficies son de 16 bits) y mis imágenes de momento las guardo a 32 bits (por ejemplo, una textura) y solo las convierto a 16 bits cuando las copio al buffer. (aun no se si trabajar con las texturas a 16 bits o a 32, pero lo cierto... es que necesito reservar memoria bien, jejej)

Paso a mirar el .zip que has adjuntado.

Gracias
Un saludo

[Aiken]

El zip de Mr Spiv he estado investigando ...

Busca cosas que estan en un directorio
include/g++-v3/

alguien sabe que es esto ? el directorio existe en el minigp32-v1, pero en el minigp32-v2 no esta ese directorio a si que no tira. Supongo que MrSpiv lo hizo para el mini-v1.

No se si volver al minigp32-v1 o esperar a que alguien lo adapte para usarlo en el v2, pues no tengo huevos de hacerlo funcionar con el v2.

Alguien sabe que diferencia hay entre el minigp32 v1 y v2, creo que la version del gcc y no se si algo mas. quizas en la v1 no estaba el libc-wrap (para el fopen,malloc etc) ??

Aiken

[(_=*ZaXeR*=_)]

Yo no es por nada pero creo recordar que el new de C++ siempre ha cascado sin tener que tratarse del que se usa para gp32, vamos que cuando programabamos en C++ bajo windows nunca usabamos el new

[Zheo]

Entonces dudo mucho muchísimo que programaseis en C++ :P
Al menos crear clases reservando memoria dinámica no pudisteis hacerlo, lo que le quita gran parte de la gracia al eliminar la ligadura dinámica :(

El new de C++ funciona perfectamente al menos bajo los compiladores que he probado: g++(linux), minGW, djgpp, visual C++ 6.0 , visual C++ .net, y borland (no me acuerdo de que versión, aunque es antiguo.) Bueno, al menos a mi me funcionaba bien, que no me quiero pillar los dedos (sobre todo con el Visual C++ 6.0 :P:P:P:P)
Ahora, que el compilador que usaras tuviera una implementación del new que fuera kk pues no se. En el compilador de Borland que digo (joer que rabia me da no acordarme de la versión) no podías utilizar correctamente la clase vector<T> de la STL, ni siquiera compilaba...