GP2X Physics Thing

[schmidget]

First, I'm not really a programmer, and I barely know C++. But I do know java pretty well, and was able to tie in similarities. With help from tutorials on the internet, I decided I'd make a little something for my brand new GP2X. I like the idea of using physics in 2D games and decided to try and throw something together that was physics based. Starting from scratch, I grabbed the Box2D code, tried to figure out how to use it, and programmed a simple physics demo of sorts. It really isn't that cool in comparison to all of the other amazing developments for this hardware, but figuring this is the first thing I've even made in C++, I'm rather proud of it.

I decided to work on it today while I have a chance and see if I can do some things with the touch-screen and different shapes. Using actual sprites would be cool too.



You can nab it here if you want to test it for me. (I run it at 275MHz).

(If I can post attachments on the board or somewhere better than upload2, please tell me)

Caution: filesize is not proportional to coolness. I don't know what I'm doing so I don't know what is creating that gigantic 2MB gpe for something so simple. It might be all of the overhead from the Box2D code or perhaps SDL or something, but I don't really know. Also, the demo isn't all that fast, but that seems to be more from the fact that it has to generate and render all of those boxes every frame. It would explain the fact that it start out pretty fast then gets slower and slower as more boxes enter the view.

As for the uh...controls:
X-resets the simulation
Up/Down-Increase/decrease timestep (can make the simulation move a little quicker at the cost of accuracy)
Start/Home - quits

Really...That's all there is (not much for interactivity so far)

Tell me what you think or what I should try to include as this physics demo evolves.

 

[schmidget]

In these last few minutes I added a sort of wireframe view to see how that influenced the framerate and added a framerate counter to help with the debugging process. Here. Press Y to switch views.

 

[PokeParadox]

I'm going to hazard a guess and say that you used the official Box2D library. That's fine and all but I do believe that it uses floats. The GP2X doesn't have hardware support for floats, so they can be slow, especially if you are using lots of them in calculations.

Box2D was converted to FixedPoint by the author of Pocket Physics on the NDS.
I would recommend using that version of the library and it should perform much better.

 

[schmidget]

Alright, cool. That might explain the slowness. I knew there was something strange about using floats on the gp2x, but I couldn't remember any specifics. I'll see about throwing in that library instead and seeing what happens.

 

[Lineus]

QUOTE
Caution: filesize is not proportional to coolness. I don't know what I'm doing so I don't know what is creating that gigantic 2MB gpe for something so simple. It might be all of the overhead from the Box2D code or perhaps SDL or something, but I don't really know. Also, the demo isn't all that fast, but that seems to be more from the fact that it has to generate and render all of those boxes every frame. It would explain the fact that it start out pretty fast then gets slower and slower as more boxes enter the view.

Which toolchain are you using? you should try passing the -s and -fexpensice_optimizations -O3 flags to the compiler, which strips the debugging info and optimizes the executable, respectively. That's what shrunk and sped up my version of the Yeti3d engine over synkro's mostly. Also, as PokeParadox said, the gp2x doesn't have floating point math, so use the fixed point libraries for a speed boost as well. You could also try to add in Squidge's MMU hack, it's in the archive. Anyways, great work, I hope to see more out of you in the future! Good luck!
~Lineus

 

[schmidget]

-s was already being passed to the compiler, but the other two weren't. It didn't do anything to the filesize, but it might increase speed. I'll have to check. I'm waiting for the programmer of the NDS version of box2d to give me the source. I'm not on linux or osx, so using the .patch file from his download to patch the box2d source is not exactly easy.

 

[dockthepod]

Let me know if you get the fixed point box2d. I've also been playing with it and have a demo very similar to yours

Edit: Btw - here is my demo http://joshmattoon.org/gp2x/physicsRfun.rar

Use arrow keys to move one of the squares around (applies force so you need to use a light touch ) start to pause the physics simulation (but runs the rest of the game loop) and select to exit. It seems like when too many bodies are in contact framerate really drops. If you pause framerate jumps up to 100+. I wonder how big of a difference fixed point will have.

 

[schmidget]

Well after hours of work and frustration I was able to get a hold of the fixed point code. Trouble is, it is a little different then the source I was using before, so now I have to diagnose all 23 errors. To top it off, fixing one error seems to bring about 5 more errors. The way shapes and bodies are handled is different. Once I get the code working I'll see about uploading it somewhere. I told Tob to see about making his source available as a package rather than a .patch. We'll see what happens.

