[SOLVED] Box2D and orxObject_SetPosition

edited October 2011 in Help request
I've got an object (the player) in...essentially a top-down shooter. The player can fly up, down, left, and right, and when they hit the edge of the screen (I poll for this in the update() function), I just warp them to the other edge of the screen, Pac-man style.

Wrapping the player around the vertical (y) axis works perfectly.

However, when I'm wrapping them around the horizontal (x) axis, some weirdness happens. All I'm doing is something like this...

(EDIT: CODE tag isn't working? Anyway, this:)
orxVECTOR pos;
orxObject_GetPosition(player, &pos);
pos.fX = -pos.fX;
orxObject_SetPosition(player, &pos);

So, only the horizontal position should change. However, I notice that when they loop around, the player keeps getting closer and closer to y=0; that is, if they are towards the top of the screen (in the y<0 space), they'll get lower and lower each time they warp around horizontally until they get to y=0; and if they're in the bottom half of the screen, they'll inch closer and closer upwards to y=0.

This is odd, since I'm not affecting the y-axis in any way. I did read elsewhere that Box2D and orxObject_SetPosition don't always work well together. Is this a symptom, and if so, why does it only happen when the player is moving horizontally, but not vertically?

Thanks.

Comments

  • edited October 2011
    I've never encountered that precise issue, but yes, Box2D doesn't like when we do SetPosition on bodies with recent version. It apparently messes with its internal simulation and weird things can happen.

    Obvious question: is your gravity set to 0 or do you have any other force that could affect your object?

    First of all, what happens if you don't have a body on your player? Do you still see the same behavior?

    The only easy workaround I can think of would be to apply a speed that would bring your player exactly at the right spot for one frame instead of teleporting the object. Of course the issue with that is if there's something in the way, in which case you need to deactivate the collisions on it first. Well then it's not such an easy workaround after all. ^^
    Code tag should be working fine!
    

    And not sure why it happens only on that axis. Have you tried to put a data breakpoint on the y coord of the position stored in the frame held by your object? If you don't feel like tracing this, send me your project and I'll have a look on my side if you want. Although I don't have much access to my computer right now so it might take a couple of days. :/
  • edited October 2011
    Also, have you tried nullifying/enforcing previous speed after the warp has happened? Just in case, it's really weird though.
  • edited October 2011
    (First off, the code tags are acting weird on my end! If I quote your post, I can see what you put in your code tag, but when I just look at your post, there's nothing there but "e!" Odd, but entirely on my end, so I'll worry about it :P)

    As for the orxObject_SetPosition...yeah, it's a really weird one. As you suggested, I removed the Body from the player, and everything worked fine. So I think we're getting somewhere. I also noticed that without the Body, the player moved a lot faster than before, even though I didn't change the speed at all.

    I suspect it's something to do with scaling. As I'm trying to make something for the Android platform, I have to keep scaling issues in mind. To do so, I have a global "objectscale" object, which serves as a parent to ever object, and in theory scales everything appropriately. But of course, Bodies (from Box2D) have trouble with scaling...maybe the issue lies there. Anyway, will keep investigating.

    Oh, and my CustomGravity on my player is just (0, 0, 0).
  • edited October 2011
    Ah yes, don't look further, scaling probably is your culprit. :)

    Did you redefine the ratio between visual and physics worlds? By default it's 100 units (pixels if your camera/viewport gives a 1:1 ratio) for 1 meter. Box2D performs well between decimeters and decameters. Outside of that range, you'll lose both precision and stability. :)

    Can you tell me more about what you want to achieve with world scaling? Wouldn't playing with camera zoom/frustum and/or viewport do the trick in your case?
  • edited October 2011
    Hmm. I think I read elsewhere in the forums about using scaling to achieve Android resolution-independence, but I may be mistaken. Either way, yeah, camera zoom does seem like a much better solution. And much less prone to error.

    Will work on it and let you know how it goes!
  • edited October 2011
    If you're simply looking for resolution independence it should be easy to achieve using the camera/viewport couple: after all the camera only has a size in the world while the viewport will map it on screen and both have dimensions that can be set independently. Orx will then do the upscaling/downscaling/letterboxing automatically for you according to those settings.
  • edited October 2011
    Righto. So if I take my player OFF of the global scaling object, everything works fine; the warping happens without that weird y-axis shift.

    I'll work on removing that whole global scale thing (shouldn't be too much trouble).

    Anyway, thanks for the input!
  • edited October 2011
    Excellent, I'm glad when things are easily fixed. :)

    Any details on your current project or nothing can yet be revealed publicly?
  • edited October 2011
    Oh, it's not top-secret or anything. I'm porting my experimental (read: VERY experimental) game "The American Dream: Are We Not Drawn Onward to New Era" to Android.

    The game was made for the GAMMA IV one-button competition, and I'm actually pretty happy with it, despite the fact that it's not much to look at. Anyway, I kinda dig the idea of having something up on the Android Market, so I'm gonna pop this on there for free when it's done.

    Not exactly a feature-filled demonstration of Orx's abilities, but it's something.
  • edited October 2011
    Ah nice. I've tried a few GAMMA IV entries back then but I don't remember trying yours. I'll fix that soon. :)

    I'm glad to see you've been sticking with orx for quite some time now. Any feature you'd like to see in it, btw?
  • edited October 2011
    Yeah, I was quite happy with my game even though it's...quite experimental, I guess. And not much to look at. It wouldn't have played well in the GAMMA arcade-y setting, but I had an idea and I ran with it, so I'm happy with that.

    As for Orx: it suits me! I'd tried a few other 2D libraries, but they were either buggy, or not fully-featured, or too high- or low-level. I like Orx because I can make a game entirely out of config files, or switch it up and code things directly in C. I like that flexibility.

    Other features...hm. Haven't come across anything that's really been a deal-breaker. Usually if I'm having a problem, I realise (after some puzzling) that I can implement it using something built into Orx. One thing I thought of (perhaps this could use another forum thread?) is have a setting so that the log file could be automatically deleted on startup? Maybe I missed it; I'm just worried if I port my GAMMA game to an Android device and end up with a 20GB log file ;)
  • edited October 2011
    Ahah yep, this might need a new thread but I'll give you a hint here anyway! ;)

    You can deactivate file logging if you need. Actually the full logging process works with flags that can be changed at runtime (like adding timestamp, file name, ...). There orxLOG() macro will set default flags but there are sister macros that will target either console or file or even let you decide of all the flags. All this magic is in orxDebug.h. ;)
Sign In or Register to comment.