I’m trying to come up with some data structures for rendering my map on OpenGL. It is going to be ~ 100×100 blocks(squares) total, with each block being around 100 pixels. However, the screen will only display about 20×10 of these blocks at a time, depending on character location. So from this post:
https://stackoverflow.com/questions/19979031/android-only-game-in-opengl-performance-in-c-ndk-vs-java-dalvik?newreg=53760d542cb94d05afe42faa39d1aef6
It says that I shouldn’t do a lot of allocation with ByteBuffers. So here are approaches I came up with:
- Allocate all 10,000 blocks, and simply change the vertices on every frame, for the ones I need to display. So no dynamic allocation, but a lot of up-front space.
- Only allocate blocks as I need them. So if in a frame I move left, and have to display new blocks, I will allocate 10 blocks in OpenGL. That way I have less memory allocated at once. However there is dynamic allocation and I need to set up the textures on every frame.
- Cache a few blocks of each type, and update the vertex information for them as I need them, that way I don’t need to allocate a lot in the beginning, and I don’t need to allocate anything dynamically. (So have 100 wall blocks, 100 door blocks, 100 floor blocks, all set up from the beginning)
Are any of these approaches the right way to go about doing this? Or how would one go about displaying a bunch of Bitmaps and updating their location on every frame? Or is Java a bad idea from the beginning, even for a simple 2D game?
1
~10,000 textured quads is on the order of ~1MB. While max buffer size varies by GPU, 1MB should be no problem.
On the other hand, while repeatedly uploading geometry data to the GPU generally isn’t advisable, you could easily get away with it in this case, with only ~200 quads visible at a time.
So I expect either approach would be fine, unless you’re targeting extremely low-end devices.
If you did have a ton of geometry, and too much visible in one screen to upload it repeatedly, you could divide the geometry into several block regions and allocate/deallocate buffers as regions become visible or invisible.