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.
Related
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.
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 want to create a 360 degree turntable showing lots of pictures (12, 24 or 36) by controlling that rotation with touch events (like that example but coded for an iOS app natively).
The simplest idea depending on the touch position is to load that specific uiimage.
Any ideas what's the best practice for that? Is there a chance to create that image-turntable with the help of coreanimation faster? Any other hints on that? Any other projects known where I can get some help on that?
Thanks for your time and hints in the right direction.
Here's another example for an ipad-app from the "audi a8".
From the first example it becomes obvious that the objects have actually been photographed for each angle of rotation. This is the really tricky part. You will need a tripod and a camera with remote control, and if possible also a rotational platter to keep angles consistent.
Implementation is relatively straightforward. As you guessed, you just track the touch positions and, depending on delta to the last touch position, show the appropriate image.
well, you can just use the HTML/CSS/JS used in the same example... just load that in an UIWebView in your app and load your site embedded as a resource...
Subclass UIImageView, load array of your frames, handle tap movement over the screen y-axis and change active image accordingly. Don't forget to loop your images. :)
I hardly know how to explain my case other than to point to the excellent Absolute vodka app, Drink Spiration.
I am trying to make a carousel like image browsing with a little spice. I would really like to find a simple core animation explanation on how to accomplish something like the above app.
I hope someone can help with this. The solution doesn't have to be exactly the same, but just explain what is happening and it would be best if it was simple and no opengl. Just something to point me in the right direction. I don't think using just a scrollview with uiimageviews is enough.
I wrote something similar and its quite easy once you figure it out in your mind. All done justing using regular old views and animating transforms on them.
Say its 3 images on screen, and you can rotate new ones on and off ... then you will need 5 views set up (most simply just a UIImageView with a relevant image set). They are the currently selected image, the two either side of it and the ones that are, or will be animating on or off when the user flicks left or right.
Each of these 5 images has a position, an angle and an image. When the user flicks left or right each gets animated to the next position and angle, views that are about to come onscreen have their image updated to the next image in the set. If the user keeps on flicking in the same direction you simply reposition views on one side as they come off the other.
With this setup you can do lots of cool carousel like things very simply.
I'm working on an iPhone OS app whose primary view is a 2-D OpenGL view (this is a subclass of Apple's EAGLView class, basically setting up an ortho-projected 2D environment) that the user interacts with directly.
Sometimes (not at all times) I'd like to render some controls on top of this baseline GL view-- think like a Heads-Up Display. Note that the baseline view underneath may be scrolling/animating while controls should appear to be fixed on the screen above.
I'm good with Cocoa views in general, and I'm pretty good with CoreGraphics, but I'm green with Open GL, and the EAGLView's operations (and its relationship to CALayers) is fairly opaque to me. I'm not sure how to mix in other elements most effectively (read: best performance, least hassle, etc). I know that in a pinch, I can create and keep around geometry for all the other controls, and render those on top of my baseline geometry every time I paint/swap, and thus just keep everything the user sees on one single view. But I'm less certain about other techniques, such as having another view on top (UIKit/CG or GL?) or somehow creating other layers in my single view, etc.
If people would be so kind to write up some brief observations if they've travelled these roads before, or at least point me to documentation or existing discussion on this issue, I'd greatly appreciate it.
Thanks.
Create your animated view as normal. Render it to a render target. What does this mean? Well, usually, when you 'draw' the polygons to the screen, you're actually doing it to a normal surface (the primary surface), that just so happens to be the one that eventually goes to the screen. Instead of rendering to the screen surface, you can render to any old surface.
Now, your HUD. Will this be exactly the same all the time or will it change? Will only bits of it change?
If all of it changes, you'll need to keep all the HUD geometry and textures in memory, and will have to render them onto your 'scrolling' surface as normal. You can them apply this final, composite render to the screen. I wouldn't worry too much about hassle and performance here -- the HUD can hardly be as complex as the background. You'll have a few textures quads at most?
If all of the hud is static, then you can render it to a separate surface when your app starts, then each frame render from that surface onto the animated surface you're drawing each frame. This way you can unload all the HUD geom and textures right at the start. Of course, it might be the case that the surface takes up more memory -- it depends on what resources your app needs most.
If your had half changes and half not, then technically, you can pre-render the static parts and then render the other parts as you're going along, but this is more hassle than the other two options.
Your two main options depend on the dynamicness of the HUD. If it moves, you will need to redraw it onto your scene every frame. It sucks, but I can hardly imagine that geometry is complex compared to the rest of it. If it's static, you can pre-render and just alpha blend one surface onto another before sending to the screen.
As I said, it all depends on what resources your app will have spare.