At the moment i can draw a route on a map.
On the map i can zoom and i can pan. If the route is very big it goes really slow.
Therefor i want to do it with OpenGl.
From the map i can convert coordinateToPixel and get the current zoom.
I thought it would be the best to base the translation and zoom on that for the transformation matrix.
I never worked with OpenGL before. I have been reading stuff for the last few hours but most stuff i read is outdated or goes into things i don't care about for now like shaders.
Can someone provide me with resources for simple stuff like on the image?
I never worked with OpenGL before.
You are asking a lot, and I do mean a lot, of work from yourself if you want to switch from using native iOS drawing methods to using an advanced real-time rendering system that you don't even know yet.
I agree with Brad Larson that you are going to go much further and faster by leveraging the tools in iOS for your purpose. However, that does not mean you can't improve performance while using them.
I have found that when using Core Graphics for complicated drawing, you can dramatically reduce the time it takes to render a drawing by drawing it on a background thread. And Apple makes it much much easier to learn and use Grand Central Dispatch than the time it would take you to do all of this in OpenGL.
I learned how to use dispatch queues also for the single purpose of making drawing go faster. The simple technique is to render in the background, then take the results to the main thread for displaying them. Since you already have your drawing code figured out, you won't have to do much extra work to take this extra step, and I think you will be impressed with the performance.
I saw an improvement of at least 5 - 10 times in drawing speed when I implemented Core Graphics drawing with dispatch queues. They are really awesome.
Related
My first question on StackOverflow. So feeling kind of shy ...
I've been working and tweaking on an curstom control for some weeks now. It uses ±6 subclassed CALayers for some fancy animations to give the best possible user-feedback. Additionally there are 2 animated UIViews adding up to some heavy animation and redrawing during user interaction.
I managed to get the responsiveness and performance on an iPhone 5S up to +50fps. But on a iPhone 4, it really makes me cry: 8 ~ 15fps. I tried to figure out what causes this awfull performance, but till now I found nothing other than the fact I might be wanting to much from Core Animation.
Using layer.drawsAsynchronously = YES; on all CALayers increased the responsiveness by A LOT. And I also took out all unnecessary animations (including implicit animations). But it still isn't enough. The performance on an iPhone 4 is still not the way I want it.
I notice a lot of improvement when I switch to layer.opaque = YES; But due to the design of my interface, this really isn't an option.
Is there anyting you guys can suggest to look into? Are there any other "magic" properties, like .drawsAsynchronously I might want to try or look into?
Are there any resources you can suggest on how to debug/analyse the performance?
Any help is appriciated. Thanks in advance!
The quickest answer will be don't use drawRect: because it's very expensive.
CALayers are the best way.
If you need to draw something complex is good to consider Core Graphics because it use GPU instead of CPU which is much more effective. You can draw image with Core Graphics and add it to the view.
Have a look on this link
There is good explanation how UIView works and how to write most efficient code
I am interested in roughly how megatextures are/could be implemented on iOS.
In particular I am making a 2D platformer with a large (non-tiled) background and I would like to have one (precalculated, unreasonably large) image that is mapped to the background. One option I have gone with is to chop the precalulated image into tiles, and load/unload in the background.
I am however curious about megatextures. It would be far more convenient to map these all to one surface. Are megatextures simply another way of phrasing what I am doing right now, or is something more cunning going on. Is there one superlarge texture on the graphics card with multiple gltexsubimage2d calls going on?
Megatexture is a well-developed and advanced implementation of clip-mapping technique: http://en.wikipedia.org/wiki/Clipmap
So yes, basically it is a continuous background loading of content to be displayed and unloading of currently unused content.
Is it even possible to continue rendering and updating while resizing the window so that it doesn't stretch?
This is pretty deeply baked into XNA's Game class's behaviour. I'm dealing with this exact problem now, but I don't have a good solution yet. EDIT: I how now found a solution - but it doesn't answer the bit about scaling - so I've posted it as a question/answer pair over here.
You could possibly dive in with reflection and disconnect the events that pause the game's timer when you start resizing (and unpause it when you stop). I haven't tried this yet, I'm a bit loathe to do it without understanding why they exist in the first place.
(Personally I am thinking of having my game subscribe to the resize start/end events as well, and then pumping Update myself on an appropriate timer until XNA comes back. I wasn't going to worry about the scaling of the display.)
One way to work around this problem is to replace the Game class entirely. The XNA WinForms Sample provides a suitable replacement - although you have to implement your own Draw/Update loop and timing. I've just tested this in an old level editor and it works just as you want when resized.
Although it does slow down quite a bit when you make the window larger, as it constantly re-allocates the backbuffer to make it bigger. You could replace that behaviour to make it over-allocate the backbuffer size, so it doesn't reallocate so often.
The underlying problem has something to do with win32, and is described in some detail in this thread on GameDev.net. But it doesn't really provide a satisfying solution either.
It might be interesting to note that the WinForms sample draws on its OnPaint method (and you get a loop by constantly calling Invalidate). Whereas XNA's built-in Game class subscribes to Application.Idle.
I've already published a 2D game on the App Store, but I've noticed that when I add too many objects, the fps drop down, and it's a quite simple game, so I believe it shouldn't happen.
So I think that I'm not rendering the graphics properly.
What should I use, OpenGL ES, Quartz 2D, ...?
I've been reading Apple's documents about OpenGL ES for iOS, but they hardly ever mention 2D, so I'm not sure if it can be used for this.
I'm now using Quartz 2D, (I guess it's UIView, UIImages, UIImageViews), but in fact, I'm not using the drawRect method of the views, ever. I create the images or graphics within the init function of the view, and a save them into a variable if I need to modify their properties later.
Any suggestion, recommendation, pdf would be highly appreciated! :)
PS: Here's a link to the game, if you want to have a better idea about it: http://itunes.apple.com/es/app/kipos/id494638587?mt=8
I recommend you use Cocos2D. Its features will make game development a lot easier for you. If you think you're up for a challenge, try OpenGL ES. I'll warn you though: it has a very steep learning curve.
I've been looking at a lot of iOS user interfaces that have been customized. I wonder, is it better to customize the UI using images or using libraries like CoreGraphics and Quartz, or is it on a per case basis, as in I use libs for some elements and images for others?
It is very hard to guess your particular situation. I can state that iOS gives us a lot of leverages to make any custom interface. I would use:
images for complicated graphic elements, buttons, icons, arrows, etc.
images + stretching to get complicated backgrounds/elements
custom drawing all that contain lines, ellipses, squares, lineral and/or circular gradients, simple image preprocessing, etc.
The key idea is - to find balance between memory usage and processing time. Note: from my experience - interfaces based on images which created by professional designer looks awesome.
Case-by-case basis. Images can be drawn more quickly but use more memory; custom drawing, whether via Core Graphics or Quartz, uses less memory but takes more time.
Case by case. If you want a lot of complex graphics that aren't lines and don't change much, use images. If you just need lines/gradients, or if you want things to move and morph, you'll need to use quartz.
It depends on you, as well. Would you rather write code for quartz for an hour and debug it, or would you rather spend an hour in photoshop? How fast are you at PS? Do you already know Quartz?
It depends on a lot of things, so "case-by-case".
Determine the complexity of each approach. (nontrivial) Icons are a good example of an image, while large gradients are a good use for drawing. Drawing can take some time/experience to get right, compared to graphic assets, but you can reuse that implementation later and use less memory in many cases (images can also use less memory - depending on what you're drawing). Complex static images can take time to render if drawn so... there are a number of things to consider in order to achieve the best balance. Using the gradient vs. image example, quality and time are also factors -- resizing/scaling a simple image can take a lot of CPU or have artifacts a rendered gradient would not have. Much of it comes down to experience, knowing the implementations you use well, and a lot of sampling/profiling to determine what is simple/complex/consumes a lot of memory, and so on.