Sdl Simplest Example

[fells]

Hi all , I am trying to build some stuff for the Wiz and getting stuck early on.

My steps:

1. I downloaded Torpor's openwiz toolchain for linux, followed his directions to install it.

2. I copied this simple SDL example, called it main.c, changed the dimensions to 320x240, and then ran

/opt/openwiz/toolchain/bin/arm-openwiz-linux-gnu-gcc main.c -o test.gpe -I /opt/openwiz/toolchain/include/SDL -lSDL -L /opt/openwiz/toolchain/lib/ -liconv

3. I then copied the file libiconv.so.2.4 from /opt/openwiz/toolchain/lib/ and test.gpe to the root of my SD card.

4. Booted the Wiz, ran termula2x. Copied libiconv.so.2.4 to /usr/lib/libiconv.so.2 .

5. When I run test.gpe from the launcher I get a blank screen. When I run it from termula2x I get a segfault.

Any ideas? Also, do I always need to copy shared libs over to the wiz's /usr/lib/ or is there a better place?

 

[Pickle]

Hi all , I am trying to build some stuff for the Wiz and getting stuck early on.

My steps:

1. I downloaded Torpor's openwiz toolchain for linux, followed his directions to install it.

2. I copied this simple SDL example, called it main.c, changed the dimensions to 320x240, and then ran

 /opt/openwiz/toolchain/bin/arm-openwiz-linux-gnu-gcc main.c -o test.gpe -I /opt/openwiz/toolchain/include/SDL -lSDL -L /opt/openwiz/toolchain/lib/ -liconv

3. I then copied the file libiconv.so.2.4 from /opt/openwiz/toolchain/lib/ and test.gpe to the root of my SD card.

4. Booted the Wiz, ran termula2x. Copied libiconv.so.2.4 to /usr/lib/libiconv.so.2 .

5. When I run test.gpe from the launcher I get a blank screen. When I run it from termula2x I get a segfault.

Any ideas? Also, do I always need to copy shared libs over to the wiz's /usr/lib/ or is there a better place?

I dont know if /usr/lib is in the path. You can put all the special missing libs right next your binary.

 

[fells]

I tried putting libiconv.so.2 in the same folder as my binary and when I ran it under the termula2x it told me it couldn't find libiconv.so.2. So I copied to it /usr/lib and it ran but segfaulted immediately

 

[fells]

I am now able to compile it so that it runs! I looked at the lemonboy-sdl source makefile to do it. Here's the result:

# A basic Makefile to compile for Gp2x/SDL 

OPEN2X = /opt/openwiz/toolchain

CC = $(OPEN2X)/bin/arm-openwiz-linux-gnu-gcc
LD = $(CC)
STRIP = $(OPEN2X)/bin/arm-openwiz-linux-gnu-strip

NAME=test
TARGET= $(NAME)-sdl.gpe

DEFS = -DGP2X -DIS_LITTLE_ENDIAN -D_REENTRANT -DGP2X_ASM

INCS =  -I. -I$(OPEN2X)/include -I$(OPEN2X)/include/SDL

LDFLAGS=$(CFLAGS) -L$(OPEN2X)/lib
LIBS = -Wl,-rpath,$(OPEN2X)/lib -lSDL -lpng -lm -lz -lpthread

OBJS = main.o

MYCC = $(CC) $(CFLAGS) $(INCS) $(DEFS)

########################################################################

sdl: $(TARGET)

$(TARGET): $(OBJS)
	$(LD) $(LDFLAGS) $(OBJS) -o $@ $(LIBS)
	$(STRIP) $@

.c.o:
	$(MYCC) -c $< -o $@

clean:
	rm -f *.o *.gpe

The bad part is I don't know what's different here... my .c code is exactly the same. With the above Makefile, it runs, with a simpler gcc call like I showed in my first post, it segfaults. Is it the extra libs like -lz (even though the linker never complained before?) Is it the strip? Anyway, I'm not complaining too much-- I have a working app, so that's nice.

 

[Pickle]

strip should make no difference (beside making your binary smaller)

 

[Orkie]

I downloaded Torpor's openwiz toolchain for linux

You did, eh?

 

[fells]

I downloaded Torpor's openwiz toolchain for linux

You did, eh?

Yes.... am I missing something?

 

[torpor]

I didn't build the toolchain - just the libs, using the Open2X scripts - and I packaged Pickles toolchain + the libs to make it easier to have all the bits together.

The reason the newly-compiled version of your app works better, is probably due to this line:

