Baking the Backgrounds
Monkey Forums/Monkey Programming/Baking the Backgrounds
| ||
| I'm interested in baking background images constructed from tilemaps into large images that I can scroll for parallax, with the middleground image being partly transparent so the background can show through. I want to eke out every bit of speed that I can so I don't want to draw two layers of background tiles. Does anyone have any suggestions and/or code for doing this? I figured I would draw the background to a buffer, then use grabimage to pull the whole thing into a texture. Thoughts? |
| ||
| Would theoretically work, but not well on all targets. From my experience with Androids, the Alpha channel isn't kept when using GrabImage, (although I've not used it for a while, recent updates might've fixed that) so your parallax might not end up looking too good on Android targets. Best bet, give it a whirl, see how well it works, but be sure you test it on as many things as possible. (Don't forget to try switching Windows to 16-bit mode. That's buggered a few of my graphical effects up!) |
| ||
| GrabImage is fine with alpha; I take it you mean ReadPixels. I suspect the issue is that the Android back buffer may only have 24-bits in the first place; there's no reason for it to be transparent. So you'll have to get the alpha data into your int array in some other way, e.g. by passing the alpha channel as a separate image. |
| ||
| Gerry, can you expand on that at all? I just need to throw together a prototype and experiment, I suppose. I don't have easy access to an Android device-- how good is the Android emulator? |
| ||
| I'm not sure how much, if at all, this will ultimately benefit you. If you create huge images to move about you'll be limited by texture memory and risking texture thrash. I suppose it depends on how large these composite images that you intend to create are going to be and how your scrolling works. Have you just tried rendering the tiles and found that it's amazingly slow? On OGL targets mojo batches the render operations if the texture doesn't change so as long as you're using sensible texture atlases it really shouldn't be slow. With batched vertex loads it mostly comes down to straight fill-rate and that's the same for tiles or one image. |
| ||
| Have you just tried rendering the tiles and found that it's amazingly slow? No. :( I just assumed that it would be too slow. Other people who have tried multi-level parallax (like the guy at OrangePixel) have said that it is too slow but probably I should try it. If it is too slow there are a few ways I could drastically lower the number of draws by batching multiple tiles onto smaller images that would then form part of a mosaic. Edit: I am actually getting a pretty good framerate. I presume that it's faster with fewer draws and that the tile size shouldn't matter too much so I will create tiles twice the dimensions with all 2x2 permutations and then use those to construct backgrounds. |
| ||
| zoqfotpik wrote: "Gerry, can you expand on that at all?" I'm just going by what people have posted in threads that say, for example, "Cls doesn't clear the back buffer to transparency, but fills it with the background colour". I'm guessing that the reason is that on some systems there is no such thing as a back buffer alpha, i.e. you are drawing to a 24-bit buffer. If this is the case, you'll need to get alpha into your arrays in some more convoluted fashion than a simple draw and read. "I just need to throw together a prototype and experiment, I suppose. I don't have easy access to an Android device-- how good is the Android emulator?" It works okay for me (except no sound, and sometimes a program I send it just doesn't start up for no apparent reason) but is very slow on my i3 laptop. Things can run at 3 FPS that run fine on a cheap tablet. I still use it for testing non-time critical stuff, though, because I don't need to plug anything in. So you can test your algorithms okay, and if they work at a fifth of the speed you need, you can be reasonably optimistic that they will work fine on a real machine. |
| ||
| I see what you're getting at about the alpha, I will have to experiment. Currently I am indeed getting good framerates just by drawing tiles and there are a number of ways I can batch tiles to decrease number of draws. One other thing about the emulator: how well does it predict readability on various devices? I have 15,000 downloads on one of my previous games but I've received zero feedback from any users and I really don't know if it looks ok on android devices. I suppose it must be all right. What would you suggest for a cheapie android pad? |
| ||
| There are lots of tablets for $100 now and they will do the job unless you need high resolution. Check out eBay or your local electronic store. I would guess that performance will be about the same on a cheap 800x480 as on an expensive hi-res tablet anyway, and you can use the emulator to play with different layouts. In my experience, the real thing tends to look better than the emulated version. |
   |