Sorry your browser is not supported!

Here's my quaint little storefront. It's in 3D. As you can tell, the texture quality applied to my little heroic mesh is very small. It's 32x48 pixels.

So, here's why I'm bringing this up. Unity3D forums suck when it comes to this kind of stuff, and I know AppGameKit is dabbling in 3D pretty soon - and this will be a GREAT way to start discussing texture management in AGK.

Basically, here's the thing: On mobile devices, you're capped moreso by how many different textures are being used in a single render sequence than by polygons. This is why forum users hammer home the concept of using Atlas textures whenever possible - it saves on draw calls and increases FPS

EDIT: To those who don't know, for mobile devices, each different texture rendered on screen = 1 draw call. Have 50 different sprites using 1 texture? 1 draw call. 50 different sprites using 50 different textures? 50 draw calls. For any mobile device released including and after the iPhone 3GS, you want to keep it to about 100-120 drawcalls. For iPhone 3G and before, 30.

Now, the problem here I'd describe as 'order of magnitude'. Making a 2D game is tough. Making a 3D game is even tougher. There's so much more assets and textures you need to manage over a 2D game. Which I bring up my little storefront up above.

Since 2000, I've always wanted to make a clone of Jet Grind Radio. I even made a semi-functioning version in Dark Basic Pro before real-life hit and I was forced to stop. Now with my legit free copy of Unity3D (multi-platform deployment!) and also with AppGameKit supporting 3D soon (multi-platform deployment if my app development in Unity3D bombs!)

So, the problem with making a 3D game in a city or any populated area is that there's SO MUCH to make. Many different storefronts, different locations, different textures. And it goes to the order of magnitude question. Each building I see around me is different. Different windows, different siding. How can I make a platformer-type game and be smart with texture usage?

Option 1:
Design buildings with repeated textures (e.g., seamless brick texture) and then manually add over simple textured two-poly objects to represent windows and other features. This is how Super Mario 64 did it.

Those little brown windows are actually simple two-poly textured meshes placed just closer to the camera than the wall to give the illusion that's part of the building. They're separate objects.


This works. But on the flipside, you'd have to design the building and then design the windows on the outside (double the work, double the models). You'd use two separate textures to render one building. But you could use the window texture on other buildings, causing a texture savings there.

Option 2:

Bake the windows and other features into the primary texture and just wrap the texture around the building model. Sonic Adventure 2 did this in City Escape:



Look at the windows on the building on the middle-right of the picture. They're the same texture, just repeated.

The problem with this is that buildings tend to look the same, because they all use the same texture. In addition, if you do this, you'll need to make an additional texture for each and every variation that you'd like. This means that if you want 50 different looking buildings, 50 different textures. Unless you sacrifice texture quality and cram multiple designs into one texture.

Option 3: Paging Terrain (Occlusion culling)
Brought up by another poster, this allows you to seamlessly load in and out of memory portions of the level as they are needed. For instance:

OOOOOOOOOOOOOO
OOOOOOOOOOOOOO
OOOOOONNOOOOOO
OOOOOONNOOOOOO
OOOOOOOOOOOOOO
OOOOOOOOOOOOOO

If the character is in the NNNN area, only objects around the player are loaded into memory. If the person moves into a new area, the O's change to N's (and are loaded and displayed) and areas that are out of reach/view are destroyed and hidden (objects to be destroyed turn to M's, and when memory is freed for other usage turned into O's).

OOOOOOOOOOOOOO
OOOOONNOOOOOOO
OOOOONNMOOOOOO
OOOOOOMMOOOOOO
OOOOOOOOOOOOOO
OOOOOOOOOOOOOO


By doing this, you could load in high-quality textures and reduce the draw count by only allowing what's closest to the player to be rendered onto the screen. This would be a programming solution to the problem I mentioned above.

That being said, as this is done through coding, this could make your project technologically more complex than necessary, and would possibly require multithreading for maximum usage (this would exclude AppGameKit Tier1).

---

So, that's my discussion topic. Perhaps squeezing down one building texture down to 32x48 is a little bit extreme. On the flip side, I could cram 682 different variations of this one building into one 1024x1024 texture and only have one (1)! draw-call to render all variations on-screen.

