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:)
pos.fX = -pos.fX;
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?
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. ^^
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.
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).
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?
Will work on it and let you know how it goes!
I'll work on removing that whole global scale thing (shouldn't be too much trouble).
Anyway, thanks for the input!
Any details on your current project or nothing can yet be revealed publicly?
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.
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?
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
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.