GP2X It Doesn't Run On The Gp2x D:


furyhunter600

Still Fresh
Joined
Sep 29, 2006
Messages
21
So I decided to give C one more chance, and I guess the last chance was the charm, because I've been enjoying programming this thing for the past 3 days. The problem is, recently this program I've been working on has stopped working on the gp2x (however it runs fine on Windows). It is an SDL application and uses SDL_mixer for the music test.

Source: http://www.sendspace.com/file/2nmfvy

If someone could possibly show me what is going on (The gp2x build does not seem to create any error logs like it should), I'd greatly appreciate it.

I compiled this using the GP2X SDK from Gamepark Holdings.

EDIT: What happens is, when I run the compiled .gpe on the gp2x (with the data folder copied over), it just shows a black screen for a second, and then goes back to the home screen.

EDIT EDIT: and I forgot to add that you need to place the folder SDL_gfx with the latest stuff in it in the folder with the source, or change the #include to <> instead of "" :/
 
I've no time to download and debug _for_ you, but some tips so you can learn how.. hopefully people can post those :)

o Send to the device _frequently_, so when oyu do a change, and it breaks, you know exactly what possible changes caused it.

o keep multiple versions of source; so you can compare when you forget what you did above :)

o logging; you mention no logs.. well, theres 3 cases:

i) You're not logging early enough
ii) If your first funcall is a log routine, and it doesn't get logged, then its crashign before that*
iii) (your log function doesn't work? :)

Now, if its crashing before the first thing, which is a log routine.. most likely its not even a crash, ut a linking issue or something, thats preventing loading. Assuming your toolchain is sane, this shouldn't likely occur too much.

So likely you're not logging enough, or your log routine is busted.

jeff

If you're really on top of your game, you could fire up gdb on the device and catch it at the crash, and other trickery.. but thats effort.
 
Hmm, it's probably likely that it's a linking issue, because it started to happen when I #included SDL_mixer.h. But I just tried commenting all the mixer stuff out, and it still does it... hmm

I'll try making it log more. Thanks, will post any results.
 
The logging may not be syncing to the SD card if you are printing out ot a file.
 
Run your prog through telnet will give you all the debug output and usually the reason for jumping back to the menu.

Also, don't forget output is buffered, so if your program crashes before the output is flushed, your program could crash after something you have logged, but before it was actually written out by the os.

GDB is your friend :)
 
I advocate adding:
#define HERE() fprintf (stderr, "%s - %s(), Line %d\n", __FILE__, __FUNCTION__, __LINE__);
to /usr/include/stdio.h
and scattering calls to
HERE();
throughout your code...

Well it's what I've always done :)
 
I'm not sure if stderr is buffered, but I would of assumed so, in which case you might want to add a fflush.
 
stderr is buffered, so you need a fflush(stderr)

better is doing a reopen so stderr is a text file instead of console (I think SDL does this already...)
 
Never had to a do an fflush if there is a newline at the end - that flushes...
or always has on every machine I've ever written software on in the last 24 years... -
but I guess I could be wrong (it has happened once or twice that I'll admit to) :) (Note you will have to fflush if you don't end in a newline).

Another little trick is to send output to /dev/pts/1 - then you can have a dedicated telnet window with just debug output (note you then have to \r\n at the end of lines). Note your code will crash if no telnet session matching that `tty` - so if it's unopenable, dump it somewhere else - /dev/null or stderr.
 
The problem with gp2x Linux is that when it core dumps it bypasses the usual buffering mechanism, so you can get the "Core dumped"/etc before the printf you put before the crash. Also, if you use the serial output (rather than telnet) you can actually see the text intermixed
 
Well, here's the problem with running telnet...

There is no USB networking drivers that work with the gp2x for Windows XP x64

If someone could help me with this huge problem, I'd greatly appreciate it.

Now that I'm done with that, I tried looking into my NAND memory to no avail (however I do realize that it's likely in the ROOT of the NAND memory, which isn't where the NAND memory explorer goes to in the firmware.) for the log.

Also, I feel a bit wrong asking this, but how do I statically link libraries? ;_;
 
Furyhunter said:
So I decided to give C one more chance, and I guess the last chance was the charm, because I've been enjoying programming this thing for the past 3 days. The problem is, recently this program I've been working on has stopped working on the gp2x (however it runs fine on Windows). It is an SDL application and uses SDL_mixer for the music test.

Source: http://www.sendspace.com/file/2nmfvy

If someone could possibly show me what is going on (The gp2x build does not seem to create any error logs like it should), I'd greatly appreciate it.

I compiled this using the GP2X SDK from Gamepark Holdings.

EDIT: What happens is, when I run the compiled .gpe on the gp2x (with the data folder copied over), it just shows a black screen for a second, and then goes back to the home screen.

