Positioning elements in 2D space with OpenGL ES

后端 未结 3 2101
盖世英雄少女心
盖世英雄少女心 2021-02-09 06:00

In my spare time I like to play around with game development on the iPhone with OpenGL ES. I\'m throwing together a small 2D side-scroller demo for fun, and I\'m relatively new

相关标签:
3条回答
  • 2021-02-09 06:19

    If you are only using screen aligned quads it might be easier to use the OES Draw Texture extension. Then you can use a single texture to hold all your game "sprites". First specify the crop rectangle by setting the GL_TEXTURE_CROP_RECT_OES TexParameter. This is the boundry of the sprite within the larger texture. To render, call glDrawTexiOES passing in the desired position & size in viewport coordinates.

    int rect[4] = {0, 0, 16, 16};
    glBindTexture(GL_TEXTURE_2D, sprites);
    glTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_CROP_RECT_OES, rect);
    glDrawTexiOES(x, y, z, width, height);
    

    This extension isn't available on all devices, but it works great on the iPhone.

    0 讨论(0)
  • 2021-02-09 06:36

    You are concerned with the overhead it takes to transform a model (in this case a square) from model coordinates to world coordinates when you have a lot of models. This seems like an obvious optimization for static models.

    If you build your square's vertices in world coordinates, then of course it is going to be faster as each square will avoid the extra cost of these three functions (glPushMatrix, glPopMatrix, and glTranslatef) since there is no need to translate from model to world coordinates at render time. I have no idea how much faster this will be, I suspect that it won't be a humongous optimization, and you lose the modularity of keeping the squares in model coordinates: What if in the future you decide you want these squares to be moveable? That will be a lot harder if you're keeping their vertices in world coordinates.

    In short, it's a tradeoff:

    World Coordinates

    • More Memory - each square needs its own set of vertices.
    • Less computation - no need to perform glPushMatrix, glPopMatrix, or glTranslatef for each square at render time.
    • Less flexible - lacks support (or complicates) for dynamically moving these squares

    Model Coordinates

    • Less memory - the squares can share the same vertex data
    • More Computation - each square must perform three extra functions at render time.
    • More Flexible - squares can easily be moved by manipulating the glTranslatef call.

    I guess the only way to know what is the right decision is by doing and profiling. I know you said you haven't written this yet, but I suspect that whether your squares are in model or world coordinates it won't make much of a difference - and if it does, I can't imagine an architecture that you could create where it would be hard to switch your squares from model to world coordinates or vice-versa.

    Good luck to you and your adventures in iPhone game development!

    0 讨论(0)
  • 2021-02-09 06:36

    You might also consider using a static image and just scrolling that instead of drawing each individual block of the floor, and translating its position, etc.

    0 讨论(0)
提交回复
热议问题