I want to make an endless vertical scrolling layer that gives the impression that the main character is moving upwards. I have been brainstorming on how to achieve this.
My issue is that I want objects to appear as if they are coming from above and below the screen at the same time. Secondly, I want to be able to move the main character to create and destroy box2d joints between it and some of the objects appearing on the screen. What is the best way to achieve this with consuming too much memory? I would appreciate any help on this.
Apple did a wonderful tutorial of this in a WWDC 2011 video session. It was "UITableView Changes, Tips & Tricks" and it's about 35m40sec into the video.
Since the use of the UITableView is really just a UIScrollView for the purposes of the background, you could just use a UIScrollView and you can either have it move on timer or events as needed.
Think of your player as moving within a stationary bounding box. The background can scroll using the aforementioned pooling method (as the background tile scrolls off the screen it is placed into a pool, and before a new tile is instantiated the pool is checked for available reusable tiles). Thirdly, your enemy objects will simply approach from either the bottom of the screen or the top.
Imagine your idea without the scrolling background (flying effect) and you should find that the problem is relatively straightforward.
I also needed and endless scrolling background layer. This can do exactly that, and it is super simple to set up and use. Just copy the four files in to the cocos2d folder in your project, then follow the quick tutorial seen on the github. Make sure the image you use is seamless (when you line them up vertically you can't tell where one ends.
Related
I am working on an app in which I need to have the ability to tap and drag UILabels around. The second challenge is that I need the other UILabels on the screen to move out of each others way (never overlap). So as I drag one label and run into another, it bumps the second out of the way. Perhaps an important note is that each label will be random rotations as well.
I am sorry but I don't really have any code to share because I am not sure where to start with collision detection of this sort.
Perhaps CGRectIntersectRect() ?
Learn to use Cocos2d, you can set layers for images for your overlapping problem. You can create your own labels and just set their position to accelerate towards where the user touched, or customize this however you want.
Also with the collision detection, this would be easy to implement in Cocos2d.
I am developing a game for iPhone and I came across a question whether this can be done using UIAnimation or I have to switch to OpenGL.
If you see the picture above, you can realize there is a rectangle (it will have background image) having many holes in it. User is supposed to touch on holes and initiate the animation. The holes are actually on the image and are not some view. Do you know any article or tutorial I need to read in order to understand this can be done using UIAnimation?
It's more like chess. When you tap a hole, there is a view placed and moved at z-axis and then when you press the other hole, the view is moved to that hole and so on.
I believe it can be done with UIViews too. The holes can be made by using an image with "transparent" holes in it. You can place this UIView on top of a background image(if required). When touches are detected, you can animate another view on top of this view using addSubview:. You can keep this other view outside the screen bounds initially so that the animation seems like a sliding animation.
yes UIView is also an option in your case. if you feel that you will use high quality lots of graphic and will do lots of animation stuff at once on the screen, openGL will be the best or perhaps the gane you are making is a 2d game so you must consider COCOS2D "http://www.cocos2d-iphone.org/" for kick starting your game you'll surely get many effects and other glittering stuff with it. and bes of all it is openGL based..!! Performance will be too high for you..!!
Best of luck..!!
I am in process of creating a multiplayer game similar to the Scrabble / Wordfued / Rummi. I am trying to see what would be best way go about implementing the UI and their interactions.
I would be having a framework which would keep track of all the pieces on the board and the AI for knowing if it is a valid move.
I am trying to figure out what could be best solution to handle the UI part. The game board would be larger than would the current iPhone screen could support. So the board would have an effect of a scroll view. The same goes for the game tiles using which user can play. These are not fixed amount of tiles/cards and the same could be more in numbers which would also need another scroll view kind of effect.
There would be many more effect's were the user can move a complete set of tiles/cards from the board and place it in another location of the board. Or even a tile in between the set of tiles on the board.
So I am trying so see if I should go with two scroll view provided by iOS and handle all the detaching the tile/card from one scroll view and placing the same in GameBoard scroll view
Or
Should I go with something like cocos-2d which provides more advance game UI handling capabilities.
Please do let me know your thoughts and feedback on what could be the best choice for the same. Thanks in advance for all your help.
Words With Friends uses native UIKit views. It is quite simple and uses a transition to move between the two degrees of magnification (close up and not close up).
You can do everything quickly in UIKit with a UIScrollview. You can use drag events to move tiles around the screen, even changing their perspective/look during dragging. Using UIAnimation would allow you to do simple frame based animation for things like dropping a tile.
Cocos2d will be quicker if you already know a similar gaming library. However if you choose it you you'll miss out on using Interface Builder and a lot of conveniences in UIKit.
If you're starting from a base of zero with either approach, then only use Cocos2d if you want particle effects (like stars and sparkles, UIKit has nothing for this).
Otherwise I'd say try UIKit, it's easier and there are more resources on the web.
I am working on a sample in which I have placed two textures one above the other. What I want, whenever user moves his finger on the screen, underneath view should get revealed as he moves. Wiping out front view to reveal underneath view is what I am looking for.
I would like to know some of ideas/ thoughts to implement this feature using OpenGL ES. Any related pointer will be highly appreciated.
Thanks in advance.
This does not sound performance-intensive so simple code can trump complicated tuned operations.
You don't need to use OpenGL. You can simply have two images - front and back - with the front supporting an alpha channel. Each time you get a hit or move, you clear a circular patch whereever the impact is for some certain radius or such.
And then queue-up a redraw. The redraw draws the two bitmaps, back first then front.
If possible, try to queue a redraw for just the the area where you have updated the front since the last draw.
I'm trying to make a level-of-detail line chart, where the user can zoom in/out horizontally by using two fingers, and grow the contentSize attribute of the the UIScrollView field. They can also scroll horizontally to shift left or right and see more of the chart (check any stock on Google Finance charts to get an idea of what I'm talking about). Potentially, the scroll view could grow to up to 100x its original size, as the user is zooming in.
My questions are:
- Has anyone had any experience with UIScrollViews that have such large contentSize restrictions? Will it work?
- The view for the scroll view could potentially be really huge, since the user is zooming in. How is this handled in memory?
- Just a thought, but would it be possible to use UITableViewCells, oriented to scroll horizontally, to page in/out the data?
This is kind of an open ended question right now - I'm still brainstorming myself. If anyone has any ideas or has implemented such a thing before, please respond with your experience. Thanks!
This is quite an old topic, but still I want to share some my experiences.
Using such a large UIView (100x than its origin size) in UIScrollView could cause Memory Warning. You should avoid render the entire UIView at once.
A better way to implement this is to render the only area which you can see and the area just around it. So, UIViewScroll can scroll within this area smoothly. But what if user scrolled out of the area that has been rendered? Use delegate to get notified when user scroll out of the pre-rendered area and try to render the new area which is going to be showed.
The basic idea under this implementation is to use 9 UIViews (or more) to tile a bigger area, when user scrolled (or moved) from old position to new position. Just move some UIViews to new place to make sure that one of UIView is the main view which you can see mostly, and other 8 UIViews are just around it.
Hope it is useful.
I have something similar, although probably not to the size your talking about. The UIScrollView isn't a problem. The problem is that if you're drawing UIViews on it (rather than drawing lines yourself) UIViews that are well, well off the screen continue to exist in memory. If you're actually drawing the lines by creating your own UIView and responding to drawRect, it's fine.
Assuming that you're a reasonably experienced programmer, getting a big scroll view working that draws pars of the chart is only a days work, so my recommendation would be to create a prototype for it, and run the prototype under the object allocations tool and see if that indicates any problems.
Sorry for the vagueness of my answer; it's a brainstorming question
But still, this approach (in the example above) is not good enough in some cases. Cause we only rendered a limited area in the UIScrollView.
User can use different gestures in UIScrollView: drag or fling. With drag, the pre-rendered 8 small UIViews is enough for covering the scrolling area in most of the case. But with flinging, UIScrollView could scroll over a very large area when user made a quick movement, and this area is totally blank (cause we didn't render it) while scrolling. Even we can display the right content after the UIScrollView stops scrolling, the blank during scrolling isn't very UI friendly to user.
For some apps, this is Ok, for example Google map. Since the data couldn't be downloaded immediately. Waiting before downloading is reasonable.
But if the data is local, we should eliminate this blank area as possible as we can. So, pre-render the area that is going to be scrolled is crucial. Unlike UITableView, UIScrollView doesn't have the ability to tell us which cell is going to be displayed and which cell is going to be recycled. So, we have to do it ourselves. Method [UIScrollViewDelegate scrollViewWillEndDragging:withVelocity:targetContentOffset:] will be called when UIScrollView starts to decelerating (actually, scrollViewWillBeginDecelerating is the method been called before decelerating, but in this method we don't know the information about what content will be displayed or scrolled). So based on the UIScrollView.contentOffset.x and parameter targetContentOffset, we can know exactly where the UIScrollView starts and where the UIScrollView will stop, then pre-render this area to makes the scrolling more smoothly.