GP2X It Doesn't Run On The Gp2x D:

[Orkie]

gdb is incredibly useful for applications, what are you on about?

 

[Sphinxter]

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?

Think commercial cartoon animation runs at around 18 fps, 12 is pretty acceptable, security footage goes low as 8 and still looks ok. I've been doing this to drop frames when the processing gets too long, seems to work well though I rather liked your state machine, my next main loop will look different.

CODE

unsigned int timeleft(unsigned int x)
{
static unsigned int next_time = 0;

Now = SDL_GetTicks();
if ( next_time <= Now ) {
next_time = Now + x;
return(0);
}
return(next_time-Now);
}
//--------snip
do
{
if ( !Paused )
{
if ( ! Smallview )
draw();
else
bigshow( Screen );
collide();
}
else
{
banner();
textxy( Screen, 128, 95, "PAUSED", -1, 3 );
}
SDL_Flip( Screen );
if ( doevents() )
{
Alive = 0;
break;
}
SDL_Delay(timeleft(rate)); // 1/18 = 55 1/12 = 83
}
while( Alive );
//----- snip

 

[Sphinxter]

gdb is incredibly useful for applications, what are you on about?

Sure, if you need that sort of thing, an excellent choice, install it on your gp2x, hook up a bob and plug in a keyboard, get an xserver and ddd too, why not, if that's what you need and you think that's efficient.

 

[Squidge]

You don't need a BoB or a Keyboard - all you need is a usb lead. GDB can save countless hours finding out why your application doesn't work, and if you don't want to learn anything new, just run your application with it, and if it crashes, it'll tell you the exact source file and line in your program that caused the crash (along with a nice back trace if you want to, so you can see what called the function that caused the crash).

But if you prefer to use text files instead, thats your choice. It just seems a little bizzare when there are free options available that can save you all that hassle.

 

[Sphinxter]

You don't need a BoB or a Keyboard - all you need is a usb lead. GDB can save countless hours finding out why your application doesn't work, and if you don't want to learn anything new, just run your application with it, and if it crashes, it'll tell you the exact source file and line in your program that caused the crash (along with a nice back trace if you want to, so you can see what called the function that caused the crash).

But if you prefer to use text files instead, thats your choice. It just seems a little bizzare when there are free options available that can save you all that hassle.

I prefer text files because adding debug info or removing optimization changes things making the debugger less than true combat conditions. My usb cable does not reach the loo or travel well on the train. Bizarre, yes, but the best debugger is still not to introduce any.

 

[YakumoFuji]

I prefer text files because adding debug info or removing optimization changes things making the debugger less than true combat conditions.

lest push water uphill.

see what happens is, you add debug info, find bug... fix bug... create release version without debug info.. omg!

not true combat conditions? you shouldnt have a 'release' version with debug info anyway. but if your creating 'debug' versions for testing without debug info, well your just plain stupid.

 

[Sphinxter]

I prefer text files because adding debug info or removing optimization changes things making the debugger less than true combat conditions.

lest push water uphill.

see what happens is, you add debug info, find bug... fix bug... create release version without debug info.. omg!

not true combat conditions? you shouldnt have a 'release' version with debug info anyway. but if your creating 'debug' versions for testing without debug info, well your just plain stupid.


Actually testing what the user will be running, how stupid.

 

[Squidge]

not true combat conditions? you shouldnt have a 'release' version with debug info anyway. but if your creating 'debug' versions for testing without debug info, well your just plain stupid.

A little harsh don't you think? It's up to each person how they decide to debug there software. If they want to wear out there sd card with constant text file creation/deletion, spend several hours adding countless 'printf' statements, etc to debug there apps rather than using a debugger, then I'd say we just let them. At least they now know an alternative, easier solution exists if they wish to use it.

Personally, my makefile generates two executables - a debug version and a release version. I generally always use the release version unless I stumble across a not too obvious bug, in which case I switch to the debug version, find it, kill it, and then recompile.

 

