GP32 Sdl And C++

[Gammenon]

Hi
I tried to use the recently released SDL standalone of Chui. I was able to run all examples both in Windows and GP32, but those are written in plain C. Later, I tried using C++, and after fighting with makefiles and its dreaded settings, I was able to run it in Windows, but it didn't work in GP32. I mean, program runs both in Windows and GP32, but doesn't draw anything when running in the handled. SDL_Blit doesn't work, but SDL_FillRect works properly.
All this happens using C++, but works OK with old plain C. Does anybody have this problem?

Thank you for reading and suffering my "macarronic" english

 

[no_skill]

i gave up on getting c++ to work on the gp32.

however scummvm is written in c++ afaik, so it *is* possible.

but i'm waiting for the gp2x anyway.

 

[Saido]

No_Skill your my hero
I love your tutorials

 

[no_skill]

thanks

 

[Oankali]

i gave up on getting c++ to work on the gp32.

however scummvm is written in c++ afaik, so it *is* possible.

but i'm waiting for the gp2x anyway.

​

*You can* code in c++ with the oficial SDK if you want right now.
Here you can find the SDKs for GCC and for VC++6.

 

[M-.-n]

i gave up on getting c++ to work on the gp32.

however scummvm is written in c++ afaik, so it *is* possible.

but i'm waiting for the gp2x anyway.

​

Using C++ & libmirko's also pretty much of a breeze.. I enjoy a lot being able to use it for GP32 dev.

 

[kissbengt]

i did my pizzaworm game using mirko's and c++, i recently moved it up to work with devkitpro. so it can most certainly be done.

 

[Gammenon]

Hi, thank you all for your replies, but I want to use C++ with SDL, not with other SDK. I knew that C++ can be used to program the GP32 with mirko's SDK, for example.
Nobody has experience with SDL + C++?

 

[elektrocution]

i just recently downloaded devshed c++ so hopefully i can get it working on the gp32 after i while, i have about 300mb of c++ books and tutorials to read tho ;D

any pointers on how to make my cpp stuff gp32 compatible would be great, havent gotten far enough to work with some sdk

 

[Muffinman]

I got C++/SDL running last weekend - I'm pretty sure there's a better way of doing it, but it (mostly) seems to work - libpng crashes on load, for example, and I'm hoping that this isn't because of all sorts of other reasons. But blit and fill_rect both work.

Anyway, try something like:

- Get hold of devkitarm_r14 (last one I think with gcc 3.4.4 - it didn't like 4.0.1), install to c:\devkitarm.
- Install MirkoSDK (to c:\devkitarm\libmirko)
- Install binary version of SDL (to c:\devkitarm\SDL)

- Download and unzip source version of SDL from Chui's site to some other separate location.
- Recompile the SDL libraries after removing -msoft-float from each makefile.gp32, because this seems to cause a conflict with libc++, and overwrite the libraries in c:\devkitarm\SDL\lib
((I've tried SDL, SDL_Image, SDL_Gfx, (which worked), libpng (which didn't) and libz (untested)

In your program, use #include <gp32.h> (Mirko's) rather than #include <x_gp32.h> (SDL).
The file io part of SDL doesn't seem to work with this setup, but you can use Mirko's SDK to load a file into a buffer, and then use SDL_RWFromMem to do things with it - e.g. load as a gif, and subsequently blit.

Makefile below - based on Mirko's pure C++ example.

CC  = arm-elf-gcc
LD  = arm-elf-g++
AS  = arm-elf-as
AR  = arm-elf-ar
CXX = arm-elf-g++

PRG  = framerate
OBJS = test.o control.o screen.o gp32_fileio.o

MIRKOROOT = c:/devkitarm/libmirko
SDLROOT = c:/devkitarm/SDL

LIBS      = -L$(MIRKOROOT)/lib -L$(SDLROOT)/lib -lm
MIRKOLIBS = -lmirkoSDK_GEEPEE 
SDLLIBS   = -lSDL -lSDL_gfx -lSDL_image -lZ
CRT0      = $(MIRKOROOT)/lib/crt0.S
LNKSCRIPT = $(MIRKOROOT)/lib/lnkscript
INCLUDES  = -I$(MIRKOROOT)/include -I$(SDLROOT)/include/SDL -I$(SDLROOT)/include
CFLAGS    = $(INCLUDES) -O2 -s -mtune=arm9tdmi -DGP32
CXXFLAGS  = $(CFLAGS)
 
all:	$(OBJS)
	$(CC) -c -o crt0.o $(CRT0)
	$(LD) -nostartfiles -s -Wall -Wl,-Map,Test.map  -T $(LNKSCRIPT) crt0.o -o $(PRG).elf $(OBJS) $(LIBS) $(SDLLIBS) $(MIRKOLIBS)
	arm-elf-objcopy -O binary $(PRG).elf $(PRG).bin
	cp $(PRG).bin e:\$(PRG).gxb
	b2fxec -a Muffinman -t Test_$(PRG) $(PRG).bin $(PRG).fxe
	cp $(PRG).fxe e:/
install:
	gplink put $(PRG).fxe gpmm

clean:
	rm -f *.o *~ Test.map *.bin *.elf

 

[pea]

Hi,

Just a tip with libpng - it was crashing on me alot too (not with SDL, but with standalone version) which turned out to be the use of 'setjmp' and 'longjmp' for some freaky 'goto' style error handling (BAD BAD BAD BAD!).

So I altered the source for libpng (I have a cut down load-only version) to pass back error values rather than use longjmp for errors. It took freakin ages, but the process is rather simple.

I don't think my sources would be much use to anyone else as they are extensively modified to use my graphics structures, but if all else fails, try replacing the 'setjmp/longjmp' error handling! (even comments in the code say 'TODO: replace setjmp/longjmp error handling' - seriously!).

 

[Gammenon]

Hi!
Thank you very very much for your help, Muffinman! I'll try it this weekend

 

[Muffinman]

Thanks for possibly clearing that up Pea - I might have a look at that if I get time.

 

[Ksmiler]

What was your setup to recompile the SDL libraries without -msoft-float?
Did you use Cygwin, and where did u place it (directory wise)?
Did you use any extra files to help with the recompilation?

Thanks.

 

[codesmith]

Hi,

Just a tip with libpng - it was crashing on me alot too (not with SDL, but with standalone version) which turned out to be the use of 'setjmp' and 'longjmp' for some freaky 'goto' style error handling (BAD BAD BAD BAD!).

So I altered the source for libpng (I have a cut down load-only version) to pass back error values rather than use longjmp for errors. It took freakin ages, but the process is rather simple.

I don't think my sources would be much use to anyone else as they are extensively modified to use my graphics structures, but if all else fails, try replacing the 'setjmp/longjmp' error handling! (even comments in the code say 'TODO: replace setjmp/longjmp error handling' - seriously!).

​

Huh, interesting. I would have tried to fix it by fixing setjmp and longjmp (which, being C library functions, are IMHO more important to get working than a 3rd party lib). I totally agree with you about misusing setjmp/longjmp - I suspect libpng was written by someone who normally uses C++ or Java and wanted to get some form of exception handling working in C.

I hope GPH have the entire C library working properly by the time they release the official SDK.