Monsters stumbling in the scenario.

edited November 2013 in Help request
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

  • edited November 2013
    Yes, going from a single body to multiple aligned bodies would do that, unfortunately.

    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. ;)
  • edited November 2013
    Thanks for the reply.

    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
  • jimjim
    edited November 2013
    You can set the Alpha to 0 of the object you are hiding behind, this way it wont be shown, no matter what z value you use.
  • edited November 2013
    Yes, i was thinking of that today, but wouldn't it be heavier?
    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.
  • jimjim
    edited November 2013
    I am not sure about z buffer, coz if I draw 10,000 object in same position the performance is same as drawing 10,000 object all over the screen though I can only see one object in the former case. Even if I change z it does not affect as long as the z is inside the camera far clip.

    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
  • edited November 2013
    Sorry, I should have given more details! :)

    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:
    [Camera]
    GroupList = background # game # foreground # UI # Overlay
    
    [HiddenPhysicsObject]
    Group = none
    

    The group "none" isn't "seen" by the camera -> not rendered.

    Ex2:
    [Camera]
    ; No group list attribute here, meaning the camera only see the group "default"
    
    [HiddenPhysicsObject]
    Group = none ; Could be anything but default, really
    

    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.
  • jimjim
    edited November 2013
    Group is really really cool and amazing stuff, that's why I plan on using ORX for my next project(I already started working on it) probably I am going to mobile first (android,ios).
Sign In or Register to comment.