so im trying to make a game with just a simple static background at the moment, but when i draw it to the screen (no scaling being done as the resolution of the image is the same as the screen) it draws the bottom portion of the image incorrectly where the bottom few hundred pixels of the image are exactly the same going down the image. Sorry it's so difficult to explain but being new here i cant actually post an image of what is going wrong.
Now im just using a simple sprite to render this background image. Here is the code being used:
// background layer: another image
background = CCSprite.sprite("WaterBackground.png");
// change the transform anchor point (optional)
background.setPosition(CGPoint.make(GAME_WIDTH/2, GAME_HEIGHT/2));
addChild(background);
am i doing something wrong here? Does Cocos2D not support such large images for sprites? (resolution of 800*1280)
Any help would be greatly appreciated!
Since i am now able to upload images, here are visuals of what is going wrong:
And the problem in my game:
As you can see, the problem is hard to describe. The problem only exists with this larger image; i scaled it down manually in GIMP and then scaled it up for the game and it looked fine (except for being a lower resolution). I also tried scaling down this larger image which still resulted in the same problem. Hopefully you guys can help me as I have no clue what could possibly cause this error. Especially since i read that Cocos2D's max supported image size is 2048*2048 and my image is well within that.
Thanks for any help you guys can provide!
This is due to limitations on the size of textures. Coсos2d-android supports images with a maximum size of 1024 x 1024 pixels.
I faced the same problem and looking for a way to solve it.
EDIT
I found the solution
In cocos2d project open file CCTexture2d.java in org.cocos2d.opengl package and change kMaxTextureSize from 1024 to 2048
I'm not certain, as from your code and looking at the cocos2d code I can't see a definite reason why this would be happening, but given the number of sprites you've got on the screen, i'd definitely take a look at my answer to this question as you may well be hitting one of cocos2d's quirky little rendering faults around multiple sprites. can't hurt to try spritesheets, and it's certainly the correct way to actually do sprites in cocos.
also, definitely create yourself a helper utility to determine the scaling ratio of a device compared to your original image sizes, as unlike on iphone, android does have a pretty much unlimited variation of screen resolutions, and a simple bit of "scale as you load" utility code now will save you lots of time in the future if you want to use this on any other device.
you should try to make one method for adding background,i am doing this this like this way try this hope it will help full for you...here addBackGroundScene is my method and i am adding my background with this method,scrXScaleFactor is maintaining scaling part of my screen try this...
private void addBackGroundScene() {
CCSprite bgForLevel1 = addBackgroundAtOrigin("prelevel1/bgMenu.jpg");
bgForLevel1 .setScaleX(scrXScaleFactor);
bgForLevel1 .setAnchorPoint(0, 0);
addChild(bgForLevel1 );
}
Related
I'm having trouble cleanly down-scaling images on Android. I'm looking to scale small PNG images between arbitrary sizes of about 10-100% of their original size.
I've created a sample image to demonstrate the problem and exacerbate the unusual behaviors I'm seeing in Android's image scaler:
The above image is a screenshot from an Android device with some annotations added. I've also added the same images in a second column on the left side showing how they are rendered with a linear scaling by "The GIMP" (GNU Image Manipulation Program).
The base image consists of a checkerboard pattern background of red and blue pixels. On that background I've drawn some 1px-wide yellow lines and fairly thin green text. The image is 288x288 pixels.
When scaling the image to 1/3 of its original dimensions, Android seems to simply grab one in nine pixels, throwing out all other data. Some of the yellow lines disappear entirely as a result. Remarkably, the checkerboard pattern remains intact (which is simply a result of every 3rd pixel being used).
When scaling the image to a dimension of near-but-not-exactly 50% of its original size, e.g., 142x142 or 143x143, the scaler creates some fairly large anomalies/artifacts on the image.
At 50% size (144x144), the image looks correct.
The test image does bring out the worst of the image scaler, but "normal" PNG icon images are severely impacted as well. From 10-33% or so the images aren't properly resampled, and thus appear extremely "bitmapped". And certain larger size images have very strange anomalies in them at certain sizes.
If anyone knows a means to disable this strange scaling behavior, even at a performance cost, I'd greatly appreciate knowing about it. It can certainly be solved by writing an algorithm that works directly on the pixels of bitmaps, but I'm hopeful that isn't the only option.
Also noteworthy is the fact that all image work is being done with ARGB_8888 Bitmap.Configs. I've tried manipulating image size by setting maxwidth/maxheight on ImageViews, by using Bitmap.createScaledBitmap(), and by using Bitmap.createBitmap with a Matrix. All attempts have this same result. Bitmap filtering is enabled.
Thanks again for any suggestions!
Using Bitmap.createScaledBitmap() and Bitmap.createBitmap with a Matrix is the same; see the source for Bitmap.createScaledBitmap (which hasn't changed since Android 2).
On Android 4.0+, using a matrix (as in Bitmap.createScaledBitmap) allows hardware-accelerated operations if enabled (enabled by default on 4.1+ IIRC), thus we doesn't have direct control over what is being done and how it is done.
That means you'll have to implement your own scaling method using the desired (here, linear) filtering; either by pixel processing; or using OpenGL ES with the good filter, but it may not be available on all devices.
I have a background png in my Android application. I would like to support lots of displays, but I have this one obstacle - many displays have many resolutions and many ratios. I would like to make sure my background is displayed properly and make it more ellegant, than just creating 10+ cropped png files in Photoshop.
My idea would be - a fairly large picture imported in the project. The app would find out screen dimensions and simply say starting points(x,y) and ending points, that would "crop" the picture and display it without any deformations.
Is there a way of doing it?
I think bitmap.createBitmap() is the method your looking after. The method simply lets you cut out a defined portion of the bitmap.
My app is loading a large image (a house floorplan), then drawing touch-reactive objects (furniture, lamps etc.) on the image. I have a base image file included with my app but the objects come from coords in my database.
I've successfully deployed the app in multiple iterations, but now I need to use larger base images and BitmapFactory is causing an OutOfMemory exception on many devices (both old and new devices; anything with < 32MB heap seems to crash). I've read the 157 OOM questions on SO, but I'm afraid the link they all seem to point to won't help me since resolution / zooming is critical to the app's function.
I've tried to test the device's available memory before loading, but the results are spotty at best (some devices like the galaxy S3 report plenty of heap but still crash). I've also tried decreasing resolution but the image became unusable when reduced to a safe size based on the above test.
Is there another way to implement this design without ever using bitmaps?
I need to:
Load large base image
Create clickable shapes on top of the base image, maintaining their position / scale relative to the base image
BONUS: in the iOS version of my app, I can do SVG-style text scaling so a long label on a small object will stay inside the object
instead of running across the map(and will be invisible until the
image is zoomed). Replicating this in android would make me a happy
code monkey.
I can post code if needed, but you've all seen it before (almost all of it came from SO).
Thanks in advance for reading, and for any help you can give.
you have a few options:
break your large image into tiles, load these tiles into an array, and move a camera object around and only load tiles that need to be drawn, as the comments suggest.
make your image small and scale it up using 'android:scaletype`
Draw lines and curves on a Canvas object at runtime.
Use OpenGL
The appropriate solution really depends on how you want it to look. Tiling will take more dev effort but will look better, just be careful that you are properly cleaning up any tiles that aren't being drawn...
dynamically scaling will be easier, but you cannot guarantee the image won't be blurry.
Drawing on a Canvas object at runtime could work well-- just use Lines of different width and circles and Rects etc.
Using OpenGL will have the steepest learning curve, and might be overkill. This depends on your purpose.
You might like to look into using a "largeHeap"
http://developer.android.com/reference/android/R.styleable.html#AndroidManifestApplication_largeHeap
Here are some options:
1) Use tiles. Use tiles and dynamically load your data. Honestly, this is the best solution. With this solution you can load arbitrarily large images.
I've successfully used this approach for an endless paint canvas and it works quite well. You really only need to draw what is directly visible to the user. Tiles is a way to cast away pieces you don't need. A pyramid of tiles (where you pre-downsample your images and create more tiles), allows you to do this in a clean and fast way.
2) Use native code. The memory restrictions on native code are not the same as Java code. You can get away with allocating more memory.
3) Use OpenGL. Once again, the memory restriction for OpenGL are not the same as Java code.
4) Convert your original plan to an SVG and use an SVG library like this one.
5) Use "largeHeap". I strongly discourage this, as I think a largeHeap is rarely the solution, there are generally cleaner ways to approach the problem.
if the image is static , you might wish to use this nice library:
https://github.com/ManuelPeinado/ImageLayout
if the library doesn't support auto-downsampling of the image, you should do it by yourself, in order to use the best image for the current device (so that you won't get OOM).
for auto-sizing text , you might have some luch with the next post:
Auto-fit TextView for Android
I have created sprite with texture size of 2048X1024 and attached to my scene.
Things are going fine but problem is that when i attach any other sprite with scene it takes time to display. Without this larger sprite things are displayed without any note able delay.
As I attache this larger sprite other attachments start getting time to display
I am working on AndEngine
Please help if any one solved this kind of problem
Thanks
I can't figure out why you would need an image of that size on your screen. The problem is that Android limits image sizes to around 1024 x 1024 so AndEngine is most likely swapping out the different images. Without seeing your code or knowing what you are trying to do, there's not much I can suggest. except to break your large image down into images smaller than 1024 x 1024. If you are doing a game and are using the image as a background I'd suggest looking into using a program called "Tiled" and loading it up in AndEndine using its TMXLoader. There is a tutorial on the AndEngine forum for this.
I'm using the code outlined in the following post:
Draw text in OpenGL ES
I thought I could use this technique in order to dynamically display text (say an FPS counter). I realised that calls to resources to get the drawable slows down this process quite a lot, and I didn't need a bitmap background, so I removed it.
The technique works, but after a while (~2000 frames) the whole phone locks up. I suspect there's some memory which is not being freed in this code but I don't know where. I tried offloading the Canvas, Paint and Bitmap object creations which worked (so they aren't created every single frame) but the same problem still occurs.
I suspect therefore, that the generated GL texture is to blame, but I'm unsure how to remove it, or if this is even the case.
Any help would be appreciated.
EDIT: As an alternative, can someone please point out an easy way to render text to the screen dynamically (e.g. should be able to render the # of frames since starting for example, continually being updated and increasing). All the ways I can think of are either extremely tedious (make individual quads for each digit, store the textures for 0-9 in memory, parse the number and render each digit onto each quad), cannot be updated in good time (overlay Views) or can't get the required positioning in the glSurfaceView.
CBFG - http://www.codehead.co.uk/cbfg
This really is exactly what I've been wanting. You build a bitmap file from a font file using CBFG which can then be loaded and displayed with only a few lines of code (after importing his packages). It's literally as easy as fnt.PrintAt(gl,"Hello world!", 50, 160); in onDraw and more importantly, it handles dynamic text really well. I strongly advise anyone who is the same situation to try this.
two things I can guess you'll want to try:
1) dont' recreate the number of your frs every frame, generate number 1 to 60 and always reuse those.
2) there is an issue I found when generating text for my textures is that the font loader code of android never frees the memory space so avoid loading the font all the time, do it once and store a reference to it
I just wrote an entire tutorial on creating exactly what you are looking for.
The idea is basically to use font files and then generate a font bitmap (or atlas) at run-time instead of using a tool like CBFG to generate it offline. The benefit of this is that you can ship a small font file instead of multiple large bitmaps with your app, and never have to sacrifice font quality by using scaling.
The tutorial includes full working source (that can be dropped into any project). If you are interested go have a look here.