4
\$\begingroup\$

I'm going to develop a game and this is just a prototype of it's graphics. enter image description here

Knowing that my primary target platform is iPhone, I'm wondering if it's better to create a spritesheet containing all possible angles from a wall or is it better to render them with 3d boxes?

here is sample spritesheet I was going to use: enter image description here

\$\endgroup\$

4 Answers 4

7
\$\begingroup\$

If you're going to use a perspective camera like that, you're really not saving anything by using a sprite sheet. I mean I guess you could render all of the potential walls in one quarter of the screen and then do mirroring for the other 3 quadrants, but that assumes a stationary camera.

Why would you want to use a sprite sheet anyway? You're not really going to save on transparent drawing as the sprites themselves are going to have to be transparent.

Plus as a sprite sheet you're limiting yourself if you want to do any interesting camera effects like zooming, tilting, panning, etc.

\$\endgroup\$
5
  • \$\begingroup\$ camera can only move across the screen, there won't be any rotating. the main reason I was going to use spritesheet was my gameengine. I was just looking for a way to avoid 3d rendering. by the way even if I use spritesheet I can use simulate all the things you mentioned. I added a sample spritesheet I was going to use. \$\endgroup\$
    – Ali1S232
    Oct 2, 2011 at 19:41
  • \$\begingroup\$ Honestly I would say if you want it to look 3d, use a 3D engine. Otherwise embrace the 2D aspect of it and lose the fake perspective. \$\endgroup\$
    – Tetrad
    Oct 2, 2011 at 20:12
  • \$\begingroup\$ well faking is exactly what I want to do using spritesheet \$\endgroup\$
    – Ali1S232
    Oct 2, 2011 at 20:28
  • \$\begingroup\$ Don't know the platform so I may be unqualified to comment, but isn't alpha blitting going to be faster if you do this with OpenGL as opposed to Cocos2D's native renderer? I would definitely opt for 3D here. \$\endgroup\$
    – Engineer
    Oct 3, 2011 at 8:49
  • 1
    \$\begingroup\$ Cocos2D uses OpenGL ES. \$\endgroup\$
    – user744
    Oct 3, 2011 at 8:57
2
\$\begingroup\$

You'll likely find that going full 3D is going to be a lot simpler than your proposed sprite sheet approach. For example, you'll get perspective for free instead of having to do a lot of tedious and complex calculations for each wall. It will also be considerably more lightweight on texture memory usage.

\$\endgroup\$
1
  • \$\begingroup\$ you've got a point about memory usage but managing wall sprites is not really that difficult. I have marked a anchor point for every wall frame. based on sprite position I just change wall frame (like an animation) and then change anchor point. everything just fit in place. or at least I think everything will fit in place! \$\endgroup\$
    – Ali1S232
    Oct 2, 2011 at 20:41
2
\$\begingroup\$

Did you have a look at cocos3d? It allows you to mix 3d content with regular cocos2d layers/nodes.

Since you're already using cocos2d, this might be the ideal choice for your task. AFAIK the import of 3D models for cocos3d is kinda limited at the moment and there are problems with exporting animated assets from blender. But for simple cube-like objects like your wall, this seems to be a perfect fit.

\$\endgroup\$
1
\$\begingroup\$

If going full 3d just for the walls is too much, I'd suggest 'hard coding' the 3d just for the walls.

One way of doing this, if you can create and change shapes in runtime: every wall is a 2d square. 4 vertices, vertex1_bottom, vertex2_bottom, vertex1_top and vertex2_top. Make bottom vertices move with the foreground and the other two vertices would be slightly displaced and move with a slightly larger velocity. This is the usual technique for parallax effect in older games (8/16 bit, for example) for the background, only here you would be using it in a different way.

The equations for the displacement and velocities are actually quite simple. If we put the coordinate system on the center of the screen (this is very important) all you have to do is scale the top vertices according to the bottom ones:

v1_top = factor * v1_bottom;

v2_top = factor * v2_bottom;

You might need to experiment with the factor. Basically, the higher this factor the closer to the camera the top of the walls will appear (a low value will probably work best).

I'm making this stuff as I write so there may be some conceptual problems. Let me know if you find any. Hope this helps :)

\$\endgroup\$
1
  • \$\begingroup\$ This was the original idea that created the prototype program, I think I would go with this system in the end. \$\endgroup\$
    – Ali1S232
    Oct 3, 2011 at 8:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .