Gp2x Code::blocks Pre-configured Sdk Rc2


I just checked the file date on the libs, they are a mix of late 2005 and early 2006 (March). My libs are from May 2006 and a few later in the year and 2007 so it could be a possible cause of them being old libs.

Although saying that it shouldn't really matter as sdltest has worked since the early days of GP2X. So it might not be old libs that is the problem, maybe a conflict or bug in the libs?
 
I hope it could be updated/fixed easily if that toolchain is really better than the default SDK :)
 
It might just be a case of grabbing the latest devkitgp2x and libs and adding them to this setup. if someone wants to try they can try with my setup I released late last year (it is newer than the one in codeblocks package) at http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,19,1875. all you need to do is replace the devkitGP2X folder from codeblocks package with this downloaded one.

I have to go out for a bit, but I will try it when I get back.
 
Looks like it was the supplied libs that were the problem, I copied my libs and afterwards, the Open2x ones into devkitGP2X and they both worked fine.

The Open2x libs are probably the ones to use as they are more recently built than mine so I would add them if its OK with Orkie into your distribution.
 
In your GP2X template properties, build target, PC should be "GUI application" type and GP2X "Console application" type.
They seems to be inverted ( will not be easy to figure out for a noob ) ;)
Anyway for my first try, Code:Blocks seems better than Dev-cpp !!!
Thx again for that toolchain !
 
UMXPRime said:
In your GP2X template properties, build target, PC should be "GUI application" type and GP2X "Console application" type.
They seems to be inverted ( will not be easy to figure out for a noob ) ;)
Anyway for my first try, Code:Blocks seems better than Dev-cpp !!!
Thx again for that toolchain !
PC Debug should be Console as it aids debugging when the programmer scaffolds the code. PC release should definitely be GUI. For the GP2X, does it matter?

Edit: Expect a Rc4 on Monday with the fixed template.
 
Last edited by a moderator:
yaustar said:
UMXPRime said:
In your GP2X template properties, build target, PC should be "GUI application" type and GP2X "Console application" type.
They seems to be inverted ( will not be easy to figure out for a noob ) ;)
Anyway for my first try, Code:Blocks seems better than Dev-cpp !!!
Thx again for that toolchain !
PC Debug should be Console as it aids debugging when the programmer scaffolds the code. PC release should definitely be GUI. For the GP2X, does it matter?

Edit: Expect a Rc4 on Monday with the fixed template.


Well I was assuming that invertion comparing guyfawkes SDL project properties with the template. Anyway I am not sure about the GP2X type, but maybe a console type help a lot to get output within telnet I don't know as I'm a noob :) ...
Thanx updating the package for everyone :)
 
Last edited by a moderator:
Not to detract from the attempt but this "package" has not worked in the slightest for me.

I'm running Vista so I've unpacked it according to instructions, then played with MinGW. Then all I get is one group of errors after the other relating to files which cannot be found.

After 30 minutes of showing C:B where "stdio.h" was etc I've given up as I don't see the benefit of "pre-configuration" if I'm sifting through page after page of "cannot find" errors.

Hope it gets better in the future.
 
Dingo_aus said:
Not to detract from the attempt but this "package" has not worked in the slightest for me.

I'm running Vista so I've unpacked it according to instructions, then played with MinGW. Then all I get is one group of errors after the other relating to files which cannot be found.

After 30 minutes of showing C:B where "stdio.h" was etc I've given up as I don't see the benefit of "pre-configuration" if I'm sifting through page after page of "cannot find" errors.

Hope it gets better in the future.
As said before, you could try this :
http://wiki.codeblocks.org/index.php?title...inGW_with_Vista
 
Last edited by a moderator:
ack... I updated CromoZome to use this, and now my main game has slowed to a crawl once I've compiled... is MP3 playback expensive in the libs used...
I'mon RC2 atm... I'm going to update and see if it still happens...
 
If it's Open2x libs, yes. We couldn't build libmad support into SDL_mixer due to the GPL :(.
 
Dingo_aus said:
Not to detract from the attempt but this "package" has not worked in the slightest for me.

I'm running Vista so I've unpacked it according to instructions, then played with MinGW. Then all I get is one group of errors after the other relating to files which cannot be found.

After 30 minutes of showing C:B where "stdio.h" was etc I've given up as I don't see the benefit of "pre-configuration" if I'm sifting through page after page of "cannot find" errors.

Hope it gets better in the future.
I haven't got Vista to test it on. Vista has a huge long running problem of running GCC compilers. Cygwin also suffers from similar programs due to all the extra security that Vista has included in running programs. On XP and 2000 this should work fine. This is more of a problem with Vista rather then the package:
http://www.google.co.uk/search?q=Vista+GCC...lient=firefox-a

I will send Dingo_aus a test package for Vista on Monday and if it works, I will upload it to the archive.

As for the sdl_mixer problem, I am considering to use the libmad support version. Not 100% sure how well that would go down though :/.
 
Last edited by a moderator:
Well tbh if vorbis is supported well enough then there's no reason to use MP3. I only used it since I couldn't get vorbis to play in my previous dev setup. I'm going to see if I can get my game running up to speed and playing music properly with vorbis and using the open2x MMUHack module (I'm running Open2X DR2...)

It's probably best to stick with the Open2X libs... since we want to support Orkie & co's hard work with Open2X :)

EDIT: Arg... I'm now on the RC3 of the code::blocks devkit... Using Vorbis has made the game marginally faster (although it's still going slower than it should...) But now no music is playing at all :S I'm a little frustrated here...
 
I am experiencing something strange.
Well I have not another toolchain on my computer but now I made a simple app that load a png and moving it over the screen.
When compiling and testing within codeblock there is no problem, I see the thing correctly but when I launch the exe outside, it seems the png isn't loading properly. I put a printf to see where the thing get strange, and there it is :

--------------------------------------------------------------
SDL_Surface *load_image( std::string filename ) {

SDL_Surface *loadedImage = NULL;

SDL_Surface *optimizedImage = NULL;


loadedImage = IMG_Load( filename.c_str() );


if( loadedImage != NULL ) {

optimizedImage = SDL_DisplayFormatAlpha( loadedImage );


SDL_FreeSurface( loadedImage );
}
else
{
printf("can't load image ");
printf(filename.c_str());
printf("\n");
}


return optimizedImage;
}
--------------------------------------------------------------

So when it is run under c:b stdout is empty, and when i launch it outside c:b, I have "can't load image ball_static.png" in stdout.txt
Maybe a path problem, but I don't understand it as the exe is in the same directory as the png...
All SDL dlls are in the exe path too.
Could it be a compilation problem, or something I made wrong with that toolchain ?
Thx for any help
 
Things I would do:
- Double check the filename and location
- Check that the png is valid (i.e. it is in the proper format and viewable standalone
- Double check you have all the correct DLLs including the non-SDL ones such as zlib1.dll
- Build as release not debug if you are intending to run it as standalone
- Upload the entire project somewhere and have someone else check it over,
 
Back
Top