I'm going through tutorials to learn Libgdx and every time I see, use same instances or variable to output your sprite objects. So, I can understand that if we want to create and render the same image or sprite, we can simply use the same variables. But now, I need to display several objects (different players/images). Can I still use the same variables to output them or should I create variables for each of them? Cause I've seen it saves space and memory. To output sprites I'm using SpriteBatch, Texture, Sprite and TextureRegion(for moving sprites) objects.
No you cannot use same sprite object for different entities (Players etc) This is not where you will be saving memory. Creation of Sprite object is not heavy weight operation.
Where you can save memory is Textures. You should reuse Textures wherever possible. You do not want to load new Textures every time you create a new Sprite. Let's say there is 1 image which represents a player, you should not be creating that image again and again. You should rather just load it once in memory using AssetLoader and then re-use it.
If you have multiple texture of small sizes, then you should use libgdx's texture packer to pack them into a single image because loading multiple small textures is not a great idea, rather loading a bigger texture sheet is fine because binding Textures is an expensive operation. Read this Texture Atlas for more detailed information.
Also once you don't need a Texture, you should dispose them.
Read this page Memory Management in Libgdx for more information about Disposable interface which is implemented by many of the Libgdx classes.
I also feel that you are trying to optimise your game prematurely. Don't worry about object creations at all at such an early stage. And remember one more thing - Premature optimization is the root of all evil.
Related
(if you want to skip all this text you can go straight to the "short
question" version at the bottom)
Hello, guys!
I'm a beginner android developer currently creating a 2D RPG game. It basically consists of a map where the player walks (in 8 possible directions - west, north-west, and so forth) and interact with objects, creatures and others. The player's character walking animation consists of 9 sprites per available walking direction, totalizing 72 sprites. I have these sprites both in individual .png files as well as in an organized sprite sheet.
Until some days ago, I've been using the individual sprites in the game. I would load their drawable ID into an int[][] array and then, when each frame was going to be drawn, I would decode (using BitmapFactory.decodeResource() method) the necessary sprite and pass it to my renderer class that would then draw it.
After some thinking, I decided to try and use the sprite sheet instead, since the constant decoding of the sprites images was bothering me. For that, I decode the bitmap containing the sprite sheet with all the needed sprites and store it into a member variable. Depending on the required sprite for the next frame, my program would crop the required sprite out of the sprite sheet (previously saved into memory), resize it according to the player's devices needs and then pass it to my renderer in order to be drawn.
The problem is, I can't tell which method is more efficient! While it's easy to measure how much memory the decoded sprite sheet bitmap occupies (when stored in a member variable) in the player's memory (approximately 4MB), it's hard to know how much memory my program uses for constantly decoding small bitmaps, that corresponds to the individual sprites. Does anyone have any insights on how I could make this comparison? Or perhaps can share a previous experience related to this subject? I have searched for hours and, despite having found much useful information on how to load bitmaps efficiently and suggestions for libraries (like Glide, Fresco, and Picasso), I still couldn't find an answer nor better methods. Thanks in advance!
SHORT QUESTION: Is it better to constantly decode small bitmaps or to just decode a large bitmap once and then crop smaller bitmaps from it as needed?
P.S.: I'm aware that both presented methods for creating the animations in my game are probably inefficient. But, for the sake of my learning (my primary objective for creating this game), I don't want to use game engines, like AndEngine and libgdx. I also started learning OpenGL ES (which I've read provides great tools for loading and displaying bitmaps), but implementing it into my game would require a complete remake, in which I'm not interested right now.
Note: I am new to LibGdx with android.
I am Creating a clone of the famous game Color Switch for practice purposes.
I have used ShapeRenderer for creating the ball and moving circles.
After reading more about ShapeRenderer, I realized it is mostly used for debugging purposes, so I searched for other alternatives to it and I got to know about Pixmaps but I am stuck on how to use it and cannot find any source.
So I want to know if there any other alternatives to ShapeRenderer or any sources for Pixmaps to get started?
ShapeRenderer is perfectly fine for your use-case. So, unless you have an actual problem with it, there is no need to switch to something else.
The reason that ShapeRenderer is primarily used for debugging is because it's limited to basic shapes and colors. In many use-cases this is insufficient and e.g. images (like .png files) are used instead. In those cases SpriteBatch is typically used to draw the images, which is optimized for (rectangular) images instead of shapes.
A Pixmap is the raw image data in CPU memory (RAM), which is practically an interim step between the image on disk (e.g. the .png file) and the image (Texture) in GPU memory (VRAM). LibGDX handles this interim step for you, so you should never have to deal with Pixmap in most use-cases yourself. Manually manipulating a Pixmap is very costly operation and worse than using ShapeRenderer for your use-case.
I've been trying various ways of creating a two-dimensional tile-based game for a few months now. I have always had each tile be a separate object of a 'Tile' class. The tile objects are stored in a two-dimensional array of objects. This has proven to be extremely impractical, mostly in terms of performance with many tiles being rendered at once. I have aided in this by only allowing tiles within a certain distance of the player being rendered, but this isn't that great either. I have also had problems with the objects returning a null-pointer exception when I try to edit the tile's values in-game. This has to do with the objects in the 2D array not being properly initialized.
Is there any other, simpler way of doing this? I can't imagine every tile-based game uses this exact way, I must be overlooking something.
EDIT: Perhaps LWJGL just isn't the correct library to use? I am having similar problems with implementing a font system with LWJGL... typing out more than a sentence will bring down the FPS by 100 or even more.
For static objects (not going anywhere, staying where they are) 1 tile = 1 object is OK. That's how it was done in Wolf3d. For moving objects you have multiple options.
You can, if you really really want to, store object sub-parts in adjacent cells/tiles when an object isn't contained fully within just one of them and crosses one or more cell/tile boundaries. But that may be not quite handy as you'd need to split your objects into parts on the fly.
A more reasonable approach is to not store moving objects in cells/tiles at all and process them more or less independently of the static objects. But then you will need to have some code to determine object visibility. Actually, in graphics the most basic performance problems come from unnecessary calculations and rendering. Generally, you don't want to even try to render what's invisible. Likewise, if some computations (especially complex ones) can be moved outside of the innermost loops, they should be.
Other than that it's pretty hard to give any specific advice given so little details about what you're doing, how you're doing it and seeing the actual code. You should really try to make your questions specific.
A two-dimensional array of Tile objects should be fine........ this is what most 2D games use and you should certainly be able to get good enough performance out of OpenGL / LWJGL to render this at a good speed (100FPS+).
Things to check:
Make sure you are clipping to only deisplay the visible set of tiles (According to the screen width and height and the player's position)
Make sure the code to draw each tile is fast... ideally you should be drawing just one textured square for each tile. In particular, you shouldn't be doing any complex operations on a per-tile basis in your rendering code.
If you're clever, you can draw multiple tiles in one OpenGL call with VBOs / clever use of texture coordinates etc. But this is probably unnecessary for a tile-based game.
I have a map, divided into 375x375 tiles of 16 pixels. I want to develop a java application to stitch those images together into one big image. How would I go about doing this in java? Any useful libraries?
Create a BufferedImage that is 375*16 or 6000x6000px. For a 36 MPix image, you will need a lot of memory.
Get a Graphics instance from the image.
Loop through the tiles and call g.drawImage(tile, x, y)
Dispose of the graphics instance.
Of course, it might make more sense (and would take a lot less memory) to draw the tiles that are within view, directly to the rendering surface of the game (if that is the end purpose).
Any useful libraries?
Overkill for this. Using either technique outlined above, it would only take a couple of lines of code.
I'm trying to develop side scrolling game for android involving many many textures so I was thinking if I could create a separate layer, all a single unique color (very similar to a green screen effect) make a collidable and make it invisible to the player.
(foreground layer) visual Image
(2nd layer)collidable copy of foreground layer with main character
(3rd layer)Background image
I not sure if this is possible or how to implement it efficiently, the idea just came to me randomly one day.
Future regards, Thanks
I assume your game is entirely 2D, using either bit-blits or quads (two 3D triangles always screen-aligned) as sprites. Over the years there have been lots of schemes for doing collision detection using the actual image data, whether from the background or the sprite definition itself. If you have direct access to video RAM, reading one pixel position can quickly tell if you've collided or not, giving pixel-wise accuracy not possible with something like bounding boxes. However, there are issues greatly complicating this: figuring out what you've collided with, or if your speed lands you many pixels into a graphical object, or if it is thin and you pass through it, or how to determine an angle of deflection, etc.
Using 3D graphics hardware and quads, you could potentially change render states, rendering in monochrome to an off-screen texture, yielding the 2nd collidable layer you described. Yet that texture is then resident in graphics memory, which isn't freely/easily accessible like your system memory is. And getting that data back/forth over the bus is slow. It's also costly, requiring an entire additional render pass (worst case, halving your frame rate) plus you have all that extra graphics RAM used up... all just to do something like collision-detect. Much better schemes exist, especially using data structures.
It's better to use bounding boxes, or even a hierarchy of sub-bounding boxes. After that, you can determine if you've landed on the other side of, say, a sloped line, requiring only division/addition operations. Your game already manages all the sprites you're moving, so integrate some data structures to help your collision detection. For instance, I just suggested in another thread the use of linked lists to limit the objects you must collision-detect against one another.
Ideas like yours might not always work, but your continual creative thinking will lead to ones that do. Sometimes you just have to try coding them to find out!