New answers tagged

0

It's probably better to use one surface view. Each GLSurfaceView appears to get its own OpenGL context unless you jump through a bunch of hoops to manually create the context and customize the way each surface creates its context. The practical upshot is that you cannot easily share resources between each view, so you will need to reload textures and ...


2

Expanding on Greffin28's Answer Tile Based Collision Detection in Games In tile based games it's really easy and fast to detect whether an object is colliding with a tile. Some psuedo- code to accomplish this: /** * Moves our entity along the x, then y. If we do both at the same time the entity * will not move if any of the collision detections fail ...


2

For accessing the array i suggest you make a function like the following: String getState(int x, int y) { if (x < 0 || x >= WIDTH || y < 0 || y >= HEIGHT) return "g"; // Let's say all blocks outside the map is solid. return blocks[y][x].state; } This simple function can save you from array out of bounds error. Basically, the function ...


0

Some of the answers here are reasonable for early uses of OpenGL ES on Android. The first GLES devices only supported a single context, so GLSurfaceView was designed to aggressively discard state. Convincing GLSurfaceView to do otherwise isn't easy. For more recent versions of Android (probably anything using GLES 2.x), the best answer is to use a plain ...


2

I don't know cocos2d, but the general approach to use for this effect is simply to just render the scene at a lower resolution into an offscreen render buffer (VBO, in OpenGL terminology), and then copy that low-resolution image to the screen, with smoothing turned off. (in OpenGL terms, that'd be performing the copy using GL_NEAREST instead of GL_LINEAR). ...



Top 50 recent answers are included