LIBS = -Wl,-rpath,$(OPEN2X)/lib -lSDL -lpng -lm -lz -lpthread

compared with:

 /opt/openwiz/toolchain/bin/arm-openwiz-linux-gnu-gcc main.c -o test.gpe -I /opt/openwiz/toolchain/include/SDL -lSDL -L /opt/openwiz/toolchain/lib/ -liconv

.. it means you are now using the libs from $(OPEN2X)/lib (the new libs I built with OPEN2X) rather than the ones that came with the compiler toolchain .. mixing these two up can cause problems.

I will use your example as a base for making a more complete sample-app for use with this toolchain .. good that you've found a solution to your issue, as this is bound to cause future confusion.

FWIW, Orkie's script for building Open2X is pretty close to being useful, just has some bugs in it that prevent it from building successfully .. I'll try to get some WIZ-hacking time this week to commit my fixes of this script so that people can use it to build their own libs package from scratch without having to use my release, which I wanted to make available for basic testing and anyone who wants to just get on with hacking .. you finding this bug and a fix for it definitely makes it more useful, so thanks for the details!

 

[torpor]

I downloaded Torpor's openwiz toolchain for linux

You did, eh?

Now now, Orkie, no need to be snarky with me. I appreciate all *YOUR* hard work to make things easier for other guru's to come along and take all the credit.

 

[fells]

Ah, got it. Sorry Orkie, and thanks for the clarification torpor.

Torpor: you said you disabled pulseaudio from SDL in your build. Do you know if this disables all sound input? I want to try to get a simple microphone input example up next.

 

[torpor]

It doesn't disable sound input - just the use of pulseaudio within SDL. From what I know, the way to do mic input is by directly reading the raw device - there is an article on this in the wiki somewhere (don't ask me where, I'm bad with wikis) and I'm not sure if anyone has managed to get it working yet, so please post your results here if you make any progress - or not - so we can track it .. I also am interested in audio on the WIZ, so I'd be very happy to help you get recording from the mic working. My WIZ hacking schedule is a bit delayed because I have to hack up a serial cable before I can make any further progress on my personal projects, and I'm a bit lazy about that.. but I'll be eagerly awaiting news of your progress!

 

[ekureuil]

Hello,

It will be like one month since I got my wiz, and time to do something with it ... One year earlier I made a DS game: perfect test for the wiz ... Rewrote the code so that it worked on linux, and when enough options got implemented, tried to compile for the wiz. But I more or less get the same negative results as what is described in this post.

The facts:
- Got torpor toolchain+libs
- Untared to / => arm-openwiz-linux-gnu directory created ... as it was told to have toolchain ... mv to toolchain
- ln -s /toolchain /opt/openwiz/toolchain
- made a basic Makefile ... doing basically what fells done
- Launched termula:
-> libiconv.so.2 not found ... Put it beside my app, but no good, then in /lib: OK
-> idem for SDL_image and SDL_gfx ... OK
- Finally, my app launches but it segs fault. As I had some printf .. I saw that the seg fault is occuring at screen initialization. SDL has been correctly initialized.

My Makefile :

WTC=/opt/openwiz/toolchain
GCC=$(WTC)/bin/arm-openwiz-linux-gnu-gcc
Winc=-I. -I$(WTC)/include -I$(WTC)/include/SDL 
WCCF=-DGP2X -DIS_LITTLE_ENDIAN -D_REENTRANT -DGP2X_ASM
WLDF=-Wl,-rpath,$(WTC)/lib

wiz: sdlmammoth.c
	$(GCC) sdlmammoth.c -o sm.gpe $(Winc) $(WLDF) -L$(WTC)/lib -liconv -lSDL -lSDLmain -lSDL_image -lSDL_gfx $(WCCF) $(CFLAGS)

Now some remark,

First, torpor told that It may be a mix between libs problem ... but in fact the two version of fells compilation process use the same path to lib ... did I miss something ?
In my case, I progressively used informations from this thread (DGP2X flag etc...), but with no luck.

Second, the given Makefile is incomplete ... don't there miss some important informations, fells ?

To be sure, I tried to compile the fells' example, with its Makefile (slightly modified so that it worked). For the record, here it is:

# A basic Makefile to compile for Gp2x/SDL 

OPEN2X = /opt/openwiz/toolchain

CC = $(OPEN2X)/bin/arm-openwiz-linux-gnu-gcc
LD = $(CC)
STRIP = $(OPEN2X)/bin/arm-openwiz-linux-gnu-strip

NAME=test
TARGET= $(NAME)-sdl.gpe