Edit: I fixed all the compile-time errors, but now I have a mysterious run-time error. Not good.

 

[dockthepod]

I got the fixed point patch integrated into svn 80 and it built but my code is using a bunch of stuff added later on so now I'm trying to update to HEAD. Gotta resolve some conflicts. Did you already do that? Maybe you could hook me up with the changes?

 

[PokeParadox]

Well after hours of work and frustration I was able to get a hold of the fixed point code. Trouble is, it is a little different then the source I was using before, so now I have to diagnose all 23 errors. To top it off, fixing one error seems to bring about 5 more errors. The way shapes and bodies are handled is different. Once I get the code working I'll see about uploading it somewhere. I told Tob to see about making his source available as a package rather than a .patch. We'll see what happens.

Edit: I fixed all the compile-time errors, but now I have a mysterious run-time error. Not good.

Keep at it, I'm sure it will pay-off in the end! What error are you getting? Are you checking the call-stack?

 

[dockthepod]

I've got it up and running but it exits after a bit. I think it is hitting an assert and rather than breaking for me in the debugger, it just exits. I'm not sure how mingw/gdb is supposed to handle asserts but if I could find out where it asserts I could surely fix it.

 

[dockthepod]

Bah, so close... created my own assert macro with a breakpoint so I can tell what's going on but the debugger in CodeBlocks kinda blows... Can't move up the stack and look at local vars

Anyhow... The assert I hit after a while is in ProcessThree but I'm pretty sure something is going wrong elsewhere because all my bodies are stuck at 0 to start out with even though that's not where they should be.

Edit: Okay, I give up for the night. I downgraded back to SVN 80 to see if maybe I just screwed up the update but I get the same crash with the old version. I don't know squat about fixed point so maybe somebody with fixed point experience can track this one down

 

[yaustar]

Bah, so close... created my own assert macro with a breakpoint so I can tell what's going on but the debugger in CodeBlocks kinda blows... Can't move up the stack and look at local vars

You should be able to. In the Call stack, right click on the function call/frame that you want to go to and select 'Go to local stack frame' or something similar.

Edit: Funnily enough, the only reason I found this was because I was working on my own assert system last night

 

[PokeParadox]

Bah, so close... created my own assert macro with a breakpoint so I can tell what's going on but the debugger in CodeBlocks kinda blows... Can't move up the stack and look at local vars

Anyhow... The assert I hit after a while is in ProcessThree but I'm pretty sure something is going wrong elsewhere because all my bodies are stuck at 0 to start out with even though that's not where they should be.

Edit: Okay, I give up for the night. I downgraded back to SVN 80 to see if maybe I just screwed up the update but I get the same crash with the old version. I don't know squat about fixed point so maybe somebody with fixed point experience can track this one down

Fixed point is bit shifting, basically it's where you manually handle how many bits should hold the decimal. So you can have different levels of precision depending on use.
I recommend Trenki's Fixed point classes. They make Fixed types a lot easier to use.

 

[schmidget]

I decided to start over from scratch, but I was too tired last night to continue. DockThePod, keep this into consideration:

"Issues:
A numerical problem occurs an object's coordinates become 0, causing them
to freeze. A workaround is to place the origin off-screen "

You guys are obviously a lot better than me at this stuff. As far as debugging goes, I'm almost screwed. I don't know anything about how it works in C++ with codeblocks. Breakpoints seem to be ignored, nomatter where I place them. The only light at the end of the tunnel is that my VC++ runtime debugger shows up and points at specific lines of code and says something about "Assertion Failed, line 100, (m_body==null)". That's what it gives me, but I'm confident it's my code. Hence why I'm starting over.

By the way, what's an assertion?

Edit: I've decided to, in addition to rebuilding the physics code, to make a simple SDL framework. Before, I did a lot of copy/pasting other tutorials' code, and I didn't like the way it all pieced together in the end. This is probably something you guys would do starting out. I want to bring it closer to the way GTGE was configured when I made a few games in Java.

 

[yaustar]

Breakpoints seem to be ignored, nomatter where I place them

