I am currently designing Agar.io game with Java. Most parts of my game went well. The only problem is when the blob reaches certain size, it become too big for the current screen size to handle. I need to find a way to automatically shrink game canvas (window dimensions stay the same) to make the big blob to appear smaller and smaller food blobs appear even smaller than before.
My original approach was reducing each of blob's width and height to make then smaller, that's when I noticed this approach will not only reduce blob's size but increase distance between blobs. I dropped it.
I need some suggestions on how to take account on blob's x, y positions and width, height to "shrink" game canvas.
Related
In short, I'm making a simulation where I have a bunch of creatures that can see each other. The way I want to do this is to capture an area around each creature and give it to their neural network, and make them evolve to recognize their surroundings. I am coding this using LibGDX, and I don't plan on making screenshots every single frame because I can imagine that that is already a very poor idea. However, the problem is that I don't know how to get the pixels inside a defined square without capturing the entire screen and then cherry picking what I want for each creature, which will cause a MASSIVE lag spike, since the area these creatures will be in is 2000x2000, and therefore 12 million different values (4 million RGB values).
Each creature is about 5 pixels (width and height), so my idea is to give them a 16x16 area around them, which is why iterating through the entire frame buffer won't work, it would pointlessly iterate through millions of values before finding the ones I asked for.
I would also need to be able to take pictures outside of the screen (as in, the part outside the window's boundaries), if that is even possible.
How can I achieve this? I'm aiming for performance, but I do not mind distributing the load between multiple frames or even multithreading.
The problem is you can't query pixels in a framebuffer.
You can capture a texture from a framebuffer, and you can convert a texture to a pixmap.
libgdx TextureRegion to Pixmap
You can then getPixel(int x, int y) against the pixmap.
However, maybe going the other way would be better.
Start with a pixmap, work with the pixmap, and for each frame convert the pixmap to a texture and render that texture fullscreen. This also removes the need for the creatures environment to match the screen resolution (although you could still set it up like that).
I have a Texture sheet that was created with a texture packer app, it removes all of the unnecessary transparent pixels to save space in the final texture sheet. The problem is my animation is a guy with a sword, so when he attacks he swings the sword over his head, meaning it changes the width and height of the sprite. Example...
characterAttack1 = new TextureRegion(texture, 863, 979, 152, 149);
//more animation frames...
characterAttack8 = new TextureRegion(texture, 1, 2, 340, 256);
As you can see the first frame is 152x149, but by the 8th frame it is now 340x256.
So when the animation runs if I use the normal getWidth() getHeight() methods within my Character class the character will shrink as he attacks, since the height and width of the attack is larger as the sword swings. On the other hand if I use the method...
((TextureRegion)AssetLoader.characterAttack.getKeyFrame(runTime)).getRegionWidth();
and
((TextureRegion)AssetLoader.characterAttack.getKeyFrame(runTime)).getRegionHeight();
The character will bounce around the screen when the attack animation is run. I know I can't be the only person that has encountered something like this, but I can't seem to find any information on this. Is my only course of action to repack the texture file and make each one the same width and height even though there will be a ton of transparent pixels in the final packed texture?
If you need to see the AssetLoader and the batcher.draw methods or anything else I am more than happy to provide code samples, I am just trying to keep the post from being too large. Thank you.
Unless you are tying to make your game run on something with extremely low RAM, there is really no need to pack the textures so tightly. Sprite sheets are really quite small when you think about the grand scale of things. I imagine your game would require around 100MB of RAM when running, given that most computers now have upwards of 4GB of RAM, what's a few more MB?
A sprite-sheet for your character should be the maximum size of any one of the frames. e.g. If the largest frame is 340x256, every frame needs to be that size.
Now the character will be in the same position every frame because the render position will not change.
If the centre of the character is always in the middle of the sprite, you could render from the centre of the image, which would fix your problem.
I am new to libgdx and this question might be obvious since they skip it in every tutorial.
But say I set a camera up like this:
cam = new OrthographicCamera(100, 100);
This means I will now be working with my own units instead of pixels. So how do I know what size to make an image? Say for example I want an image to fill the width of the camera and half of the height. How would I do this? Do I make the image 100x50px? that makes no sense to me.
You say you are working with your own units when you define your camera, yet you are still thinking with pixels when you ask whether you should make your image 100x50px.
Since you are working with your own units, I would assume that they are not completely detached from original pixel units, meaning that everything should now be measured by your units including the size of the images.
If you can calculate what 1 unit of your represents pixel-wise, you can then determine the scale to which you can scale all of your images.
Then you can say that your image should be 100x50units in size, you don't need to make the image to fit this condition, you just need to adjust its scale so that it corresponds with your defined unit measurement.
If you are using SpriteBatch to draw your images, you might find that a couple of the defined draw overloads documented in the API can be given scale for both X and Y and could prove to be useful in this scenario.
I need to fit a huge image (BufferedImage to access colors etc) into a JScrollPane derived class. Nothing very hard until there.
The image is a JPG scan of an A3 sample of material, its size is 13030x20840 pixels, 24bits, and weights 12MB on disk -> about 800MB in RAM.
I embedded the BufferedImage into a Jpanel, which lies as the Scrollpane's view.
When I try to scroll/drag my image, it takes seconds to respond, so it is not very handy.
I need your help in order to know what I should do to render the scrollpane's scrolling and the image dragging as smooth and reactive as possible, but I easily figure out that with such an image it could be impossible.
I tried many options, such as double buffering, etc. but I'm quite new to Swing, then it is greatly possible I missed some simple solution.
If there is a need to change the BufferedImage by something else, or whatever, I'm receptive to any solution.
So, we have a large 13,030 x 20,840 pixel image.
if we break this image into 256 x 256 pixel tiles, we get a tile set that's 51 tiles across and 82 tiles down. The last tiles in the rows and columns will be partial images, since 256 doesn't go evenly into 13,030 and 20,840.
Let's assume our display window is 400 X 400 pixels. Let's also assume were starting in the upper left hand corner of the large image.
We take and make a 3 x 3 tile buffered image. This would be 768 x 768 pixels, which allows enough overlap for smooth scrolling. We take the first 3 tiles from the first row, the first 3 tiles from the second row, and the first 3 tiles from the third row to make our 3 x 3 tile buffered image.
Now, when we set up the horizontal and vertical scroll on the JScrollPane, we have to set the maximum value on the horizontal scroll to 13,030 and the maximum value on the vertical scroll to 20,840. This is so the user is kinetically aware that he is scrolling a large image.
Ok, we display the 3 x 3 tile buffered image. The user scrolls to the right to see more images. The user has scrolled 256 pixels.
The application now has to build a new 3 x 3 tile buffered image. We take the 2nd through 4th tiles from the first row, second row, and third row. We display this new buffered image. To the user, it looks like one huge image. To the application, a series of small 3 x 3 tile buffered images are displayed.
mKorbel has already created some code which builds and displays these smaller buffered images on the fly.
To deal with zooming, you can resize the large image outside of the Java application and create more than one tile set. This makes the Java application code more complicated, but much faster than trying to resize the smaller buffered images in the Java application.
I found what I needed there :
very large image manipulation and tiling
A nice book, the sample shown covers that.
The Java JAI lib has a lot of features to handle these kind of problems, and is supported by Oracle, which means it is (theoretically) stable and sustainable.
Thanks to #BryanD !
I have been developing a game for Android and I had an idea for catering for the different screen sizes, and I would like feedback on whether the idea is a good one, and how it can be improved, or if it shall be scrapped.
What I have is a 2d size scrolling game, where it is locked it landscape mode. Because screen sizes vary, the width of the screen (usually height, but it is in landscape so I shall refer to it as width) changes. This causes all sorts of problems for me with moving the background because it is basically two identical pictures scrolling, and as one leaves the screen the other begins to replace it, so I must catch the image when it has just left the screen, so it can be reset and ready to scroll again. This means it must reach an int value every time, else it will not be caught and both images would scroll off screen.
My idea, which I have briefly tested is as follows. Truncate the screen size to the nearest 100px. Add 100 to this value and have that as the width for the background images. Then divide this value by 100 and use this as the rate of px per frame it moves. This would mean that the background would move at a similar rate dependent upon screen size (set frame rate of 25FPS). It would move faster on larger screens and slower of smaller screens, but would move at the same speed relative (1% per second or whatever).
Is this idea flawed? I have tested it vaguely on a few screen sizes but the emulator is verry laggy, and I only have a couple of devices to test it on (I am only 18 so I cannot get my hands on many!).
Any feedback appreciated.