Problema con fopen

[anibarro]

Salustian prueba a incluir este wrapper que te adjunto, creo que ahora funciona muy bien.
De todas formas es raro que con las ultimas SDL de chui te haga falta tanto rollo...si puedes habla con A600 que el domina el tema

[Salustian]

En la página de Chui pone ésto:

LIBC REPLACEMENT.
Core library. Standard C library replacement, newlib based but contains code of RobBrown, Chui and Mirko.
Also you can read 'x_gp32.h' header file for extra low level functions: video mode select, draw messages with internal fonts, enable/disable IRQs, etc...

Según entiendo yo, esto quiere decir que Chui ha reescrito fopen y demás funciones... ¿cierto?

Anibarro, gracias por tu ofrecimiento, pero tengo entendido que con las SDL no hace falta para nada el SDK oficial y preferiría evitarlo.

Un saludo.

[anibarro]

haces bien ;P Ya te digo que intentes contactar con A600 que hizo muchos ports SDL en los que se manejaban archivos

[Aiken]

ayer mirando codigo ... vi que hacian un smc_init y me acorde de ti porque luego usaban smc_open, smc_close, smc_read, lo has probado?

Aiken

< - >

sprite = IMG_Load("datos/sprite.png");
Y según he leido en varios post de los foros IMG_Load funciona sin problemas en la GP32.

yo uso el gpwrap.h que te han adjuntado, pero ya te digo que es mas antiguo que la propia gp32

Y en cuanto al Img_Load de las SDL, yo he leido en algun foro que daba problemas y recomendaban usar fopen y fread para leerlo a un buffer, y luego en lugar de cargarlo con Img_Load cargarlo con Img_LoadRW directamente de la memoria.


de todas formas prueba el smc_open y smc_read que creo que pertenecen a las x_gp32.h

Aiken

[Salustian]

Solucionado. Era un problema con los paths.

Lo que en windows es "datos/art.dat" para la GP32 debe ser "gpmm/datos/art.dat", a pesar de que la posición relativa entre el ejecutable y el fichero de datos sea la misma en ambos casos

Lo pillé por un ejemplo que publicó the_Guolin hace un tiempo (gracias tío).

Seguramente estará escrito en algún lugar de una documentación que debería haber leido

Y en cuanto al Img_Load de las SDL, yo he leido en algun foro que daba problemas y recomendaban usar fopen y fread para leerlo a un buffer, y luego en lugar de cargarlo con Img_Load cargarlo con Img_LoadRW directamente de la memoria.
Aiken

Es lo que precisamente estaba intentando hacer (y lo he conseguido )

El IMG_Load tambien funciona perfectamente.

de todas formas prueba el smc_open y smc_read que creo que pertenecen a las x_gp32.h

En el x_gp32.h que viene con las SDL no tiene esas funciones.

Y fopen, fread, fclose , etc. funcionan a la perfección, gracias al magnífico trabajo de Chui.

Gracias a todos por vuestro interés y vuestro tiempo

[Aiken]

Lo que en windows es "datos/art.dat" para la GP32 debe ser "gpmm/datos/art.dat", a pesar de que la posición relativa entre el ejecutable y el fichero de datos sea la misma en ambos casos

Eso es porque la gp32 lee por defecto de gp:// no de la carpeta donde esta el ejecutable, hay una funcion que se llama algo asi como GpRelativePathSet en el que le dices cual es el path inicio, supongo que habra su equivalente en x_gp32.h

PD. Lo digo porque si pones al principio una llamada a GpRelativePathSet, podras usar el mismo path para windows y gp32

Aiken

[esp3tek]

Lo pillé por un ejemplo que publicó the_Guolin hace un tiempo (gracias tío).

lo se, no viene a cuento, pero the goulin perdio su vieja pagina web y los ejemplos o ejercicios o explicaciones de su web, si lo stienes pasaselos que el otro dia hizo un llamamiento aver si alguien los tenia

[rlyeh]

Y fopen, fread, fclose , etc. funcionan a la perfección, gracias al magnífico trabajo de Chui.

Fue LD_Chen xD

[Salustian]

lo se, no viene a cuento, pero the goulin perdio su vieja pagina web y los ejemplos o ejercicios o explicaciones de su web, si lo stienes pasaselos que el otro dia hizo un llamamiento aver si alguien los tenia

El ejemplo que vi de goulin lo saque del foro, no sabía de su web.

Fue LD_Chen xD

Pues magnífico trabajo de LD_Chen.