Use "Ctrl + F8" which is to run with Debugger attached (it is in the Debug tool menu).

DockThePod: Can you upload your new version code (with the library)? I wouldn't mind taking a look at it myself.

 

[dockthepod]

You should be able to. In the Call stack, right click on the function call/frame that you want to go to and select 'Go to local stack frame' or something similar.

Edit: Funnily enough, the only reason I found this was because I was working on my own assert system last night

Ah! Thanks much! I wonder why it doesn't just switch frames when you double click like every other debugger in the world. Anyhow, that works!

Fixed point is bit shifting, basically it's where you manually handle how many bits should hold the decimal. So you can have different levels of precision depending on use.
I recommend Trenki's Fixed point classes. They make Fixed types a lot easier to use.



Yup, I know about fixed point and I'm using Trenki's classes but I've not extensively used it and know about all the pitfalls. I'd assume I'm either hitting some overflow or maybe, uh, underflow (whatever it is called when something is too small to be represented in fixed point).

QUOTE
DockThePod: Can you upload your new version code (with the library)? I wouldn't mind taking a look at it myself.


I've got everything pretty torn apart at the moment but I managed to get a build cobbled together for you

http://joshmattoon.org/gp2x/code.rar (it's big because i was too lazy to clean )

Everything should be there to build. Open the scape codeblocks project and build. Haven't tested current on gp2x. Please note, code was all in hacked together in main.cpp until recently and I'm currently in the middle of moving stuff around so I make no guarantee on code quality

I synced box2d to version 80, applied the patch, synced to current, resolved collisions, did search and replace on these defines he used to switch between fixed and float in b2settings.h:

#define FLOAT32_MAX FLT_MAX
#define FLOAT32_MIN FLT_MIN
#define FLOAT32_EPSILON FLT_EPSILON

To build in fixed mode, just define TARGET_FLOAT32_IS_FIXED in your project and rebuild. You'll know it worked when it doesn't work right

 

[schmidget]

Maybe someone can point me in the right direction with mine. I built a really simple framework that would simplify a few things for me. But it seems, I'm in the same boat as before, except this time, I got the debugger working. I stepped through the code and traced it through the shape creation, through polygon switch, then through the memory allocator, and stopped on this line:
"shape->m_bodyNext = shapes;" and concluded with "Program received signal SIGSEGV, Segmentation fault. "


Edit: Nevermind. C++ memory management is really new to me, but I figured out what that means and was able to work through it. I fixed that one but another one showed up later in my code! Doh!

Edit2: Well, I finally figured out the source of the following segfaults. Every single one of them leads to the Fixed class. Interacting with it in any way, whether that be just getting a fixed from the position of an object, to trying to do any kind of math with them, it brings the program to a halt. I'm screwed if I can't figure it out.

Edit3: Perfect, now I'm really screwed. I don't know what I did, but now a different seg error appears, this time out of nowhere, pointing to a line of code that has never before caused problems, and I don't know what I did to cause it. Actually the error ends up coming from ntdll from a function called WaitforCriticalSection. I'm very close to just giving up.

Edit4: Once again, I don't know what I did, but it fixed that previous seg error. Now I'm back to the Fixed errors. More specifically, the following line of Fixed.cpp is giving me issues:
CODE
Fixed::Fixed(const Fixed& a) : g( a.g ) {}

I do believe it's something I'm doing wrong though. Right before that is "body->GetAngle()" (inside of a function that takes doubles) which on the inside looks like this:
CODE

inline float32 b2Body::GetAngle() const
{
return m_angle;
}



I think if I can crack why that is happening, I can fix all of the problems I've had with fixed interactions. I have tried seeing if I could cast or convert the fixed to a float or double just to see what happens, but that leads to the same kinda thing. Bah...Java was so much easier.

 

[yaustar]

CODE
Fixed::Fixed(const Fixed& a) : g( a.g ) {}

That is the couple constructor which means that 'a' might be invalid (NULL pointer, mangled data etc).

 

[schmidget]

What is a couple constructor? Also, are math functions with Fixed used the same way as ints or floats? Like this?
CODE

float num1=1.0f;
float num2=2.0f;
float num3=num1+num2;

Fixed num4=1.0;
Fixed num5=2.0;
Fixed num6=num4+num5;



Something is telling me that isn't how it works.