I'm looking for an android 2d game engine, where you can create your game at the resolution you want, and the game will work the same on every phone, no matter the resolution, maybe by auto creating thoose black rectangles.
I was working with libGDX, but i could not find any ways to do that, just some viewport scalling methods, that will make the game graphics quality crappy.
I also used to work with the android sdk using surfaceview, and i had to code everything by a ratio, and also scale the bitmaps by a ratio, but i don't really think that that is a good way to do it.
Are there any android game engines that support every device resolutions?
You are asking for something you won't get. I doubt that there's a tool or engine released to the public that will automagically fix all resolutions possible to fit your needs. This is something that developers has to tackle, and it's a nice thing to handle independently.
Now when working in LibGdx, did you even try to use Texture filters? Linear filtering will smoothen your images when enlarged. They may get some blur but I've released a commercial game using this method.
All in all, i really think you should give it another shot. LibGdx will spare you a large amount of troubles and in my opinion; The request of yours ain't that hard to overtake.
Related
I plan to publish my unity game (a simple 2d game) on Android, Web and ios.
So, when I finish my project after testing in the web player, what do I have to consider
when publishing to all the platforms?
If my game is dimensions 900 px hight and 400 px width, will it fit in all screens when I publish
it for iOS and android.
Do I need to change some things?
I think this post might be of use to you: http://answers.unity3d.com/questions/660799/scale-camera-to-fit-screen-size.html
Overall, it really depends on how far you go. The easiest route to go would be letter-boxing. Keeping your game area the same size and then fitting the camera to the aspect ratio at start-up.
Obviously, this is a pretty common issue people come upon when porting their games, so there are tools made. I've never used it, but AspectRatioEnforcer looks like a pretty simple tool that will ensure your game is playable on any platform.
After implementing something, its always good to test it in the Unity editor, switching resolutions around and seeing what happens.
I am trying to write a libgdx livewallpaper (OpenGL ES 2.0) which will display a unique background image (non splittable into sprites).
I want to target tablets, so I need to somehow be able to display at least 1280x800 background image on top of which a lot more action will also happen, so I need it to render as fast as possible.
Now I have only basic knowledge both about libgdx and about opengl es, so I do not know what is the best way to approach this.
By googling I found some options:
split texture into smaller textures. It seems like GL_MAX_TEXTURE_SIZE on most devices is at least 1024x1024, but I do not want to hit max, so maybe I can use 512x512, but wouldn't that mean drawing a lot of tiles, rebinding many textures on every frame => low performance?
libgdx has GraphicsTileMaps which seems to be the tool to automate drawing tiles. But it also has support for many features (mapping info to tiles) that I do not need, maybe it would be better to use splitting by hand?
Again, the main point here is performance for me - because drawing background is expected to be the most basic thing, more animation will be on top of it!
And with tablet screen growing in size I expect soon I'll need to be able to comfortably render even bigger image sizes :)
Any advice is greatly appreciated! :)
Many tablets (and some celphones) support 2048 textures. Drawing it in one piece will be the fastest option. If you still need to be 100% sure, you can divide your background into 2 pieces whenever GL_MAX_TEXTURE happens to be smaller (640x400).
'Future' tables will surely support bigger textures, so don't worry so much about it.
For the actual drawing just create a libgdx mesh which uses VBOs whenever possible! ;)
Two things you dindn't mention will be very important to the performance. The texture filter (GL_NEAREST is the ugliest if you don't do a pixel perfect mapping, but the fastest), and the texture format (RGBA_8888 would be the best and slowest, you can downgrade it until it suits your needs - At least you can remove alpha, can't you?).
You can also research on compressed formats which will reduce the fillrate considerably!
I suggest you start coding something, and then tune the performance up. This particular problem you have is not that hard to optimize later.
I want to know the best way or a tool for making a good Android game!, I mean by "good" that the game must have a nice performance no lags or something like that, ..
So I will begin by 2D game development, and I want to avoid "Game engines"! ..
So what's the best way?! - to make it by Open GL ES or there another way?! ..
You should be able to learn a lot about open gl graphics programming by looking at Replica Island. Its an open source 2d Platform game which uses no engine.
The author gave some talks on Google IO which might be of interest to you:
http://www.youtube.com/watch?v=U4Bk5rmIpic
http://www.youtube.com/watch?v=7-62tRHLcHk
http://www.youtube.com/watch?v=cdvaPyq_eBU
It's possible that this is considered too broad a question - we can't tell you how to make a game. But in response to your last question: yes, OpenGL is the best way to make a high performance game in 2D or 3D. If you have a more slow moving, turn based game, then you could stick to a Canvas on a SurfaceView or even use basic View widgets to build up the layout of a game board.
But if it's your first game, unless you have a lot of time and patience, I would strongly urge you to try an existing game engine. You may not realise how much work goes into a decent game engine until you're halfway (or 10% of the way) into making one. Have a look at the source of an engine like LibGDX and think about whether it's the sort of thing you'd be able to write.
There's plenty of info in the Android graphics dev guide.
You do not need a game engine to develop a 2D game in Android. You do not need to use SurfaceView either. SurfaceView, OpenGL and AndEngine and (maybe other game engines) have issues with consistent sprite animation speed and size of sprites across the various Android devices. Especially when the game has complex sprite movements. I went crazy trying to build a 2D game with consistent speed movement of sprites and sprite sizes in relation to screen size and density (e.g. tablets vs phones). So, I decided to drop the game engines and this is how I accomplished my first recently published 2D Android game:
Use drawable-nodpi for sprite images (gives sprite size consistency
across screen densities and sizes)
Use different layouts to support various screen sizes (e.g.
layout-large, layout-xlarge, etc...)
Use TranslateAnimation and ObjectAnimator to animate sprite movements across screen
Use math to figure out sprites collision (e.g. screen coordinates and sprite location etc.)
Use handlers and condition statements to control the game events
You can test the outcome of following the above guide to developing a 2D Android game without game engine by checking out the game. It is called Yum Yum Pow available on Google Play. The free limited version is available also on Google Play. I can only link to free apps I think, so here it is:
https://play.google.com/store/apps/details?id=com.wildroid.yum.yum.pow.limited
If u are planning to build a simple game then stick with Basic android.If it is a big game,With out game engine your game developing will be a heavier process.if u want to use a lot of images then memmory problem will occur(OOM).if u are comfort with the game engine that will be easy for future game developing.if u are making a simple game then there is no need of game engines.
there are so many game engines available
andengine,libgdx,cocos2d..
I am a fairly "newb" Android developer, and I would like one of my first projects to be a live wallpaper, however I am conflicted on whether I should be focusing on Canvas or OpenGL for it. Being new to this I know I should master Canvas first since it is easier to use, but I prefer to learn from real world projects that I have an interest in, even if it's a little backwards at times.
I have used both before in very basic ways, and I understand the general concepts to them, but I am not sure how they transfer over to the realm of live wallpapers. I figure that the full blown speed of OpenGL isn't required on a live wallpaper, since running it at max FPS would just run down the battery more than it necessary, but at the same time I am worried that using Canvas would cause lags and stutters when doing things like changing home screens.
I have been leaning towards using OpenGL ES 2.0, both to keep performance optimal and because my initial ideas for the wallpaper involve a lot of layering that I am not sure Canvas is capable of, but I'd like a more experienced developers opinion on whether or not all of the extra work involved in using OpenGL (especially in relation to live wallpapers, from what I've read) is worth it.
If you can get away with just drawing to a canvas (e.g. cube example in SDK), that's much less work. Because of the simplicity of the animation (no bitmaps), the cube is able to achieve a high frame rate without difficulty.
If you want to use OpenGL, you will need to use a supplemental package, such as GLWallpaperService, AndEngine, or RenderScript.
http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers
http://www.andengine.org/forums/tutorials/live-wallpaper-template-t258.html
Browse the Android source code to see how the stock wallpapers (e.g. Grass, Galaxy) are implemented using RenderScript. This link may work, but no guarantees: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.1.1_r1/com/android/wallpaper/ (then scroll down to the wallpapers)
Moonblink has discontinued his project, but if you're really keen, you can try researching his work (Substrate) starting here: http://code.google.com/p/moonblink/source/browse/wiki/Setup.wiki
I ended up using OpenGL as halfway through the project, canvas drawing proved to be too slow for what I was trying to achieve. Using OpenGL caused a massive performance boost. Unfortunately I had to refactor my code, so I would reccomend using OpenGL from the start. Dirty rendering is supported by OpenGL as well as the wallpaperservice's structure doesn't rely on the way you render things so you would still be able to create a wallpaper that doesn't drain the battery. Actually a well programmed wallpaper doesn't render when it's hidden. As the wallpapers shipped with android don't follow that pattern, live wallpapers now have the bad name of being battery suckers. Really a shame..
To put some context, my game has been developped for android 1.5. So it was using the lowest resolution by default on any android phones. Which was great, game was running fast and all.
Now I added support for scoreloop which required my game to support android 1.6. When I runned the game I realized everything got smaller since I used unit dimension without looking at the screen density.
Now that I fixed sizing. I realize that my game seems a bit choppy. I believe that redrawing on the new screen resolution is the problem.
I draw my game in a Canvas in a SurfaceView. How can I make it faster? I use default functions like drawCircle, drawLine... I believe reducing the screen resolution should help since I don't need high screen resolution. I just don't know how or if it's possible.
Or may be doing my drawing in opengl would solve the problem too.
Read this : http://developer.android.com/guide/practices/screens_support.html
You should use the pixel format depending of your needs.