I took a look on those 2 project that I found in here:
AndEngineJb2dJson
AndEngineRubeLoaderExtension
As some of you know I'm developing a rolling scene based game
I'm loading all the entities from a XML file and create them in the Loading Scene
recently I increase the game width , and by doing so , in the whole level I have about 500 entities (instead of 250+-)
But this cause a performance problems , the game is "Lagging" \ "jumping" and everything move slow.
My question is , if those Rube Loaders support performance issues , do some improvement
or its just like the normal andengine loader , that I need to manually load each entity in the XML \ JSON
Does anyone develop a rolling scene based game with the same amount +- of entities and tell me what it the correct way to implement it?
Thanks
As you don't really provide much detail about your specific implementation I will just provide you with a generic way of handling a game of this type.
First, you need to define an "active" area for your game world - this would be the area of the world that needs to be simulated (i.e. the entities in this area will move and interact with the world).
Your world layout might look something like this:
In this example your world is the grey block and extends beyond the screen boundaries (which is the black frame). The red frame indicates the active area - notice that it extends beyond the size of the display, but does not cover the entire world. The size of this area will depend on your specific implementation/needs.
The active area will generally move along with your player and hence can easily be represented as distance from player (in two directions).
The basic idea is that the entities (in blue) are only simulated while they are inside the active area. All entities to the right of the active area should be inactive until they enter it, at which point their simulation can start - for this reason, the active area should extend some amount to the right of the display area so that entities have some initial time to run their simulation before being displayed. Once the entities leave the active area (to the left) they can stop their simulation - and be removed if needed.
So in the example image:
E1 is has already gone through the active area and is no longer needed (it can be disabled/removed)
E2 is active and visible (currently displayed)
E3 is active but not visible yet
E4 and E5 is not active yet and will only become active once they enter the active area as the player gets closer to them
As for how to handle the entities, that depends on the size of the world, the number of entities, etc.
One way is to create/load the entities once they enter the active area - in which case it should extend far enough to the right of the display so that they have enough time to be created/loaded before entering the display area. This is the best approach for large worlds where there may be thousands of entities. In this case you may also need some kind of subdivision for your world so that you can exclude large amounts of entities from processing without checking each one - a array of fixed sized "blocks", each containing the entities that are within it, would work fine in most cases for a simple 2D side-scroller.
Another approach is to load all objects at the start and only perform simulation updates (such as physics, movement, collision detection) for them once they enter the active area. This approach works great for smaller worlds and provides an easier implementation.
Related
I'm working on an app where I must have on a part of the screen an animated music staff. That's:
5 static lines
A dozen of music notes (each one is basically an oval and a line)
A few additional symbols (clefs)
I must have a precise control of the size of each element, and have to smoothly animate position and alpha of the notes and clefs so the notes are moving right to left (disappearing when on the left of the screen, and appearing when on the right, hence the alpha). I also have to change sometimes the color of the notes.
I think I can't use standard "Animations" class, as it's an endless animation with the speed and the notes depending on real time factors.
So what is/are the best way(s) to do that and to achieve a smooth animation?
Different Views? (VectorDrawables?) Single SurfaceView where I manually draw each shape at each frame? (or TextureView?)
(Note: minimum API is set to 15)
Thank you for helping me choosing the right technique.
So you're wrong about the Animations class being infinite. It doesn't need to be. However EVERYTHING in Android will depend on real life factors- Android is not a RTOS (real time OS), there is no guarantee of execution time.
However, if you absolutely need total control, I would just jump to total control- hook the Choreographer so you get a call every 1/60th of a second, and each frame invalidate your view(s) that need to change and redraw them. If the phone is running slow for some reasons like other apps you may drop a frame or run slightly slower than 1/60th of a second, but this is as close as you can get (and what Animation classes use behind the scenes).
With animators you can animate smoothly around 5 different views on average phone. So in your case (with dozen of notes and so on) it will have around 10fps. So slightly better will be SurfaceView and handdrawing all that you want. Maybe GLSurfaceView worth considering.
In order to test this I recommend you to create some test app first, where will be 10 views flying around, and look at performance.
(Just to be clear I'm asking for guideance not for someone to program this whole thing(unless they want to XD))
Hi, I'm currently trying to make a game for android in which you can build a map out of blocks(there are several types but we'll just use walls here).
The map is going to be 100x20 blocks, in which the players can put any of the blocks available inside in any order, and it's going to be stored as a text file "Let's call it "mapFile""(this part I've already solved) in which 0's would be nothing and 1's would be walls.
Now, the problem is that when you start playing the map, the game will have to load all the blocks to make the obstacles, but I want it to do it in a specific way (mainly to make the game go smoother and doesn't have to check 2000 blocks every update):
-make groups of blocks(lines, squares, rectangles) as 1 obstacle so there os only 1 collision detection in a large amount of blocks(the difficult part is to divide a complex shape in the best way)
-divide the map into 5x5 chunks so it doesn't have to check every obstacle in order to see if it should be drawn(it would just draw the chunk in which the player is in and the ones surrounding it)
The output from this should be a 4 levels array(or something similar):
Array[Ychunk][Xchunk][obstacle][x,y,xBlocks,yBlocks,type]
(Type is just the num of the block in the map(in this case it's 1 because it's the number for wall in my app)
For now the game has:
-An array with all the obstacles info (x,y,xBlocks,yBlocks,type)
-Only updates obstacles if they are a small distance from the player(still has to check them all)
-Only draws obstacles that are inside the window(also has to check them all)
Firstly, You don't need an array with all the map info, what you need is a 2D array of tiles. The tile object will contain all the info like the image, isSolid, etc.
Secondly, You will always have the player visible, so that acts as your anchor, Only show the tiles around your player and render that to the screen. Its makes no sense to render the tiles that will not be rendered on the screen e.g., If the player is at the center and the screen renders 5x5 tiles then +/- 2 tiles of the player tile. Same goes for checking if the tile is visible No, need to check all
Lastly, Again you don't need to check the player collision with all the obstacles, only need to check collision with the tile that the player is going to move on.
Hope it helps.
I'd like to create a custom map. It should be or look like one picture, but according to the part of which the user clicks, it should move the user to a different location (i.e. start a different activity). I've seen it done in several games but I don't know how to do it myself.
The part of the picture should have non-geometrical borders (obviously it would be easily done with many square images). Sadly, I don't even know what term describes what I want to do so I wasn't able to find any helpful tutorials or discussed topics.
Example:
Picture: http://i236.photobucket.com/albums/ff40/iathen/mapEx.png
If the user touches the purple slide, (s)he should be leaded to activity_1
If the user touches the blue slide, (s)he should be leaded to activity_2
If the user touches the green slide, (s)he should be leaded to activity_3
In my experience there are 2 main (most used) ways to achieve this.
The first (my favorite):
Get the data from a PNG
You should write multiple layers to a canvas. These layers constitute your "zones" (blue, green, purple in the image). To obtain the data of these areas, you get it from PNGs (with transparencies off course) to write the canvas with whatever you want. You must store the values where there can be a tap from the user (non-transparent areas). Notice that this values can be scaled up/down depending on the map size, screen resolution, map dimensions, etc.
Once you've written the layers to the canvas you should check for a match of the user tap and the stored areas you have. You should take into consideration here the order in which the user tap is processed in your code. For instance, in your image, the purple layer is on top so it must be processed first, the blue as second, and the green as the last one. This way you can have an "island" inside a bigger area.
The second way:
Generate the boundaries programmaticaly
I think this solution is self-explanatory. The only I've faced with this variant is that when the surfaces boundaries get messy, it's really complicated to generate the proper equations.
EDIT:
Using the first approach you can employ multiple PNGs to load data or use a single PNG with data coded into the bytes (i.e. RGB values). It's up to you to decide which one to implement.
Hope it helps!
Since a touchscreen itself isn't very accurate, your collision detection for the buttons doesn't need to be either. It would be a waste of time to try to make a complicated collision detection algorithm to detect a touch within those weird shapes.
Since you are making a game, I assume you know how to handle custom touch events, as well as canvas (at least). There are many ways to do what you want, but in the specific example image you linked is kind of a special case.
You could create a giant bounding circle around the three blobs, and then check if the user touched within the bounds of the circle (ie check if the distance from the touch to the center of the circle is less than or equal to the radius). Once you determine that it is, you could check which section of the circle it falls into by splitting it up into 3 equal sections. Requires some math, but shouldn't be that complicated.
It wouldn't be a perfect solution, but it should be good enough. Although, you might have to change the buttons a little so they aren't so stretched out horizontally, otherwise a bounding circle wouldn't be ideal.
Personally, in my games I always have "nodes" that represent the visual elements of the game, such as buttons. Instead of using a large image like you are doing, I would create separate images for each button, and then check their collisions with touch events independently. That way I could have each button check with their own individual bounding circles, or, if absolutely necessary, I could even have custom algorithms for each individual button.
These aren't perfect solutions. If you do want a pixel-perfect solution, you'll need to implement some polygon collision detection algorithms
One thing to consider is screen size and ratio. The only constants you should use are for percentages.
Currently I am doing app allowing user to draw. Simple think, just extend Canvas class and most of the thing is done.
That was my initial thinking and idea. But as the canvas is rather small because this is only what user see on the screen there is not much possible space to draw. Going through documentation I found translate() method allowing me to move canvas. What I did find out is when I move it, there is some kind of blank space just as you would move piece of paper. I understand that this is totally normal, as I've said before - canvas is only "the screen".
My question is - is there a possibility to make something like infinite canvas so you can make a huge painting and move everything around?
Before this question I was thinking about two things how something like this can be done:
Move all objects on canvas simultaneously - bad idea, because if you have a lot of them then the speed of moving is very bad.
Do something similar as it is done in ListView when you move it (or better see on the screen) only views that are on the screen together with one before and one after are loaded to memory and rest is uploaded dynamically when needed. I think this is the best option to achieve this goal.
EDIT:
Question/answer given by Kai showed me that it is worth to edit my question to clarify some of the things.
Basic assumptions about what can be done by user:
User is given opportunity to draw only circles and rectangles with some (around 80%) having drawable (bitmap) on them on canvas.
I assume that on all screens there will be maximum 500-800 rectangles or circles.
First of all thinking about infinity I was thinking about quite big number of screens - at least 30 on zoom 1x in each side. I just need to give my users bigger freedom in what they are doing.
On this screen everything can be done as on normal - draw, scale (TouchListener, ScaleListener, DoubleTapListener). When talking about scaling, there is another thing that has to be concerned and connected with "infinity" of canvas. When user is zooming out then screens, or more precise objects on the invisible "neighbours" should appear with proper scaling as you would zoom out camera in real life.
The other thing that I've just realised is possibility of drawing at small zoom level - that is on two or three screens and then zooming in - I suppose it should cut and recalculate it as a smaller part.
I would like to support devices at least from API 10 and not only high-end.
The question about time is the most crucial. I want everything to be as smooth as possible, so user wouldn't know that new canvas is being created each time.
I think it really depends on a number of things:
The complexity of this "infinite canvas": how "infinite" would it really be, what operations can be done on it, etc
The devices that you want to support
The amount of time/resource you wish to spend on it
If there are really not that many objects/commands to be drawn and you don't plan to support older/lower end phones, then you can get away with just draw everything. The gfx system would do the checking and only draws what would actually be shown, so you only waste some time to send commands pass JNI boundary to the gfx system and the associated rect check.
If you decided that you needs a more efficient method, you can store all the gfx objects' positions in 4 tree structures, so when you search the upper-left/upper-right/lower-left/lower-right "window" that the screen should show, it'll fast to find the gfx objects that intersects this window and then only draw those.
[Edit]
First of all thinking about infinity I was thinking about quite big
number of screens - at least 30 on zoom 1x in each side. I just need
to give my users bigger freedom in what they are doing.
If you just story the relative position of canvas objects, there's practically no limit on the size of your canvas, but may have to provide a button to take users to some point on canvas that they are familiar lest they got themselves lost.
When talking about scaling, there is another thing that has to be
concerned and connected with "infinity" of canvas. When user is
zooming out then screens, or more precise objects on the invisible
"neighbours" should appear with proper scaling as you would zoom out
camera in real life.
If you store canvas objects in a "virtual space", and using a "translation factor" to translate objects from virtual space to screen space then things like zoom-in/out would be quite trivial, something like
screenObj.left=obj.left*transFactor-offsetX;
screenObj.right=obj.right*transFactor-offsetX;
screenObj.top=obj.top*transFactor-offsetY;
screenObj.bottom=obj.bottom*transFactor-offsetY;
//draw screenObj
As an example here's a screenshot of my movie-booking app:
The lower window shows all the seats of a movie theater, and the upper window is a zoomed-in view of the same theater. They are implemented as two instances of the same SurfaceView class, besides user input handling, the only difference is that the upper one applies the above-mentioned "translation factor".
I assume that on all screens there will be maximum 500-800 rectangles
or circles.
It is actually not too bad. Reading your edit, I think a potentially bigger issue would be if an user adds a large number of objects to the same portion of your canvas. Then it wouldn't matter if you only draw the objects that are actually shown and nothing else - you'd still get bad FPS since the GPU's fill-rate is saturated.
So there are actually two potential sources of issues:
Too many draw commands (if drawing everything on canvas instead of just drawing visible ones)
Too many large objects in the same part of the screen (eats up GPU fill-rate)
The two issues requires very different strategy (1st one using tree structures to sort objects, 2nd one using dynamically generated Bitmap cache). Since how users use your app are likely to different than how you envisioned it to be, I would strongly recommend implementing the functions without the above optimizations, try to get as many people as possible to do testing, and then apply optimizations to each of the bottlenecks you encounter until the satisfactory performance is achieved.
[Edit 2]
Actually with just 500~800 objects, you can just calculate the position of all the objects, and then check to see if they are visible on screen, you don't even really need to use some fancy data structures like a tree with its own overheads.
I am developing an OpenGL Android Game and I am right now dealing with the User Input.
I have two main ideas for implementing it. The two of them I think that they work perfectly but I do not know which one is "better" (in performance/speed).
The basics are that there are several "buttons" drawn in Opengl (such as four arrow keys, action button...) on some specific positions around the screen. These buttons do not change of place during gameplay.
FIRST IDEA
My first implementation was to create a 2D-matrix with references to each button. Something like:
InputObject matrix = new InputObject[Width_of_screen][Height_of_screen]
At the loading stage each button inserts in the Matrix its references for each pixel where they appear.
So each time the user touches the screen I can look directly on the matrix which button he has clicked (with e.getX() and e.getY()).
Pros: "Fast" to know which button to call.
Cons: (At common screens) 800*480 ~ 300K references, with 80% of them being null (But memory heap already taken)
SECOND IDEA
My second plan is to make an ArrayList of the Input Objects and ask each one if its theirs. Something like:
for(InputObject ob : TheArrayList){
if (ob.for_him(e.getX(),e.getY())){
ob.do_it();
break; //They cannot overlap
}
}
Pros: Less heap space taken (no null references at all...)
Cons: Have to detect for each object if its for itself, so they need to do comparisons on for_him method. Taking more CPU time.
With these said, which one may be the best idea for Android Phones (and other Smartphones) due to having not much processor time for user input.
If there is a third and best approach please I would love to know about it.
Thanks in advance.