Hi there, I am having a really weird problem right now, I used to create my scenario ground with a template.
Like this:
[HorizontalGroundGraphic@GroundGraphic]
Times = 50
Repeat = (50, 1, 1)
Now I am creating it by code:
orxS32 i;
orxOBJECT *ground;
orxVECTOR pos;
for(i = 0; i < 50; ++i){
if (orxMath_GetRandomS32(1, 100) <= 50){
ground = orxObject_CreateFromConfig("Ground");
}
else{
ground = orxObject_CreateFromConfig("Ground_2");
}
pos.fX = 64.0 * orx2F(i);
pos.fY = 536;
pos.fZ = 0.0;
orxObject_SetPosition(ground, &pos);
}
So I can variate the ground graphic. The object physics is exactly the same as before. The only change is Graphic.
But when I use this code, the monsters that were walking flawlessly start stumbling in the scenario. I have no ideas what is causing this...
Here is a video:
Video (MP4 format)
I tried increasing the physics collision detection, but didn't change anything.
Any tips would help.
Thanks in advance.
Edit:
In my despair to get it working (need to present another part of it tomorrow), I made a workaround, I created the object with repeat and the body with a Z = 0.1.
Then I created objects with no physics body with z = 0.0. So they hide the objects that have the working body.
It is a dirty trick, but everything is fair in love, war and game dev.
Comments
The way to solve this issue is exactly as you described: you need to decouple the visual(s) from the physics object.
That being said I find it cute the way the monsters tip over.
It is just weirdy to have an drawn object in the backgorund =p
But, if that is the right way to do it, I am ok with it.
I found it funny when they started walking over their heads =p
I believe that if the object is behind another, the zbuffer algorithm would take it out of the scene (i may be wrong).
If so, would having an alpha channel set to 0 have the same effect?
Not that I really mind the performance, it still runs at over 1k fps, just got curious.
Afaik, only 3d engines do this kind of sorting and culling, for 2d you have to take care of it yourself.
Note: I tried with BlendMode none
So nope, you don't need to (and shouldn't) display that background object. It should only serve as a physics object.
There are a few different ways to achieve this:
- The first one is to not give it a Graphic property, of course. That means that if you rely on the Graphic to automatically get the BodyParts size, it won't work anymore and you'll need to specify the size of each part manually.
- If you'd like to keep the Graphic to get the automatic size for your BodyParts, you could of course push the object outside of the camera Frustum by playing with its Z. Or, simpler, if you use a recent version of orx, you can use object grouping to exclude that object from rendering (more on object groups here).
By simply giving it a group that is not referenced by any of your camera(s), the object will get excluded from rendering.
Ex1:
The group "none" isn't "seen" by the camera -> not rendered.
Ex2:
There's no Z-buffer for sorting: as Jim pointed out, it's mostly pointless in 2D as most of your objects are alpha-blended so they can't use Z-buffer for hidden part removal. It only work for fully opaque (blend mode = none) objects and the performance might not be much better given that we'd need two separate internal lists + hand sorting the non-opaque one (not even speaking of the memory cost of the Z buffer itself).
NB: An optional Z buffer can be created on-demand via config. It's only useful if you plan to hook your own 3D rendering in addition to orx's 2D rendering (like 3D backgrounds, etc...)
Overdraw with alpha blending is *not* cheap. Especially on mobile devices.
Actually, today I had the exact same issue on Child of Light: on XBox 360, a lot of alpha overdraw, due to thousands of alpha blended particles, was cutting the framerate from 60 down to 30 FPS.