What is the best way to get around the max texture size in Libgdx? I currently have a 2048x2048 texture with an ortho cam zoomed in at 2x which serves as the "map" for my top down shooter. The problem is that 2048x2048 just isn't enough space for the player to move around in, so I need to expand the map without creating a huge texture. Am I going about this wrong? should I not just use a giant texture for the background?
Only some phones will support textures bigger than 2048x2048. This is a GPU hardware/OpenGL driver limitation and not the fault of LibGDX.
The most common solution is to build a map out of several smaller textures that can be repeated to create the illusion of a giant map. You don't just take the map of the world and divide it into 2048x2048 chunks, you instead have a bunch of tiles that are 32x32 pixels and represent things like grass, dirt, grass meeting dirt, etc.
This is why LibGDX has a maps package. See https://github.com/libgdx/libgdx/wiki/Tile-maps
Instead of trying to create the map programmatically you record the map in a text file and use a map loader at runtime. There are a couple of supported map formats. The best way to create the map files is to use a map editor like http://www.mapeditor.org/
Related
I am developing a game using libgdx. Now i'd like to have a Background all over my map (Map size is not fixed yet i'll decide later). My map is tile based but i don't use TiledMaps. So i create and load the map with own code/editor.
My question now: How should i implement the background thing?
I thought about different ways:
Loading a huge Image, which covers all the map. This is not realy good cause i render things, which are not in my viewport (80 Tiles X,50 Tiles Y).
Deviding the Image in 4 or more Images and loading the one in the viewport. The Problem: At some point maybe part of all Images is in viewport so all Images are sent to GPU right?
Having 1 Image which cover the viewport (80,50) and follows the camera. Best performance i think, but it will look stupid...
Or every tile has an own Image and the Objects are drawn above them. Notice that i only render Tiles inside the viewport. But on Gamestart it would need to load Information about every tile in the level.
For Information: My Game is Topdown and the Background Shows the floor so no detailed hills etc are needed, just maybe some simple desert sand look and things like that. Is there another even better way?
What would be the best way for performance and optic?
If your game is Tile Based. It would make much more sense to have the background tiled aswell. Just use another layer for it. If your editor/loader does not support multiple layers, then I would recommend you to switch to another one, or add those features to it (if possible).
The Background Shows the floor so no detailed hills etc are needed, just maybe some simple desert sand look and things like that.
It is very easy to reuse tiles in something like a desert, because all their tiles are very similar (sand).
I have a large tmx map which I made in Tiled. I am using libgdx to render the tmx map. I would like to know how can I render specific tiles. For example I have a 100x100 tile/tmx map. Player entity spawns in 10,30 (x,y) I only want to render around the location of the player entity (or for any entity, and control the seeing distance within the respective entity class). How can I use libgdx to selectively render like this? I tried setting rendering bounds to camera but not working like I want.
I want to be able to zoom in/out of overall map (which would look dark/completely blacked out) except for the parts where an entity sprite is located. Looking to maintain the fog of war around the entity sprite.. and multiple entities.
Should I pass renderer into the entity constructor? multiple cameras? How can I do a layered effect where i have another 100x100 blacked out tilemap on top of the actual map and have it so the alpha around entities is 0? (bear in mind im using tmx maps)
I'm making a map editor for my 2d tile based RPG game, and I'm running into a roadblock. The problem is actually how to draw the grid lines efficiently for very large maps like, say 300x300 tiles.
Originally I called redrew the entire grid panel every time you moved the mouse or clicked(since it allows you to drag and also highlights the tile you are hovering over). This was horrible for large maps and was very slow.
So my solution was to create a bufferedImage for the grid of a specified size right when a new empty map was created, and redraw that image every time paint was called. This worked very well, except that for anything above 200x200ish java would run out of heap space in creating that bufferedImage. I can't really have a preloaded image because the user should be able to specify a new map to be any size. Also, I like the grid to be drawn over the tiles, otherwise the tiles cover up the lines and it looks messier. That means the grid has to be drawn again every time tiles are added right?
My question is, is there another way to draw a very large grid that will repaint each time you move the mouse?
The program Tiled can easily create maps of 1000x1000 or more, how is it done?? Thanks
EDIT:
I mean the actual grid LINES, not the grid content such as tiles. Right now when the grid is drawn it iterates through the 2D array and draws a line at every length of a tile.
EDIT:
I got it to work by painting only the visible portion of the screen. Turns out it's not that hard to find the coordinates of the view pane in a JScrollPane. :)
Ok so this is similair I guess to what im working on at the moment. I am currently writing a bit of simulation software with a 3D frontend in Ogre3D. I have a tile based map that can be easily 3000 x 3000 sometimes they may be even larger.
Now im not sure how you are going about drawing your grid, if you are just doing 2D/3D, but the main problem for me was how to apply different textures to each tile. If this isnt relevant then hopefully this may help anyway for future lol. The problem for me is that creating a seperate object for eacch tile is a no no, due to speed. If there are even 1024 x 1024 your looking at over 1 million tiles, each with attributes. This worked great on my first tests where I only had 10 x 10 maps but on larger maps it just ground to a halt.
What I am currently doing is rewriting it, the new approach is as follows. (You may be able to adapt this for what you are doing if it helps). The grid is now only 1 object, its a mesh in my case as im working in 3d. Each vertex holds a couple of values, one is the column and one is the row. I have a seperate texture which is the same size as my map, so for a map with 100 columns and 100 rows i create a texture 100 x 100 (this is created dynamically).
I then pass this texture and the vertices to my cg shader (this is where tyou may have to think of an equivalent way of doing things, but I think it should be doable). By looking up the colour at the pixel in this texture relating to the grid slot I want to texture I can find a colour value, these colour values relate to my texture atlas which holds all my possible textures for my map. All you then have to do is use that particular part of the texture atlas for that particular part of the mesh / grid.
I hope that makes some sort of sense, if not then id be happy to explain a bit more. I think even though im using CG shaders, you should be able to come up with an equivalent for non CG based stuff in java. The advantage of this is that you end up with one lookup texture, one object in memory and a buffer holding your vertices which is very quick for lookup.
Hope this helps.
I am using AndEngine to create a project game for school.
I am creating a Tiled map using Tiled. The problem i am having is that i cant figure out the size of the map it should be to fit all devices.
or is there a way to create the Tiled map to fit all screen sizes? If so please let me know.
As of now the TiledMap is to small on tablet devices and on cell phones it is to large.
Any suggestions or tutorials on this?
This is what i want to create. Not exactly like this but it is an example.
There's no built-in function for changing the tilemap resolution in Tiled.
Someone wrote a script to change the resolution of a Tiled map. This might help in making the Tilemap with two sets of graphics.
Generally speaking you should aim to support the two or three primary display resolutions. You may have to optimize the tilemaps for each resolution. An alternative would be to either display borders (assume a larger screen is as big as a slightly smaller one) or scale up the tilemap layer (that will most likely result in visual degradation). That means for the best quality you'll need to create one set of tilemap with the corresponding graphic assets for each of the device resolutions you want to support. There's nothing "automagic" about this.
I'm writing a basic sprite engine for my own amusement and to get better aquainted with Java's 2d API. Currently I am making use of large numbers of separate .png files with transparent backgrounds to represent the various sprites and different frames of animation that I need. Most 'real world' game development projects seem to make use of 'sprite sheets' which contain multiple sprites or frames of animation within a single file. Also, rather than making use of native image transparency support, people often nominate an arbitrary colour that does not appear in the sprite pallette to be the transparent colour. How does one manage a file like this programatically?
how do you know where one sprite
starts and the next begins
how do you deal with transparency
There may be other factors that I've not thought of here, so I may add to the list above as I think of things or as people make suggestions (please do so in the comments).
I currently use XML files generated by a simple sprite editor that store the sprite as a collection of (optionally animated) poses, which are in turn a collection of frames or cells. Frames store per-frame information like the x and y offset of the frame in sheet, cell width and height, and any transformation (resize/rotation/hue/etc.). Poses store individual frames and animation information (speed, for example), and a pose name to easily identify them in the program (hero.pose = sprite.pose["standing_right"]). Sprites serve as a document root to hold several poses, such as a pose for each facing direction.
A less flexible alternative I used earlier was to specify fixed sizes for cells and sheets and calculate frame offsets and sizes based on these values (e.g. width is always 32 pixels, so third sprite is at 32 * 2). Later I started specifying these dimensions in the file name (e.g. sprite_name_32x64.png) for sprites that don't fit the fixed cell dimensions. I like the new approach more, especially with a simplistic editor that fills most values for me and allows me to use sprites as templates for other sprites.
I use the alpha and transparency information stored in PNG images directly so I don't need to worry about storing it elsewhere, although other approaches would be to pick a fixed value per sprite and store somewhere, use the leftmost pixel in the pose if you know it's always empty, use a specific palette entry if you're using those, sprite masks, or what have you.
Not about java but generally you can make your all sprites in the same size. Thus, you will be able to generate your sprites in your game (or app) with a simple for loops.
But for different sized sprites there may be problem for spritesheet size (it can be larger than expected). So you must define an xml or json file for your spritesheet to find your sprite images in your code. You can use sprite sheet editors (there are plenty of them, I'm using Sprite Master) for quick and easy way to generate sprite sheet and coordinate datas.
Make your sprite sheet knowing the size and number of each sequence.
Grab a buffered image of your sheet and use something like this:
currentframe=spritesheet.getSubimage(x, y, w, h);
Your x and y will change based on the frame you are on. Keep the width and height the same to make things easy on yourself.
Forget trying to keep the entire game on one sheet. It's nuts and hard to manage. Use a new png for each animation sequence. If you are anal about saving space only create moving right animations and just flip the buffered image real time to move left.
Java will read png files with the alpha so don't worry about the transparency colour. Draw everything in pngs. Use Photoshop or Gimp.
Search google for java image TYPE_INT_ARGB
Well, since most of them are custom, those details are up to the implementor.
You'd generally have the file start with header information that contains the details of height/width and encoding, transparency, etc.
A lot of the time things are in one file because it is very expensive to open/read multiple files compared to open/read one file. Many game engines use zip or "ziplike" files with 0 compression to treat a single file as a filesystem.