For some time I'm creating simple google cardboard vr game. It's one of my first games so I probably dot know many things. My problem is that i was uing standard shader all the time, but recently I noticed that there is mobile shader available. Then when I was browsing through Unity's standard assets i found AutoMobileShaderSwitch script(I suppose it switches between shaders depending on the platform). The thing is that I have been using standard shader all the time and it worked just fine(on my phone).
Is there any reason to use this moblie shader in this case. Maybe it will increase performance sginificatly? Aleso do you know what shoul I do with this AutoMobileShaderSwitch script? Should I just attach it to any gameobject?
Usually what you do is to develop with standard shaders. Don't worry about mobile shaders until you are about to release for mobiles, then you switch the shaders to mobile. By doing this, you will know that the images you see during developing is the highest quality of what your game would look like.
Also, when making your game, always check for the framerate once in a while, on your mobile device. If it gets down to something you consider to be unacceptable for your game, then you can switch the shader to mobile and see if that makes a difference before spending time, optimizing you code.
And yes, mobile shaders will improve performance, especially when using transparent shaders. Mobile shaders are optimized for mobile devices. Basically, things were stripped out from them to make them faster and lighter on mobile devices. The down part of this is that some mobile shaders don't look good like the standard ones because things were removed.
Related
I hear that most of flash engines have problems on mobile devices except Starling Framework . But starling didn't feed all my needs as pathfinding and tilemaps tool that i can perfectly use with flixel. What engine/framework i could use with Air or starling framework without miss much fps? I need collisions, pathfinding and tilemaps support.
As of this date (May 22, 2012) you will have to wait for that. There is not a single engine that rolls all of the above into one easy-to-use package like Flixel. The team working on Flixel has anncounced the intent to make such a thing (http://www.photonstorm.com/archives/2524/looking-for-developers-to-help-build-a-new-game-framework) But to date it does not exist.
That said, you could build a game using Box2D and some implementation of pathfindting (like a*) and just use starling to render the game. You'll sink some time in setup, but its not impossible. Before stage 3D i did a similar approach for this game:
http://www.candystand.com/play/cougar-town
It uses box2D to manipulate graphics.
(minus the pathfindong of course)
I released the source code of a similar game on my blog here:
It uses the old display list. But you could see how it works and switch it to startling.
http://plasticsturgeon.com/2011/05/box-2d-2-1a-cannon-game-part-3-the-complete-game-source/
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..
Can I Use both Adobe Flash cs5 and OpenGL to create an application on an android OS4.3 device?
I am creating a 3D chess game compatible for an android OS 4.3, so I am using eclipse and the SDK obviously.
The problem I have now is I am meant to make the chess pieces human like. For instance, the pawn pieces should look like miniature foot soldiers and the king piece should be a figure of a person sitting on a throne etc. I started with OpenGL but because I am new to it, I might not be able to carry put displaying the graphics with OpenGL. So I decided to use adobe flash cs5 to create the pieces and use OpenGL to make the chess board because I can do that and also because in my specs, I said I would be using OpenGL.
I want to know if this will actually work and also if there is a much easier way of doing this I just haven't thought of. Any suggestions would be appreciated, especially how to implement this with the A.I.
If anyone has a sample or an idea I could work with, I will also be very grateful.
Adobe has said that "Stage 3D" support will be coming to mobile devices in the future, but in the meantime, there are not any ways to accelerate 3D with Adobe AIR.
Although Away3D or another 2.5D library would be fast enough for the web or desktop, I am not sure how well this will work for mobile, as AIR moves slow enough even for 2D games.
Since chess is a relatively static game, you might be able to create 3D graphics, then render to 2D sprites. I was the lead engineer for a large Facebook game, and we used this approach. ALthough it required more file size, it worked very well for quality and performance. The end result was something similar to Diablo 1, but in a cowboy theme instead of medieval.
Although it does not have true 3D support, yet, you might also consider looking into NME. That Facebook game I made ran at 5-6 FPS using Flash, but topped 30 FPS using NME on my old Palm Pre (so not the fastest phone in the world). That might help give you extra overhead to be able to lean into rich graphics. The framework will also publish as a true C++ NDK application, so it is actually possible to extend or modify the framework (it's open source) with your own OpenGL calls.
Here's the website if you're interested: http://www.haxenme.org
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..
I want to create a simulation game and a main component of this simulation will be a 2D map (topographical/navigation map), which shall have different layers (objects are moving on the map, using of labels, you get it)
The question for me is now, shall I use OpenGL to accomplish this or is that not necessary? I have no special requirements apart of that the scrolling and zooming shall be smooth. The target platform are only Android tablets (so Android OS 3.0+).
Edit: To precise my question:
platform independence is not important for me
I'd like to go with the easiest way concerning implementation efforts
If and only if you're really targeting Honeycomb specifically, then don't bother with OpenGL... and I say that as a reasonably experienced OpenGL programmer who's done some cool things with it on Android.
My reasoning is that, starting with Honeycomb, the normal Canvas-based APIs are hardware-accelerated too. Typically the only real reason for using OpenGL was greatly increaased performance, but that is no longer the case.
Or so the theory goes... I've yet to see actual Honeycomb hardware and run comparative tests. What I do know is that the Honeycomb emulator shows triangular tearing everywhere, strongly suggesting the whole desktop is now going through the GL pipeline.
If you have solid experience with OpenGL go with it. If not try some performance tests before you really decide if you invest time to learn it or if you use the good old simple 2D canvas drawing...
I'm not an expert on OpenGL + android (or any other mobile devices), but I think you will get better results (more FPSs, better drawing and animation options, etc) using OpenGL.
If you're used to non-OpenGL android development and are new to OpenGL it would be easier develop the game without using OpenGL. But before you choose this option, be aware that it should be a better option to use OpenGL if you aim to achieve beautiful/good performance graphics!
In short, if you master "regular" android development and prefer to build something good enough in a short time, stay "regular". Otherwise, I advice you to go for OpenGL.