Say I have a main menu screen which has a Logo which is png. Would I draw it as a texture or convert it into a sprite then draw it? This logo would have no interactivity on it, it's just sitting there looking pretty.
Thanks!
It's up to you which you prefer. Sprite is a convenience class that allows a Texture or TextureRegion store its position, rotation and scale, etc. If you don't use Sprite, that just means you plan to store that info elsewhere to use when you call draw().
Typically, you should try to put a groups of 2D images into a single TextureAtlas using TexturePacker, from which you can extract TextureRegions or Sprites (which are TextureRegions with features) to draw as a batch with SpriteBatch. If you only have a couple images on screen, such as on the initial loading screen, then you might want to go with just a Texture, but generally, you want to minimize the number of unique Textures on screen at once for performance reasons.
For instance, the low-res 2D game I'm working on has only three image files. One is the logo that appears before anything else is loaded, so I just draw it as a Texture, centered on screen. The other two are TextureAtlases, containing hundreds of sprites. One that is loaded with nearest filtering, and the other that is loaded with linear filtering.
Related
In my game I have some gold that the player can collect. My problem is I want to individually refernce textures of gold so i can take that particular instance of gold off the screen (player picked it up). How would I go about doing this as i am pretty sure you cannot do this with regular textures. Would i have to create a shape and fill it with the gold texture so I can delete that particualr gold piece? Thanks
I think you confuse Texture (which is basically a loaded image that you can draw) with game entities. Depending on how you implement your game, you can spawn multiple bodies (Box2D), actors (Scene2D) or your simple data containers (width, height, x, y) representing each coin and draw each one on the screen using the same texture. Actually, that's the preferred way to handle assets: you load images once and then simply reuse them for each sprite.
I suggest looking into the following classes:
Sprite (makes it easier to draw textures).
Image (allows to display simple images on Scene2D stage).
Box2DSprite (third party utility class that makes it easier to draw Box2D worlds).
What sort of approach should I take when I'm writing a game that uses sprites.
Say for example, my phone runs with a 1080p resolution. If I wanted to run my game on my phone without some weird stretching going on, would I have to use a large sprite sheet with huge sprites, or would I just write the game with a small sprite sheet, using the original sizes for each sprite (without upscaling), and just let everything be automatically scaled by LibGDX?
Thank you!
I would recommend storing the image larger. You could then enable mipmapping and tweak the texture filters. (See libgdx texture filters and mipmap)
This way, the image gets automatically scaled into a variety of sizes on runtime, and then the appropriate image gets selected depending on the size the image is shown.
there are spritesheets of tiles for a new game I'm developing. I'm planning to use them with mask layers. I mean for example there is 30 different tiles on each spritesheets, to use each one I'm planning to change spritesheet's x and y, so mask will show only the wanted tile.
But the problem is, it may force cpu.
For example if there are 30 tiles on the screen and if each spritesheets has 30 different tiles, that makes 900 tiles if I use mask layer instead of cropping each tiles.
So the problem is , If I use mask layer, does it effect the cpu in a bad way, or does only the part under the mask is calculated on cpu?
I hope I could define the problem clearly.
Thank you
-Ozan
Starling is a whole new field, as it's using Stage3D. This means you have to rethink your development flow - everything must be as textures and so there are a lot of limitations - you cannot simply design a button in your Flash IDE, give it a name and use it. I'm not saying it's bad, no, I just say you have to you it wise and if you don't have any experience with it - it will take time to learn.
I think you are doing some calculations wrong. You say For example if there are 30 tiles on the screen and if each spritesheets has 30 different tiles, that makes 900 tiles, which means you have 30 spritesheets with 30 tiles on each. This is a lot of tiles for your game, are you sure? :)
Anyways, the common approach is to use each tile of the spritesheet as an individual one. That's why it's called spritesheet. And the meaning of this is very simple - the memory it will use. Imagine you have 100 tiles in one spritesheet (for easier calculations), and this spritesheet is 1mb. If you splice it in smaller chunks (100 of them), the size of it will be close to 1mb also. So if you do this and delete the original source, the RAM that will be taken because of those bitmaps will be close to the original.
Then you want to use a single tile (or let's say your map is just "water" and you use only one tile). You instantiate many instances of the very same class, and because you use only one kind, the memory that will be taken in order to be displayed is 1/100 of the original 1mb.
What I mean is that the worst case scenario would be to use the total 100 of them at the same time, and this will take 1mb of memory (I'm talking for the images only). Every time you use less, the memory will decrease.
The approach of having a mask is worse, because even if you use a single tile, it will put all of the original spritesheet into memory. Single tile - 1mb. And it will also draw a mask object (Sprite) and will also need to precalculate that mask and remove the outer part of the Bitmap. This is more memory, more CPU calculations, and more graphic rendering (as it will draw the cropped Bitmap every time you instantiate).
I think this will give you an idea why it's used that way! :) If you have some fancy regions and that's the reason you want to use masking instead, then use some spritesheet packager program. It will provide you with a data file describing the regions of the spritesheet that are used, and so with a single class (there are many for that) it will parse your initial Bitmap, create Bitmap children for each chunk and destroy the original. And the coordinates won't matter.
Cheers! :)
I have done a little bit of basic stuff, I can tiles a grass tile across the screen evenly, I can display a transparent texture to the screen but I can't seem to find any documentation on loading sprites from a larger sprite sheet.
How would I dice the image up into smaller images? Or is there a different way to do it?
There is a SpriteSheet class in Slick that does exactly this.
SpriteSheets, in Slick, are large images made up of a series of uniformly sized tiles. Each tile is typically an animation frame in a Sprite. In the SpriteSheet constructor you specify the image (which has all the tiles), and the width/height of the tiles in the sheet, along with any spacing and margin, if you have/need that.
Finally, the getSprite(x, y) method allows you to retrieve the specified tile, as if it were an element in a 2D array. In other words, if you have a SpriteSheet of 16 tiles, that are arranged in a 4x4 grid of tiles, then to get the tile in column 3, row 2, you would call getSprite(3, 2);
I believe the indexes in getSprite(x, y) are zero-based, just like arrays in Java.
I have an image of a basic game map. Think of it as just horizontal and vertical walls which can't be crossed. How can I go from a png image of the walls to something in code easily?
The hard way is pretty straight forward... it's just if I change the image map I would like an easy way to translate that to code.
Thanks!
edit: The map is not tile-based. It's top down 2D.
I dabble in video games, and I personally would not want the hassle of checking the boundaries of pictures on the map. Wouldn't it be cleaner if these walls were objects that just happened to have an image property (or something like it)? The image would display, but the object would have well defined coordinates and a function could decide whether an object was hit every time the player moved.
I need more details.
Is your game tile based? Is it 3d?
If its tile based, you could downsample your image to the tile resolution and then do a 1:1 conversion with each pixel representing a tile.
I suggest writing a script that takes each individual pixel and determines if it represents part of a wall or not (ie black or white). Then, code your game so that walls are built from individual little block, represented by the pixels. Shouldn't be TOO hard...
If you don't need to precompute anything using the map info. You can just check in runtime logic using getPixel(x,y) like function.
Well, i can see two cases with two different "best solution" depending on where your graphic comes from:
Your graphics is tiled, and thus you can easily "recognize" a block because it's using the same graphics as other blocks and all you would have to do is a program that, when given a list of "blocking tiles" and a map can produce a "collision map" by comparing each tile with tiles in the "blocking list".
Your graphics is just some graphics (e.g. it could be a picture, or some CG graphics) and you don't expect pixels for a block to be the same as pixels from another block. You could still try to apply an "edge detection" algorithm on your picture, but my guess is then that you should rather split your picture in a BG layer and a FG layer so that the FG layer has a pre-defined color (or alpha=0) and test pixels against that color to define whether things are blocking or not.
You don't have much blocking shapes, but they are usually complex (polygons, ellipses) and would be unefficient to render using a bitmap of the world or to pack as "tile attributes". This is typically the case for point-and-click adventure games, for instance. In that case, you're probably to create path that match your boundaries with a vector drawing program and dig for a library that does polygon intersection or bezier collisions.
Good luck and have fun.