I was just wondering does java already paint the portion of an image to a given component or is it wise to do sub-image rendering? What I am trying to do is get as much performance as I can out of my code structure especially since I am creating a game with 2d maps as large as possible without drawing too much RAM. My 2d map involves a looping world whereas the player is able to reach the north part of the image while also seeing part of the south part (using sub-image rendering) and will move directly to the bottom of the image once the character has reached the top of the actual image.
Java 2D is very clever about not painting parts of a graphic element or image that is not visible. I'd trust it unless/until you experience a bottleneck and a profiler identifies the painting as taking up the time.
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.
I am making a game similar to Risk and struggling to find a way to implement the interaction with countries.
The basic idea is to create custom objects that are not rectangular and be able to change their colour by clicking them, highlight them with mouseover, or as the game progresses.
How would I go about having highlight-able countries that can be selected? The problem with sprites is their bounding boxes are rectangular, and if I define Box2D vertices and make polygons it gets really messy. Also, there are a lot of countries so a lot of the platformer style solutions don't fit.
How should I also change the colours of what is selected? Would it be best to have an individual sprite for every country and keep switching between them or is there a better way?
One way is to use polygons like you tried but I wonder why and what you mean it got messy. There are tools out there that let you draw vertices over a image and let you export that. You probably need to clean up the data a bit and import it into your app. It's also not very hard to make such an app yourself, have it import your image and start drawing and export to your favorite format. The more detailed you draw your polygons the more detail you get in your.
Perhaps an easier solution would be to use the opacity of each image of a country. Each country gets it's own image and you need to overlap the bounding rectangles to line them all up. When your mouse is hovering over one or more of these bounding boxes you check if the mouse is over a transparent pixel. If it is transparent you are obviously not hovering over the actual country. Some things to consider:
I would create the game in a pixel perfect manner so each pixel of your images is translated to a single pixel of the screen your outputting to.
To align your whole map I would create one big world map in your drawing application. Then save each country but remain the canvas size of the complete map. When packing these images with the LibGDX TexturePacker remove the whitespace (transparent pixels) and you will get an offset in your atlas. You can use this offset for each country to line them up and save precious texture space by removing all that whitespace.
Always check for a simple collision first before diving in deeper.
If you want to have "hover" functionality then don't do pixmap = texture.getTextureData().consumePixmap() each update since it's rather expensive. You might be better off creating your own 2D boolean array that represents the clickable area when you initialize the country object.
1) Re-Draw Vs Draw
Kind of a philosophical question, but... what is the "correct" or "accepted" way to render a game (2d, I understand how OGL perspecives work...) at different resolutions? Should I include separate sizes for my images (like Android APKs) and resize each object individually at draw on one canvas, or should I draw on a set-resolution drawing canvas, then resize that image onto another display canvas? I'm speaking generally, but, if you need me to be specific I'm using Java to build the engine.
Foreseeable benefits/issues:
#1) Resize at Draw
+ No additional drawing step
+ Sweet resolution
- Possible math/physics/placement issues
- Tons of math each step for scale
- Lots of resources
#2) Resize at Render
+ No additional math; one step
+ One set of images; smaller res. package
+ One set canvas size (easier to do math/phys./placement)
- Additional drawing step
- Poor resolution =(
It would seem that #2 is the obvious choice because of the number of benefits vs issues, but... is it? Is there a standard way to resize 2D games?
2) JOGL + Java2D + Java Swing
Would it be cumbersome to use JOGL, Java2D, and Java Swing at the same time? Would it be worth it to do 2D or layouts in JOGL? Why or why not?
EDIT: Using a BufferedImage to draw on and rendering the BufferedImage to the size of the panel with respect to aspect ratio is incredibly inefficient in swing. Apparently it's better to draw immediately to the panel, while resizing each image/element individually. Not my first hypothesis...
EDIT 2: Silly me... just scale and translate the graphics context to the size of the adjusted resolution before any other operations. The performance boost is super-dooper awesome. THIS is the correct answer to the question. DRAW ONCE, to scale/translation. B)
I can't answer your second question fully as I do not have much experience with JOGL or Java2D, but I don't see any reason for them to ever conflict or be cumbersome.
For your first question, I can definitely say that it depends. What's your target audience? Is your game memory intensive (Ever notice that many games have a high res/low res option)? Is this a game that will be available for vastly different screen sizes? If so you might want to provide 2-3 different "packages" of your assets, each scaled at a different size of the original (the largest one). The math to draw the images isn't as much as you think.
In addition:
If you build the game the right way, you wouldn't have to do much math at all. If you have some sort of Camera class that takes care of the viewing of your GameWorld then you simply have to scale the Camera's image instead of scaling each image independently.
I have a very large complicated diagram that needs to be drawn on the fly.
I am already using a double buffered technique to paint the image (from this answer: Using threads to paint panel in java) however, the generated image that is being painted is so large that it cant be painted as a single image (and the multiple images required to paint it cant be stored in memory all at the same time). For this reason, I paint the currently visible area of the view + some margin. As I scroll, I paint the area that is going to come next, and remove from memory the area we just came from. However, if the user then decides to change direction, they need to wait for this area to be painted again. My question is this:
If a single "frame" of the screen being painted is approximately 1000*1000 pixels, in which approximately 5000 lines/circles are drawn (nodes/edges of a graph) is it likely to be more efficient to repaint this image each time, or is there a way to affectively cache the image to hard disk (to avoid java heap limitations).
Ive already optimised the paint method as much as I can think of, but there are still several seconds of delay if a user scrolls to quickly (i.e. moves out of the painted area before the next set of "frames" are painted). So my second question is this: Will moving to OpenGL offer a large improvement, and will it require major changes to the infrastructure of the code? (I tried doing this a couple of days ago, and found it was not as simple as I thought - often led to the computer crashing).
Several things come to mind:
Profile to verify your working hypotheses; self-time the animation budget on your target platform for comparison, as shown in this AnimationTest.
Compare your approach to the example cited here; it scales into the 1000's and accommodates dragging selections into the hundreds.
If your frames have a suitable geometry, consider adopting the flyweight pattern for rendering; JTable rendering is an example; the underlying mechanism using CellRendererPane is examined here.
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.