EDIT EDIT: and I forgot to add that you need to place the folder SDL_gfx with the latest stuff in it in the folder with the source, or change the #include to <> instead of "" :/


This should work. The problem was you were failing to SDL_Load but missing it by checking for less than 0 when it returns NULL on error. The biggest problem I had loading it and why it was failing for me was unrar lower-cased the TITLE directory when I unpacked it to a vfat file system, my xfs workstation did not and I had exactly what you see. I'd lower case everything until you get it working. Very good job for a starter, have a few suggestions that may help in the long haul, f*xed copy is here:
http://gp2x.fullsack.com/cocoon/gp2x/downl...stupidg-0.1.zip
I took the liberty of re-arranging things a bit. Style counts. Headers, files you #include should not contain code, constants, macros, structure definitions, but not functions, those go in your .c files. Each c file should have an h file with at least the prototypes. Declare and initialize all variables at the top of each function, never mixed with the code. C has few restrictions, more than programming it is an art and a discipline, you either get really organized and into best practice or you'll find yourself repeating this exercise over and over. A good naming convention really helps too. Recommend Brian Hook's, "Write Portable Code". But above all else stick with it.

Try this one, create a shell script named stupid.gpe with the contents below in the stupid directory and launch it on your gp2x instead of your application after sprinkling your code with fprintfs, be sure it's executable:

#!/bin/sh
./StupidGame.gpe 1>out.txt 2>err.txt
exit 0
#eof

run your game then you can check out the .txt files with e-book, the poor mans embedded debugger.
 
Last edited by a moderator:
Wow, that looks a whole lot better than my original code. Thanks! ;D

But there are a few issues that I am having with it:

1. xpos -= 96; <-- This sets the xpos back 96 pixels. It's supposed to set it to -96 so that the "PRESS START" scrolls smoothly across the screen. The result of the current code is a strange jumping.

2. audio_buffers = 128; <-- Why is this so low? It was causing the sound to warp and go all freaky dizzy o_O
 
Furyhunter said:
Wow, that looks a whole lot better than my original code. Thanks! ;D

But there are a few issues that I am having with it:

1. xpos -= 96; <-- This sets the xpos back 96 pixels. It's supposed to set it to -96 so that the "PRESS START" scrolls smoothly across the screen. The result of the current code is a strange jumping.

2. audio_buffers = 128; <-- Why is this so low? It was causing the sound to warp and go all freaky dizzy o_O
You suspected sdl_mixer, setting that too large gave me some trouble in the past on the gp2x so I just dropped it down, crank it back up. Stuck a few fprintfs in there to see if those were sane and must've put xpos back wrong, sorry bout that. Was not sure how it was supposed to work, really glad to see people still taking an interest in C, my first and still favorite. Hope the game turns out, liked the style of your art.
 
Last edited by a moderator:
Sphinxter said:
run your game then you can check out the .txt files with e-book, the poor mans embedded debugger.
You do realise that the gp2x has a free, full, symbolic debugger that allows you to set breakpoints, analyse variables, etc ? Much better than spitting out text files and viewing them later on with the text reader.
 
Last edited by a moderator:
If it does, it'll probably become Robi: Genesis, a Game Maker project of mine. (yes, I know, Game Maker. Introductory but still a bit awkward to say on such forums).

I fixed the problems, now there's only one thing seperating the Windows and gp2x executables: Windows draws at 60fps, but the Gp2x is drawing about half as slow.

You wouldn't happen to know any nice framerate scripts that work across multiple machines, would you? Right now, as you probably saw, I'm just using SDL_Delay(1000/TICRATE) (ticrate is 60). I'm guessing linux, or the gp2x, doesn't have as many/has more tics per second as Windows?
 
Furyhunter said:
2. audio_buffers = 128; <-- Why is this so low? It was causing the sound to warp and go all freaky dizzy o_O
If set any higher, in my experience, your sounds have a second or so delay before they actually play. Thats not so bad for music, but its really bad when your sound effects are a second or so behind the actual game event that caused the sound. Adjust this number cautiously. With SDL you have to find the happy medium between accurate sound, and accurate timing.
 
Last edited by a moderator:
Squidge said:
Sphinxter said:
run your game then you can check out the .txt files with e-book, the poor mans embedded debugger.
You do realise that the gp2x has a free, full, symbolic debugger that allows you to set breakpoints, analyse variables, etc ? Much better than spitting out text files and viewing them later on with the text reader.


Grievous overkill besides actual development on the device not sounding like much fun at all, never even plugged in my bob. I have no plans for anything below the application level so I doubt it will ever come to that.
 
Last edited by a moderator:
Back
Top