[yaustar]

While we are on the subject of GDB, is there a GUI version that we can use for the GP2X? Or is just InsightGDB?

 

[Sphinxter]

not true combat conditions? you shouldnt have a 'release' version with debug info anyway. but if your creating 'debug' versions for testing without debug info, well your just plain stupid.

A little harsh don't you think? It's up to each person how they decide to debug there software. If they want to wear out there sd card with constant text file creation/deletion, spend several hours adding countless 'printf' statements, etc to debug there apps rather than using a debugger, then I'd say we just let them. At least they now know an alternative, easier solution exists if they wish to use it.

Personally, my makefile generates two executables - a debug version and a release version. I generally always use the release version unless I stumble across a not too obvious bug, in which case I switch to the debug version, find it, kill it, and then recompile.


How tolerant, may you never have to work in an environment where there is no debugger.

 

[Squidge]

How tolerant, may you never have to work in an environment where there is no debugger.

Considering my day job is an embedded software engineer, that happens regularly; So I just use whatever tools are available to make my life easier. If there is a debugger, I'll use it, but if all I get is is an LED that I can toggle on and off (or even worse, nothing whatsoever), then so be it.

I certainly wouldn't make my life more difficult however by refusing to use a debugger when one is available, and it is practical to do so.

 

[Orkie]

I certainly wouldn't make my life more difficult however by refusing to use a debugger when one is available, and it is practical to do so.

Squidge, I insist you stop using any electrical appliances! What if you are stranded on a desert island and don't have any? Sphinxter has an excellent point! :rolleyes:

 

[Squidge]

He sure does. I'll also stop using tap water and dig a hole in the ground as a replacement toilet too, just in case I go somewhere that doesn't have those

 

[Sphinxter]

How tolerant, may you never have to work in an environment where there is no debugger.

Considering my day job is an embedded software engineer, that happens regularly; So I just use whatever tools are available to make my life easier. If there is a debugger, I'll use it, but if all I get is is an LED that I can toggle on and off (or even worse, nothing whatsoever), then so be it.

I certainly wouldn't make my life more difficult however by refusing to use a debugger when one is available, and it is practical to do so.


Gee me too. Never said I wouldn't use one, I just very, very rarely if ever need to.

 

[kevcal]

I also very very rarely need to use gdb - only if I really can't trace where the problem occurs (very rare).
However, very useful when learning to code (don't think Squidge falls into this category ) and also if you are distrustful (or suspect) the hardware.. which as a sw dev is a given B)

Using allegro at the mo on the gp2x, which means I actually write it to work on my linux laptop and copy it across to the gp2x as needed. This way I can debug a lot faster on the laptop - problem is when I have started to put in specific code to HW blit...

But Squidge is right - everyone has their own ways.

 

[Squidge]

Using allegro at the mo on the gp2x, which means I actually write it to work on my linux laptop and copy it across to the gp2x as needed. This way I can debug a lot faster on the laptop - problem is when I have started to put in specific code to HW blit...

But you have the gp2x specific code in a seperate file, right? And this file is different on your laptop and gp2x, so both versions get optimised for the system they are running on?

 

[kevcal]

Yeah - I have a hw_abstraction.cc file that gets pulled in as required.

I also run the code on an ETX card that I'm using at work...

Okay, framerates are amazingly fast on the laptop (and on the ETX - although I have yet to access the hw acceleration on there yet - am thinking of porting a hw accelerated allegro to it for 'fun') - but I can check the mechanics and that there are no silly crashes, which are the main things I worry about.. and difficult to debug on the target. I'm a great believer in offline testing as much as possible.

Just playing around really at the moment, but I have myself focussed on writing an arcade-style game in the near future (as work allows).
EDIT: in fact thought of a great idea for a game today based on ideas from another, but with a different slant...

Hoping this time to build on top of allegro, but must admit rlyeh's minimal lib (where's 0.c?) gives me access to everything I need...