In my LibGDX game I have a TextureRegion1, which I would like it to serve as a base TextureRegion. Then I have TextureRegion2, which should be placed on top of the first one.
There is the 'obvious solution' and that is to render those two TextureRegions on top of each other. But that would require more rendering time and when rendering the whole map with 10 layers on each time, the graphics processor wouldn't handle it.
So is there a way to merge two TextureRegions in LibGDX?
Related
My team is currently working on a rather large Web application. We have switched from the flash platform to Html5 in hope for a one size fits all platform.
The UI, is mainly based on createjs, which I by the way really enjoy working with.
However we have now reached the maturity phase and started optimizing some of the animations, that doesn't run smoothly in especially IE.
The thing is that we have a around 1500 sprites (pngs & jpgs) which is drawn onto a stage. We only draw around 60 of them per frame.
They are rather large (up to 800x800 pixels), and the application engine can choose which 60 to show more or less randomly.
The images are packed in a zip file and unpacked in the browser and Html images are constructed by converting the binary data to a base64 encoded string, which is passed to the src property of an image.
So in each frame render a set of around
60 images are drawn to the stage. And this is for some reason slow.
I have therefore used some time to experiment with the Spritestage of createjs to take advantage of Webgl, but with only small improvements.
So now I'm considering to pack our sprites in a spritesheet, which results in many sheets because of the large amount of data.
My question is therefore:
Would spritestage gain any improvements if my sprites are spread across multiple sheets? According to the documentation only spritesheets with a single image are supported.
Best regards
/Mikkel Rasmussen
In general, spritesheets speed up rendering by decrease the number of draw call required by frame. Instead of say, using a different texture and render for every sprite, spritesheet implementations can draw multiple sprites with one render call, provided that the sprite sheet contains all the different individual sprite images. So to answer your question, you are unlikely to see performance gains if the sprites you want to draw are scattered on different sprite sheets.
Draw calls have significant overhead and it is generally a good idea to minimize them. 1500 individual draw calls would be pretty slow.
I dont know if it this is applicable to your situation but it is possible your bottleneck is not the number of draw calls you dispatch to GPU but you are doing too much overdraw since you mention your sprites are 800x800 each. If that is the case, try to render front to back with the depth test or stencil test turned on.
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.
I'd like to create a XAML application which progressively displays some graphic in a part of the screen. I can have a large number of elements, so I'd like to retain the elements already drawn and only draw the new ones as they come. But unfortunately, I can't get to the swap chain from the SurfaceImageSource (tell me if it is possible) so I can't just copy buffers with each draw call.
How can I draw new elements onto the SurfaceImageSource while preserving the old ones in a performant way?
I think a swap chain is something you would use with a screen rather than a surface like the one used with SurfaceImageSource, so I don't think it has a swap chain at all - it is just a single texture. I haven't tried but I would assume that if you don't clear it between render calls (with the ClearRenderTargetView method) - the contents should stay as they did. If you want to reuse only a part of the content - you should probably create a separate texture and a render target view that you would use to render to that texture and then copy the contents of that texture to the SurfaceImageSource one some way. I am not sure what the best way to do that would be - maybe memory mapping the textures and doing a memcpy between them or rendering one as a textured quad (two triangles) to the other one.
I'm creating a space game in actionscript/flex 3 (flash). The world is infinitely big, because there are no maps. For this to work I need to dynamically (programatically) render the background, which has to look like open space.
To make the world feel real and to make certain places look different than others, I must be able to add filters such as colour differences and maybe even a misty kind of transformation - these would then be randomly added and changed.
The player is able to "scroll" the "map" by flying to the sides of the screen, so that a certain part of the world is only visible at once but the player is able to go anywhere. The scrolling works by moving all objects except for the player in the opposite direction, making it look like it was the player that moved into that direction. The background also needs to be moved, but has to be different on the new discovered terrain (dynamically created).
Now my question is how I would do something like this, what kind of things do I need to use and how do I implement them? Performance also needs to be taken into account, as many more objects will be in the game.
You should only have views for objects that are within the visible area. You might want to use a quad tree for that.
The background should maybe be composed of a set of tiles, that you can repeat more or less randomly (do you really need a background, actually? wouldn't having some particles be enough?). Use the same technique here you use for the objects.
So in the end, you wind up having a model for objects and tiles or particles (that you would generate in the beginning). This way, you will only add a few floats (you can achieve additional performance, if you do not calculate positions of objects, that are FAR away. The quad tree should help you with that, but I think this shouldn't be necessary) If an object having a view leaves the stage, free the view, and use the quad tree to check, if new objects appear.
If you use a lot of objects/particles, consider using an object pool. If objects only move, and are not rotated/scaled, consider using DisplayObject::cacheAsBitmap.
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.