But then again, I'm a one-man shop and I don't have the novelty to make gorgeous high-res textures (because I'll become anal and give up after wasting a week trying to make one building look perfect).

What do you think, forum members? This topic will more than likely come up again at some point, and I think this would be a great historical posting for people searching for it. That being said, each programming and development style is different, but having insight about different techniques will help everyone when AppGameKit does go fully 3D.

Well, what you could do is to have many world parts saved as (for example) .obj files, where each of them has a texture of 512x512 / 248 x 248 and load them respectively. For example, here's a "drawing" representing what I mean.

OOOOOOOOOOOOOO
OOOOOOOOOOOOOO
OOOOOONNOOOOOO
OOOOOONNOOOOOO
OOOOOOOOOOOOOO
OOOOOOOOOOOOOO

O is unloaded part of the world, while N is loaded part of the world. Player is somewhere between those Xs - though, when he moves too far off their center, we delete two parts of the load, replacing them by loading another two. For example, if player has made a diagonal move (left-up direction), we'd have this:

OOOOOOOOOOOOOO
OOOOONNOOOOOOO
OOOOONNMOOOOOO
OOOOOOMMOOOOOO
OOOOOOOOOOOOOO
OOOOOOOOOOOOOO

Where "M" is deleted part and X is loaded part.
That's about the basic world - which contains both "floor" and optional buildings / anything we can pack up, is static, and doesn't require complicated texture.
Having those four parts loaded makes you have (for example) 4 x 512 x 512 textures, which is "only" four draw calls.
Assuming you might want to add some more objects, where each has 248 x 248 texture, you could have few objects loaded.
That seems to be proper solution for GTA like games, where character can see quite far and can move fast around big world.
I am uncertain how long would it take to load 2 x 512 x 512 textures when loading up new part of the world, but I think you could get away with little lag + displaying little loading sprite somewhere in the corner of the screen.

It's not that much of philosophy when you don't need many objects on the scene. I think there might be problems with storing many textures of bigger sizes, so better use GL_NEAREST instead of GL_LINEAR + small textures (128 x 128 for small items, 248 x 248 for people)

You can't really measure how will it work, unless you can try it.

What you described would be considered ''paging terrain', which is another option - seamlessly load in new data in the scene when it's needed, and delete it when it is no longer of any use. This could be considered as Option 3, however it's practical applications are dependent entirely on the quality of the programmer(s) developing it. Also, this approach would work best in areas where multithreaded programming is available (this automatically excludes Tier1 AGC).

I completely agree with you, this is an option available to be used for designing complex environments. However, the trade-off with this option is that it makes your program technologically more complex, even if your SDK supports it off-the-bat. I'm just saying that an option employed by a multimillion dollar project (GTA3) might not translate well into the indie world.

Edit: I'll post this and your description into my OP when I'm not using my phone browser.

so does AppGameKit work in this way?

if i have 10 spites in 10 different image files is that 10 draw calls?

and if i put the same 10 sprites in 1 spritesheet file, is that 1 draw call?

You are correct. Obviously, this is a slight oversimplification of what a draw-call is. There might be other factors that influence how many draw-calls there are per frame (or as AppGameKit calls it, 'batching').

The more sprites you can put into a spritesheet (or an Atlas texture), the better performance you'll get on ANY mobile device.

this is not good news, as i had a lot of problems with spritesheets on agk and decided not to use them. you cannot do uvscrolling with spritesheets too

It all depends on what you're using them for! It's a huge stretch to have 100+ different images being rendered onto your screen at once. I only use spritesheets for three different things in my game, and that's adequate enough for a good FPS.

1) my 320 road sprites all share a spritesheet
2) my vehicles in my game all share two spritesheets
3) my font is a spritesheet

There's also other considerations to how things get batched. If the game runs fine with your testing, don't be too concerned about it. It's just something 'to keep in mind'. Also, keep in mind that everything has a trade-off. Atlas textures/sprite sheets are efficient but are impossible to use UV scrolling with - that's one tradeoff right there.

Just because something is efficient and works great in Case A doesn't mean it works well for Case B or Case C! It's more about being an experienced programmer and realizing that some things work better in some instances than in others.

you are right answerman no solution is 100% perfect

right now my game runs at 60fps on iphone 3gs. i am not using any spritesheets

Well, just counted and 100 512x512 RGB textures takes 50 MB of RAM to store. Phew. It's not that bad actually.

Therefore, if I am not wrong, you can have 50 1024x1024 RGB textures in 50 MB ram... If I am not wrong

You're very wrong everytime you double the width and height of an image, you're making it four times bigger

100 512x512 textures in memory equals 25 1024x1024 images
400 256x256 textures equals 100 512x512

It's an easy mistake to make. If you only double the width or height (but not both) your math would be correct.

Ouch, you're right. But I was correct (I think) in counting that 100 512x512 RGB textures take 50 MB of RAM. Correcting my earlier calculations we can have 25 1024x1024 RGB textures, which would take 50 MB of RAM too.

I don't think there's anything to worry about. Even my weak LG GT540 Swift has 50 MB of operational RAM all the time (normally it has 70 MB of opertional RAM, though sometimes you have many apps working in the background), so I guess I could put 50 512x512 RGB textures and still have 25 MB RAM for other things.
Though, why would I want a 3d game to run on such weak device?

So I'm not in any shape or form against what your suggesting but isn't this really a designer issue rather than an AppGameKit issue?

Example:

100 buildings as 3d models
1 x 1024x1024 wall texture with many different textures possibly of varying sizes
1 x 1024x1024 "details" texture - this has dozens of small textures on it such as window sills, doors, signs, etc
***each 3d model*** has unique uvw coordinates on one or both of the two above textures

The only AppGameKit issue I can imagine is if each model tries to load the texture even though it were already in memory this would the use up draw calls in the fashion you describe?

So I imagine from that perspective we do need to make sure that cals to the same texture that is already loaded do not result in more draw calls as a result of the way the AppGameKit handles translation to each platform hmm...

So yeah I agree we need to at least ask that this be thought about

This is 110% a designer issue, and the main reason why I brought it up (in a simplified form) is that designing for a mobile phone is completely different than for a Windows PC. When designing assets, one will have to make sure that it is designed for maximum re-use and for minimizing draw calls for devices.

Last summer, I was designing my app with the thought I'd use a different texture for each wall, etc. This would KILL any performance on a phone. Now, many buildings will be sharing the same textures and everything, because the more times a texture can be used in a draw call, the better.

i would the storm model and it looks great