DEFS = -DGP2X -DIS_LITTLE_ENDIAN -D_REENTRANT -DGP2X_ASM

INCS =  -I. -I$(OPEN2X)/include -I$(OPEN2X)/include/SDL

LDFLAGS=$(CFLAGS) -L$(OPEN2X)/lib
LIBS = -Wl,-rpath,$(OPEN2X)/lib -lSDL -lpng -lm -lz -lpthread

OBJS = main.o

MYCC = $(CC) $(CFLAGS) $(INCS) $(DEFS)

########################################################################

sdl: $(TARGET)

$(TARGET): $(OBJS)
	$(LD) $(LDFLAGS) $(OBJS) -o $@ $(LIBS)
	$(STRIP) $@

.c.o:
	$(MYCC) -c $< -o $@

main.o:
	$(MYCC) SDLTest.c -c $< -o $@

clean:
	rm -f *.o *.gpe

Result: segfault ...

As a final note, it is even harder to compile on an open console than on a cracked one !


Any ideas ? Should I investigate more (which way ?) ? Or maybe should I sit back, relax, and wait for a mature toolchain (Argh don't say that ! )?


eKuReUiL
---
(un geek peut en cacher un autre)

 

[Coder_TimT]

So, segfault in SDL_SetVideoMode? If so, I had the same and narrowed it down to using 32bpp. Changed to 16bpp and got my program to run... Can't really help beyond that as I don't actually have a Wiz.

Hope you get everything going.
Tim

 

[ekureuil]

Report back on various experiments:

YES ! changing from 32 to 16 bpp solved the problem ... Thanks you saved me a lot of time and frustration

After this step, I had a sdl_image problem: the lib did not find a function ... in fact, to solve this, -lz (i.e. zlib) is needed for the linking process

I then fought to make pad work: it is a fucking joystick that NEED to be opened (SDL_JoystickOpen) ... grrr

And finally, a weird thing: I had a file named SPACE2.png, copied it to nand, but my app couldn't find it ! I tried with termula: no SPACE2.png ... BUT ... a space2.png ... WTF ? I looked back on my linux (this is the SHORT story it took me a while to get the prob) ... no space2.png but a SPACE2.png ... Ok then, I already know that dealing with computer science is like voodoo magic, so I tried this in termula:

mv space2.png SPACE2.png
 unable to rename 'space2.png': file exists
mv SPACE2.png space2.png
 SPACE2.png: no such file or directory

mv is *not* supposed to check if a file already exists ... AND SPACE2.png *did not* exists ...

Too weird for me ... I decided to change the code so that it is lower case ...


It finally globally works. *Except* one thing: NONE of my tests were able to quit properly and get back to menu ... is there something special to do ? I quickly looked at some code (openjazz) but didn't see any special code for the exit process ...

eKuReUiL

 

[Alex.]

You have two options to return to the menu, one is to insert the following at the end of your main:

    chdir("/usr/gp2x");
    execl("gp2xmenu", "gp2xmenu", NULL);

    return 0;
}

And the other is to call your program from a script,

#!/bin/sh
./YourProgram.gpe
cd /usr/gp2x
exec ./gp2xmenu

 

[Orkie]

Just bear in mind that the first option is bad, while the second option is good.

 

[ekureuil]

Thanks for the help, I added a .ini pointing to the launcher script ... and it all works now.

I don't get why this solution is better than including it directly into the source code. In fact I would have thought of this solution as being the least optimal one as it add a shell layer that is not there if using C exec ...

Sorry if my sentence is bad, it's the evening and work used all my brain


eKuReUiL

 

[Pickle]

I don't get why this solution is better than including it directly into the source code. In fact I would have thought of this solution as being the least optimal one as it add a shell layer that is not there if using C exec ...

Its better cause it gives the user more control. For example I want to reload gmenu2x instead of gp2xmenu, since youve done the menu reload in a script I can change it. But if you hard code it in your application then im stuck, i can only load gp2xmenu.

 

[Jan-Nik]

Thanks for the help, I added a .ini pointing to the launcher script ... and it all works now.

I don't get why this solution is better than including it directly into the source code. In fact I would have thought of this solution as being the least optimal one as it add a shell layer that is not there if using C exec ...

Sorry if my sentence is bad, it's the evening and work used all my brain


eKuReUiL

Imagine you add a call to exit() in your application or an exception is thrown and not caught . The first option won't start the menu then.

 

[ekureuil]

Got it ! ... Thanks a lot everyone !

eKuReUiL